It’s all very simple when you explain your manufacturing process to your mother/neighbor/in-laws, right? And it is–normally. You manufacture widgets. Normally, a widget run produces two dozen widgets. The five-step process goes something like this:
- Set-up the widget-making machines
- Perform step A
- Perform step B
- Perform step C
- Take-down and clean the machines
This process, or “routing,” is a sequential process, of course where each step follows the previous. Scheduling this sequence is not much of a problem for most scheduling applications. However, it gets more interesting (code word for “complicated”) when an order comes in for 38 widgets. This is one normal run plus a little more than half of another run. How will this order be handled by production? What delivery date do I promise the customer? Do I schedule two normal widget runs and stock the 10 extra widgets, then wonder why my inventory is getting too big?
“No problem,” you say to your customer. Because you’re flexible and accommodating. You know that the machines that make widgets can run longer than defined in the standard routing. So why not just scale up the run times for the steps in the normal routing?
Good idea, but the set-up and take-down steps are the same for runs of any reasonable size. So what should the scheduler do to get realistic promise dates?
Here’s a solution:
Allow the standard routing to contain both flexible and fixed-length steps. Scale up the flexible steps using the ratio of the (required quantity)/(nominal quantity). Then lay in the fixed-length steps where they belong in the sequence. In our example, the scale factor would be 38/24 = 1.583. This number would multiply the run times of the flexible steps.
It gets a little more interesting (ahem) when the production of widgets involves just one step and one machine. There still is a set-up that might require a technician, followed immediately by an automated machine run during which the technician is not required, followed immediately by the take-down which again requires the technician. It’s best to model this as one activity with requirements for two resources (machine and technician). The requirement for the machine is for the entire duration of the activity, and the requirement for the technician is for an interval at the beginning and another at the end of the activity. This assures that the machine run gets scheduled immediately after the set-up is completed. Using this modeling, stretching the activity to accommodate the 38-widget runtime is more complicated because the technician requirement is fixed in length but the machine requirement is flexible. (There’s that word again! No problem, you think to yourself.)
Could it get more “interesting”? Of course! Are you still flexible and accommodating? How about a fixed-length requirement in the middle of the activity? Suppose, that a technician is required to reload supplies at some point during the machine run. But it takes a fixed amount of time to do this, no matter how many widgets are being made. Now we must stretch the nominal duration (runtime) with some flexible resource requirements and some fixed. And the fixed ones might be scattered anywhere within the activity. This situation occurs frequently enough that proper capacity modeling must accommodate this capability.
In other words, your scheduling application needs to be flexible and accommodating, just like you are for your customers, right? Can your capacity model do this? Or are you the only flexible and accommodating thing in your operation?
Curious to see if I can streamline your manufacturing? Contact me and we’ll show you how much easier it can be.