Please enable JavaScript.

Coggle requires JavaScript to display documents.

ТЕОРИЯ ОГРАНИЧЕНИЙ - Coggle Diagram

- - - - Шаг 1: НАЙТИ ограничение(я) системы.
        
        Найти её самое слабое звено.
        Отлично, мы нашли ограничение. Если мы посмотрим на организации, мы с легкостью увидим, что существует два различных случая.
        
        Первый — когда мы определили, что ограничением является физический ресурс — бутылочное горлышко, то есть ресурс, у которого недостаточно мощности для того, чтобы удовлетворить спрос. В этом случае усилить самое слабое звено будет означать, что мы должны помочь бутылочному горлышку делать больше.
        
        Второй, ограничением является ошибочная политика (правило) организации. В этом случае усиление слабого звена не должно пониматься как то, что мы хотим помочь ошибочной политике "делать" больше. Мы должны заменить ошибочную политику.
      - Шаг 2: Решить, каким образом МАКСИМАЛЬНО ИСПОЛЬЗОВАТЬ ограничение(я) системы.
      - Шаг 3: ПОДЧИНИТЬ всё остальное принятому решению.
        
        Если мы не можем выжать из бутылочного горлышка больше 10 единиц, нет никакого смысла производить больше в не-бутылочных горлышках.
      - Шаг 4: РАЗВИТЬ (расширить) ограничение(я) системы.
      - Шаг 5: ВЕРНУТЬСЯ к первому шагу.
        
        Я усиливаю слабое звено. Вся цепь становится прочнее. Я ещё усиливаю его. Вся цепь становится ещё прочнее. Я ещё усиливаю его. И ничего не происходит. Почему? Это звено перестало быть ограничением. Поэтому я должен не допустить инерции и вернуться к первому шагу. Мы нашли процесс для сфокусированности. Это процесс сфокусированности для мира прохода. И в то же время это также процесс непрерывного улучшения.
  - - - мы можем подвергнуть сомнению верхнюю исходную посылку
      - ИЛИ мы можем подвергнуть сомнению нижнюю исходную посылку
      - ИЛИ мы можем продолжать искать компромисс
      - Мы подвергаем сомнению верхнюю предпосылку. Если не-бутылочные горлышки будут производить больше чем бутылочное горлышко — это приведёт к росту запасов, а это значит что происходят лишние затраты. Мы просили не-бутылочное горлышко производить меньше, чем оно может, не для того, чтобы обеспечить проход, а для того, чтобы контролировать затраты. Мы сказали не-бутылочному горлышку ограничить его локальную эффективность всего-навсего на 50% при возможных 100% из-за единственной причины — контролировать затраты. Что это говорит нам о верхней исходной посылке, утверждающей, что достижение хороших результатов с точки зрения затрат возможно только за счёт повсеместного достижения хороших локальных результатов? То, что она неверна.
- - - - Делая оценку по времени, руководство закладывает подстраховку от неопределённости.
      - В большинстве случаев, управленцы удобно себя чувствуют при 80-90% вероятности выполнения задания в срок.
      - Однако, распределение вероятности успеха таково, что с определённой точки каждый добавочный процент вероятности успеха будет "стоить" всё больше и больше времени.
- - - - Оценка по времени основана на негативном опыте и оказывается в конце кривой распределения вероятности.
      - Чем больше уровней менеджмента вовлечено в оценку по времени реализации проекта, тем выше окончательная оценка, так как каждый уровень добавляет свою подстраховку.
      - Те, кто делают оценку, закладывают дополнительную подстраховку от глобального "урезания". Если суммировать, получается, что подстраховка составляет большинство предполагаемого времени реализации проекта.
    - - Т.н. "студенческий синдром": спешить некуда, поэтому начинаем в последнюю минуту.
      - Перепрыгивание от задания к заданию
      - Зависимость между элементами, эти зависимости вызывают аккумулирование опозданий и разбазаривание выигрышей по времени.
    - - Мы не должны защищать подстраховкой каждый отдельный элемент проекта.
      - Каждый элемент содержит в себе минимум 200% подстраховки
      - Но мы должны заложить подстраховку.
        
        Заложить же подстраховку мы должны туда, где она действительно сможет помочь. Она должна защищать ограничение — критический путь.
      - Что можно сделать — время, запланированное для каждого элемента, будет сокращено наполовину.
        
        С другой стороны, буфер проекта не будет равен тому времени, которое мы забрали из всех элементов. Он будет сокращен наполовину:
    - - Буферы мы должны создать в точках, в которых питающие пути вливаются в критический путь.
      - Откуда мы возьмем время для буферов?
        Но теперь у нас есть вышеуказанная формула. Для каждого питающего пути мы сократим изначальные оценки времени наполовину и используем половину урезанного времени исполнения в качестве питающего буфера:
    - - Убедили различные ресурсы урезать оценки по времени
      - Мы отказались от контрольных точек, или, другими словами, устранили даты завершения отдельных элементов
      - Мы ввели отчёт об ожидаемом времени завершения
  - - - Поскольку мы изменяем ограничение, мы должны в соответствии с этим изменить питающие буферы.
      - Тогда критическая цепь в данном случае будет выглядеть следующим образом:
      - Если существует конкуренция за ресурсы — критическая цепь может значительно отличаться от критического пути.
        
        В этих случаях в чем действительная опасность следования критическому пути, а не критической цепи?
        
        Это может привести к катастрофам. Критический путь начинает прыгать. Ты теряешь контроль.
        
        Необходимо добавить в PERT названия ресурсов.
        
        Необходимо добиться максимального устранения конкуренции за ресурс.
        
        Конкуренция за ресурсы означает, что от одного и того же ресурса ожидается, что он должен делать два разных элемента проекта в одно и то же время. Устранение конкуренции за ресурс между двумя элементами во многих случаях требует, чтобы выполнение одного из элементов было отложено.
        
        Проблема в том, и мы это детально обсуждали, что не существует чёткого способа решить, какой элемент отложить. Это почти волевое решение.
        
        Есть один важный пункт. Все буферы, о которых мы говорим: буфер проекта, питающие буферы и ресурсные буферы — они все защищают отдельный проект. А здесь мы должны помнить, что мы также должны защитить бутылочное горлышко, глобальную деятельность организации.
        
        Но это не так страшно, как может показаться — достаточно ввести ещё один буфер, буфер бутылочного горлышка.