Throughout the Profit Savvy, we talk about several different workflow and inventory models and their respective merits. You can quickly gain an impression of how these models work in practice by playing a simulation game with a set of dice. This will demonstrate the relative strengths and weaknesses of the various models and their impact on your profit.
Table of Contents:
Simulating Profit Improvement
A simulation is simply a type of "game" that represents a real-life system in a method that you can study more conveniently than building the real-life system. It will let you change various "variables" such as labour, production, throughputs, inventory and allow you to see the results of implementing the different models.
You may well be thinking that you do not have a business with a production line, but you will have to a certain extent.
By way of example, consider:
- A manufacturing business: the simplest example of a workflow where raw materials come in and finished product goes out.
- Restaurant: once again raw materials come in and are manufactured in the kitchen and exit as meals for guests.
- Accountants: a lot of accounting work is a routine process. A preparation of a tax return or annual accounting statements follow the same routine and can be broken into various stages of "manufacturing".
- Coffee Shop: example - a conversion of beans to brew.
- Retail: the workflow here is from goods supplied by a wholesaler through to display on shelving and then through your point of sale and they exit your business in the hands of your customers.
- Medical Practice: people enter a queue for the service of a doctor. They may go through several stages in this process including reception, waiting area, medical consultation, follow up pathology, visit to a pharmacy.
By now you can probably see that your business also has a workflow. Once we have established that, we can immediately start to model the movement of product through your production line and start to see the impact of changes on that system.
The following business models are illustrated using dice games. There are some computer simulations that achieve that same thing but may not be as illuminating to you as actually playing the dice games.
These games can be played with several people representing several stages in the production cycle, or you can play it with just the one person: but it will take somewhat longer and probably be less fun that way.
Ideally, if you need to convince your staff of the pros and cons of various production systems, these games might be a great way to demonstrate to them at a team meeting.
Set up several stages that represent several stages in your own workflow. Ideally, there should be six or more of these so that you get a stronger visualisation of the impact of your flow model on your actual production.
"Each stage" (people or location in your model) should get several counters as a starting point.
The idea is to move the counters from one stage to the next starting with the entry to your production line and finishing with the exit from your production line.
Each stage of the production line should have a dice.
Unless you have spent some time carefully thinking about your production flow, you probably have an Unbalanced Production System.
By this we mean that the flow of work through the system has not been finely tuned to the capacities of either the individuals/machines at each stage or the type of work that must happen at each stage. Therefore, product flows through your production system in a fairly jerky fashion piling up at some stages and leaving other stages without anything to do.
We can model this system with the dice and counters as follows:
- Set up the same number of stages as you have in your business’ own production system and give each stage a random number of counters falling between 0 and 6.
- Have a bigger pile at the start of the workflow to represent new materials drawn into the workflow.
- Allow the odd numbered stages, starting from the entry onto the workflow, to throw 1-6 on the dice and the even numbered stages must throw 3-5 only. Setting these stages as having different possible throughputs replicates what an unbalanced line is likely to have.
- Now each stage simultaneously throws their dice. If one of the 3-5 lines throws something other than 3-5 they re-throw.
- Move the number of counters thrown by the several dice to the next stage. If you don’t have enough to fully pass on the toss, pass on what is available at that particular stage.
- The first person in the production line is effectively the store of raw materials and they introduce that store of raw materials into the system according to the roll of their dice.
- Each throw of the dice is taken to be one day. This game will run for 20 days or 4 x 5 day weeks.
- Record the results, whatever the throughput of this system was becomes the Base Line for comparing the other models we are about to introduce to you. Write down the number of counters left in each stage (the work in progress) and the total number than was output by the final stage in the workflow.
Likely, the results are going to be quite chaotic with all sorts of different stock piles of inventory at various places in the production flow.
One of the goals of a lot of workflow improvement systems, like Six Sigma and Lean, are to "balance" the workflow.
Basically, this means that the systems work in unison and there is the minimum amount of wasted effort involved in the system.
Widely touted as the ideal solution, it comes with some notable defects, which means that it is going to be quite difficult to achieve.
The principle failure of a Balanced Line approach is that it doesn't handle variability and uncertainty very well. The one thing that we can be confident of in business is that unexpected things can happen; the so-called Murphy's Law.
Once again, set up several stages that represent several stages in your own workflow.
"Each stage" (people or location in your model) should get several counters as a starting point. Let us assign 4 counters to each of 6 stages.
To play the Balanced Line simulation:
- Throw our dice simultaneously representing the Balanced aspect of the line.
- You then move the same number of counters forward as shown on your personal dice.
- If you do not have sufficient counters, move only those that you do have forward.
- Continue this for the same 20 cycles as before and check the results.
- Record the results. Write down the number of counters left in front of each stage (the work in progress) and the total number that was output by the final stage in the workflow.
At first glance, you may think that the average result at the end of the workflow that you get with the throw of the dice is 3 (being half of 6).
However, because it is equally likely that you will get a 1, 2, 3, 4, 5 or 6, which equals a total of 21, divided by 6, gives an average of 3.5.
Therefore, at first glance, you might expect to average 3.5 counters for each of the 20 turns which is a total of 70 counters through our production line during the month that we are simulating.
This becomes our expected output of our production system.
Now play the game.
Almost certainly you will find that your output results are quite a bit less than the expected 70 counters through the system.
Much of this comes about because of the missed opportunities for moving on the amount of product your dice said you could because you do not have sufficient to fill the demand from the station before you. This is the effect of uncertainty or variation in production outputs.
Another thing you will probably notice is that there are stages in the cycle where the build-up of counters is quite substantial. This happens in situations where those stages roll low numbers on the dice and therefore cannot pass on everything that is passed to it.
You started at 4 counters per stage and 6 stages - 24 counters on the board. Take a count now and see how many there are and if there are more than 24, then your production system is building up surplus work in progress.
Quite often this number is substantially more than the original.
If you haven't already read about the Theory of Constraints (see our TOC article) read this prior to playing the game.
Effectively, TOC argues that somewhere in your production line there will be one station that will be a constraint, or bottleneck, which controls the flow of work through your production system.
No matter how hard a station upstream from the constraint works, it can only push so much through the constraint. No matter how hard a station downstream from a constraint works it can only process whatever is fed to it by the constraint. Therefore, the constraint is the heart beat of the entire production line.
Let us see the results of modelling a constrained system.
Each station, except the constraint, will have 2 dice that they can throw.
The constraint will be limited to throwing just one dice.
For best results, the constraint should be somewhere towards the middle of the system but ideally you could place it at the location of the constraint in your own production system, if you know where that is.
Once again, toss the dice in unison and move across the number of counters indicated on your dice if possible.
Record the results. Write down the number of counters left in front of each stage (the work in progress) and the total number that was output by the final stage in the workflow.
Keep in mind that the constraint is operating at, theoretically, half the capacity of the other stages (because it only has one dice).
The most likely result of this, as you play through the 20 weeks, is that there will be a build-up of work in progress in front of the constraint. This is exactly what we would expect to happen in front of any constraint.
We will also notice that, very often, there is idle time at the stages after the constraint as they can only process what can get through the constraint.
We might also find that there is a build-up of work in progress in front of some of the stages before the constraint which reflects the uncertainty of production at those levels.
It is difficult to predict what the results will be due to the random effects introduced by throwing the dice but, quite likely, you will see that the total throughput is greater than through the Balance Line simulation above.
The work in progress will also likely be substantially more than with the Balanced Line and probably backed up in front of the constraint.
Irrespective of the work in progress - which is a cost that we don't want to have - the throughput of the system was better than the two previous simulations and therefore the sales income would be better.
We have described the Drum-Buffer-Rope system (see the Drum- Buffer-Rope article).
Effectively this means that the production line marches to the beat of a single Drum just as a marching band does. That Drum is the constraint. Each time it accepts a load of input, the Drum has one beat and the "Rope" pulls one more set of products through each of the stages preceding the constraint.
You have probably seen something similar in an old-fashioned sailing ship with people pulling on ropes to raise the sail – reposition - haul, reposition - haul.
In summary, this system is a demand-pull approach where the constraint sets the demand.
To model this the entry point for the flow, where the raw materials go in, will not have a dice at all. That stage will simply load into the production line the same number of counters as the constraint with their single dice throws.
This effectively gates supply into the system so that the work in progress should always be sufficient to meet the demands of the constraint.
Up until now we have assumed a Balanced Line so that everyone commenced with the same 4 counters. However, with a constraint, we already know that there will be a pile of work in progress in front of the constraint.
Therefore, in this example, we will simulate this work in progress with 12 counters in front of your constraint stage.
Play the game for 20 cycles and record the results. Write down the number of counters left in front of each stage (the work in progress) and the total number that was output by the final stage in the workflow.
Once you have played this game through the 20-cycle simulated month, it is likely that you will find that the inventory, or work in progress, has fallen quite dramatically throughout the system. There will still be a pile in front of the constraint but the other stages will have much less in front of them than under the previous simulation.
We also expect that the throughput of the system will be greater than the throughput of the Balanced System. All things being equal, it will be rather similar to the throughput of the constraint system because the constraint is the limiting factor in both instances.
To this point, we have shown that introducing a constraint and using it as the heartbeat of a system can reduce inventory and likely increase productivity.
However, we also know that from time to time the constraint is going to have problems such as periodic maintenance, breakdown, power failures and so on.
It is also possible that there will be different products that pass through the constraint at some point but have their own production lines above, and possibly below, the constraint. We are introducing more uncertainty into how the constraint can operate.
TOC teaches us that one of the important steps for working with the constraint is to elevate it so that it gets more and more attention to keep it functioning as productively as possible.
To simulate the results from elevating (improving) throughput of the constraint, by focusing every effort that we can on it, we are going to change the rules applying to the throw of the dice at the constraint.
We do not want to simply give the constraint 2 dice like everybody else has as that would remove the constraint.
However, we are going to simulate the effect of an improvement by keeping everything the same as in the previous simulation but now whenever the constraint rolls a 1 or 2 it is going to equal a 4 and if it rolls a 3 or 4 it will equal a 5 and if it rolls a 5 or 6 it will be equivalent to a 6.
We are increasing the productivity of the constraint by removing any low yielding effort.
Because of the improved effort on the part of the constraint through the augmented dice count, it is going to be the case that your throughput will increase.
Because we are gating in materials at the same speed as the constraint is consuming them, we may have some stock outages above the constraint but it is not very likely.
By the time we have got to this point in the cycle, we have demonstrated how the tuning of a production line can lead to far better productivity and likely less stock on hand.
If you have played this game by representing the flow of things through your own business, it is likely that it has indicated to you that using TOC can substantially improve your productivity with no other changes to your system and personnel.
You can play the game as often as you like to prove to yourself that the concepts are correct. You can also involve staff and others who will need to be convinced of the possible improvements.
Each time you play, results will differ because of the randomness introduced by all the dice. However, the outcomes should be rather consistent for each methodology in relation to other methodologies.
We can also use dice simulations to demonstrate improvements that can be obtained from centralised inventory control. See more about this in our TOC and Inventory articles. It is advisable that you read these articles before playing this game.
This article argues that the effect of variability in demand for stock out of regional warehouses is much higher than the variability of stock out of a centralised warehouse. Consequently, the regional warehouses will be over and under stocked much more often than the central warehouse.
We assume that you have 4 regional warehouses and that inventory is delivered to them from a centralised sourcing warehouse in response to their replenishment requests.
A simple experiment will prove this key point about demand variability smoothing as more events are aggregated.
For each warehouse location, dice are rolled to simulate daily demand.
Two dice are used for warehouses 1 and 3, while a single dice was used for warehouses 2 and 4.
The different number of dice being used is meant to bring some additional reality to the scenario by simulating warehouses that might do higher levels of volume for a specific product.
|Warehouse 1||Warehouse 2||Warehouse 3||Warehouse 4||Sourcing Unit|
Table 1: Results of the distribution dice experiment.
Each day the sourcing warehouse’s demand is the sum of all the regional warehouses’ demand. The column labelled “ADU” is the Average Daily Usage over the 14-day time frame at each location.
Now when the results for each location are charted, several results can be seen visually.
Graph 1: Daily Demand Charted for all Locations
The smoothing effect at the central sourcing warehouse can be clearly observed.
This smoothing effect is not just observable through simple line graphs. It can be calculated mathematically by using the coefficient of variance formula, which calculates the normalised measure of dispersion of a distribution. The smaller the COV, the less the variation.
For those of you with a statistical bent, the equation for the coefficient of variation is the standard deviation divided by the mean. It is also known as relative standard deviation.
Table 2 depicts the coefficient of variation for each location in the experiment. The column labelled “ADU” serves as the mean for each location.
The column labelled “SD” is the standard deviation at each location.
Finally, the column labelled “CV” is the coefficient of variation.
Table 2: The Coefficient of Variation at Each Location
This makes a compelling case that the best place in a distribution network to mitigate and manage demand variability is at the central, aggregated, warehouse where there is less inherent relative volatility.
Yet this mathematical fact seems to be lost on the people and organisations running the vast majority of distribution networks. Many distribution networks are designed and managed in a way that prohibits them from taking advantage of this concept.
Doug H: Create Rolling Dice in Excel - https://www.youtube.com/watch?v=QAPXtrUMqFk
Alex Knight: Pride and Joy - Online dice game simulator - http://www.alex-knight.com/the-dice-game
Carol Ptak and Chad Smith: DDMRP – Demand Driven Material Requirements Planning, (2016) Industrial Press, Inc. An intuitive, proven planning and execution method for today’s complex and volatile supply chains - http://www.demanddrivenmrp.com