There’s always something new to discover in the scheduling world. Just when you think you’ve seen it all, someone has a need that you haven’t thought of! Here’s one that just came up:
Some environments have activities that, once started, cannot be interrupted. You can’t start baking cookies if the baking time runs past the end of the work day. Turning the oven off at 5:00 and back on at 8:00 am with a batch in the oven is not very good quality control. It turns out there are a lot of these type of examples of course—and not just in the baking business.
That said, there are also many environments where processes can be stopped and restarted without any problem. For example, machines can often be turned off and back on mid-task to continue a manufacturing production. Tasks at many jobsites can be suspended at quitting time and resumed the following day.
So there seems to be two types of scenarios: activities are either interruptible or not. Right? We implemented both cases and thought we had every situation covered. We even made sure that interruptible activities which use several resources simultaneously, could be restarted only when the same configuration of resources was available again after the interruption. The results were terrific! Resources were used to the maximum, capacity utilization was excellent, but some of this efficiency resulted from interrupting one activity and inserting a segment of another activity before the first one resumed. Several activities used shared resources in parallel by starting and stopping themselves to use the availability slots most effectively. Everything got done with exceptional resource utilization. Yea us!
Then the hybrid situation arose. One user wanted her activities to be interrupted by downtimes such as overnights and weekends, but not by any other activity that grabbed a shared resource, even for a short interval. Hmmm! It became necessary to distinguish between a resource being unavailable due to a downtime and a resource being unavailable because some other activity was using it–even for a brief interval. -This user had a circumstance in which an activity could be interrupted, but only by a weekend when no other activity was occurring. Plus, the activity had to resume immediately when regular work hours resumed.
It’s one of those smack-your-forehead insights that seems obvious once the situation is presented. So now there are three start/stop cases for an activity: 1) not interruptible, 2) interrupt only for downtimes, and 3) interrupt as appropriate with other activities to ensure maximum use of shared resources. Which case do you have? You may have all three—or you may have a fourth that we haven’t thought of yet. In any case, we can handle it. Make sure your automated scheduling application can handle all of them too!