Отвечаю на вопросы:
1. ЧТО ТАКОЕ «ЛОГИСТИЧЕСКОЕ РЕШЕНИЕ ТОС»?

Елена Федурко-Коуэн, 7 июля 2021

Мне задали вопрос: «Логистическое решение ТОС для управления запасами – это что? Это программа какая-то, методология, регламент….?»

Мой ответ ниже охватывает несколько аспектов:

  1. В ТОС «логистическое» решение – это решение для управления потоком.
  2. Блок стандартных логистических решений ТОС включает в себя:
  • решение для производства на заказ
  • решение для производства для обеспечения наличия
  • решение для производства для обеспечения внутреннего наличия
  • решение для управления запасами в производстве и проектной среде
  • решение для управления запасами в дистрибуции и ритейле
  • решение для управления отдельным проектом (в любой сфере)
  • решение для управления многопроектной средой (в любой сфере)
  • решение для управления потоком пациентов в больницах
  1. Любое стандартное логистическое решение ТОС это:
  • сочетание определенного количества элементов решения (например, 8 – для производства, 10 – для управления запасами в дистрибуции и ритейле, 12 – для многопроектной среды и пр.)
  • конкретная механика для внедрения каждого элемента решения
  • прописанные процедуры
  • прописанные формулы расчетов
  • графические представления и отчеты
  • техники адаптации расчетов и управленческих решений к меняющимся условиям (как, например, к меняющимся объемам спроса и колебаниям в поставках на производство и в любое звено дистрибуции, к меняющейся ситуации со внутренними мощностями и пр.)
  • техника мониторинга потока для раннего оповещения замедлении потока и угрозе выполнения компанией взятых на себя обязательств по выполнению заказов клиентов
  • техника восстановительных действий
  • прописанная последовательность внедрения элементов решения
  • проверка на то, что данное решение подходит для конкретной компании
  • проверка на появление возможных побочных негативных явлений и их отсечение
  • введение механизма непрерывного улучшения.

Центральным механизмом управления потоком (следовательно, любого логистического решения ТОС)  является буфер ТОС.

Значение термина «буфер» в ТОС не имеет ничего общего  с общепринятым значением «на всякий случай» или «про запас». Буфер ТОС – это МЕХАНИЗМ УПРАВЛЕНИЯ.

 

Смотрите также: 

 

 

Елена Федурко-Коуэн, 7 июля 2021

About the question “What is TOC?”

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  

 

Наличия НЖЯ недостаточно для того, чтобы рекомендовать решение ТОС

Елена Федурко-Коуэн,18 апреля 2019

Наличия НЖЯ недостаточно для того, чтобы рекомендовать компании логистическое решение ТОС, направленное на устранение этих НЖЯ.

Для того чтобы рекомендовать компании любое логистическое решение ТОС, надо сначала убедиться, что в компании есть условия для того, чтобы это решение РАБОТАЛО.

Часто встречающаяся ситуация:

  • Компания-производитель, продающая со склада дилерам.
  • Компания страдает от стандартных НЖЯ для цепи поставки:

– регулярная нехватка на своем РЦ (распределительном центре) ходовых товаров (разные SKU), особенно в сезон, и

– затоваренность другими товарами (разные SKU).

На первый взгляд, прямо так и просится решение: «производство для обеспечения наличия».  У консультанта (или менеджера компании, который знает об этом логистическом решении и по факту принял на себя роль консультанта), возникает большой соблазн «продавить» среди лиц, принимающих решение, установку «Производить для обеспечения наличия».

Между консультантом и руководством достигается согласие о том, что это ХОРОШЕЕ решение для компании. После долгих безуспешных усилий запустить внедрение консультант приходит к выводу: проблема в том, что установка «Производить для обеспечения наличия» «не прошла». То есть, что высшие руководители находятся на шестом слое сопротивления: «Говорят «Да», но ничего не делают».

Однако чаще всего оказывается, что сопротивления руководства и специалистов не было вообще. Они не сопротивлялись новой идее. Они просто изначально знали, что в компании НЕТ УСЛОВИЙ для того, чтобы это решение могло работать. Они, возможно, даже искренне сказали «Да, мы это решение ХОТИМ!»  Однако «хотеть» не означает «иметь условия для того, чтобы решение работало». 

Давайте поближе посмотрим на эти два стандартных НЖЯ.

Read more

Я начал разрабатывать [вставить] по ТОС

Елена Федурко-Коуэн, 22 февраля 2019

Регулярно получаю письма от людей, никогда не изучавших ТОС: “Я начал разрабатывать [разработал/хочу разработать/написал] программное обеспечение [калькулятор/приложение/более правильный размер зон буферов/более правильный механизм пополнения/продолжить список] по ТОС.” Далее следует перечень функций “новой разработки по ТОС” и замечание о том, что в открытых материалах выступлений и статей на наших сайтах автор не может найти все, что ему надо для разработки. Часто к письму  прикреплен pdf написанной автором письма объемной статьи [описание структуры макета/пр.] с “должными исправлениями механизмов ТОС” и четко прописано предупреждение о том, что автор позволяет мне воспользоваться прикрепленной статьей/макетом/расчетом только для того, чтобы я прислала обратную связь и ответила на список его вопросов, касающихся его разработки, но не для получения мной какой-либо выгоды. 

На мое предложение приехать к нам и сначала получить грамотные знания, ответа часто вообще не приходит. Или мне отвечают, что когда автор найдет заказчиков на разработанный им продукт, он рассмотрит возможность приехать на обучение.

Для того чтобы РАЗРАБАТЫВАТЬ что-либо в области любых знаний,

  1. сначала надо знания получить,
  2. затем изучить то, что уже разработано,
  3. затем МНОГОКРАТНО применить на практике в разных сферах и разных индустриях то, что уже разработано, опробовано и многократно зарекомендовало себя как дающее хороший результат,  
  4. и только ПОСЛЕ этого можно задумываться над разработкой чего-то еще.

Поскольку пункты 1-3 у авторов таких писем отсутствуют, говорить о какой-либо “разработке” – крайне непрофессионально.

Любой “продукт”, разработанный на собственных интерпретациях просмотренного или прочитанного в интернете разрозненного материала в форме выступлений или статей, имеет крайне высокую вероятность нанести серьезный ущерб тем, кто будет этим “продуктом” пользоваться. 

У тех, кто “изучал” ТОС самостоятельно, так же нет знаний по ТОС, как и у тех, кто о ТОС никогда не слышал. Нельзя путать “знание О теории органичений” и “знание теории ограничений”.

На эту же тему: 

Елена Федурко-Коуэн 22 февраля 2019

Собственник поставил задачу: в разы увеличить

Елена Федурко-Коуэн, 10 сентября 2018

Часто встречающаяся ситуация: собственник поставил амбициозную целевую задачу “в разы увеличить прибыль/продажи/долю рынка/рыночную цену компании/количество разработанных и выведенных на рынок новых (или инновационных) продуктов/и пр”.

Как правило, для достижения этой задачи собственник дал 2-3 года.

Как правило, топ-менеджмент не верит в то, что эта амбициозная целевая задача достижима.

Собственник дал пару/несколько месяцев для того, чтобы топ-менеджмент представил экономическую модель и конкретный план того, как эта амбициозная задача будет достигнута. Скорее всего, назначается отвественный топ-менеджер.

Топ-менеджмент дает указание соответсвующему менеджеру начать искать, какие управленческие подходы/методы подойдут для того, чтобы включить их в/на их основе написать  экономическую модель, которую нужно будет представить собственнику через пару (несколько) месяцев.

О чем эта ситуация говорит?

  • Если (1) собственник не сказал высшему руководству, КАК за несколько лет достичь увеличение В РАЗЫ прибыли/продаж (и далее из списка выше), и (2) требует представить экономическую модель и план действий, то, скорее всего, у собственника отсутствует знание того, КАК достичь поставленную им оцифрованную задачу за оцифрованный период. Предполагать иначе (то есть, что собственник знает КАК) означало бы, что поставив эту задачу и дав указание представить модель и план, собственник ПРОСТО ХОЧЕТ ПРОТЕСТИРОВАТЬ свой высший менеджемент на управленческие знания и компетенции в области достижения этой задачи. Такой вариант возможен, но, скорее всего, не типичен.

Read more

«В чем ограничение теории ограничений?»

Опубликовано Еленой Федурко-Коуэн 10 апреля 2018

Мне часто задают вопросы: «А в чем ограничение теории ограничений?» и «С каким (самым ключевым) ограничением сталкивается сама ТОС»?

ОТВЕТ: Теория ограничений – это свод знаний, а не система, имеющая поток. В терминах и концепциях ТОС мы не можем говорить об «ограничении теории ограничений».

Сама по себе постановка этих вопросов говорит о том, что задавший вопрос не понимает концепции «ограничение» в теории ограничений и не знает определений термина «ограничение» в теории ограничений (приведены в конце этой статьи).

Если суть теории ограничений передать двумя словами, то эти слова будут «фокус» и «поток». Теория ограничений занимается УПРАВЛЕНИЕМ ПОТОКОМ ЧЕРЕЗ ОГРАНИЧЕНИЕ, которое есть по умолчанию в любом потоке.

Если спрашивающие имеют в виду не ТОС как свод знаний, а компании, предлагающие консультационные и обучающие услуги в области ТОС, то каждая такая компания – это система и она имеет поток и ограничение в потоке. У КАЖДОЙ компании, также и тех, которые предлагают услуги в области ТОС, есть ограничение: мощность, или рынок, или время, или такие формы ограничения мощности как оборотный капитал или сырье, или другая форма ограничения.

ТОС не может «сталкиваться с ограничением». «Сталкиваться» можно с препятствием.

В ЧЕМ РАЗНИЦА МЕЖДУ ОГРАНИЧЕНИЕМ И ПРЕПЯТСТВИЕМ?

Read more

What the Cloud is NOT for

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

«САМЫЕ необходимые»?

19 февраля 2018, Елена Федурко-Коуэн

Мое внимание привлек недавний короткий пост в одной из групп в Facebook: «В отличие от Тейлора его последователь Гилберт изучал работу самых ленивых рабочих:  они выполняют только самые необходимые движения…»

Когда речь идет о «необходимости», мы говорим о том, что задействована логика необходимости. То есть, что-то является НЕОБХОДИМЫМ условием для того, чтобы получить определенный результат.  НЕОБХОДИМОЕ условие по умолчанию означает, что БЕЗ НЕГО НЕВОЗМОЖНО ПОЛУЧИТЬ ОЖИДАЕМЫЙ РЕЗУЛЬТАТ.

Логика необходимости четко определяет: если НЕ БУДЕТ ХОТЯ БЫ ОДНОГО ИЗ НЕОБХОДИМЫХ УСЛОВИЙ, то не будет и следствия.

Поэтому выражение «самые необходимые», несмотря на его широкую распространенность, логически неверно.

Read more

TOC and Risk Management for Projects

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

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