blog – Page 2 – tocExpert

Building culture in a new organization vs ‘mending’ culture in an existing organization

June 13, 2017/1 Comment/in blog /by Jelena Fedurko-Cohen

13 June 2017, Jelena Fedurko-Cohen

I want to share some discussions that we had during Tribute to Eli, two days ago, 11 June 2017, when people from many countries came to the Goldratt House in Bene Atarot, in the suburb of Tel Aviv, to share memories and celebrate legacy of the man that has touched so many lives. It was a great day, with the atmosphere full of warmth and light. Tribute speeches and discussions were dedicated to Eli, his impact, his legacy. As it happens when people know each other for many years and share professional interests and passion, the day was very intense with discussions, moving from one subject to another with the central line being how to strengthen the way TOC helps people make significant improvements in their systems and individual lives.

I want to share here a part of discussion that Dr. Shoshi Reiter and I had after Eli’s memorial. We were looking into challenges of managing projects in cluster organizations and eventually moved to discuss whether there is difference between building culture in a new organization versus ‘mending’ culture, i.e. changing a part of culture that malfunctions for the one that works properly’. Is it so that when a new organization starts building culture the starting point it ‘Zero’, while ‘mending’ culture in an existing organization starts from ‘Minus’?

This question opens a subject of change in an organization and behaviour of people in response to change.

The difference between an Obstacle and an UDE

January 20, 2017/0 Comments/in blog /by Jelena Fedurko-Cohen

20 January 2017, Jelena Fedurko

In the Facebook discussion of my recent blog post If an Injection is a solution you knew BEFORE you built the Cloud, why did you need the Cloud? I wrote a phrase that clearly stated that there is a difference between an Obstacle and an UDE. The phrase read “… are obstacles for the implementation, rather than system UDEs.” Thereafter, I was asked what is the difference between an Obstacle and an UDE.

I think that the confusion between the two may be caused by the fact that from the point of view of the global meaning, an UDE is, of course, an obstacle to achieving the desired performance level of the system.

However, when we speak about the difference between an Obstacle and an UDE as TOC Thinking Processes elements, there are four aspects to it.

If an Injection is a solution you knew BEFORE you built the Cloud, why did you need the Cloud?

January 15, 2017/2 Comments/in blog /by Jelena Fedurko-Cohen

15 January 2017, Jelena Fedurko

I quite often see Clouds that were built after a person has read a TP book/teaching material. Looking at the solution presented in the Injection box I often ask the author, ‘Hadn’t you thought about this solution or discussed it BEFORE you built the Cloud and recorded this solution in the Injection box?’

If the Injection IS WHAT YOU KNEW WITHOUT THE CLOUD, what was the value of building the Cloud, surfacing assumptions and challenging them?

The cloud is the TOOL FOR FINDING A SOLUTION. And it is not a final tool, because the Injection that was derived with the help of the Cloud is nothing more than raw material for checking that the solution meets the important needs (B and C), and for trimming whichever negative consequences may arise as the result of implementing the derived solution.

If the diamond structure of the broken Cloud presents an Injection that the person had been contemplating before they recorded the situation in the Cloud, it is likely that the person substituted (often unintentionally) the Cloud’s purpose of finding a solution by a purpose of justifying the solution that they had known or contemplated before.

In such cases the Injection will sound as one of the conflicting actions with a slight addition or clarification. The assumption which served as the basis for this Injection will sound as a mere repetition of the arrow connecting the conflicting action to the need (which is a typical mistake in surfacing assumptions), or as an argument supporting this conflicting action that is recorded in the assumption box between D and D’ (also, a typical mistake).

The Cloud CAN be used as tool for justifying the solution/persuading, but AFTER IT HAS SERVED ITS PURPOSE OF FINDING A SOLUTION.

To avoid misunderstanding regarding the objectives of the Cloud, here is the exchange between me and Ian Heptinstall in our Facebook group TOC Practitioners Worldwide on 16 January. Ian, many thanks!

Ian Heptinstall Jelena, are you suggesting that it is not worth using the cloud to check an idea one has for a possible solution, or are you suggesting that you need to take more care in writing it, and to properly surface and test all your assumptions?

Jelena Fedurko Hi Ian Heptinstall, thanks. No, i do not suggest that it is not worth using the cloud TO CHECK an idea. But then it is a different approach and the Cloud is RECONSTRUCTED – like in reverse engineering. Then you ask, “If THIS is a solution, then what is the problem?” In TOC a problem can be represented by a conflict/dilemma, an UDE, a perceived negative outcome, or an obstacle. If the problem is a conflict, dilemma, or UDE, one can use the Cloud. But as you are correctly saying – then the conscious objective is TO USE THE CLOUD TO CHECK AN IDEA. In the blog I was speaking about the situations when people are aware of the problem, decide to use the Cloud to sort it out, spend time on writing it, and then put the known solution as an Injection. As I wrote – in such cases as a rule you cannot find assumptions that would lead to this injection.
Regarding ‘testing assumptions’, yes all assumptions should be carefully tested before being accepted as raw material for developing injections. Thanks!

Comments

Jelena Fedurko, 15 January 2017

Sales Machine – The discussion after the 23d TOCPA Conference in Tennessee, March 2016

March 30, 2016/1 Comment/in blog /by Jelena Fedurko-Cohen

30 March 2016, Jelena Fedurko

A few days ago we had the 23d TOCPA Conference in Tennessee. It was a great gathering of TOC practitioners from nine countries. It was good to see old friends and meet new friends. We had two intensive days of presentations, discussions and networking.

The discussion on some subjects has continued after the conference. With permission of the authors and with our big Thank you to them, we publish their discussion.

The Five Focusing Steps, the Green Curve and the Red Curve. Part 2

January 13, 2016/1 Comment/in blog /by Jelena Fedurko-Cohen

Read Part 1

13 January 2016, Oded Cohen

This post is the response to Alejandro Fernandez’s comment to the post The Five Focusing Steps, the Green Curve and the Red Curve -Part 1, on 10 January 2016, that says:

“Looking the green and red curve I wonder about thinking – and remembering Eli Goldratt presentation – that red curve is growth and green curve is stability, and how it can generate a conflict. Grow but lose stability; be stable but do not grow. Then Eli proposed the progressive equilibrium as the win win solution. We are talking about the same graph?”

The Graph that Alejandro refers to is taken from Eli Goldratt’s discussion on the necessary conditions for a company to become “Ever Flourishing”. The graph looks like that:

A riddle on product development projects to think about! Part 2

January 7, 2016/9 Comments/in blog /by Jelena Fedurko-Cohen

Read Part 1

06 January 2016, Jelena Fedurko

I got a clarification for the riddle as presented in Part 1:

“Just one big BUT!! There is a resource conflict. The process engineers in the factories are responsible for both types of projects. New products require new/modified processes. Existing products require improvements – speed, quality, capacity, cost … and also require process engineers. YES, there are product development resources and they are a different set. The conflict arises when the new product is qualified for sale and must be industrialized in the factory. It is in the factory where the conflict occurs.

It is a ‘conflict’ between the factory and product development because the factory delays product industrialization for their factory reasons (local optimization). The product development people often face a question ‘Why should we speed up only to have to wait for the factory to do their part. It feels like the army … hurry up, and wait?’ “

This comment brings in new understanding of the conflict which is now truly between the product development projects and improvement projects.

Let’s look again at the first part of the clarification to the conflict:

“The process engineers in the factories are responsible for both types of projects. New products require new/modified processes. Existing products require improvements – speed, quality, capacity, cost … and also require process engineers. […] The conflict arises when the new product is qualified for sale and must be industrialized in the factory. It is in the factory where the conflict occurs.”

If we go along with the claim that there is a resource conflict, and based on the statements “The process engineers in the factories are responsible for both types of projects” and “It is in the factory where the conflict occurs”, the conflict seems to be of factory process engineers and looks like that:

A riddle on product development projects to think about! Part 1

January 5, 2016/4 Comments/in blog /by Jelena Fedurko-Cohen

05 January 2016, Jelena Fedurko

A long-standing TOC colleague offered a riddle to solve:

Situation: A factory has many projects to do. Some are the industrialization of new products that they can be produced effectively.

Some are improvement projects for speed, capacity, quality, cost reduction, capacity expansions.

For the moment assume that the factory/company decides correctly which product development projects should be pursued (for instance with the 6 technology questions, AND improvement projects are also selected correctly with proper application of T, I, OE and proper focus on the organization’s constraint.

The Five Focusing Steps, the Green Curve and the Red Curve. Part 1

January 3, 2016/17 Comments/in blog /by Oded Cohen

03 January 2016, Oded Cohen

This graph with the green and red curve belongs to the core of TOC. It is embedded in the logo of TOCPA. It represents the motto of Ever Improve way of managing systems, it shows the point in which managing the constraint is critical for the future of the system, and more messages.

Recently, we have had discussions with some TOC practitioners that expressed some frustration about the progress of their implementations. They claimed that while the first part of the TOC project produced outstanding results within a few months, the continuation of the growth was not as rapid and not as easy as they have expected it to be.

30 March 2016, Jelena Fedurko

We work together with you