If you have taken me up on the challenge to create a silo free one metric to rule them all TDD schedule through out the flow of your plant you are in good shape. If you have done this and implemented it you might start seeing it’s not quite perfect. That leads us to step 3 the drum report.
Sure TDD is the coolest metric you have come across, but what would the schedule be if it did not take into account a constraint. It isn’t called theory of constraints for fun. So we need to subordinate the flow of everything and every step that flows into the constraint via a pull system.
Side note: if you apply just the TDD schedule for each step or major process you will find work building up in front of the slowest process in the chain. This does build up a nice buffer which is necessary to always keep the bottleneck feed so there is ZERO down time on that machine. But too big of a buffer doesn’t work either. We will discuss how to size these buffers later.
You build a pull system by using the TDD schedule at the constraint/bottle neck and then based on what it’s going to run have all processes that feed into it run stuff that will feed into its buffer but to do so only at the pace at which the drum aka the constraint can go (through-put rate). If you run faster than this the buffer gets too big and if you go slower you starve the bottleneck of work.
Now here is a concept about the bottleneck. Downtime for a bottleneck is your total overhead as it is the constraint for your entire business. Does that get the idea across about why you want a buffer and to always have that machine or process running?
If that wasn’t crazy enough I am going to blow your mind here. If another process isn’t the bottleneck you don’t need to maximize its through-put! So it’s ok that it runs at a lesser rate and has more downtime, don’t even analyze it! What I am saying is if you have a bunch of mag ones and you keep telling your manager to optimize them all you don’t believe in constraints, if you did you would ask him to optimize the constraints first!
To recap if the process is before the constraint it uses the same TDD schedule running things up to the constraint at the speed of the constraint. Got it?
Now if the process is after the constraint have it run as fast as it can for the work it has to do, max its speed out. And then when the job is done let it sit till it has work again. Don’t try to keep a steady flow of work to it, its full throttle and hard on the breaks.
Side note: I am sure most of you won’t agree with me on this. And it’s not really me but with TOC. But the theory is correct. And for those that do agree it will take a culture change for leadership to walk out on the floor do be ok with machines not running and the worker just sitting there waiting for the next tub to arrive. The Japanese companies that implemented TOC went as far to put newspaper stands next to the machines.
Side note: obviously if there is some AM or PM maintenance that can be done go for it but what you don’t want to do is move that resource elsewhere and then work shows up and he is not there to run it. In essence your old school drive to maximize everything you have created another constraint, be it temporary, and how much does down time of a constraint cost again? Oh I don’t know just your entire company overhead! So think about it what’s 20 min of a guy sitting at a machine vs that cost?
And just to say it in case you are wondering, why go full out then stop? It is so that product or process sequence can continue and move on to the next process as fast as possible to shipping.
And the old school mentality I mentioned above has a name it’s called a balanced line and it failed miserably in the 80s yet some people hang on to parts of its philosophy.