The purpose of this blog is to record my day to day growth in understanding and application of the Theory of Constraints (TOC). This first blog is copied from an email conversation that I am engaged in with a colleague. We are both currently employed by a large financial services institution, albeit in different divisions. I have been studying TOC under the tutelage of Dr. Lisa Lang and Brad Stillahn at the Science of Business. I welcome and encourage you comments.
Quote from a Jonah:
I am a certified Jonah. The issue with TOC is that when you subordinate all activities to the constraint, it not only promotes, but necessitates waste. This is a difficult concept for business leaders to embrace. In the financial services world, your machine resource is actually people. FTE is very scalable, so some of the concepts of TOC become less value-add. Also, in our world, we are required by law to produce a certain quantity in a certain timeframe. In the manufacturing world, you typically are trying to anticipate customer demand and produce exactly what is needed. If you under or over produce you end up with a stock out or excess finished goods inventory. Both are bad, but the OTS won't come and shut you down because of it..
My reply:
TOC thinking processes can be applied to any business situation. The first time I read The Goal, I came away with the impression that the manufacturing bottleneck was the constraint - only after a second reading did I come to realize that the management team had to overcome much more than just increasing capacity through the bottleneck (aka Capacity Constrained Resource (CCR)). They repeated the thinking processes throughout the story every time they ran into an obstacle to finally end up with an impressive magnitude of improved throughput.
I assume that you are familiar with Critical Chain PM? Project Management by definition does not fit in the manufacturing world - however by applying cause-effect analysis using the thinking processes led to a PM approach that has achieved far superior results over the traditional PMBOK approach. TOC methods have also been applied to software development with fantastic results (Best to Worst in 9 Months).
Servicing can be viewed as a manufacturing process - there is input, processing and output. The processing is performed by people running machines (computers) that transform the state of the work in process. The process is performed repeatedly to deliver the final products - posted payments, completed payoffs, etc. We should take a more holistic approach, analyzing not only the servicing workflow, but also looking at policies and assumptions that have been ingrained over time - we should be able to identify the constraint that is keeping us from achieving
our goal...
Start with identifying the goal - make more money now and in the future. Then identify the constraint...given our current technology and human resources (and regulations, of course), what one "thing" governs over our ability to increase throughput - is the constraint in the market or internal? - I assume we have account execs trying to sell our service - would they say that they cannot make additional sales because there is nobody buying, or are they restricted by their perception of our capabilities? I would guess the constraint is internal... if so, what is holding the sales team back? Assuming it is lack of capacity, what is the constraint that is governing our ability to increase throughput? Is it a certain type of resource bottleneck? Is it a policy? (perhaps the way work is assigned results in bad multitasking - is there too much work-in-process?) I think if we were to start analyzing the business in that manner, we would be able to quickly identify improvements that would have immediate results on the bottom line.
By the way - TOC does not promote nor does it necessitate waste. For example, the DBR method requires that non-bottlenecks have "excess" capacity to protect the bottleneck - protective capacity by definition is not waste and, managed properly, this capacity can be utilized to
increase throughput. Also, by implementing TOC, there is a huge reduction in overall wip - which is a net reduction in waste. Furthermore, by subordinating your improvement efforts to the
constraint, you should be able to reduce wasteful expenditures trying to improve the non-constraints - again, a net reduction in waste.
3 comments:
Hi Dave,
Thought I'd connect with you through your blog in the first place, having just scanned the posts so far.
Re your discussion on TOC and waste, think about the difference between 'activating' a resource and 'utilising' it. Activating a resource such as a machine in a production plant would mean 'make stuff'. Utilising the machine would mean 'make money'. Do you see the difference? To people with cost world thinking, not running the machine always looks like waste.
Thanks for your comments Eric. I coundn't agree with you more - "elegantly" put, I must say! My friend has not overcome this concept of activity vs utility since there is an underlying assumption that an idle resource is waste.
Another thing that troubles me about his comments is the statement that FTE is very scalable. To me this implies up and down scalability...further implying FTE are disposable. Isn't that counter to the very core of TOC? Once you have excess capacity wouldn't the goal be to sell it - rather than to scale back?
Hi Dave,
By FTE I take it that you mean people (full time equivalents)? If so, I share your reservation.
The scaleability of FTEs varies around the world and depends on local employment law. Certainly in the EU it is a significant management task to make people unemployed or to hire people - not trivial at all.
So perhaps this is a question of focus. Cutting people clearly reduces OE. But how might this impact Throughput?
Post a Comment