Business Analysis and the Theory of Constraints

During one of "infamous" my lunch time walks, I was pretty excited to hear "MBA213" - Mastering Business Analysis Episode 123 "Applying the Theory of Constraints

What was even more interesting is the person talking in this episode Clarke Ching tells a very similar story to how he got into the Theory of Constraints (TOC) as my own story.

For me, it was around 1999, when I first came across "The Goal" in audiobook format. It was also my first experience with the 'business novel'. The Goal was written by Elijah Goldratt and Jeff Cox, and is an amazing story of Alex Rogo a 'middle manager' of a manufacturing plant, and he interactions with "Johah" his old college professor giving him his sage advice.

I absolutely loved the book and at the time was working in a quasi-manufacturing company, I was also learning to be a quality assurance manager, and the two fell hand-in-hand.

The key concept in all of Goldratt's business novel is the theory of constraints, mainly the 'simple' concept that you can dramatically improve the entire output of a system by identifying and only focusing on the constraints of the system.  Moreover that no matter how complex the system seems, it likely has only one or two constraints, that once identified and exploited improve the entire system.




The trick, of course, is identifying where in your system the constraints lie, and correctly identifying something as a constraint.  Some key tips that the novel touches on when identifying a constraint.

a) It likely has built up 'work in progress'.  That is their is a queue of things built up beside it that are waiting to be done - be careful however just because something has a queue does not mean it is the constraint, it is just an indicator.

b) The "work center" produces a sub-set of output that is fed into other outputs which create the final product.  It is a link in a chain.  Specifically, this work center can be setup / configured to produce multiple different outputs and has multiple different 'WIP' in front of it.

c) The constraint typically is being used a large percentage of the time, while items further down the line are 'waiting on it' to finish.

d) The key piece that identifies a constraint is time. If you measure the time an item processes through the mfg process, any time lost on a constraint is time lost in the entire system.  If it normally takes 1hr to make 100 widgets, and part of the machine that makes the widget is down for 1hr, those widgets are used to make product 'x', and you are behind in 'product x' but have lots (too many) product 'y', then that machine is likely the constraint.

Now this is all well and good if you are in the manufacturing industry, but what if you are in a service industry, or what if you are a programmer/development shop?

The key here is that the 'constraint' need not be a machine at all.

A resource constraint is where a resource providing the service is the constraint NOT a machine

A policy constraint is where a policy is limiting the output of the process. For example if you policy requires you do produce work in a specific way, but another way may increase your output, the policy is the constraint.

While it may seem intuitive that the next step would be to "eliminate" your constraint,  this is actually NOT what you want to do.

The key to TOC is in exploiting the constraint, re-arrange your processes such that you recognize that the constraint is the limiting factor for your output, and then subordinate all your efforts to improving that constraint.

From a manufacturing point of view, this might mean redirecting the flow of incoming processing to other work centers / machines that can preform the same work as the constraint.

From a project management perceptive this means arranging your work, tasks, and priorities such that all non constraint tasks are redirected resources to work on the constraint first before going back to the scheduled item.

Think of each item moving along a chain from one spot to another, and a drum beating at the pace of your constraint, each item moves through each work center (or resource) at the pace at which the constraint can handle (NOT at the maximum speed of the other work centers).  Put special buffers around the constraint to make sure it receives its incoming workload 'just in time (jit)' This is known as 'DRUM-BUFFER-ROPE'

Well that's a brief intro anyway. To learn more check out Goldratt's books, "The Goal", "Critical Chain", and keep an eye out for future posts. 

Good Luck !


If you liked this post please consider sharing via your favorite social networks!!

and ..if you like my blogging, video, audio, and programming - please consider becoming a patron and get exclusive access @ Patreon.com/GeekWisdom

Comments

Popular posts from this blog

Programming Rant - Stop the Insanity!! - .NET 7 is not the successor to .NET 4.8

Everything in Moderation...

So I started a Podcast ! - The G33k Dream Team .

Way back then...Apple ][

Diabetes is not caused by eating too much sugar !!!

Buy Local - the online way

You should be able to do that...

Software Tools - Productivity or Distraction?

Child Rights and Confidentiality

ChatGPT and Artificial General Intelligence