In previous posts, I’ve written about how rescheduling—rather than creating the original schedule–is the main job of any operations manager. How many times has a set schedule played out exactly as planned? It’s probably the rare occasion. This need is really the result of two things happening in real time:
- The production capacity in the last scheduling run did not match the production capability achieved, and/or
- There is a change in the demand profile or project requirements.
Examples of these are obvious. Someone didn’t show up for work; something broke; results didn’t meet quality standards and work must be redone; circumstances have altered production priorities, and so on. Murphy must have been a production manager when he uttered his first law: “If things can go wrong, they will.”
If this is the case, then the ability and ease of a “manufacturing execution system” (MES) to be able to tweak a schedule—in real time, and sometimes multiple times–is paramount. Thus, if you acquire or have a scheduling application that doesn’t support rescheduling very well, you have a mess, not an MES.
Stepping back for a moment, consider the actions needed to achieve an optimal manufacturing or project management scenario. A scheduling system must:
- Collect accurate and frequent status from the shop floor or jobsite;
- Compare the actual schedule status with the expected status;
- Determine if the difference is significant enough to warrant rescheduling;
- Determine how the originally-scheduled activities must be modified, if necessary;
- Integrate the new demand with the modified activities to create a new demand profile;
- Unschedule some activities and put them in the hopper with the new demand profile; and
- Perform the rescheduling;
… and back to step #1 again.
I’d be willing to bet most MES applications support step #1. Production line sensors, tablets and smart phones enable quick reporting of production status. A few systems even support parts of step #2. However, it’s surprising how few scheduling applications determine what should have been produced at the time the actual production is recorded.
Step #4 usually requires that activities defined in the scheduler be split at the point where planned production just matches reality. The tail that’s chopped off must be reconfigured as a new activity to be scheduled using different resources or extended run times. The relationship of this new activity to the original truncated activity must be maintained. Can your scheduling AP split activities appropriately?
Step #5 is a re-prioritization task. How does the importance of finishing something compare to producing a new order or attending to an updated demand profile?
Step #6 is a critical task. A good rescheduler will be able to find all tasks downstream from a given time point that are impacted by shop-floor deviations. Both routing and resource sharing logic must be examined to determine how much of the schedule must be revised. Unscheduling too many downstream tasks leads to unnecessary change. But appropriate unscheduling of some, but not all, downstream tasks leads directly to the requirement that the scheduling application be able to populate a partially-filled timeline. Some scheduling applications require an empty timeline as a starting condition. This is especially true for systems based on optimization logic. If everything downstream is subject to revision, the situation becomes an unstable jumble of change on the shop floor or jobsite, and thus a mess. In sum . . .. find a scheduling AP that can handle all the MES requirements 1 through 7, especially steps 4 and 6. avoid the mess from the get-go.