“A bargain ain’t a bargain unless it’s something you need.” –American screenwriter, Sidney Carroll
Identifying what your company really needs and finding the best-fit application to fill that need is the crux of every purchasing decision. The same can be said with manufacturing and project scheduling applications, of course. Such a purchase shouldn’t be taken lightly and it’s not necessarily a simple task to narrow down your unique needs—and potential needs.
By working in this field for decades and examining the ins and outs of literally hundreds of applications has led me to an understanding of the design assumptions that underlie the fundamental flaws in many of them. The one thing I know for certain is that your company and its resources, processes and goals are exclusively unique–but certainly not unsolvable.
Use the following list of questions to help you narrow the field of vendors of manufacturing ERP, MES, MRP, and CRP systems and other advanced planning systems (APS).
Does your manufacturing or scheduling application…
- Assume that resources are the objects to be scheduled? Manufacturing applications shouldn’t be designed to schedule machines, work centers, people or materials. They should be designed to schedule the activities those resources perform. This is a critically important perspective because the relationship between an activity and its required resources is one-to-many. It usually takes several resources to perform an activity. Also, sequence relationships are among activities, not resources. Inverting this perspective at design time leads to complex software that may miss performance opportunities. Resource-oriented scheduling is the logic used by many spreadsheets from which some manufacturing applications have evolved.
- Assume resource assignments and activity durations are the same? An activity might require a person intermittently during its performance. This is especially true with computer-controlled machine tasks. Other activities might require different machines or equipment during different intervals within the performance of the task. It is important that manufacturing support software not assume that all resources are required for the duration of the activity they are supporting.
- Assume that the same quantity of a resource is needed for the whole activity? Realistically, resources might be needed in time-varying amounts over the duration of an activity.
- Assume that all activities are either interruptible or non-interruptible? Clearly some activities can be stopped temporarily at the end of a shift and resumed at the next shift, but others must be completed once they’re started. Neither model is universal. Most environments have both types of activities.
- Assume that schedules should be built either forward or backward? There are cases when one-way scheduling in either direction is useful, but there are also many cases when the best schedule is built by placing activities at times that maximize the use of the resources. One-way schedulers will not find those possibilities.
- Assume that required attributes can be aggregated by simple logic? An activity might require both a machine with a certain capacity and an operator with a certain skill. Or it might require the machine or the operator. In realistic environments these kinds of requirements can require a more complicated combination of and, or and not
- Assume that resources cannot be shared simultaneously? Some technicians can be working part-time on several different activities simultaneously. Some resources (like ovens) can be shared by several different baking activities.
- Assume that rescheduling requires erasure of an interval on the timeline? It is often necessary to unschedule selected activities that are scattered all over the timeline. Some software cannot unschedule activities selectively and then reschedule them or others into the holes that result.
- Assume that resources required by an activity must be explicitly specified? It is usually the case that some activities can be performed using different combinations of resources. A “wild card” specification is necessary to properly marry the assignment logic to the start time selection logic.
- Assume that time can be partitioned into pre-defined intervals? Time buckets are good for spreadsheets but not for utilizing resources to their maximum capacity. Time is essentially a continuous variable. Basing software on some minimum time interval, such as days, hours or even minutes is restrictive.
- Assume that constraints must be either enforced or ignored? If you need to do capacity planning and want to know how much capacity must be added to support a specified demand profile, enforcing or ignoring capacity constraints will not provide the needed information. You need to be able to track the requirements for resources even when you know they may not be sufficient.
- Assume average lead times when predicting finish times? An available-to-promise date must be calculated with a real capacity model that does not pollute a working timeline with hypothetical activities.
Vendors that use these assumptions to build their software end up limiting a production environment. The result is an inaccurate description of the true capacity. This translates into missed promise dates, the requirement for more resources than necessary and unnecessary costs to meet production demands. These also have indirect effects. One of these is the need for more specialists to manage production process because of the learned-on-the-job “tricks” needed to compensate for the limitations. These “tricks” add to the training time that scheduling personnel must acquire before being effective. More training time and more time managing the scheduling process are required because reality must be shoehorned into an application that doesn’t real model it accurately.
Skip all those headaches. Trust me—and Sidney Carroll. The bargain will be to purchase what you need and to sidestep scheduling applications that simply don’t fit.