Sunday, March 31, 2013

Focus and Leverage Part 196


To all of my followers, I made a mistake on my posting number so I'm reposting this as Part 196.

Our piece on the Conflict Resolution Diagram is no quite ready to go to press, so in today’s posting I’m going to substitute what I think is an interesting and common place dilemma facing many manufacturing plants.  I have been working with a client that produces medical devices and a couple of weeks ago I had an interesting discussion with the plant’s GM.

I had done an assessment of his plant earlier in the year and one of the most disturbing findings was the level of work-in-process (WIP) inventory scattered throughout his plant.  It was clear to me, after an in depth look at his operations, that there was no synchronized flow in place.  In fact the system in place was clearly based upon the principles of “push” rather than “pull.”  That is, keep the workers “busy” all of the time.  The plant was also characterized by large batch sizes and no discernible production scheduling system to control the level of WIP.  Part of the discussion I had with the GM was the impact these large batch sizes were having on the overall production lead times which in some cases were as high as 6 months.  This concept of batch size versus lead time is the subject of this posting.

Before moving on, let’s explore the differences between a synchronized and nonsynchronized manufacturing environment.  A nonsynchronized environment is characterized by systems where products have long manufacturing lead times and materials spend a large amount of time waiting in queues as WIP.  Studies have demonstrated that in many manufacturing plants, the majority of manufacturing lead time for materials is actually spent waiting in these WIP queues.  In some plants, the actual processing time on a given order is as little as 5 percent of total manufacturing lead time and this plant’s lead time certainly met this scenario.  Conversely, synchronized manufacturing plants have relatively short manufacturing lead times and materials spend very little time waiting in queues.  Unlike the nonsynchronized plant, processing of materials in a synchronized plant accounts for a relatively high percentage of the manufacturing lead time. 

There are several key factors that impact synchronization in a manufacturing setting, but one of them in particular, batch size, plays a very large role.  As I explained to the GM, improperly chosen batch sizes contribute significantly to nonsynchronized material flows.  The direct result of this lack of synchronization are increased levels of inventory, extended manufacturing lead times, poor on-time delivery and needless operating expense.  Many times these plants must resort to overtime and expedited freight charges.  Of course, this GM did not agree with and asked me to prove it to him.  One of the easiest ways to demonstrate the impact of batch sizing decisions on synchronized flow is by looking at a simple example which is what we did.

In this process example there are two side-by-side machines used to clean the interior of the parts.  The two different media types are used to remove things like burrs or other obstructions/impediments from the parts.  The figure below summarizes the normal running conditions for the parts entering this 2-step process.  The parts to be processed are received from a feeder process in batches of 48 parts and 8 parts are loaded into a fixture which is inserted into the first machine.  These 8 parts are run for 30 minutes and then removed, cleaned and placed in a holding rack.  The next 8 parts are run and the process repeats itself until all 48 parts are completed.  When all 48 parts are completed, they are then moved to the second machine (Media Type 2) which contains a second media type where, like the first machine, are run in batches of 8 parts.  From beginning to end the process takes a total of 360 minutes of elapsed time from beginning to end to complete all 48 parts (i.e. 180 minutes on Media Type 1 machine plus 180 minutes on Media Type 2 machine).  This example assumes no setup time.

This is a classic example of a nonsynchronized flow, but what would this same scenario look like if the flow was synchronized? 

In the figure below we see that instead of waiting for all 48 parts to be completed on the Media 1 machine, after completing the first run of 8 parts, we immediately start processing the parts on the Media 2 machine.

In this case our wait time is the length of time to complete the first run of 8 parts or 30 minutes rather than the 180 minutes of wait time in the nonsynchronized scenario.  Now both machines are running simultaneously until all 48 parts have been completed on both machines.  Instead of taking 360 minutes to complete, as in the unsynchronized flow, we see that the total elapsed time is now only 210 minutes.  In effect what we have done is change the transfer batch size from 48 parts to only 8 parts and the result was an almost 60% reduction in lead time.  It didn’t cost us anything to achieve the seemingly impossible (impossible to the GM that is).

It should be apparent then that one of the key considerations we should always be evaluating is the concept of transfer batch sizes within a facility as part of our synchronized flow process.

Bob Sproull

Tuesday, March 26, 2013

Focus and Leverage Part 195


In this posting we will complete our Current Reality Tree for Dome and then talk about next steps.  The Thinking Process Tools are quite dynamic and can be used to solve a variety of system problems.  The problem in many organizations is that the symptoms that exist are often mistaken as the problem to be solved and we end up only treating these symptoms.  In reality they are part of a chain of cause and effect relationships which terminate with a true root cause or core problem.  Herein lies the real power of the CRT…..identifying the one or two core problems that create all or most of the negative symptoms (UDEs) that exist within our organization.  Let’s continue on and complete our CRT, so you may want to keep our last posting handy for reference (i.e. Focus and Leverage Part 194).

At this point it could become possible that the next entity we are looking for might not be on our list, especially if we look at entity 10 and 60.  Let’s look at both entities, 10 and 60, and see if there is a statement on our list that might be the effect of either one of these.  It doesn’t appear as if there is a fit, at least for what we have listed.  If that is the case, then ask the question: “What would be the effect of either one, or both of the entities?”  How about a statement that reads: “Some customers are unhappy with Dome’s performance.”  It wasn’t on the list but, it is probably an entity statement that does exist.  So, now we will invoke the Entity Existence reservation from the CLR’s and determine if the some customers are really unhappy with Domes performance.  As it turns out, this is a true statement.  Why else would they want Dome to pay a late charge?  It makes sense.

 
If you read up through the tree looking for sufficiency on the arrows and clarity of the statements you will notice it is a bit jerky in the flow.  By using the Additional Cause reservation we can add an additional cause entity between 50* and 20*.  The reason this becomes necessary is to clarify the effects of the change orders on poor on-time delivery.  Is it sufficient to say that many change orders will cause poor on-time delivery?  Are there other things that could cause poor on-time delivery besides just change orders?  Let’s add the statement: “Change orders slow down production for orders already started.”  We’ll add this statement with the ellipse on the arrows, which is the logical “and” statement.  The “and” statement implies that both entities must exist together for the effect to happen.

As you can see, by adding this statement to our tree it also adds clarity to reading the tree and adds the missing piece as to “why” on-time delivery might be affected.

At this point there are still two UDE statements on the list that haven’t been used.  Let’s take a look at those and see if we can integrate them into the CRT.

1.Quality is becoming a problem.

2.New product design/ development seems slow.
 
Let’s look first at “Quality is becoming a problem.”  There are two places to start.  First, ask yourself, “what caused Quality to become a problem?  The second question would be, “What effect happens because of the poor Quality?”  The most probable answer to either of these questions is not on our remaining UDE list.  Let’s work the quality statement and see if we can figure where it fits and why.  This scenario is a great opportunity to look for any Predicted Effects (one of the CLR’s) that might come from poor Quality.  As you ask the question(s) and look for predicted effects it is important to validate any affects you might discover.  Even though an effect might be logical, it can only be valid if it exists in your reality.  Let’s look for some predicted effects and see if they exist.

Let’s ask the question “What else might you expect to see if Quality was poor?  We might expect to see that “many products have been returned.”  We might also expect to see higher levels of “product rework” because of failed inspection.  In the business case write-up, neither of these negative affects we listed.  However, that doesn’t mean they don’t exist.

What we have discovered is two predicted effects that would/should exist if Quality really is becoming a problem.  If you observe the system, or ask the questions, to find out if these entities exist then, you can validate the entities.  If neither one of these entities exist then, it is doubtful that Quality is a real concern (maybe it happened once or twice, but does not occur on a regular basis).  However, if one, or both, of them exist, then the Quality problem is validated.  For the sake of discussion let’s assume that both of these entities were validated to exist at Dome.  Let’s work these into the tree.  It is possible that there is cause-effect-cause relationship between 120 and 130, i.e., many products being returned could cause higher levels of rework and repair.  If there are higher levels of rework and, repairs and rework take additional production time then available production capacity is reduced doing repairs and rework.  If production capacity is reduced doing rework and repairs then, it helps provide another causality as to “Why” on-time delivery is poor.

 

By adding this next segment to the CRT the causalities for poor on-time delivery begin to expand.  Another question to ask at this point is “Why is Quality becoming a problem?”  In other words, we see the effect but, what is that cause?  If we search for the cause there could be several possible answers.  One possible cause is that Production is trying to build too fast and is making mistakes.  Another possible cause is that product inspection is not finding (or overlooking) the production flaws in order to keep up with the demand. (it can happen in many companies in order to keep pace with cash flow demands.)

 

There is no “and” statement here because each entity by itself could be sufficient cause to generate the effect.  If one, or both, of these entities exist they could be causalities for the Quality problem.  If neither entity exists then, the search continues for an applicable cause.  For our discussion, let’s assume that both do exist.  Let’s take it one step further for these entity effects and ask “Why do they exist?”

These two additional entities (160 and 150) would make sense to cause both 140 and 141.  So far this CRT has expanded greatly and surfaced additional entities that were not part of the original UDE list.  In all fairness the search for additional entities could continue, almost to an infinite level.  But, at some point you need to decide “When is good enough – good enough?”  These lower entities were not revealed in the original business case, not because they aren’t important, but because the people at Dome didn’t view them as problems.  Their assumption is that efficiency is “important”, and if I push the products in they will come out.  Let’s look at the entire CRT.

The general rule when analyzing a CRT for the root cause is to find the entity nearest the bottom that has the most arrows coming out of it. Or, to find the entity that causes at least 80% of the remaining entities.  The 80% rules is most typical when you have a tree configuration that contains two distinct branches (or more) that seem to run parallel to the top. With each branch covering basically a different subject matter.  Go as deep as you can, find the one with the most arrows coming out if it, or that causes at least 80% of the other entities and you’ve found (most likely) what you are looking for.

There was one additional UDE that has not been discussed yet.  The UDE was “New Product Design/Development seems Slow.”  If you think about this UDE it probably does exist but, it is outside the scope of this CRT.  It is mostly un-to-itself.  The design side would present a different subject matter than the production side.  Right now we are interested in getting products delivered on time and not necessary designing them on time – at least not yet.  With that said it would be possible to work the “New Product Design/Development seem Slow” UDE into this tree.  However, it would add complexity and much more time to scrutinize and develop.

The real benefit of a CRT is being able to collect the UDE’s and realize that they are not individual problems that need to be solved in isolation but, rather there is a cause-effect-cause relationship between them.  We could spend a lot of resources and time trying to solve these individually.  The CRT allows, with some time and thinking, the ability to FOCUS on the problem that will provide the most LEVERAGE to improve the system.

With the CRT information now in your hip-pocket and the first part of the system analysis complete it is time to ask a question.  Based on this tree – what do you think the root cause is for Dome's problems?  In the next segment we will use the Conflict Resolution Diagram (CRD) to continue our analysis.
 
Bob Sproull

 

Sunday, March 24, 2013

Focus and Leverage Part 194


Building the Current Reality Tree (CRT)

In the last posting we presented the business case for analysis and asked if anyone had ideas on how to help Bill with this analysis.  The Dome Company appears to be a company in chaos and what is required is to help them develop a path forward to improve.  We did receive a few recommendations, but one of them stood out by recommending the construction of a simple Current Reality Tree (CRT).  In the next several postings, we will do just that.  We intend to build this CRT methodically so that everyone who is not totally familiar with CRT’s will see what powerful information can be gleaned from it.  Remember one of the keys to improvement is the recognition of the many cause and effect relationships that exist and that most of the time, if we simply take our time to identify the one or two core problems and "fix" them, most of the symptoms we see will disappear.

Develop the Undesirable Effect (UDE) List

From the business case you can instantly deduce many undesirable effects (UDEs) that are taking place within this company.  The important step here is to determine the important few from the frivolous many.  In others words determine which ones are important and which ones aren’t so important.  Many times an original UDE list is only one side of the story and it’s usually the management side.  Every story usually has two, or more, sides and it’s important to get ALL sides of the story.  So, how do you do that?  First, is what you are being told is the problem – is it real?  Second, would be from observation of the system.  What do YOU see as you watch products move through the system?  What do you hear when you talk with people on the line? Third, would be validation that what you are being told actually exists.  Many times what someone thinks is happening can be far removed from what is actually happening.  This UDE gap can widen between what you are told versus what actually exists.
With an accurate and robust UDE list you can determine ALL of the system effects, in this case the undesirable effects.  We see the system effects, now we must understand the cause for these effects. For every person who reads the business case the UDE list would most likely be similar but, different. Each person might focus on, and highlight, different comments and observations for their UDE list.  Not to worry.  Many times the difference can be overcome with emphasized scrutiny using the CLR’s (see posting 192 and 192B for an explanation of the CLR’s).  So, let’s build the list and start from there.  A good list will consist of 5 – 10 UDEs.  It’s a place to start and more UDEs will probably surface when you start to build a CRT.  To develop the UDE list, answer the question: “It bothers me that….” Our list would include:

10 Dome is losing sales
20-time delivery is poor
30 Some orders are sometimes entered incorrectly
40 Quality is becoming a problem
50 Production has many change orders
60 Some customers want Dome to pay a late charge
70 New Product design/development seems slow

This list is probably good enough to start.  We’ve hit some of the highlights from the business case.  Now we need to take these effects and start assembling into a CRT to surface the cause.

Building the Current Reality Tree (CRT)
First, look for two entity statements that look like they might be related to each other in terms of cause-and-effect.  Remember:  the CRT is sufficiency based logic, so the logic statements are “If entity A …Then, entity B”.

(NOTE: The number with the asterisk in the box is strictly a number system to give an entity address.  This number (or a multiple of it – e.g. entity 1 x 10 = 10 which is the designation used here) is how it appeared on the UDE list.  The asterisk indicates that this entity came from the original UDE list.  This can be important to distinguish between original UDEs and surfaced UDEs.)
It would appear that “poor on-time delivery” would be sufficient to cause a “loss of sales.”  The next question would be, “Is there anything else on our list that could happen because of poor on-time delivery?

It appears as if entity 60 can also be an effect of late on-time delivery.  From here you can work the tree in two different directions.  First, look for any effects on the list that might be caused by entity 10, or entity 60.  Second, you can ask the question, “What caused entity 20?”  For sake of discussion let’s look on our list and see if we can identify a cause for entity 20.  There is a possible connection between entity 20 and 50 on our list – “Production has many change orders.”


So far, it appears to be a good fit.  It seems sufficient and it also makes sense.  “If Production has many change orders, then On-time delivery is poor.”  Now, there are four (4) possible avenues of continuance.

1.)  Is there another effect on our list that comes from entity 50?

2.)  What caused entity 50?

3.)  What is the effect of entity 10?

4.)  What is the effect of entity 60?

 

Let’s look on the list and see if there is something that could cause entity 50?  If you look at the list you’ll notice 30 – “Some orders are entered incorrectly.”  That statement would seem sufficient to explain “why” production has many change orders.  However, in this case we are going to invoke the clarity reservation and add some clarity to the statement.  We will change the statement to read: “Some orders are incorrectly entered into the system.” 

In our next posting we'll continue building our CRT, complete it, and then move on to our next Thinking Process Tool, the Conflict Diagram.
Bob Sproull

 

 

Monday, March 18, 2013

Focus and Leverage Part 193


In this next few series of posts we’re going to use a case study to demonstrate how to use the TOC Thinking Process (TP) tools.  This posting sets the stage for future posts on these tools.  Take a look at the following scenario that Bruce Nelson has put together and then let's hear from some of you on how you would handle this analysis to help Bill Smith solve these problems.
 
Jonah Course:  A company for analysis

The Dome Company has been in business for 35 years.  It is a privately held company owned by a father and two sons.  The father is Bill Smith, and his two sons are John and Don.  Bill acts as the CEO, and his two sons are Vice Presidents.  John is the VP of Operations, and Don is the VP of Administration.  Both of Bill’s sons have attended college and graduated with business degrees.  Bill attended some college but did not graduate.  Bill originally started the business in his garage and it has grown to the point that it is currently producing revenues of about $10M a year.  The raw materials (RM) are about $6M a year.  The operating expenses are about $3M a year.  Net profit (NP) is about 10% or $1M per year.  However, in the last 18 months revenues and profits have begun to shrink. 

The company makes electronic components for the high end electronics industry.  Most products are standard off-the-shelve, with a few custom design products.  The custom design products can generate a nice profit margin.  They have a fairly modern manufacturing facility of about 20,000 sq ft. and employ about 60 total people. Of the 60 about 40 are in the manufacturing/production organization.  The remaining 20 are in all of the support organizations including engineering, quality, purchasing, human resources, sales, etc.  In the past, their products have met or, exceeded the industry standards for quality. However, lately they have had an increase in product returns for quality problems.  Current product pricing seems competitive and their prices are similar to the competitor’s.  Dome is convinced that their pricing is already “rock bottom” and they don’t want to start a price war in the industry.  They are making only small margins on some products right now.

Recently, in a morning staff meeting George, the Director of Sales, complained about the loss of sales to competitors and how they are taking business away from Dome.  George centered his complaint on the fact that Dome IS NOT getting the orders delivered on time.  George says it is extremely hard to talk with customers and take new orders when customers have doubts that Dome can deliver on time.  Some of Dome’s customers are even asking them pay a penalty if they deliver late.  George wants to put pressure on production to make products faster in order to meet the customer demand.

George also complained about the slow response of Dome to design new products.  He claims that their competitor’s can design, and start production on new products 2 to 3 months faster than Dome can. Their competitors can establish a solid customer base for the new products before Dome can even finish the design. 

The Production Manager, Pete, responded to George’s complaint of late orders.  Pete stated that the plant is currently working 2 shifts, 10 hours per shift, to reduce the backlog and ship on time.  Pete complains’ that the high percentage change orders, even after the order has started production, has become a big problem lately.  Some order changes require starting production over again.  Pete estimates this happens 5 - 10% of the time.  In Pete’s mind it isn’t production that is causing the problem, its sales for not getting the order right the first time.  Pete says production can make the order, if they just had the correct order information to begin with.

Greg, the Quality Manager addresses the increase in quality problems.  Greg says the he’s not sure why the increase in quality problems has occurred.  However, he suspects it might be an issue with production because they are trying to build products too fast and not taking the time necessary to make sure the quality is right.  Products that might not have passed inspection in the past are being rushed through the system in order to meet demand.  Greg believes that production needs to slow down and do it right.  Greg is convinced that the quality problem will go away if production would just do it right.

This staff meeting has been reduced to a finger pointing exercise and everyone is blaming everyone else.  Bill calls the meeting back to order.  He realizes now that there is a serious problem in his company, but he’s not sure what it is, or exactly how to fix it.  He must find a way to correct this problem.  Bill calls you to do an analysis of his company and tell him how to correct the problem.  Anybody have an idea for how to do this analysis for Bill?
 
Bob Sproull

 

 

Sunday, March 17, 2013

Focus and Leverage Part 192B


I apologize for the delay in posting the second half of the Categories of Legitimate Reservation (CLR), but here it is.  The CLR’s set the stage for the development of the Thinking Process Tools such as the Current Reality Tree (CRT).

 CAUSE INSUFFICENCY

The Cause Insufficiency reservation challenges the assumption that a single cause is sufficient to cause an effect.  The stated cause may be a partial statement or partial reason why and effect exists, but it is not sufficient by itself to cause the effect.  Let’s walk through an example.

 

      

 



In the above example A we challenge the assumption that the cause for the downturn in sales is because the competitor has improved their product.  The fact is there could be other reason for the downturn and not just because the competitor improved.  There could also be reasons the the competitor offers a lower price, or perhaps has perceived higher quality, both of which could cause a downturn in sales.  If could also be that “we have not improved our product” to keep up with customer needs.

The point here is that in example A the reason are sales are going down is probably caused by more than just our competitor improving their product.  This statement is most likely part of the cause but, not the entire cause for the effect.  In example B we have added another cause which makes it much more probable to achieve the known effect.  The ellipse added to the arrows is the logical AND statement.  If entity 1 AND entity 2 then, the effect.  Neither of the bottom two entities are sufficient, by themselves, to cause the effect but, when both causes are present (there could even be more causes) then it is much more probable to achieve the effect.  A reminder of caution; There can be a tendency to abuse cause insufficiency by trying to be so fractal in the thinking that the message becomes unclear as to what is really meant.  In other words, trying to add so much detail in the causes that it becomes unclear what the message really is.

ADDITIONAL CAUSE

There are times when a single cause is sufficient to cause an effect.  But, there can also be times when an effect can also be caused by an Additional Cause.  In other words, each cause by itself can be sufficient to create the effect.  The caution is using the Additional Cause reservation is that the additional cause must be relevant and have a scale of effect at least equal to the already stated cause. Just adding additional causes because you can is discouraged. However, adding additional cause because you must is highly encouraged.  Let’s walk through an example and understand how this works.
 

In example A, the cause of a downturn in the economy is sufficient to cause the sales to go downward as stated.  In the example B we propose an Additional Cause that could also cause sales to go downward.  Each cause is independent of each other but, each can cause the effect independently. Therefore, these entities and arrows are not connected with the “AND” statement (ellipse).  We could also add an additional cause such as, “Congress has not approved a budget.”  As true as that statement might be it is also possible it outside the relevancy for what your tree is trying to accomplish. Hence the desire to add additional causes because you can (discouraged), rather than because you must (encouraged).

 

CLARITY

The Clarity reservation can be used on arrows and also with the words in an entity statement.  Sometimes it can make a significant difference with an entity statement to verbalize correctly the words within an entity.  As an example, suppose we had written an entity cause statement claiming “All employees are frustrated with the situation.”  It might be possible to use the Causality Existence reservation and determine that not “ALL” employees are frustrated!  By changed the clarity of the entity statement and changing the word “All” to “many” or “some, or “most” the meaning is significantly altered.  Instead of “All” Employees being frustrated what we really meant was only some, or many or a few are frustrated.

Anytime you have a reservation about an entity statement or the arrows between entities it is important to ask for Clarity and determine exactly what the proposer meant by his or her statement or arrow.  The assumption to invalidate is that everyone is clear and knows exactly what is being said.

 TAUTOLOGY

Tautological logic is also known as circular logic.  In others, the cause determines the effect, and the effect circles around and determines the cause.  The logic goes no direction except in a circle.  Some examples are: “if our team lost the game… then, they played poorly.”  So, you might asked “What caused tem to play poorly?”  The response is most likely “Because they lost, didn’t they?”

Most often it is warranted to be suspicion of tautology when using the when using the Causality Existence reservation.  If it is difficult, or impossible, to verify another effect from a single cause you most likely have an intangible–cause supported by only a single effect.  If that happens be very suspicious of a circular logic situation.

USING THE CLR’s IN GROUP

The primary function of the CLR’s is to seek understanding about what is being presented.  The CLR’s should not be used as a tool, or method, to ridicule, intimidate, or worse belittle someone based on what they are presenting.

In a group you first challenge is – seek to understand.  This can best be accomplished using the CLR’s wisely to make sure you understand what someone else is saying

Your second challenge is – seek to be understood.  If, and when, you do have a reservation, seek to be understood and explain your reservation in a non-threating way.  If you happens to raise and additional cause reservation, or perhaps a Cause Insufficiency reservation you must be prepared to offer any additional cause(s) and explain the cause insufficiency as you see it.

CONCLSIONS

As you might be able to tell by now the understanding and correct application of the CLR’s is a crucial component of any Thinking Process analysis.  Most of the time, it is very noticeable to discern which Thinking Process trees have been correctly subjected to the CLR’s and which one haven’t.  When a tree has been properly constructed and scrutinized the smoothness of flow and clarity floats to the surface.  This is usually most evident when reading a tree to a person or group and what you notice is that the people just shake theirs heads in agreement.  If, by chance, you notice someone with a puzzled look stop and make sure they understand what is being said.
 
In our next posting we will lay out a case study for a company and see how to develop a current reality tree.

 

Sunday, March 10, 2013

Focus and Leverage Part 192


Categories of Legitimate Reservations (CLR’s)

 In this posting, we’re going to take a closer look at TOC’s Thinking Process tools.  No discussion about the TOC Thinking Processes would be complete, or accurate, without an in-depth discussion about the Categories of Legitimate Reservations, commonly referred to as the CLR’s.  In most discussions, the CLR’s are often ignored or glazed in briefness. However, the CLR’s are an extremely important component for using the TP, and conducting a successful analysis.

The concept behind the CLR’s is they provide the methods and tool to scrutinize the entities, entity statements and arrows between the entities themselves.  The CLR’s can apply to ALL entities  and tree within the TP stable.

Let’s begin with a short review of the TP.  The TP tools are based upon two different type of logic for construction and verbalization.  The first type of logic is Sufficiency Based and implies that the arrow between two entities is sufficient to cause the relationship of sufficiency between the two entities. In other words, it’s a cause-effect-cause relationship between entities.  From single cause statement can come many different effects statements, with a minimum of one effect.  What the arrow implies between two entities is that the entity at the base of the arrow is “sufficient” to cause, or have caused, the entity at the tip of the arrow.  The sufficiency arrow is read “if (the entity at the base of the arrow exists), then (it is sufficient to cause the entity at the tip of the arrow to also exist). The thinking tools associated with sufficiency include the Current Reality Tree (CRT), Future Reality Tress (FRT) and, the Transition Tree (TT).  The second type of logic is focused on Necessity.  In other words, you are looking for the “necessity” relationship between two entity statements.  In determining necessity the arrow between two entities is read “in order to have... (entity at the tip of the arrow), I must have…(the entity at the base of the arrow).  Necessity logic thinking includes the Pre-Requisite Tree (PRT) and the Conflict Diagram (CD).

The important take-away from the discussion above is the emphasis on the entities and arrows.  The arrows are the binding element that holds the trees together.  If we get the arrows and entities wrong, then there is high probability that the entire tree is wrong!  This is the important, and distinctive, aspect of the CLR’s to help determine if the tree is logical and correct.  The CLR’s are used to validate entity existence, causality existence, predicted effect existence, cause insufficiency, additional cause, tautology and to insulate the arrows for correctness and accuracy.

In logic we are dealing with the relationships between entities therefore; the basic relationship is defined as cause-effect-cause relationship.  This relationship is focused on the “causality” between the entities and is expressed with an arrow between them.  Scrutinizing entities and arrows on a tree can be frustrating and very time consuming but, also worth the effort.

Each of these seven CLR categories has a purpose, and the best of expression for each category should be applied to EVERY entity and arrow in a tree.  Let’s review the seven CLR’s for application and expected outcome for the use.

ENTITY EXISTENCE


For an entity to be accurate and correct it must be expressed as a statement.  Making a statement does not mean that the entity statement is valid therefore; it must be scrutinized for its existence in reality.  If the entity does not exist in reality it cannot be used as an entity in a logic tree.

The primary focus of the entity existence reservation is to ask yourself “Does the entity, as stated, exist in reality?”  If it doesn’t, then clarify the wording in the statement to reflect what reality really is.  As an example:
                                                     
                                   A                                         B
 
 
In the A example above it can easily be argued that the cause (base of the arrow) is NOT a statement.  If you try and read this arrow using sufficiency and the “If…, Then…) it makes no sense.  It should be replaced by a complete statement that reflects reality and solidifies the arrow between the two entities.  Example B provides such a statement.

It is worth noting that in a negative tree, each entity MUST be scrutinized to its existence in current reality.  In a positive tree (Future Reality Tree) when you are dealing with entities that do not or might not exist yet, then this category of the CLR is only valid for those entities in the tree which ARE NOT considered Actions.

CAUSALITY EXISTENCE

Probably one of the most powerful reservation checks is causality existence.  This can be accomplished by reading the arrow between two entities.  Read the arrow by asking “If (cause)… Then (effect).”  Train yourself to read the words EXACTLY as they are written.  Avoid the tendency to add words, or leave words out of the statements.  If you add or delete words then it is only a partial statement and needs to be changed to reflect what is really is.

Causality existence reservations can occur when the “If…Then” statement appears acceptable to one person but, not to another person.  In other words, one sees the connection, but the other person does not.  This situation does not mean that the “cause” is not legitimate (valid), it just means that the cause must be validated.  This condition seems even more pronounced when it is associated from the existence of a “cause” that might not be verifiable.  If such is the case, how do you verify the existence of a “cause?”  The most practical step is to verbalize another “effect” that can come from the ventured “cause.”  The verbalization of an additional effect that comes from the cause is sufficient to verify causality existence.  By being able to show the existence of, minimum two, directly verifiable effects that come from the same cause, then the cause is verified. In the example it could be argued by person (a verbalized reservation) that the cause of “Sales are going down” is not “Customer markets have changed”, but rather something else (the A example).

                              A                                                        B
 
By being able to verify the existence of another “effect” (minimum two) stemming from the cause, the cause is verified.  The effect could be verified by an increase in sales alternative products within the current company, or perhaps from an increase in sales from a competitor.  However, this data may prove much harder to get and verify.
 
PREDICTED EFFECT EXISTENCE

The predicted effect existence is used most often to invalidate a cause.  This can be accomplished by surfacing any additional causes (minimum one) that must be present in order for the cause to exist.  In other words, if the cause really does exist then, “What else would you expect to see?”  If your predicated effect does not exist, and it should exist but, doesn’t then, the cause is not really the cause. As an example, let’s walk through the following scenario.
                           A                                                      B 

 
In our example it states that “If the battery is dead (cause)…Then the car won’t start (effect)”. The Predicted Effect Existence challenges the assumption that the battery is dead. “If the battery is dead…then nothing electrical on the car should work”.  What we have listed are several other “electrical” components that should also NOT WORK if the battery is really dead.  If, in fact, these other electrical components DO NOT work then, is it highly probable the car battery is dead.  However, if any of these electrical components DO work, and work well then, it is highly probable that a dead battery is not the reason the car won’t start. The Predicted Effect Existence can quickly validate, or invalidate, a perceived cause.  If the stated “cause” is invalidated it swiftly points to the need to find another “cause” to achieve the “effect” of why the car won’t start.
 
In our next posting we'll cover the remaining Categories of Legitimate Reservation (CLR) and then begin taking a closer look at our Thinking Process Tools..
 
 

Wednesday, March 6, 2013

Focus and Leverage Part 191


I know that I promised to get back into a posting on performance metrics, but I’ve been involved in a discussion on my favorite LinkedIn Group, TLS.  This discussion has centered around the use of my favorite tool of all time, the Intermediate Objectives Map (IO Map) which Bill Dettmer now refers to as a Goal Tree.  Although I have tried to change my reference to the IO Map as a Goal Tree, it just doesn’t seem right to use this expression even though the principal developer of it (Bill Dettmer) has changed its name.  I know I’ve written about this tool before on my blog, but there’s more to say about it.

First I want to state unequivocally that the IO Map does not replace Goldratt’s original Thinking Process (TP) tools such as the Current Reality Tree (CRT), Conflict Resolution Diagram (CRD), the Future Reality Tree (FRT), etc.  But what I am saying is that for me (and I might add Bill Dettmer recommends this as well), the IO Map is the natural starting point for the use of the TP tools.  Actually the true starting point is to first define the boundaries of the system we are studying primarily to determine which elements of our problem lie both within it and outside of it.  The reason we start with boundaries is because we need to know which elements are within our span of control and which fall within our sphere of influence.  Those elements that fall within our span of control are those things that we have unilateral decision and change authority on while those that fall within our sphere of influence are those things that we can only influence.

As Dettmer rightfully points out in The Logical Thinking Process, “the distinction between span of control and sphere of influence is important because we can influence far more than we can control.  The Thinking Processes provides us with a way of expanding our sphere of influence to include things we never thought possible.”  So let’s take a look at the basic elements of the IO Map in more detail……namely the Goal, Critical Success Factors and Necessary Conditions.

So exactly what is the purpose of a Goal?  I think Steven Covey said it best with his immortal phrase “Begin with the end in mind.”  A goal is an end-point, a destination if you will, for which we strive to achieve.  For example, suppose you are overweight and you want to lose….say 50 pounds.  Your goal then might be as specific as losing 50 pounds.  Who sets this goal?  If you are the person who wants to lose 50 pounds, then it’s very clear that you set the goal.  But what if you’re the owner and CEO of a company.  Since you own the company, doesn’t it stand to reason that it’s you who decides what the goal is for your company?  In other words, the goal is established by the owner(s) of the system and it is stated as though it has already been achieved.

The Critical Success Factors, on the other hand, are the high level requirements that must be in place before the goal can be achieved.  The CSF’s are also stated as though they were already in place…..as terminal outcomes.  In our simple example of losing 50 pounds, our CSF’s might be written as follows:
Because the IO Map is a necessity based logic structure, it is read as, In order to become 50 pounds lighter, I must eat healthy, exercise regularly and avoid stressful situations.  Each of these three CSF’s are stated as terminal outcomes that must realized and achieved before we can achieve our goal of being 50 pounds lighter.  One could argue that these aren’t the CSF’s someone might select for losing weight, but for demonstration purposes, they will suffice.

The next level of the IO Map are Necessary Conditions (NC’s), but unlike the Goal and CSF’s, the NC’s are written more as activities that must be completed before each of the CSF’s can be realized.  As such, the NC’s are seen as discrete actions that must be taken to achieve the CSF’s.  The NC’s form the basic foundation for the entire necessity based logical map.  It is from the NC’s that improvement action plans can be developed.

As I said earlier, what prompted this posting was a discussion on the LinkedIn Group, TLS where one of the members asked the question, “What are the best Lean or TOC metrics to use to analyze the current state of a manufacturing site?  There were lots of suggestions forthcoming and then I recommended using an IO Map.  So what does the IO Map have to do with developing the best Lean or TOC metrics to analyze the current state of a manufacturing site?  Let’s look at an example from Epiphanized that Bruce and I used to demonstrate how this can be done.
Joe and Sam, two of the key figures in Epiphanized, had been asked to help a corporate team come up with a list of key performance metrics.  Joe knew that everyone would necessarily have to agree on a goal. Knowing this group was motivated by money and financial metrics, he suggested that the goal should be read, “Make more money now and in the future,” and everyone nodded in acceptance.  Joe then explained the concept of the Critical Success Factors (CSFs) and Necessary Conditions (NCs) to the group.  After many attempts to develop a complete IO Map, the group finally agreed on the final version.  It was not perfect, but for its purpose today, perfection wasn’t a prerequisite.  After all, the real purpose of this team was to develop a new performance measurement system, and this diagram would facilitate that objective.
The next step for the team was to focus on what metrics would be used to evaluate Barton’s overall performance in the days to come.  With that in mind, Becky suggested that the group take another fifteen-minute break.  So how do you think it’s going Becky?” asked Joe as he lit his cigarette.  “I think it’s going very well,” she replied.  “Let’s just hope that the selection of metrics will flow as easily,” she added.

Just as Joe and Sam lit another cigarette, Paul came out to join them, and to their surprise, he actually complimented them on their work so far.  Needless to say, they were all stunned, but they were even more stunned when Paul asked if he could lead the metrics piece.  “Of course you can, Paul, and if you get stuck, we’ll be here to help,” said Becky. And with that, they went back into the conference room.

Paul, who was a character who previous to this meeting had been adamantly against the adoption of Throughput Accounting, was simply brilliant in his leadership of this phase of the group’s activities, and the final outcome, the IO Map with metrics, was a thing of beauty—at least that was the consensus of the team.  It was clear that Paul had just been epiphanized and it would not go unnoticed or unreported in Becky’s mind.  Paul had somehow managed to incorporate all of the Throughput Accounting metrics and formulas into a single blueprint for Barton that everyone agreed would work.
So there you have it, an example of how performance metrics can be developed by first starting with an IO Map.  While the metrics for the Goal and CSF’s are high-level organizational metrics, as we move down through the organization other important lower level metrics can be developed and tracked.

Bob Sproull