What is a logical “long arrow”?

In Logical Thinking Process (LTP) parlance a long arrow is a “leap of logic” or the omission of one or several cause-and-effect steps that connect a cause to an effect.

In the Logical Thinking Process, a cause is linked to its effect by an arrow. The arrow’s tail is connected to the cause and the tip points to the effect. Hence the reference to the arrow.

In the picture, the cause is at the bottom and the effect is on the top.

Ellipses are logical “AND” connectors. Arrows going through an ellipse read “if…. AND if… then…”

Some may refer to the AND connectors as “bananas” but I would not encourage this.

The “long arrow” skips several “if…then…” or cause-and-effect relationships, also considered as logical steps.

Leaps of logic are to be avoided for the sake of logical soundness. Long arrows are likely to confuse an audience as the listeners or readers cannot naturally link the things together.

True listeners may have difficulties to follow the speaker’s logic or readers might get confused, lost or perplexed while reading a text.

Many people speak or write long arrows because the sequence of causes-and-effects is clear in their mind. They don’t pay enough attention how their thinking can be received by someone not knowing about the subject, the unspoken assumptions or the implicit and skipped relationships.

The more logical steps or cause-and-effect links skipped between a specific cause and an certain effect and the longer the arrow.

In the scrutinization process of logic trees, long arrows are generally considered as “mistakes” or at least “logical improvement points”. Long arrows are not officially considered as Categories of Legitimate Reservations (CLR), but could in fact. Long arrows should be broken into more detailed steps in order to get the faulty tree more sound and robust from the Logical Thinking Process point of view.

About the author, Chris HOHMANN

About the author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn


Why you cannot use tentative language in a logic tree

I once happen to see a Current Reality Tree cluttered with “coulds” and “shoulds”. Conditional or tentative language cannot be used with logic trees and here is why.

Cause-and-effect (sufficiency logic)

The Logical Thinking Process logic trees use either sufficiency or necessity logic. Sufficiency or cause-and-effect relationship states that a cause, if it exists, is sufficient by itself for the effect to happen. Using conditionals like should or could violates the sufficiency principle as it suggests that the cause is not always producing the effect.

The Current Reality Tree (CRT), Future Reality Tree (FRT) and Transition Tree (TT) are built on sufficiency logic and therefore cannot hold any entity with shoulds or coulds.

If a should or could is found in such a tree, the scrutinizer must raise a “cause insufficiency reservation“. The statement must then be corrected, for example by adding one or more additional cause(s) combining to the first one with a logical AND connector. If this combination is valid, the sufficiency relationship is restored and should or could is removed as the effect is now guaranteed to happen.

If no additional causes can combine to the first one, the cause-and-effect relationship is probably only assumed or false. Anyway no should or could can be left in a logically sound tree.

Using present tense

The entities – the building blocks of the logic trees holding the statements – must be expressed in present tense.

Using present tense is natural in a Current Reality Tree (CRT) as it is the description of the actual situation, the cause-and-effects relationships that exist right now.

The use of present tense in Future Reality Trees (FRT) is highly recommended even so these future situations and the Desirable Effects do not yet exist. Present tense helps to project oneself and the audience into the future and visualize the situation as it were already improved (Scheinkopf, “Thinking for a change, putting the TOC Thinking Processes to use”, p119). Dettmer also recommends to use positive wording (Dettmer, The Logical Thinking Process, p244).

This applies to entities in a CRT, a FRT and in a Prerequisite Tree (PRT) which are verbalized in full sentences.

What about necessity-based logic?

Can necessity logic based tree use conditional/ tentative language?

The Goal Tree (GT), the Evaporating Cloud (EC) and Prerequisite Tree (PRT) are built on necessity logic. They describe the chains of enabling conditions that are required to achieve a goal or an objective. Without the enabling conditions, the objective cannot be attained. Conversely, with the enabling, necessary conditions fulfilled, the objective will not automatically be achieved; additional action is required.

As the Desired Effect is not guaranteed to happen even so all necessary conditions are fulfilled, the use of conditional / tentative language seems legit. Practitioners would not use it though.

First because we need to demonstrate positivity about a desirable change and help the audience to mentally visualize the future where things happen and produce the desired outcome.

Second because we need to give confidence and demonstrate our own trust in the proposed solution. No audience would be thrilled hearing that this solution “may”, “should” or “could” produce the desired result. No decision maker would give his/her go for a change program or a solution implementation which is not certain to produce the expected result.

The use of conditional / tentative language would only raise concern about the feasibility of the proposed solution and appear as a lack of confidence of its promoters.

Wrapping up

Tentative language is recommended in academic writing, not at all with logic trees.

Using tentative language is recommended in academic writing and scientific research in order to leave room for alternatives, later corrections, etc. unless there is solid evidence backing up a statement. Therefore the use of verbs like “appear, suggest, indicate,…”, modals “may, might, can, could, will, would” and adverbs like “possibly, probably, likely…” are recommended.

But when building or presenting logic trees, absolute certainty is required in order to demonstrate robustness of the analysis and the confidence in the conclusions. If a logic tree is built on the canonical logic rules (we’ll consider the use of present tense as a canonical logic rule), has been scrutinized and cleared of all reservations, it is robust and tentative language is no option.

The author, Chris HOHMANN

The author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

The Logical Thinking Process – An Executive Summary (Book)

Bill Dettmer, my friend and mentor often cited on this blog, wrote his 9th book “The Logical Thinking Process – An Executive Summary” that is now in the final stages of the publishing process.

This book will be much smaller in size and number of pages than the famous “The Logical Thinking Process: A Systems Approach to Complex Problem Solving”. The latter is a 413 pages, 17,1 x 3,2 x 24,1 cm (6.8 x 1.2 x 9.5 inches) hardcover book. Bill Dettmer’s students use to call it “The Bible”. It is a complete step-by-step guide, easy to read and understand, but not everybody can invest the time required to read it just to get a primer on the Logical Thinking Process.

That’s where the “Executive Summary” comes in handy. Bill himself stated: “Over the years, I’ve found myself having to explain what the Logical Thinking Process is in 30 seconds or so to people who have never heard of it – or know nothing about it if they have. I came to the conclusion that while the LTP is difficult, if not impossible, to encapsulate in an “elevator speech,” it might be somewhat easier to do in a pocket-sized book.

I was fortunate to be selected by Bill as a kind of sounding board and proofreader, even so Bill did so more out of kindness than necessity, and had a privileged first reading. The book will serve its purpose, I think it can be read during a short business trip on a plane or a train. The final copy should be less than 100 pages.

As soon as I’ll get a copy, I will complete this post with an extended review of the book.

You may subscribe to my blog to keep being informed of new posts or follow me on twitter.

View Christian HOHMANN's profile on LinkedIn

Management attention as a constraint – Part 2

In part 1 of this series, I introduced management attention as a constraint. This second post goes on with more reasons why management fail to pay the necessary attention to the factor limiting the whole system’s performance.

Unaware or wrong about the constraint

Management attention might be on the wrong things because manager are unaware of or are wrong about the system’s constraint.

Spotting the real constraint of a system can be tricky, see my series of posts about this topic: How to identify the constraint of a system?

Not able to identify the constraint

Many managers are unaware about the system’s constraint, in other words: what really limits the system performance. Despite the number of people pretending to have basic understanding of Theory of Constraints, few really have enough understanding to spot the real constraint and to manage it as it should. Instead, many of them are still stuck in older paradigms, seeking the maximum output at every process step and trying to minimize unit costs.

True Theory of Constraints-aware people know that this approach is bound to fail as the global optimum cannot be the sum of local optima. Local objectives will simply compete against each other at the expense of the overall performance.

Unaware of the true limiting factor, management simply cannot focus on what matters.

Identifying the wrong constraint

It is common to mismatch bottlenecks and constraints and also common to wrongly identify a resource or a process as a constraint when it is not. When management identifies the wrong constraint, its attention is focused on the wrong spot and the decisions made won’t help the overall performance.

From a Theory of Constraints perspective, management attention is therefore a constraint itself because it does not focus on the right spot, the real constraint.

Lack of focus

As we have seen in part 1 of this series, lack of focus can come from lack of clarity about the Goal, lax attitude or mismatching the constraint. It can also come from lack of self-discipline or a personal difficulty to keep focused on something for a longer period of time.

Another possible cause is the overwhelming number of things managers must take care of. Their attention is required by so many things that they will task switch (notice I didn’t write multitask), losing their focus to a new problem as soon as it pops up.

Manager’s time is a scarce resource so it must be used wisely. Therefore, managers themselves must know what to focus on and, maybe more important is to understand what’s NOT to spend time on.

Especially in an industrial environment opportunities for improvement are literally endless. It’s very easy to start project on something that looks good and promising but doesn’t benefit the system as a whole.

Therefore it’s very important for management to refrain giving attention to everything and discriminate what will benefit the system and what is just a local improvement.

From a Theory of Constraints perspective, If making more goal-units (often money) is your goal, throughput is your obsession. And if throughput is your obsession, you’ll have literally to sit on the constraint and make the most out of it. Keep focused!

Not enough feedback

Senior management and middle management may be well aware about the organization’s Goal and the system constraint, but do not pay enough attention to give feedback to the teams lower in the organisation. Without clear guidance, those teams can go astray without even noticing, burning up precious and scarce resources working on the wrong subjects. This is a variant of lack of management’s direction and lack of management focus, described in part 1 of this series.

Lack of management support

Subordinates may be willing to work on the right thing but for some reason need management support they can’t get. Management then turns out to be the blocking point, thus the constraint.

There are some legit cases for which subordinates cannot act without management support, but if subordinates are too dependent upon management, there is something wrong.

Many organizations don’t use the principle of subsidiarity, which means delegating action to the lowest possible level. Some managers love to be asked over and over for help and support, but keeping subordinates in this dependency is not a good investment for the future. The flattered managers, making themselves indispensable, are in reality trapped as they have to continuously backup their teams.

Managers should develop their teams to be more autonomous so that they can focus on manager’s tasks, like taking care of the system’s constraint and not turn themselves into one!

Lack of management commitment

Some managers do not buy-in the objectives, the strategy or the organization’s Goal. This may be the case after a merger and acquisition, when a new vision is set by the acquirer, for example. Those managers stay with the new structure to collect their paycheck but pay only lip service to the job to be done. Lack of commitment creates lack of focus and probably a lax attitude.

I’ve met such kind of middle managers in charge of a critical process or constrained resources that didn’t give a dime managing it properly, even after in-depth explanation of its importance for the whole organization. Needless to say that their future wasn’t as comfortable as their past from this point.

Distracted managers

Managers may be attracted (distracted would be more appropriate) by some project or endeavour they like but without connection to the system performance as a whole. Especially nowadays with the hype of the concepts like factory of the future, the industrial internet and the like, it’s very easy to get allured by some new technology and behave like a big child in front of brand new toys.

While dreaming about their new “toys”, the distracted managers don’t take care about the actual critical resources that limit the system throughput.

If you liked this post, share it.

Comments welcome.

About the author, Chris HOHMANN

About the author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

Management attention as a constraint – Part 1

A system’s constraint, the limiting factor that is an obstacle to getting more Goal units* from the system, can be pretty difficult to identify (hence the success of my post on the topic: How to identify a constraint?!).

*”Goal units” can be money, profit, services to citizens, number of patients treated, free meals served, or whatever the organization delivers to achieve its Goal.

The Theory of Constraints community discusses the management attention as a constraint for a long time now and Goldratt himself called management attention the ultimate constraint (the one remaining when all others have been elevated). My own experience convinced me that management attention can indeed be a constraint for the whole system, from the beginning.

Misaligned organization

Striving to achieve the organization’s Goal is management’s sacred mission and it is management’s duty to align the efforts of their subordinates to achieve that objective. Lean Management uses the “True North” metaphor and Hoshin Kanri or Policy Deployment to achieve it. The Logical Thinking Process calls it the Goal and have the Goal Tree as a roadmap and benchmark. Both approaches and their tool sets can be combined.

Now too often management does not clearly communicate about the Goal neither ensure their staff’s energy and initiatives are well oriented towards achieving the Goal.

Surprisingly, some senior managers are not clear among themselves what the organization’s Goal is. Bill Dettmer published a paper on such an experience with a crowd of executives and almost as many Goals as people! The paper is downloadable at http://www.goalsys.com/books/documents/WhatisOurGoal-v5_000.pdf

Management’s attention is on something else, but not on the main objective.

When this happens, scarce resources are often wasted for meaningless purposes, on the wrong things. The longer this goes on, the stronger the evidence that management attention isn’t focused, for whatever reasons, on what really matters.

Chances are that middle managers lacking a clear stated and often reminded Goal define their own objectives for the need of guidance.

Self defined objectives

When subordinates define their own objectives because they have no “True North” to align their own and/or their staff’s work, they may define these objectives to fit their own purpose, their own views or to optimize their department’s performance. Doing so, the probability is high that the self defined objectives will be in conflict with another department’s objectives and at the expenses of the overall organization performance.

Myths and false assumptions

Lack of clear communication about the Goal and lax management may let myths and false assumptions flourish. Most often, myths and false assumptions are the result of lack of clarity, misunderstanding or overinterpretation of some “strategic intent” or senior management statements.

Management attention must foremost be on clarity of purpose, second on the alignment of all actions towards achieving the Goal. With constant attention and frequent repetition about the Goal and checking the progress towards it, deviations as well as false assumptions and misunderstandings can be detected and corrected.

Lax management

Many people have been promoted to management positions even so they lacked the necessary soft skills. Some because it was a reward for past dedication and good job, others because they were technically good and the assumption was they would also be good at managing others. The latter often does not happen.

Unfit for their position, uneasy especially when taking command over former colleagues, lacking the charisma and know-how, many hide themselves behind computers screens or in meetings and shun contact with their subordinates. Management attention is purposely not on what matters because of a form of cowardice, or to put it softer, because of uneasiness.

In order to keep social peace, middle management (at least in France) often tries to avoid frontal assault against deviant behaviors, absenteeism, poor performance and sub-standard achievement.

The situation is often paradoxical between the pressure from above to achieve the objectives and at the same time the strong recommendation not to mess up with work force to avoid social unrest, that middle management is torn between conflicting objectives.

This probably led to management positions popularity to sink to an abyssal low. The younger generations don’t want management jobs anymore.

Additionally, the new generations and their ways of teaming up, networking and work around obstacles. They have no interest in traditional management. They don’t want that kind of job and do not pay the same respect to rank like previous generations did. For them and growing part of the workforce, leadership is more important than status.

All this lead many middle managers to compromise and get lax in their management or give it up for good. Management positions are now harder to man as this kind of job lost much consideration.

Therefore, even if those managers know well about the Goal they should work to achieve, their ability or personal lax attitude does not transmit the necessary energy or inputs to their teams.

Next: Management attention as a constraint – Part 2

About the author, Chris HOHMANN

About the author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

Goal Tree Chronicles – Coloring the Goal Tree

The 3-colors system is a well accepted assessment and visual management tool by Goal Tree builders and users. The principle is simple as it uses the traditional Red-Amber-Green color code to indicate the status of each entity in the Tree.

In a Goal Tree, Necessary Conditions are enablers to the above entity. As soon as enablers are not in place or “unstable”, the outcome they should enable cannot be considered as in place, delivering or achieved.

In this post, I detail how to color a Goal Tree.

How to color a Goal Tree?

Start at the bottom, with the very basic Necessary Conditions. Have the Subject Matter Experts (SMEs) assess each Necessary Condition for its status. As soon as a basic Necessary Condition, which is a requirement or prerequisite to the above entity to exist, is Amber or Red, the above entity can only be Amber or Red. The color, symbol for the status, propagates upwards like in a line of dominos when the falling one pushes the next.

Goal Tree

Reminder: in “my” 3 color system, green stands for granted, constantly available, steady… Amber means unstable, not totally fulfilled, variable… Red means missing, non-existent, not at nominal value, etc.

Therefore, the assessment can be quite quick. The SMEs should know what’s going on on shopfloor, how process behave and deliver. Key Performance Indicators (KPI) may give additional information.

In a starting project, chances are that many identified basic requirements are not yet fulfilled, so their boxes in the Goal Tree are red. As soon as such an entity turns Amber or Red, no need to assess the above related entities, they are Amber or Red by definition.

Related: Goal Tree: How green is your tree?

The requirements that are Green need to be followed upwards nevertheless to see if their above related entities are Green as well, or if an additional Necessary Condition coming in sideways has a non-Green status. If this is the case, the above entity takes the color of the worst of the underlying Necessary Conditions’ color.

The limits of the 3-color system

It can happen that despite an entity having all its underlying Necessary Conditions set to Green can’t be assessed as Green. Facts and figures just don’t allow it. How come?

Well, remember: underlying Necessary Conditions are enablers, not triggers. Unlikely what happens with sufficiency logic where a cause is literally sufficient to produce the effect, the necessity logic used in the Goal Tree states that if a Necessary Condition is missing, the expected effect can not happen, but conversely, the underlying Necessary Condition existence is only enabling the effect to happen.

Entities in a Goal Tree are also called Intermediate Objectives and in order to achieve an objective, 3 conditions are required: having the necessary means to achieve the objective, knowing how to achieve it and being motivated to achieve it.

Related: What it takes to achieve your objective: Means, Method and Motivation

In case a should-be green Intermediate Objectives isn’t green, you should check the Means, Method and Motivation.

If you liked this post, say it, share it!

About the author, Chris HOHMANN

About the author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

How to identify the constraint of a system? Part 5

This is part 5 of a series of posts about identifying the constraint of a system and time for wrapping up and a conclusion (of the series, not the topic!).

Newcomers to Theory of Constraints understand quite easily the concept of bottleneck but are frequently puzzled when looking for them in a real-life process. Furthermore, people have usually difficulties to distinguish bottlenecks or Capacity Constraint Resources from the system’s constraint. As only the latter controls the Throughput of the whole system, meaning it does control the system’s profitability, constraint hunters should better not mismatch the focusing point.

Through the examples in the previous posts, readers can understand that there is no such a thing like a simple trick, neither ready procedure to find the constraint, but a necessary and sometimes painstaking investigation process.

If you missed previous posts, you may check:

Some constraints can really be well hidden and remain elusive, leading analysts to be wrong when identifying it. Because of the growing number of standard and regulatory requirements, the constraint is more and more often found in the paperwork process, in quality assurance or information flow. And this is the wrong place for the constraint to be.

How to be sure the constraint is found?

With so many opportunities to mismatch the constraint, how can one be sure about having found the constraint? Well, by definition the constraint controls Throughput. Elevating the constraint is like opening a valve, the flow through the constraint increases. And as, also by definition, all other resources have excess capacity compared to the constraint, the flow should soon reach the process’ output. This enables the organization to ship more, to ship on time, take more orders and shorten time-to-cash.

For non-profit organizations, the Throughput is expressed in “Goal units”, meaning achieve more of what the organization exists for, like treating more patients for a medical center, providing more food to the homeless, etc.

Now this is quickly noticeable if the downstream process steps are waiting for supplies from the constraint, otherwise the flow from the constraint may take longer to reach the process’ end.

Be aware of the S curve and Valley of despair

As with many improvement initiative, the result may be delayed to a point that some stakeholders come to the conclusion it doesn’t work. Before getting trapped in this pitfall, the project manager or the leader should be aware of the frustration with the S curve.
When dealing with bigger projects rather than improvement activities, it’s not only the S curve the project manager and the sponsors should worry about, but also the “Valley of despair”. This valley is a low in morale following the excitement and expectations about the benefits that the new project will bring. The drop in morale comes when issues and bugs let the new solution appear worse than the old. The challenge for the leader is to get everyone as quick as possible through the valley of despair, accommodate the new way or system and eventually recognize the benefits.

Keep on alert once the constraint is found!

Now once the constraint is properly identified and the efforts to exploit and elevate it begin, the leaders should immediately take care of the consequences of releasing more “goal units” through the constraint.

  • First because the constraint will most probably move to another spot and again this can be anywhere in the process.
  • Second because upstream as well as downstream process steps may be taken by surprise. Upstreams by an increase of demand in order to supply and exploit the increased capacity. Downstream by the flushing of the work in progress that may propagate a significant wave of workload.
  • Third because management must anticipate any necessary action to sustain the flow at the new level, otherwise the success will only be sporadic and ultimately disappointing.

I recommend reading two other posts related to these warnings:


The search for the system’s constraint can be very simple and straightforward, but most often it is tricky and leads to identify wrongly some resources as culprits. It is no rocket science but needs investigation skills and rigor. Experience helps a lot and the good news is that taking care of constraints is never-ending, so experience may accumulate fast.

About the author, Chris HOHMANN

About the author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

How to identify the constraint of a system? Part 4

Since the publishing of early books on Theory of Constraints, the world grew more complex and the system’s constraint got more and more elusive. Globalization and extended supply chains give a constraint opportunity to settle literally anywhere in the world and extend its nature. It can be a physical transformation process in a supplier’s facility, it can be the way cargo is shipped from distant suppliers to the company, it can be the custom clearance process somewhere along the supply chain.

Walking a factory door to door may not suffice anymore to find the system’s constraint. The examples given in the part 1, 2 and 3 of this series of posts are simplified with regard to the reality of most companies.

Another complexity is brought by the growing number of requirements of standards and regulations. A company wanting to count among the aeronautical industry makers has to comply to the AS 9100 (USA) / EN 9100 (Europe) / JISQ 9100 (Asia) standard. For the automotive industry the standard to comply to is ISO/TS 16949 (now IATF 16949). And those two examples are only standards for the quality management system.

Pharmaceutical industry, as some others, require a license to operate. In order to be awarded such a license and to keep it, the company must comply to all requirements, undergo periodic audits and keep record of anything happening along the manufacturing process. This industry is under constant scrutiny of government agencies, regulators, etc.

Therefore, the paperwork associated with products is impressive and requires a lot of resources in the dedicated processes, and as we will see, likely to host a system’s constraint!

Over time, layers of requirements accumulated. And what is a requirement if not a limitation of the way to execute, a constraint?

Quality assurance

Quality assurance (QA), according to wikipedia, comprises administrative and procedural activities implemented in a quality system so that requirements and goals for a product, service or activity will be fulfilled. It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention. This can be contrasted with quality control, which is focused on process output.


Anyone working with a Quality Assurance department soon realises that this department is more acting as a defense attorney for the company against regulatory or standardization agencies, and a watchdog internally than a support for improving quality by problem solving.

For obvious reasons, QA and Production must have a clear divide, as it would not be acceptable for the maker to assess and certify the quality of his own production. Their staff are also distinct. QA usually has a huge influence on decisions and can be very powerful, to the point that top executives have to accept QA decisions, especially when QA has to sign off the release of a batch or clear the allowance to ship.

QA activities are mainly administrative, with some lab testing. QA staff is “white collar”, working a typical 9 to 5, 5 days a week regardless of production. Some QA authorizations are mandatory for the physical batch to move to the next step in the process. Many productions run more than one shift, up to 24/7, while QA works 1 shift 5 days a week. As a result, the paperwork relative to production batches accumulate during the QA off-period and is later flushed during QA working time.

Now here comes the first problem. The difference of working time patterns send waves of workload through the system. It is not uncommon for some production batches to wait for QA clearance in front of a process or in a warehouse. This could give the impression that the bottleneck is in the next manufacturing processing step, but it is not.

In reality the bottleneck is in QA. It can be the plain process of reviewing of paperwork or some testing, measurement, analyses, etc. A trivial yet common bottleneck is the “qualified person”, the one or few ones entitled to sign off the documents. Those people, usually managers, are busy in meetings and other work and let the paperwork wait for them.

Note that QA activities are not always extensively described in the production task lists, do not always have allocated time and if they have, QA department is seldom challenged about the staff adhering to standard time neither to possibly reduce the duration by some improvements. This can lead to underestimate the impact of QA’s activities on the production lead time and “forget” to investigate this subject when searching for the bottleneck.

Dependence on third parties

With an ever growing number of requirements to fulfill and proofs, certificates and log files to keep ready in case of inspection, many specialized tests and measurements are farmed out to third parties. It makes sense, in particular if those activities are sporadic, the test equipment expensive and maintenance of skills and qualification for personnel mandatory.

Now this type of subcontracting bears the same risks than any other subcontracting: supplier’s reliability, capability, capacity, responsiveness, etc. and the relative loss of control of the flow as it is now dependent on a distinct organization. The system’s constraint may well be located then outside of the organization, and even beyond its sphere of influence!

Beware of the feeling of being in control when the third party operates in-house. I remember such a case where a specialized agency was doing penetrant inspection and magnetic crack detection in the company. While everything seemed under control, the external experts often failed to come as scheduled because they still were busy elsewhere or had sick leave. When they were in-house, they frequently lost a fair amount of their precious time moving parts around, a kind of activity not requiring their qualification but significantly reducing their availability for high-value added tasks. It turned out that this spot in the factory often was a bottleneck due to the lack of management’s attention.

Where Value Stream Mapping can help finding the constraint

These examples above show that the information flow or paperwork associated to the physical flow can have a significant influence on lead time and can even decide if the flow has to stop.

In such cases Value Stream Mapping (VSM) can help finding the constraint as it describes both physical and information flows on a single map. Note that some companies including Toyota refer to VSM as MIFA, the acronym of Material and Information Flow Analysis.

Without such a map to guide the investigations, people on shop floor may forget to mention (or are not even aware of) analyses, tests, approvals, paperwork review, etc. during interviews of gemba walks. Experienced practitioners will ask about these possibilities when inquiring in strong standard or regulation-constraint environments.

Where the Logical Thinking Process can help

When the system’s constraint remains elusive despite all the search with previously mentioned means, Theory of Constraints’ Thinking Processes or the Logical Thinking Process variant can help finding the culprit by analyzing the Undesirable Effects at system level.

This later approach is best suited for “complex problems” when the constraint is a managerial matter, conflicting objectives, inadequate policies, outdated rules or false assumptions, myths and beliefs.

To learn more about the Logical Thinking Process and the logic tools, see my dedicated pages, series and posts on this blog.

Proceed to part 5 and conclusion of this series: How to identify the constraint of a system? Part 5

About the Author, Chris HOHMANN

About the Author, Chris HOHMANN

View Christian HOHMANN's profile on LinkedIn

How to identify the constraint of a system? Part 3

Inventories and Work In Progress (WIP) can be helpful clues to visually identify the bottleneck or constraint in a process, but they can also be insufficient or even misleading as I explained in part 2 of this series.

It is often also necessary to study material and parts routes to really understand where they get stuck and delayed. Chances are that the missing or delayed items are waiting in a queue in front of the constraint. Or have been stolen by another process…

In the search for the system’s constraint, experienced practitioners can somewhat “cut corners” by first identifying the organization’s typology among the 3 generic ones: V, A or T. Each category has a specific structure and a particular set of problems. Being aware of the specific problems and possible remedies for each of the V, A and T categories may speed up the identification of the constraint and improvement of Throughput.

V, A & T in a nutshell

Umble and Srikanth, in their “Synchronous Manufacturing: Principles for World Class Excellence”, published 1990 by Spectrum Pub Co (and still sold today), propose 3 categories of plants based on their “dominant resource/product interactions”. Those 3 categories are called V, A and T.

V, A & T plants

V, A & T plants

Each letter stands for a specific category of organization (factories, in Umble’s and Skrikanth’s book) where the raw materials are supplied mainly at the bottom of the letter and the final products delivered at the top of the letter.


V type plants use few or unique raw material processed to make a large variety of products. V-plants have divergence points where a single product/material is transformed in several distinct products. V-plants are usually highly specialized and use capital-intensive equipment.



You may imagine a furniture factory transforming logs of wood into various types of furniture, food industry transforming milk in various dairy products or a steel mill supplying a large variety of steel products, etc.

The common problems in V-plants are misallocation of material and/or overproduction.

As the products, once gone through a transformation cannot be un-made (impossible to un-coock a product to regain the ingredients), thus if material is misallocated, the time to get the expected product is extended until a new batch is produced.

The misallocated products wait somewhere in the process to meet a future order requiring them or are processed to finished goods and sit in final goods inventory.

The transformation process usually uses huge equipment, not very flexible and running more efficiently with big batches. Going for local optimization (Economic Order Quantity (EOQ) for example) regardless of real orders leads to long lead times and overproduction.

V-plants often have a lot of inventories and poor customer service, especially with regards to On-Time Delivery. A commonly heard complaint is “so many shortages despite so many inventories”.

Misallocations and overproduction before the bottleneck will burden the bottleneck even more. Sales wanting to serve their upset customers often force unplanned production changes, which leads to chaos in planning and amplification of delays (and of the mess).

Identification of the bottleneck should be possible visually: Work In Progress should pile up before the bottleneck while process steps after the bottleneck are idle waiting for material to process.

Note: while the bottleneck is probably a physical resource in a transformation process, the constraint might be a policy, like imposing minimum batch sizes for instance.


A-plants use a large variety of materials / parts / equipment (purchased and) being processed in distinct streams until sub-assembly or final assembly, that make few or a unique product: shipbuilding or motor manufacturing, for example.



Subassembly or final assembly is often waiting for parts or subassemblies because insuring synchronization of all necessary parts for assembly is difficult. Expediters are sent hunting down the missing parts.

Expediting is likely to disrupt the schedule on a machine, a production line, etc. If the wanted part is pushed through the process, it is at the expense of other parts that will be late. The same will repeat as the chaos gets worse.

In order to keep the subassembly and assembly busy, planning is changed according to the available kits. Therefore some orders are completed ahead of time while others are delayed.

The search for the bottleneck(s) starts from subassembly or final assembly based on an analysis of the delays and earlies. Parts and subassemblies that are used in late as well as in early assemblies are not going through the bottleneck. Only parts constantly late will lead to the bottleneck. For those, follows the upstream trail until finding the faulty resources where the queue accumulates.


T type factories have a relatively common base, usually fabrication or assembly of subassemblies and a late customization / variant assembly ending in a large display of finished goods. Subassemblies are made to stock, based on forecasts while final assembly is made to order and in a lesser extend made to stock. In this latter case it’s to keep the system busy even there are no sufficient orders. Assembly is made to stock for the top-selling models.



Computers assembled on-demand for instance use a limited number of components, but their combinations allow a large choice of final goods.

In order to swiftly respond to demand, final assembly generally has excess capacity, therefore the bottleneck is more likely to be found in the lower part – subassemblies – of the T.

The top and bottom of the T-plants are connected via inventories acting as synchronization buffers. The identification of the bottleneck(s) starts at the final assembly with the list of shortages and delayed products. The components or subassemblies with chronic shortages or long delays point to a specific process. The faulty process must then be visited until finding the bottleneck.

Yet bear in mind that assembly cells, lines or shops may “steal” necessary parts or components from others or “cannibalize” i.e. remove parts or subsystems on some products for completing the assembly of others. If this happens, following the trail of missing and delayed parts upstreams can get tricky.

Combinations of V, A and T plants

V, A & T-plants are basic building blocks that can also be combined for more sophisticated categories. For instance a A base with a T on top, typical for consumer electronics. Yet the symptoms and remedies remain the same in each V, A & T category, combined or not.

Wrapping up

As we have seen so far along the 3 parts of this series, the search for the constraint in a system is more an investigation testing several assumption and checking facts before closing in on the culprit.

There are some general rules investigators can follow, like the search for large inventories in front of a resource while the downstream process is depleted of parts or material, but it is not always that obvious.

Knowledge about the V, A & T-plants can also help, without saving the pain of the investigation. And we are still not done in the search for the constraint! There is more to learn in the part 4!

Readers may be somewhat puzzled by my alternate use of the name bottleneck and constraint despite the clear distinction that is to be made between the two. This is because in the investigation stage, it’s not clear if the bottleneck is really the system’s constraint. Therefore, once identified, the critical resource is first qualified as a bottleneck and further investigations will decide if it qualifies for being the system constraint or not.

Bibliography about V, A & T-plants

For more information about V, A and T plants:

  • Try a query on “VAT plants” on the Internet
  • “Synchronous Manufacturing: Principles for World Class Excellence”, Umble and Srikanth, Spectrum Pub Co
  • “Theory of Constraints Handbook”, Cox and Schleier, Mc Graw Hill

View Christian HOHMANN's profile on LinkedIn

Goal Tree Chronicles – Enablers vs.triggers

In this post I explain the difference between enablers and triggers in logic trees, which basically is explaining how Necessity logic differs from Sufficiency logic. I then explain the basic assumption when building a Goal Tree and why the Goal will not automatically be achieved even if a most of Necessary Conditions are fulfilled.

Necessity vs. sufficiency

Necessity-based logic requires a prerequisite to be fulfilled in order to produce the expected effect. This is why necessity-based logic uses “in order to… [effect] we must … [prerequisite]” wording in the Logical Thinking Process.

Example: in order to have my hair cut, I must go to the hairdresser.

Even so there are alternatives to the hairdresser to have the hair cut, a prerequisite is necessary for the hair being cut.

Sufficiency, as its name suggests, does only require the cause to exist for the effect to automatically exist. The corresponding wording is ”if…[cause] then.. [effect].”

Example: if it rains, then the lawn gets wet. Or if I drop an ice-cube in hot water (the) it melts. In these examples there is little that can be done to prevent the effect to automatically happen when the cause happens.

Enablers vs.triggers

I assume dear readers, you understand the huge difference between Necessity and Sufficiency. While an effect will automatically happen if the cause exists in the case of sufficiency, the existence of the prerequisite (cause) in necessity-based logic is not enough to produce the effect, it only enables it.

For example, many prerequisites are necessary to build a house, like having a ground, having timber, having a permit, and so on. But having all prerequisite will not lead the house to build itself.

In sufficiency logic, the cause is the trigger while with necessity logic, the cause is “only” an enabler.

The Goal Tree is built on necessity-logic

The Goal Tree, one of my favorite logic tools, is built on layers of Necessary Conditions, linked from the Goal on the top to the very first Necessary Conditions at the bottom by necessity-logic. The convenient way to build a Goal Tree and scrutinize it is to check the sound logical relationship between an entity and the underlying Necessary Condition using the “in order to… [effect] we must … [prerequisite]” phrasing.

The logic trees and cloud from the Logical Thinking Process are either necessity-based or sufficiency-based and in the order of their sequential usage they alternate between necessity and sufficiency.

Now because the Goal Tree is built on necessity logic, the entities composing it are absolutely necessary to exist or being granted for to achieve the Goal. By definition, if one Necessary Condition is not fulfilled, the Goal cannot be achieved.

But, as Necessary Conditions are “only” enablers, nothing will happen as long as no real action is taken.

Achieving the Goal

Achieving the Goal requires all Necessary Conditions or enabling prerequisites to be fulfilled, but it is not sufficient.

This can be disturbing for those being exposed first time to the Goal Tree, because there is an implicit assumption that when the enablers are in place, the necessary actions or decisions will be taken, so that from bottom to top, all Necessary Conditions are fulfilled and the Goal eventually achieved.

Promoters, including me, tend to cut corners and advertise about the lower level Necessary Conditions “automatically” turn the upper ones to be fulfilled, and the achievement of intermediate objectives to happen like a row of dominoes propagating the fall of the first one till the very last: the system’s goal.

This is true if people in charge do their part: take the decisions and/or carry out the tasks.

This is why, “surprisingly”, some entities can be Amber or Red (condition not always / not fulfilled) even so their underlying Necessary Conditions are Green (condition always fulfilled).

If you are not yet familiar with my 3-color system, I suggest you read: 3-color system for Goal Trees


Here is such an example. It comes from an operational Goal Tree built to enumerate all Necessary Conditions to pass over simple maintenance tasks from maintenance technicians to line operators. The simple tasks include daily lubrication and check of tightenings in order to prevent wear and possible breakdowns. The aim is to implement the Total Productive Maintenance ‘Autonomous Maintenance‘ pillar.

Once all Necessary Conditions are listed, the Goal Tree is scrutinized for robustness and if ok, it becomes the benchmark to achieve the Goal. The next step is to assess each Necessary Conditions for its status.

We see in the figure above (showing only a tiny part of the Goal Tree) that all underlying Necessary Conditions to “Daily lubrication / tightening is done” are Green, but the expected outcome, the effect is Amber. Since every prerequisite is Green, we expect the effect to be Green as well. Amber means the outcome is not stable, not always guaranteed, not steadily at nominal level.

It means this expected outcome, the task “daily lubrication / tightening is done”  is NOT done EVERY day.

One may argue that we cannot see any mention of the lubrication / tightening being part of operators’ duties. That’s correct. The reason for this is that in logic trees, obvious prerequisites or assumptions are voluntarily omitted for the sake of keeping the logic trees simple and legible. In our case, the work instructions include the daily lubrication and tightening routine. This is a known fact for everyone concerned with this Goal Tree.

In other words, enablers are ok, but the trigger is still missing.

It is now up to management to:

  • make sure operators have a full understanding of the work instructions,
  • make sure these tasks are carried out and
  • clarify what is to be done if operators face a dilemma like catch up late work or go as planned for maintenance routine.

Fortunately those cases are the exception. People truly involved in a project and having a clear understanding of the purpose will contribute. That is, as long as they are not exposed to undesirable effects, from their point of view.

View Christian HOHMANN's profile on LinkedIn