Maybe, but IMHO, TOC is due for a shake up. Continuing the path is a path into oblivion. And that, that would be a great pitty.
Some wake-up statements
Although far from restricted to TOC, there is this eery question that continues to pop up: "how can we convince our clients/others to use ...". Of course it is with the best of intention, well there is this nice saying about best intentions ... But please, how thick can you be? Well, I was. But who truly can believe they have THE answer for anybody?
For years people, of course the TOC-minded ones, have claimed that TOC is the best problem-solving approach available. That there is no better way to do an analysis. IMHO they can't be more wrong than that. For reasons as simple as: TOC is NOT a problem-solving approach, TOC is NOT about doing analysis. Not because I say so, but TOC says so itself.
TOC, the Theory of Constraints, claims to derive its strength and power from constrained-based thinking. Well, the truth might be a bit different. The strength and power is derived mostly from limited-by-constraints thinking. This is actually very powerful for focusing, but by no means a justification to call itself the Theory of Constraints.
It is not wrong to be proud about TOC, that is not the issue!
How TOC started
But lets first move a few decades back. A time just before TOC came into existance, a world resembling much of today and yet how different it was. A time mostly driven on and by production, a time when capacity was seen as infinite, a time where labor costs where small, a time of large volumes and incidental product changes. A time where things were pretty predictable. It was a time where rational thinking emerged and grew into systems thinking.
But the world started to become less predictable. Of course like now with Big Data, the bets were on computers being able to crunch data. The ERP systems came up, but many of them failed short in expectation and practical use. Not because they were very costly, not because it required a huge amount of effort to keep feeding it with details. No, it failed mostly because of one reason: the ERP systems assumed infinite capacity.
Although I will follow a bit more the path of TOC, we can't really ignore what Deming did and achieved. Most that know Deming associate him with Quality. No doubt about this, he is a pivot point in history with respect to quality. But Deming is actually about building a sustainable future. Yes, back then quality was important to move forward, but he already warned: "They were the best in their industry, they made the best products, where are they [carburator manufacturers] now?" Reducing costs is important, but you're not in the business to reduce cost. Improving quality is important, but you're not in the business to improve quality.
Eli Goldratt picked up on a couple of things. His zealous quest against cost cutting mentality, not because he was against cost reduction. Also he managed to come up with an algorithm that assumed finite capacity. A breakthrough. And the foundations for TOC was laid.
TOC doesn't care about problems, it looks how the objective can be achieved. It is all there in the Focusing Steps: Step 0 = determine the goal. 'Problems' that do not affect the achievement of the goal are 'ignored'.
TOC doesn't do analysis, well not at first. A great deal of the time and energy goes into the synthesis: establishing how things are related and connected, testing that understanding.
Times changed
And now? Today a very dominant factor has become the service industry (I consider s/w development also a service). Production of course still exist, but a few changes have happend. Today, most companies biggest challenge is agility. The deterministic models and thinking that worked so nicely in the past have been caught up by reality.
Unfortunately too many of the models and thinking that seem to be slipping into the service. An industry who is all too willing to embrace them: 6 Sigma, optimized batch sizing, kanban, etc. All of these require high volume / no change and sufficient / surplus capacity, predictability. None of these requirements are even close to what the service industry is all about: low volume / high change rate, shortage in capacity. Today it is much more about business agility than ever before.
The human factor has become more and more dominant. The time of rationality is not gone, but is more limited. One of the things that seems to fill in this gap of change, is the Cynefin framework.
Cynefin framework
I don't think that the Cynefin framework itself will be of help other than to be able to solve some of the challenges on a meta-level. There is a lot to say about the Cynefin framework and the best person for this is Dave Snowden. If you study Cynefin framework, please keep in mind:
- NONE OF THE DOMAINS ARE BETTER OR WORSE THAN THE OTHER (except disorder maybe).
- Don't type an organization or even suborganization, it is all about a situation. It is perfectly possible that at the same time different extracts of a situation reside in different domains.
I will concentrate more on one way of looking at the Cynefin framework: looking at it from a constraints point of view.
Within the Cynefin framework constraints have a different feel about it than within TOC. TOC assumes a constraint to be the limiting/preventing/blocking factor to achieve an objective. If something doesn't limit the achievement of an objective, it isn't a constraint.
There is one other thing I must address before going into the constraints. Within the Complex and Chaotic Domain you don't think in terms of objectives to achieve. It is emergent. Now, if your reaction is anything like that of mine or Bill, that is perfectly fine. The valorization takes place in the Complicated Domain. Dave Snowden has IMHO a love affair for the Complex and Chaotic Domain, but by no means he denies the importance of the Complicated Domain nor Simple Domain ...he just as an allergy for when things become more constrained.
If a situation resides in the Complex Domain and valorization is required, then create a situation where it will move into the Complicated Domain. A bit abstract maybe, but feel free to dive into Cynefin framework
If a situation resides in the Complex Domain and valorization is required, then create a situation where it will move into the Complicated Domain. A bit abstract maybe, but feel free to dive into Cynefin framework
Cynefin framework & Constraints
There are different ways of approaching the Cynefin framework, but for now I'll use Daves ideas related to constraints. Constraints in Cynefin framework are things that influence behavior and thinking. The stronger the constraints, the more predictable the outcome. The looser the constraints, the more interactivty can take place and the less predictable the outcome will be.
If the constraints are very tight, then Cause = Effect, Simple Domain. A good way to test this, is that everybody will follow the predescribed solution without even questioning if it should be questioned (e.g. pay-rolling). Best practise.
If the constraints are reasonably tight, this means that the outcome is still predictable. Then Cause --> Effect, Complicted Domain. The domain where we do the big projects, the generating of money, most of the core business. A good test: multiple solutions are possible, but the expert(s) will advise and people will follow the advise. Good practises.
However, when constraints are loose. Then the interaction of Cause --> Effect --> Cause and the iterations means that things are no longer predictable. At best some guesses about the direction. A good test: multiple solutions are possible, but expert(s) will not be followed. It feels like indesisiviness, no alignement, etc. However, this is also the domain where multiple solutions can and should be explored, where out-of-the-box thinking can take place, innovation.
The last one Chaotic Domain. Here we don't even see Cause ??? Effect. Usually a situation when there is really time pressure to do something. To come to grip again, getting grip. Dave Snowden and party have even created a number of 'workshops' that exploit part of this. Those workshops have but one aim: disrupt the thought processes, disrupt the thinking of people. We know the saying, you can't fill a full cup.
At least it took me some time, and maybe I'm wrong, but in all this I see great potential for TOC 3.0. You can do much more with constraints then just finding the 'most limiting' and 'exploit it'. Constraints Management can get a whole new meaning. Some things probably need to change, also depending in what domain it is applied. But mostly what needs to be changed is how TOC-minded people view TOC.
- TOC is a mean, not an end
- TOC is a goal-achieving methodology
- TOC is primarily concerned with synthesis = relationship between things, and which work and which don't work
- Constraints are not restricted to that what limits/blocks/prevents and something that must be identified and exploited. Constraints are things that can be tightend and loosend to make things possible that are otherwise not.
No comments:
Post a Comment