Theory Of Constraints
Theory Of ConstraintsThe basic idea behind the theory of constraints is that a well optimized process has exactly one constraint on its rate of production. For example, a line of hikers on a trail may progress toward their goal only as fast as the slowest walker among them can walk, otherwise the line fragments into slower and faster groups. To keep the line together, put three-year-olds on shoulders, and give heavy packs to strong people to carry. It is impossible to eliminate all constraints, there's always a slowest walker, but there is no need for more than one. Once you have identified your key constraint, you should do everything possible to maximize the rate of flow through that constraint, and you should not let any other portion of the system run at a faster rate. The latter is necessary to make sure you do not have an ever growing back log of work preceding the constraint. This means that in a well optimized system, only one part is running at full capacity and the remaining parts run at only partial capacity.
http://www.eligoldratt.com and http://pinnacle-strategies.com
Those two web sites seem to have a near infinite buzzword to content ratio. I guess you have to pay for the content, or at least look harder than I did.
I would put it this way. The TheoryOfConstraints says:
For example, suppose a company relies heavily on software to manage business. Suppose their needs change frequently, the software is always getting in the way, and the software team is slow to deliver. Now, say the software team adopts an agile methodology and learns to deliver improvements quickly. The cost of software change is much less of a constraint. But if the team improves to the point that it can now handle any change the company throws at it, then further improvements to the software development process will not help the company as a whole reach its goals. So the company must find the next worst constraint, and focus its energy there.
In Goldratt's first book, TheGoal, he uses the metaphor of a factory to explain the concepts, then goes on to generalize to other systems. His second book, ItsNotLuck, talks about the thinking processes that go into finding and changing constraints, especially in systems that aren't as tangible as a factory floor.
Both of these books are told as novels, btw, and are pretty good reads. He also wrote a novel that applies the TheoryOfConstraints to project planning (CriticalChain) and software/consulting (NecessaryButNotSufficient?).
I had a quick look. There is a mention of 'pull vs push' and KanbanSystems, which indicates they are talking about "Just In Time" manufacturing, on the old ('80s) Japanese model. Nowadays manufacturing is done using MRP 2, which is a dynamic predictive process, rather than the old static process.
There isn't enough information on the site to indicate if they have moved beyond the older fragile JustInTime style. There is a lot of information around elsewhere under such banners as 'continuous improvement' etc. It is a highly jargonized field, unfortunately, but the principles are simple enough. The jargon quotient is very high because it involves management, sensitive souls that they are.
The basic idea is, and try not to giggle, you shouldn't make stuff until you need to, otherwise you end up with too much stuff.
Most of the rest is about how you define need, and how you adjust processes to support a 'lean' system. Full-on MRP 2 uses process simulation to ensure smoothness and leanness, which is a considerably more difficult (and interesting) problem. There is definitely an applicability to the programming process, indeed XP (and other lean methodologies) tend to reflect similar principles e.g. YAGNI, minimum grain-size, continuous refactoring, 'the supplier is your friend' etc.
MRP2 attempts to simulate contingent cases, particularly macro-structures where the process under view is part of a larger process which is not under your full control. I think XP is weakly defined in this area (as I understand it), as is the old JustInTime manufacturing system. MRP2 is expressed as a flow-network under local and global constraint. The constraints are derived from the desired quantifiable attributes like 'robust' and 'low cost'. I see a lot of crossover between the computer systems and manufacturing in this respect, though one should distinguish the design process from the production process IMO.
I may be going somewhat beyond Mr Goldratt here, my apologies if it is irrelevant. --RichardHenderson.
One of the good things about JustInTime/kanban cards etc is that they do not model the process or run simulations. They work with the real process as it happens. This is good because then you don't have to worry that your simulation is correct - you really are making stuff only when someone downstream has told you they need it.
JustInTime ends up fragile, as I understand it, because it has no slack - if something goes wrong, your whole pipeline grinds to a halt.
If you can accurately simulate your process (and you know what's coming up etc), then process planning is a lot easier. I'm sure I'm missing something, so can you explain how MRP2 avoids the trap of needing to precisely predict an imprecise future? How does it avoid fragility? By adding buffer stock or slack?
I spent years in the MRP and MRP2 trenches. MRP2 actually precedes JustInTime. MRP was designed in the 1970's and was brilliant for its time. One of the first business systems that really was designed for computers rather than copying paper systems. But the implementations are getting long in the tooth, and the practices around it were designed for slow-moving make-to-stock operations. In well-controlled environments, a JustInTime operation can kill an MRP2 operation. In less-controlled environments, there are other newer practices that may be much better than MRP2. I have redesigned MRP a couple of times to be event-driven and reactive, that makes it better. But it's still horses for courses. --BobHaugen
I think the point of the TheoryOfConstraints is to maximize "Throughput". The drum/buffer/rope analogy to production control is rather obvious, but no more so that the need under JustInTime to actually be able to predict when "in time" is. To put it in extreme language, "You�re not going to need it, yet." The TheoryOfConstraints ties the management system and the costing model together using a simple measure of value.
In a JustInTime operation you never predict when "in time" is. You only respond to signals from your immediate next consuming activity. So JustInTime operates under the YAGNI rule. JustInTime says "eliminate all constraints (bottlenecks) and achieve a smooth one-piece flow everywhere". The TheoryOfConstraints says there will always be constraints, in fact there will always be one main constraint, and if you can't eliminate it, you need to treat it specially. Basically, subordinate non-constraint activities in order to max out the main constraint. The main constraint is the drum. You build up a buffer in front of the drum so it can always stay busy. The rope subordinates everything else (that is related) to the drum.
Yes, there is prediction in a JustInTime operation, at least in the KANBAN model. Whenever inventory in front of a process falls below a certain level, the previous process is restarted. The prediction is the size of inventory needed to avoid underrun and stopping the process in question. The main difference between the TheoryOfConstraints and regular KANBAN is that KANBAN only looks one level back, while the TheoryOfConstraints looks all the way back to the beginning. With the TheoryOfConstraints, ideally you should be able to avoid maintaining multiple stockpiles of inventory and have only one.
There are at least two big differences between MRP2 predictions and JustInTime inventory levels.
Perhaps I was hasty invoking MRP2. Thanks for the correction. Kanban levels are a problem. One nice part of the whole 'continuous improvement' idea is the idea that the manufacturing process should not be fixed. It should be improved to try and streamline it. Particularly, the rate of flow out of one step should match as closely as possible the rate of flow into the next step. Furthermore the batch sizes should be minimized to allow a degree of flexibility, and resource should be assignable i.e. train everyone to do everything.
JustInTime practices include all of those ideas. It's easier to visualize standard containers rather than Kanban cards. The inventory buffer to smooth the flow between two operations is set by the number of standard containers that circulate between them. Continuous improvement consists of removing one standard container at a time and then dealing with the problems that arise. It's called 'exposing the hidden rocks' in the stream. (I'm not really trying to sell JustInTime here, just correct misassumptions. JustInTime is not good for every situation, but then, neither is any other set of practices.)
Modern simulations (apparently post-MRP2) analyze the cost of processing for any particular rate of flow, and allow a cost-metric to determine the optimum intra-process stock levels. This is usually done using a Monte-Carlo technique and I believe was one of the subjects of investigation in Simula. Industrial chemical companies seem to spend a lot of time researching this sort of thing.
At the end of the day, however, chaos theory shows that you can't account for everything. Any reasonable size system has non-linear feedback, and does odd things unless you maintain a reasonable buffer at each stage, or spend a lot of money actively correcting it.
The Japanese found that you could measure this by the number of spare parts workers hid in their overalls to get the job done. In software terms, it is better to secretly use the rule of three (or four or five), than attempt to refine a prediction on how long a piece of work will take. Better to be a relaxed and on time rather than stressed out and late. Convincing management of this can be a problem since they tend to think in terms of peak flow and damn the consequences. In my experience it is well worth delaying an early delivery to reinforce the original estimate or expectations will ratchet upwards. You could always do some documentation :). -- RIH.
So far this discussion has focused on maximizing throughput as the end goal. Actual manufacturing is a trade off between throughput, the number of units through the factory per unit time, and cycle time, the start to finish length of the process. Short cycle times allow you to be more responsive to customers and can allow more rapid process improvement, an important consideration in rapidly changing processes like semiconductor manufacturing. However, short cycle times are incompatible with high throughput: if you're going to make sure that the bottleneck tool is available when the hot lot gets to it, then you risk having the bottleneck tool sitting idle while it waits. For maximum throughput, you always want the bottleneck tool to run at full capacity. That's one reason why JustInTime isn't really compatible with mass customization and other agile manufacturing requirements. Goldratt's approach should be flexible enough to work in a low cycle time environment, simply by redefining the constraints.
To bring this back to software development, I would suggest that in Extreme Programming, the driving constraint in the process becomes the planning game. It controls the release of new development to the programmers. In contrast, if you look at the common waterfall model, you will see lots of constraining steps. First requirements analysis is busy and everything else is idle, then design takes place, then coding, then testing. In many organizations, this is a lot of hand offs between different people, and loops through the system create havoc. --WayneMack
And sometimes a piece isn't quite finished and you need to put it through the machine again. No great drama in XP. Disaster in BDUF. I love it.
Intuitively it feels that in a balanced system no one thing is holding everything back, but everything is working at a pace fitting the part and the whole both. A single constraint is called a BottleNeck.
Oops, the TOC advocates that there is only one or two (at most three) constraints in a particular system. Else, it would be so unstable that would make it unusable. Sometimes (well, usually), the bottleneck (or constraint) is not in the physical process but at the assumption used to build the processes. Back to software development the constraint on the waterfall model is at the premise on which everything is built: software development must be predictive. It held true some time ago, but with OO and other techniques, the premise is no longer true. Consequently, the whole process developed around that premise fails to reach the goal. -- Cloves Almeida
Also see TheGoal and EliyahuGoldratt.
EditText of this page
(last edited November 22, 2014)
or FindPage with title or text search