Last week’s blog discussed how there is no such thing as an optimal production schedule; it is in fact, an impossible problem to solve even for today’s most powerful computers. So, today’s production scheduling tools found in ERP or as bolt-on software use ‘heuristics’. Wikipedia’s definition of heuristic or a heuristic technique is especially appropriate: “any approach to problem solving or self-discovery that employs a practical method, not guaranteed to be optimal, perfect, logical, or rational, but instead sufficient for reaching an immediate goal. Where finding an optimal solution is impossible or impractical, heuristic methods can be used to speed up the process of finding a satisfactory solution
Are Heuristics Used By ERP Scheduling or Bolt-On Software Providing a “Satisfactory Solution”?
So, finding the “optimal” solution to scheduling our shop is out of the question. But the question remains, are the heuristics being used by ERP scheduling or bolt-on type programs providing us with a “satisfactory solution”?
Let’s look at what a typical production scheduling program is designed to do:
- Take all firmed and released jobs/work orders and sort them by due date. There may be overriding sorts such as most important customer, or revenue amount, but generally, the default sort is on work order due date.
- In due date sequence from earliest to latest, take all of the operations of each work order and place each one into the shops capacity. This may be done infinitely, or finitely, in a forward or a backward direction:
- Infinite loading: Infinite loading means that the system will ignore any capacity constraints and assume you can work on as many operations as needed in a single resource. Certainly not realistic, but does have value in being able to see how overloaded you may be in a particular work center. Usually, you can tell the system if all or just selected work centers should be loaded finitely or infinitely.
- Finite loading: This means that the program will respect the capacity constraints given by resource and calendar and only load the number of jobs that can truly be worked on at any one time in any selected department, or machine.
- Backward loading: This approach takes each operation starting from the last operations sequence number and places it (if capacity available when finite loading) so that it finishes the same day or perhaps the day before the want date of the work order. Then takes each operation in a backward direction and places its finish time at the start of the previously placed (or next sequence in numerical order of the routing steps) operation and so forth until all the operations are placed. If any of the operations needs to start “before today” (not possible to do work in the past), then the program stops that approach, erases the results for that work order, and commences to place that job’s operations in a forward direction (described below).
- Forward Loading: Forward loading takes each operation of the work order starting at the beginning or the lowest routing sequence number and places each operation starting today.
- Contention: As the program attempts to place each operation in each resource, if that resource is infinitely loaded, then there is never any contention, nor constraint or bottleneck, so the operation is placed directly after or before its previous or next operation in that work order’s routing sequence, depending upon whether we’ve selected forward or backward loading. If the resource is finitely loaded, however, when attempting to place a particular operation, it checks to make sure that any part of the time slot required has not already been loaded with another operation from a previously loaded work order. If it has, in forward loading, it then looks for the next open slot in the future. In backward loading, it looks for a time slot in the backward looking direction until it hits “before today”, as we mentioned, can’t load an operation into the past.
How Do We Know We Are Working On the Right Jobs?
Concerns about heuristic in general:
- Loading Capacity vs. Execution Priority: When we look at what the algorithm for a production scheduling program is actually doing, the focus is mostly on loading existing capacity than it is of truly trying to resolve one of our fundamental questions, “What job should I be working on right now”? In fact, a production scheduling program loads ALL the operations for the entire work order. But in real life, we don’t execute that way. We evaluate each job in the current resource (or resources if overlapping), and decide which is the right job at that moment in time. Just because an operation belongs to a work order for which the capacity needed was allocated by the program, does not mean that is the right job to be working on in the present moment.
- Due Date Priority: On the surface, prioritizing jobs by due date seems to make perfect sense. However, placing the operations of the jobs with the earliest due dates first, essentially “hard allocating” the capacity for those jobs, may be “stealing” needed capacity for jobs that, in spite of having a later due date, are more at risk of being a late job. In other words, and what we often see in custom, Make-to-Order (MTO) manufacturing environments, is that you have a job with a due date 2 months from now, but because it has more operations, or even has to go outside to heat treating or plating, is MORE at risk of being late if we don’t get started on it right now, than a job that’s due only 2 weeks out. So, prioritizing by due date would actually have us working on the job due 2 weeks out, thus delaying the start of the job with the later due date, putting it at danger of missing the due date.
- Variability: Said another way, “Stuff Happens”. If you commute to work, and you know that early on a Sunday morning you could make that drive in 20 minutes. But on Monday morning, you know if you want to be at work by 8:00, you better leave at 7:15. Same thing on a manufacturing shop floor. You know looking at the 8 operation steps on a traveler, that the total estimated setup and run times for all operations is only 3 days. If nothing else were in the shop, you could make those in 3 days. But there are other jobs, many other jobs, competing for several of the same resources. We also know that Mr. Murphy is alive and well, and unpredictable events, like material not showing up, people calling in sick, or tools breaking, happen all the time. But there’s no way to account for that Variability in a scheduling program. A finite loading algorithm can help you identify capacity constraints, but it has no idea – and no way to account for – unpredictable variability – which is happening all the time. Think about it: when backward loading especially, we’re telling the system, “Go ahead, let’s PLAN to finish the last operation of that job right on the date it’s required”; and every operation behind it is tucked right up against the following operation’s start date. No room for Variability!
The Disconnect In Today’s Manufacturing Scheduling Systems
Is it any wonder then, that when we run the ordered list of “priorities” by work center from a production scheduling program, typically called the “Dispatch List”, and deliver it to the shop floor, the folks there kind of look at you funny and ask, “where’d you get these priorities?”
If you’ve tried scheduling programs, and you’re back at using manual whiteboards, or spreadsheets, and your struggling to answer these 3 questions:
- What job should I work on next (in any dept/resource, or shop wide)?
- Where is this (any particular) job? How is it progressing?
- How can I tell my customer when she’s going to get her order?