A T Week schedule typically rolls from week to week and never completes. That in combination with the fact that most customers use an interim status such as Field Complete as a synonym of In Progress to drop activities off of the schedule means the normal schedule compliance tools inside of Scheduler can’t really be used effectively. Most customers also track different codes related to schedule adherence. It is common to have to supply a code as to why an activity was deferred. It is also common to capture a code as to why an activity broke into the schedule during T-0. This blog will describe mechanisms that can be used to address each of these challenges.
First off is compliance. How do you capture a baseline of activities that has been agreed to be performed and monitor adherence. One approach is to use the configuration tools to create a set of Escalations, Automation Scripts and Reports to leverage the capabilities in Scheduler in a standardized fashion. Scheduler has a snapshot capability to capture a complete replica of the schedule as it currently exists. An automation script can be created to invoke the snapshot feature and a standardized naming convention such as 242020 for week 24 in the year 2020. This creates a set of activities in the Scheduler activities table to measure against for compliance. The automation script would be invoked by an escalation set to run when the T-0 schedule is locked in, usually the Sunday before execution week. Some customers might also change the status of the Work Order as well to denote that it has been committed to a T-0 schedule for execution. Some additional configuration to limit access or edit rights of snapshots may be required.
Each activity in the Scheduler activity table has a pointer back to the Project/Version table to link it to a specific week snapshot. It also has a snapshot of key data related to the activity such as schedule start/finish, duration, status and a pointer back to the originating activity, mostly Work Orders in this case. A report would be used to compare the activities in T-0 with the current status/status history of those Work Orders to determine if they were completed as scheduled. Your organization would develop the rules for what constitutes adherence and what doesn’t and they would be built into the report as such. Using the status history, the report could be parameter driven to prompt the user for the Schedule ID, week and year and could be run at any time for any given week.
Adding the Detail
Next step is to provide more detailed reporting around schedule non-compliance, namely deferred or break-in work. Most customers add fields to the Work Order table to capture deferral or break-in reasons. Then the question comes up about an activity that may have been deferred multiple times. This could be monitored with eAudit but depending on the other fields being audited, reporting could be complicated. Another alternative is to track the data in a child table to allow reporting on how many times an activity has been deferred and for what reasons. The snapshot referenced above also gives us a population of activities that should have a deferral or break-in code but haven’t been update yet (maybe a start center result set).
The key is to be able to capture this data without it being an administrative burden. For example, in the power generation industry, depending on the weather and capacity, there may be little margin on the amount of power that can be produced versus the current demand. In some cases, the dispatcher might declare a “no touch” week meaning no elective work should be done in plant to reduce the risk of taking the unit offline. Another situation is the unit unexpectedly comes offline and all of the scheduled work is now deferred to focus on break-in work to return the unit to service. How can we effectively update these large groups of activities with the appropriate deferral or break-in code without having to update each one individually.
How to Approach Mass Updates
Scheduler has a built in right click action in the Gantt view called Modify Work Order Details that raises a dialog of key Work Order information. You can select one or multiple records from the Gantt view and invoke the dialog. The list of Work orders appears at the top and fields below that can be updated or cleared. This allows for mass updates on multiple records.
The key information listed in bottom half of the screen is configurable. This means that the deferral or break-in codes that customers typically add can be added to the dialog. IBM has an instruction guide at https://www.ibm.com/support/pages/node/1133193 that describes the process. Once configured, you can select an entire group of activities that needs to be deferred and/or break into the schedule and perform a mass update to efficiently update the Work Order.
This works well when the fields are directly in the Work Order table but there is still the issue of the child table for multiple deferrals. One approach taken is to add the child deferral table to the Work Order Tracking screen so a user can Add Row if they are deferring a single Work Order at a time. The deferral code fields are also added to the Work Order table, just not displayed in the application screen. The only way to update these fields is by using the Modify Work Order Details function in Scheduler. An automation script is attached to the fields such that on update, they create an associated row in the child table (a focused audit of sorts). This allows mass updates for deferrals and updates the child table for reporting on multiple
Read the previous posts in this series of Scheduler blogs here.