About the question “What is TOC?”

/5 Comments/in /by

Jelena Fedurko-Cohen,  4 August 2019

After our recent broadcast of ThinkCamp OnAir on 1st August, an unexpected for me topic – “Does everyone share the same understanding of what is TOC, and what is the definition of TOC?” – emerged in the course of the after-the-broadcast discussion.

My answer in this discussion was: “In our (Oded’s and mine) understanding TOC is a combination of principles and rules that are the basis for specific mechanics and tools to manage some types of social systems.”

Since I am still puzzled by the question, this morning out of curiosity I opened Eli Goldratt’s Chapter 1 in Theory of Constraints Handbook (Mc Graw Hill, 2010). Chapter 1 title “Introduction to TOC – My Perspective”.

The very start of the chapter, p.3, Eli: “[…] can we condense all of TOC into one sentence? I think that it is possible to condense it to a single word – focus.”

This goes on to the sentence opening the first section titled “Focus”.

p.3, Eli: “There are many different definitions to the word focus, but a good starting point is a simple definition such as “Focus: doing what should be done.”

p.3, lines fourth and third from the bottom of the page, Eli: “[…] when we can’t do it all, it is of the utmost importance to properly select what to do; it is of the utmost importance what we choose to focus on.”

p.4, the last sentence in the section “Constraints and Non-Constraints”, Eli: “We don’t have a choice but to define focus more narrowly: do what should be done AND don’t do what should not be done.”

With that I would like to refine the definition of TOC that I have given in the discussion. In my understanding, TOC is a combination of principles and rules that are the basis for specific mechanics and tools to manage some types of social systems in such a way that it allows those who manage these systems to do what should be done and not to do what should not be done.”

The section titles in Chapter 1 and the content of the sections list the key ones of these principles, rules, mechanics and tools:

  • Constraints and non-constraints (p.4)
  • Measurements (Throughput Accounting with T, I, OE) (p.4)
  • DBR and Buffer Management (in the section “The Goal and The Race”) (p.5)
  • 5 focusing steps (in section “Other Environments”). On p.5, Eli specifically defines 5 Focusing steps as “a precise verbalization of the focusing process”. Hence, tying WHAT is TOC (=focus) to the process outlined by 5 focusing steps.
  • CCPM
  • The Thinking Processes. On pp.5-6, Eli specifically points out: “To focus properly, the following questions had to be answered: How do we identify the constraint? What are the decisions that will lead to better exploitation? How do we determine the proper way to subordinate the non-constraints o the above decision? […] There was the crying need to provide a logical detailed structure to identify the core problem, to zoom in on the ways to remove it, and to do so without creating new UDEs.”
  • The Market Constraint (p.6)
  • Capitalize and Sustain (pp.6-7)
  • POOGI (in section “Ever Flourishing”, p.7)
  • S&T Trees (p.8)

Keeping the above in mind, I feel steady proceeding with my definition of what TOC is: a combination of principles and rules that are the basis for specific mechanics and tools to manage some types of social systems in such a way that it allows those who manage these systems to do what should be done and not to do what should not be done.

To answer a possible comment regarding how to treat TOC principles and applications that are not outlined by Eli in Chapter 1 of the Handbook, I will quote a line from the short story with which Eli started Chapter 1: “[…] the rest is just derivatives.”    

  Jelena Fedurko-Cohen,  4 August 2019  

 

What the Cloud is NOT for

/0 Comments/in /by

Published by Jelena Fedurko-Cohen, 6 March 2018

There are several typical situations in which people wrongly perceive that they should use the Cloud.

  1. Confusing a regular assessment process with the dilemma AFTER the assessment, thus wanting to use the Inner Dilemma (Conflict) Cloud

The Inner Dilemma (Conflict) Cloud is to be used NOT for the situations when we are presented with two (several) options to assess, but for the situation when AFTER assessing the options we are swinging between them unable to choose.

In other words, the Inner Dilemma (Conflict) Cloud is NOT for the situations when we know we have to / would like to do something, and having two options, we naturally ask the question, “Should I go for Option 1 or Option 2?”

The Inner Dilemma (Conflict) Cloud is for the situations:

  • When we KEEP ON asking ourselves “Should I go for Option 1 or Option 2? Or Option 1? Or option 2? Or Option 1? Or Option 2?, etc”.

Keeping on asking the question “Should I go for Option 1? or Option 2? Or Option 1? Or Option 2?” happens when after assessing both options we see that they are sort of ‘equal’: one has strong positives on some critical criteria that we have set for choosing, while the other one has not less strong positives on other critical criteria.

  • Or when AFTER assessing the available options, we KNOW WHICH option we should take (according to the criteria for decision-making that we used) but we are reluctant to take this option and keep on considering the other option.

Another typical mistake:

  1. Interpreting ANY regular alternating behaviour in a system as a signal for using the Cloud

The fact that the conflict boxes D and D’ in the UDE Cloud present regular alternating behaviour  – sometimes  we do this, but other times we behave in an opposite way (e.g. ‘buy more inventory vs buy less inventory’ or ‘take expensive corrective actions vs. stick to the plan/budget’, etc .) – often lead people to want to treat ANY alternating behaviour as a case for a Cloud. This is not correct.

When approaching traffic lights drivers some times keep on driving, other times they stop. It is an alternating behaviour, however it has nothing to do with the Cloud. Driver’s behaviour in BOTH cases is regulated by THE SAME procedure that explicitly covers cases in which situation which behaviour is prescribed.  The procedure is clear, prescriptive, does not leave room for ‘my personal perception/interpretation’ and MUST be followed. Moreover, the BOTH behaviours are there to meet THE SAME NEED (not to endanger other traffic participants).

The UDE Cloud is for the situations when we do something UNTIL WE CANNOT DO THAT ANY MORE and we swing to the opposing behaviour.

This is in order to protect TWO important needs of the system presented in B and C of the UDE Cloud. We do D in order to protect B and keep on doing D UNTIL we cannot do it any more because we start explicitly hurting C. So we swing to D’ to start protecting C and keep on doing D’ UNTIL we cannot do it any more because B starts suffering really bad. This goes on and on.

 

Published by Jelena Fedurko-Cohen, 6 March 2018

TOC and Risk Management for Projects

/0 Comments/in /by

11 January 2018, Oded Cohen  

In a recent post on TOC4U (8/1/2018) Rajeev Athavale wrote:

“Risk Management” is a standard process covered by PMBOK. It is an excellent process and is highly useful. However, I am not able to connect this process with TOC. Risks may not arise out of constraints. They typically arise out of events – internal as well as external.

Even though Rajeev states that the standard process provided by PMBOK is excellent he requests to learn how TOC handles Risk Management and especially for projects and IT projects.

Rajeev also wrote: “When I look at this [what the PMBOK offers (OC)], I struggle to find any process in TOC which can either invalidate this process or replace this process or compliment this process. I am seeking to know this.”

I disagree with any attempt for using TOC to invalidate other processes that work. What is the point? What for?

In 40 years that I have been with TOC we have never embarked on such a quest. If there is a process that works – it means that there are no problems and no GAPS or no UDEs. TOC also does not make coffee. So what?

We better focus our efforts when there are needed. Bringing Value is only where there is a real need – a problem that cannot be easily overcome.

However, discussing TOC and Risk Management may have its own merit, because unlike Rajeev there may be other practitioners that do not find the PMBOK suggestion practical.

Throughout the years there have been many cases of amalgamation of TOC with other approaches such as TOC with TQM, TLS, Goldratt and Deming and many more. Such amalgamation has been fruitful when practitioners have found that other approaches have suggested the WHAT is needed to be done but has not provided the HOW. In such cases TOC can be of a significant help.

Hence we offer our views.

Read more

The TOC Buffers

/7 Comments/in /by

11 November 2017, Oded Cohen  

Last Thursday (9th November, 2017), I gave a presentation in the 35th TOPA Conference in Vilnius, Lithuania on TOC Buffers.

Discussions that followed the presentation have brought me to realize that there is some misunderstanding of the TOC Buffers.

The word/term Buffer is commonly used today as reserve, on top of, etc. – generally to indicate a mechanism for protection for the unknown, mishaps and unexpected.

Some TOC practitioners have the perception that Buffers in TOC are there just to absorb variability. This is partially true but it is not the full picture, and this does not explain the difference between the meaning of the ‘TOC buffers’ and the conventional ‘buffers’.

The TOCICO dictionary states that: “buffer – Protection against uncertainty. The protection is aggregated and may take the form of time, stock (inventory), capacity, space or money.  Buffers are strategically located to protect the system from disruption.”

Actually, the above definition is true for any protection mechanism that was inserted into major conventional managerial systems as early as the 1950s and onward.

Read more

Opinion and knowledge

/1 Comment/in /by

15 October 2017, Oded Cohen and Jelena Fedurko-Cohen 

TOC is a knowledge based approach, not an opinion based one.

The difference between the knowledge and an opinion is that

  • the knowledge constitutes the established and tested sets of cause and effect connections that have hard proofs that appear in different sets of conditions, environments and realities so consistently and so many times that it excludes a possibility that effects appear there by chance,
  • while an opinion is an expression of a belief or conviction of an individual. That’s true that this individual may have evidence in their reality of the existence of whatever their opinion expresses. They often use this evidence as an argument to say that their opinion is CORRECT.

However, they overlook that this evidence is NOT the proof of the CORRECTNESS of their opinion, but the DEMONSTRATION of HOW THE OPINION ITSELF WAS FORMED.

Read more

God bless CEOs for resisting what consultants would love them to do

/0 Comments/in /by

07 October 2017, Jelena Fedurko-Cohen 

This post reflects my thinking about the recent discussion on Linkedin and TOC Practitioners Worldwide about a suggested new type of constraint – “Human constraint”.  The new term was suggested by Angela Montgomery who published a post on TOC Learning and TOC4U titled: ‘The Human Constraint – What Is It?’

Angela wrote: “Ultimately, the human constraint, what prevents us from moving forward, is our ability to challenge and transform our thinking. We believe there is a structured, systemic and systematic way ahead”.

I will leave aside the convenience of calling what one thinks they have a solution to as a “constraint”.

I was wondering: HOW – what is the SPECIFIC MECHANISM – of DETECTING that AN INDIVIDUAL ABILITY to challenge and transform one’s thinking is the CONSTRAINT of that person?

Who can judge that? Based on what?

When we say that the company has a CAPACITY constraint for these and these products and a MARKET constraint for other products – there is a CLEAR mechanism to detect that.

To understand whether the system has a Capacity constraint or a Market constraint we compare the existing capacity and the amount of orders to fill in this capacity within a bucket of time. If the demand on capacity exceeds the existent capacity (not averaged, but real, per product) – we conclude that the system has the capacity constraint for those products. If the capacity exceeds the amount of orders – we conclude that the system has the market constraint for those products. The same system can alternate between capacity and market constraint for the same products depending on seasonality, etc.

Please note that the CONCLUSION of where the constraint is – in Capacity or in the Market – is made (and is MEANT to be made) by THE PEOPLE IN THE SYSTEM, NOT by an external consultant.

Let’s return to the suggested ‘Human Constraint’ – the ABILITY to challenge and transform one’s thinking.

What is going to be compared with what to make the CONCLUSION that MY CONSTRAINT is MY ABILITY TO CHALLENGE AND TRANSFORM MY THINKING?

Who will be making this conclusion? A consultant? HOW DOES A CONSULTANT KNOW THAT MY ABILITY TO CHALLENGE MY THINKING CONSTRAINTS ME? Constraints me as compared to what? To the CONSULTANT’S DESIRE OF WHAT I MUST THINK AND DO?

If MY constraint is MY ABILITY to challenge MY THINKING – then by definition I CANNOT THINK THAT I NEED TO CHANGE MY THINKING. So – I cannot come to the conclusion that it is MY CONSTRAINT. Then it is someone EXTERNAL who will announce that THIS is my constraint. And this someone will tell me how to exploit that little that I have. And will tell me how I must subordinate EVERYTHING ELSE TO WHAT THE CONSULTANT SAYS. Interesting…

If the CEOs or other decision makers in THEIR SYSTEMS reject what the consultants tell them to do – the CEOs are RIGHT!!

It is THEIR systems, it is to THEM – and NOT to the consultants! – that the owners of the systems gave the right, the authority and the RESPONSIBILITY to manage the systems on the owners’ behalf!

The CEOs resist ONLY when what the consultant offers is NOT PROFESSIONAL ENOUGH for THIS SYSTEM.

If the CEO does NOT AGREE to the problem, or direction of the solution, of the benefits, or that the negative outcomes will not appear, or that the solution is doable – the CEO IS RIGHT!

This only means that what the consultant offers DOES NOT MAKE SENSE TO THE PERSON WHO HAS BEEN JUSTIFIABLY TRUSTED TO MANAGE THE SYSTEM!

This is NOT the system of a consultant. By resisting, the CEOs PROTECT THEIR SYSTEMS FROM BEING DAMAGED.

And we did see the cases when consultants badly damage the systems.

And the last comment – quite often TOC consultants use Clouds to demonstrate to the stubborn CEOs how right the consultants are and how constrained in thinking the CEOs are. There is no wonder that the CEOs are not impressed – in most cases the logical connections demonstrated in such clouds do not stand a routine logical check.

Published by Jelena Fedurko-Cohen, 07 October 2017

When we meet “Resistance” – is it really resistance and is it connected at all to Layers of Resistance?

/1 Comment/in /by

21 September 2017, Jelena Fedurko-Cohen 

In my experience, in TOC community, the phrase “Layers of resistance” is used quite often in situations when a person just encounters a disagreement in the process of communication or absence of the desired behaviour.  And quite often, after this phrase is used, people start referring to the TP tools that are used to deal with every specific Layer of Resistance.

Here are the common mistakes:

1. Confusion of Entity Existence Category of Legitimate Reservations with resistance and conflict

Read more

There is no ‘stupid rule’

/0 Comments/in /by

01 September 2017, Jelena Fedurko-Cohen 

The role and objective of a rule – any rule – is to restrict. A RULE prescribes the RIGHT way – in order to restrict one from taking wrong ways.

Restricting comes only from the need to prevent a potential negative outcome of doing things ANY OTHER way than the way prescribed from the rule. Please note that in this case the negative outcome is KNOWN. An effort to prevent a known negative outcome cannot possible be stupid, and cannot be looked at as ‘stupid’. From the point of view of preventing a known negative outcome, a rule is smart and responsible.

Read more

Does TOC have the tools and mindset to understand the benefits to the customer?

/1 Comment/in /by

07 August 2017, Jelena Fedurko-Cohen 

In a recent discussion in TOC Practitioners Worldwide FB group https://www.facebook.com/groups/1014476831927643/ Richard Zultner made a statement: ”In ToC we do a great job of understanding the benefit of our production, distribution, and retail solutions to the BUSINESS (theirs and ours). But what we must also do for certain project types (e.g., new product development), is to understand the benefits to the CUSTOMER. And ToC is weak at this, because we have no tools, and the wrong mindset.”

I was surprised to learn that there is such perception at all. This statement made me realize that there must be quite a gap in the knowledge and/or interpretation of TOC concepts, tools and techniques among the TOC community. And probably not only in this area.

My response to Richard’s statement was “This is simply not correct.”

Let’s take the claim that TOC has ‘the wrong mindset’ in regard to understanding the benefits to the CUSTOMER (as opposed to the BUSINESS – theirs and ours). Let’s assume that by “CUSTOMER” Richard meant not a company that is a customer for the TOC solution (because otherwise it would be a BUSINESS), but the final customer, the one that uses the product (any type of product).

TOC has a very strong mindset about creating for a BUSINESS a DCE – Decisive Competitive Edge. A Competitive Edge can be created ONLY by keeping the benefits to the CUSTOMER as the central element, the focus and the main drive of the solution. The benefit to OUR business (as the product provider) comes ONLY AS THE BY-PRODUCT of recognizing and finding how to create the benefits to our CUSTOMER.

Read more

The future of CCPM – What exactly do we mean when we say “The constraint is in the market”?

/1 Comment/in /by

20 July 2017, Jelena Fedurko-Cohen

Here are my thoughts after the recent late evening discussion, during the Berlin TOCICO Conference, regarding the future of CCPM.

The summary of the meeting was recorded by Oded and presented in our Facebook group TOC Practitioners Worldwide:

Twenty seven members joined the meeting. The title for the session was – The future of CCPM, as this was assumed from the discussion in our Facebook group that there is further interest in discussing and better understanding where is CCPM heading towards. 
Talking about the future implies that something is wrong with the current situation or there is a treat that must be addressed. 
However, at the meeting it became apparent that the majority of the members do not think that there is something wrong with the existing knowledge and product. Even though at is current offering is may not be enough for all the environments that members operate in and as such they need some further specific development.
The majority of the concerns expressed were regarding how to sell it? What value to offer? How to handle Agile? What to do with the diminishing perceived value that a project manager is bringing to their organizations?

Read more