My experience from working with many SMB companies around the globe tells me that even the best (and probably most expensive) production planning model never can cope with reality: data always seems to be too imperfect to feed the “perfect” algorithm and the current production conditions seem to change too fast so that systems always seem to be ‘behind’ the shop floor reality. In that regard, a scheduling grey area should be defined as the area in which the scheduling system’s settings, configuration and model does not meet the reality and in which a human scheduler is sitting in the driver seat with the need to make agile decisions.
In this blog post I talk about how a visual scheduling approach can help the driver to navigate through the scheduling grey area,
The concept of “scheduling grey areas” originates from the fundamental differences between visual and advanced/ algorithmic scheduling.
With an algorithmic scheduling system, users (or their consultants) create a precise model of the shop floor – with all dependencies, constraints, relations, alternative product routings, priorities, business rules etc. This model is then fed with plan data from the underlying ERP system, and the scheduling system derives the optimal schedule to execute the plan. It is the nature (and the undoubted strength!) of the algorithmic system to resolve – as good as possible – all scheduling conflicts, and to provide the optimal schedule. Conflicts do not exist per se in the schedule delivered by an advanced scheduling system. If they happen, the next scheduling run will resolve them again – and again deliver the optimal schedule based on the input information and based on the defined shop floor model.
In a visual scheduling system, the decision authority is with the user: the visual production planning system works as a kind of ‘assistance system’ helping the user to understand the current situation with all their issues and conflicts, as well as potential strategies to resolve these. It does not necessarily rely on an algorithmic/ model intelligence. It takes data from an underlying (ERP) system and visualizes the plan/ schedule calculated by the system. However, the visual system knows about conflicts (e.g. delivery time violations, capacity conflicts, missing material, etc.) and is able to intelligently visualize these conflicts. It is then the task of the system’s user to manage the conflicts and either change the schedule or take appropriate counter measures to deal with the conflicts.
I believe in the existence of scheduling grey areas.
Here are three typical scenarios in which the scheduling system user would make a decision “against” the rules he has previously defined for his shop floor model. He would not do this because the models are stupid, but he would do it because there are scheduling grey areas which exist in reality, but outside the model.
Imagine the following scenario: A product (P1) is produced in a sequence of three operations (O1-3) on three machine centers (M1-3). Typically, an ERP and/ or scheduling system allows you to define the delivery date, the routing, the required and used material for P1, set-up time, run time for O1-3 on M1-3 as well as wait/ transportation time between O1/2 and O2/3. Of course, you can also define priorities and constraints so that the scheduling engine can determine the best start/ end dates for all three operations given the already existing schedule. This may lead to the situation that O3 finishes at the end of day, so that the next operation for a different product on that machine center will need to start the next day.
It goes without saying that the above mentioned definitions – especially the set-up and run times – always have to be average values. They depend on the experience the manufacturer has made with that particular product on that specific machine in the past. Well, it is not so uncommon that once in a while the machine operator recognizes a slightly better “condition” of the incoming material on M3 for P1 and therefore, despite the system’s settings and based on his experience he decides to run the machine faster than the average. As a result, he manages to complete the product faster than expected so that he can free up capacity on M3 later that day. Consequently, the machine operator can start with the next operation although this was not foreseen in the “optimal” schedule.
When working with grey areas – and allowing capacity conflicts rather than trying to “optimize them away” – a visual schedule could have just shown two operations in parallel on that machine at that particular day. With the knowledge of a human being about reality being different than the average reflected in the model, this scenario would not have resulted in a schedule with a capacity conflict. Instead, the schedule would have shown much more realistic completion time information.
Again, let’s imagine a scenario. There are two production orders P1 and P2 from customer C1 and C2. Both have a similar order date, and both need to be manufactured on the same machine M1. Also, the delivery date for P1 and P2 is the same. This is actually quite common: You have production orders that compete on resources so that a deadline can be met with the current conflict resulting in a delay for one of the two production orders.
The typical way to deal with this scenario is to define rules deciding which production order should get processed first, and for which production order a delay can be tolerated. Of course, there is a wide range of potential rules that could be applied here. Let’s assume that the system is set up in a way that in case you have competing production orders, you will prioritize
(a) The production order with the earlier due date.
(b) The production order where you got the order first (kind of ‘FIFO’).
(c) The production order from the more important customer measured by total revenue with the customer in the past 24 months.
In the described scenario, rules (a) and (b) would not come into effect as both order and due dates are the same for P1 and P2. Hence, the system would prioritize the production orders according to the past revenue with the respective clients. So far, so good. This all makes sense.
In most scenarios, this rule would work just like people on the shop floor and management would have decided. However, imagine customer C1 to be one with whom you made a very good business in the past. In fact, you not only made great business with them, but you were able to build a strong (even personal) relation with this customer. In turn, customer C2 had been buying from your competitor for the past years. Due to some recent quality weaknesses of his previous supplier, he decided to grant a first order (P2) to you – with the perspective of becoming a future large client. Now think of the scheduling system deciding to prioritize P1 and to complete P2 late. Your first delivery to C2 would be late. Most likely, this would destroy the opportunity of building a long-term relation with C2.
When working with scheduling grey areas and giving decision control to humans and not to the scheduling algorithm, the visual scheduling system would provide you with a conflict alert highlighting P1 and P2 with their respective delivery dates. You would then rethink the situation, and decide to call C1 with whom you have a trustful relationship. You would explain the situation to him and ask him if just this once he would agree with a delayed delivery in order to help you build another strategic customer (which, since a stronger supplier always is a good thing, would also be of interest for C1). Presumably, C1 would agree so that you would be able to take both orders and manage to win C2 as new customer.
A non-optimized schedule regularly shows capacity conflicts at resources (e.g. at machines or people). As unwanted these conflicts may be in general, sometimes they are just small enough to be accepted by humans. Imagine a scenario with two production orders (P1 and P2) being allocated to the same machine (M1), with P1 starting at noon and running until the end of the shift that day and P2 starting in the afternoon and running for one hour until the end of the shift that day as well. As M1 can only handle one production order per time, the “overbooking” during the last hour of operations at that day would create a visual system to give a (visual) warning to the user. Remember: With an algorithmic system, these capacity conflicts do not exist per se.
Knowing that both P1 and P2 have tight delivery schedules and do not allow for any delay, the production scheduler now has to make a decision between two choices:
(a) Accept the delay (if there are no alternative machines to take care).
(b) Ask the machine operator to work an extra hour that day to get both P1 and P2 done in time.
Again, the scheduling grey area opens a degree of freedom with respect to decision making which does not exist in a rule-based advanced/ algorithmic system.
In essence, many conventional algorithmic scheduling systems often are hard to understand as the core element – the scheduling algorithm – is a kind of black box. Typically, it requires a massive amount of training to even operate these systems. However, even well trained operators not necessarily understand what is happening when they start the scheduling engine. This makes it hard to understand and systematically correct operational flaws in the manufacturing process. What’s even worse: If the scheduling engine is fed with suboptimal data, it generates suboptimal scheduling results. They can hardly be spotted (as users tend to accept the results rather than to understand them), which can result in bottleneck floor operations. Also, due to the inherent complexity driven by the underlying model, an algorithmic scheduling system that had been implemented once is hard to change. Hence they tend to become inflexible. As result, over time the likelihood increases that the reality on the shop floor will change and the algorithmic systems then fails to reflect this change.
In turn, a visual scheduler explicitly works with a clearly defined “scheduling grey area”. This enables the user to better react to unexpected changes or to adapt the schedule to reality (rather than trying to explain why reality is different than it should be according to the underlying model).
Our company is specialized in developing Gantt charts components for software developers and in using these components to develop individual visual planning solutions for SMB end customers. If you are interested in seeing your production planning data visualized, ask us for a free prototype: we are happy collaborating with you.If you are not ready to get engaged with us personally, you can get more insight from similar blog posts about "Planning & Scheduling Insight", or from downloading our free whitepaper "simplify production scheduling with intelligent Gantt charts".
In addition to this, we develop fully integrated Gantt chart add-ins for Microsoft Dynamics NAV. If you want to learn more about visual scheduling for Dynamics NAV, feel free to download our complementary Ebook: