Эли Шрагенхайм в своем блоге опубликовал еще одну статью из цикла “границы применимости” для того или иного решения Теории ограничений.

На мой взгляд, эти публикации имеют очень высокую ценность. Потому что, являясь одним из крупнейших авторитетов в области Теории ограничений, из ныне здравствующих, Эли обращает внимание на то, что никакое решение не является панацеей и, в случае, если существующая ситуация не соответствует исходным предпосылкам, определяющих границы применимости методов, требуется их адаптация.

Наверное, это грустная информация для “продавцов таблеток”, но зато для профессионалов она весьма ценна и полезна.

Как обычно, ссылка на оригинал и картина из поста автора.

Ваш Дмитрий Егоров.

ББК (DBR), Барабан-Буфер-Канат в ТОС – это методология планирования для производственных компаний. В этом посте я сфокусируюсь на применении ББК/УББК[i] для среды «производство на заказ» (MTO), когда клиент заказывает конкретные продукты, их количество и время исполнения.  Границам применимости управления запасами я посвящу другой пост. На самом верху планирования находится Управление буферами[ii], которое используется для управления приоритетами в процессе исполнения.

“Sim10” используется в симуляторе Голдратта для обучения методологии ББК

Я не собираюсь обсуждать здесь детали ББК и отличия между ББК и УББК. Я хочу обрисовать ситуации, в которых логическое обоснование ББК/УББК соответствует действительности. Напримар, Голдратт создал CCPM[iii], потому что стало очевидно, что ББК НЕ работает в отношении проектов. Понятно ли ВАМ, читатель, что исходные предпосылки, лежащие в основе ББК, не соответствуют реальности в мульти-проектном окружении и наоборот?

Для организаций, занимающихся производством или оказанием услуг, основное состояние функционирования – это получение заказов от клиентов, которые запрашивают конкретные пакеты четко определенных продуктов или услуг, которые должны быть выполнены в пределах определенного цикла изготовления.[iv] Организации обычно не хранят эти продукты на складе, поэтому им необходимо произвести их. Организации может потребоваться купить у поставщика материалы и затем произвести конкретные заказы для клиентов.

Ключевые исходные предпосылки, при которых использование ББК/УББК обеспечить надежность своевременного исполнения:

1. Чистое время обработки[v] любого производственного заказа очень мало, относительно цикла изготовления – времени от момента принятия заказа до момента отгрузки.
   1. Голдратт исходил из предположения, что меньше 10% от буфера времени для такого заказа.
   2. Остальное время производственные заказы ожидают пока ресурсы станут доступными, что означает что уровень использования множества ресурсов не слишком велик.
2. Уровень статистических колебаний в цеху не слишком велик.
   1. Например, если переналадка в среднем занимает два часа, вряд ли она займет 20 часов.
   2. В целом такое окружение подвергается значительно меньшим флуктуациям, чем проекты!
   3. Эта предпосылка также касается уровня брака. Вряд ли или очень редко весь производственный заказ оказывается бракованным.
   4. Это означает, что цех обеспечивает достаточно хорошее качество на всех этапах.
3. Организация сохраняет приемлемый уровень контроля аутсорсинга и снабжения.
4. Все производственные операции проводятся территориально в одном мести или достаточно близко, так что время транспортировки между центрами обработки[vi] мало по отношению к буферу времени.
   1. Эту предпосылку можно рассматривать как расширение предпосылки №1.Нам нужно понимать, что транспортировка, чистое время перевозки[vii], является частью «времени обработки».

Одна ключевая предпосылка для использования Управления буферами:

1. Большинство заказов заканчиваются в Желтом или очень близко к границе проникновения в Красное.

Когда одна или больше предпосылок не соответствуют действительности, это не означает, что ББК/УББК бесполезны, но это означает, что определенные изменения обязательны.

Я хочу объяснить влияние времени обработки на методологию. На самом деле, предпосылка о времени обработки – это основное отличие производством и мульти-проектной средой. В проектах мы ожидаем, что время, необходимое для выполнения задач на критической цепи, равно времени для выполнения всего проекта.  Это резко контрастирует с производством, где заказы проводят в ожидании между операциями достаточно длительное время.  Потому ключевое отличие между понятиями «критический путь» и «критическая цепь» не соответствует реальным условиям производства.

Что происходит, когда время обработки для конкретной операции около 30% буфера времени?

При использовании УББК буфер времени покрывает весь процесс производства, от запуска материалов до завершения. Когда одна операция занимает 30% этого времени, мы должны задать два критически важных вопроса:

1. Достаточен ли буфер времени для защиты срока исполнения от флуктуации всего производственного процесса? 30% времени обработки не является часть защитного времени, обеспечивают ли оставшиеся 70% достаточную защиту?
2. В управлении буферами в ББК/УББК точное местонахождение производственного заказа не отражается на статусе буфера, потому что, если время обработки незначительно, то это на самом деле не имеет значения. Однако, если одна конкретная операция занимает 30% буфера, то очень важно прошел ли заказ эту операцию или еще находится перед ней. Когда заказ все еще находится перед этой операцией, оставшийся буфер значительно короче, чем оставшееся время до окончания заказа.

Новое решение для управления буферами в рамках внедрения УББК в случае с длительным времени обработки было разработано и представлено на конференции TOCICO в 2012 (Лиза Шайнкопф (Lisa Scheinkopf), Юйи Кишира (Yuji Kishira) и Амир Шрагенхайм (Amir Schragenheim)). Это пример понимания границ исходных предпосылок и уровня требуемых изменений, когда конкретная предпосылка не соответствует действительности.

Важно еще раз подчеркнуть, что вышеуказанные предпосылки относятся к производству «на заказ». Критическое отличие между МТО и МТА (производство для обеспечения наличия), также как УББК, было осознано значительном позже появления как ББК. Предпосылка, что мы должны иметь определенное количество выполненное к конкретной даты, не была четко сформулирована ни MRP, ни DBR.  Как только роль, которую играет эта предпосылка, стала ясна, была разработана отдельная методология МТА.  Урок состоит в том, чтобы изо всех сил постараться сформулировать лежащие во основе предпосылки, которые определяют границы применимости методологии. Тогда мы можем идентифицировать ситуации, которые находятся вне этих границ, и найти соответствующее решение, которое может быть похоже или сильно отличаться от первоначальной методологии.

 

[i] В тексте «DBR/SDBR» – аббревиатуры для двух несколько отличающихся методов: «барабан-буфер-канат» и «упрощенный барабан-буфер-канат». Аббревиатуры ББК и УББК прижились в русскоязычной терминологии Теории ограничений. Эли Шрагенхайм является разработчиком подхода УББК. УББК строится на базовой предпосылки, что ограничение рынка является стратегическим для коммерческих организаций и подчинение рынка внутренним ограничениям компании – стратегически недальновидно. – прим. переводчика

[ii] В тексте «Buffer-Management» – прим. переводчика

[iii] Метод управления проектами «Метод критической цепи» – прим. переводчика

[iv] В тексте «lead-time» – цикл производства, время исполнения заказа и так далее, определяется словом которое стоит перед этим словосочетанием. – прим. переводчика

[v] В тексте «touch-time» в русском управленческом словаре нет точного термина, буквально «время касания», то есть то время, когда заказ непосредственно обрабатывается, возможные переводы: технологическое время. – прим. переводчика

[vi] В тексте «facilities» оборудование, аппаратура и т.п. – прим. переводчика

[vii] В тексте «dry-time» – прим. переводчика

Как я уже писал при публикации прошлого перевода, в пятницу 30 октября 2015 Эли Шрагенхайм опубликовал у себя пост, посвященный границам применимости метода Критической цепи.

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

Мне очень нравится в публикациях Эли тот факт, что он, как и положено, всегда задается вопросами границ применимости тех или иных методов Теории ограничений. Нет методов не правильных, есть не правильное, не своевременное или неуместное применение тех или иных инструментов.

Как обычно, ссылка на оригинал и картинка из поста автора.

Ваш Дмитрий Егоров

Управление проектами по методу Критической Цепи (Critical-Chain-Project-Management), CCPM, — наиболее успешное и широко известное решение TOC. Наиболее поразительной особенностью CCPM является работа с неопределенностью, а вторая удивительная черта — это понимание влияния показателей эффективности[i] на поведение людей и воздействие на саму эффективность.

Я поставил работу с неопределенностью на первое место, поскольку добавление наглядного буфера времени проекта в его конец — смелое заявление, что мы на самом деле не знаем точной даты окончания проекта. Это более очевидный буфер, чем буфер в методе ББК (Барабан-буфер-канат), который похож на обычное время выполнения проекта в совокупности с цепью операций. Концепция буфера проекта — значительный вклад в управление «обычной и ожидаемой неопределенностью».

Знаменитое высказывание Годратта «Скажи мне, как вы меня оцениваете, и я скажу, как я буду себя вести» сформулировано за десятилетие до CCPM. Настоящее негативное влияние показателей эффективности на поведение людей очевидно на производстве, но еще более актуально для проектов, где работники являются ключевыми ресурсами. Разрушительный эффект многозадачности также выведен из показателей эффективности, которые оценивают каждого менеджера по проекту в отрыве от остальных запущенных проектов и тем заставляют его бороться за «свой проект».

Хотя CCPM является колоссальным прорывом в управлении, мы всегда обязаны спросить:

Где границы применимости данной методики?

 

Другими словами, когда использование CCPM полезно, а когда следует внести некоторые изменения?

Все это сводится к необходимости проверки допущений, лежащих в основе методики и выявления ситуаций, когда они не валидны.

 

Просто чтобы проиллюстрировать это утверждение, давайте представим программу по поиску лекарства от рака. Возможно ли в начале подобного исследования назвать срок его окончания? Можем ли мы построить сетевой график для задач всего проекта? Представляем ли мы, сколько времени он займет? Имеет ли какой-либо смысл в буфере проекта, если у нас даже нет срока окончания?

Вот мой список исходных предпосылок CCPM, которые могут в некоторых ситуациях могут не соответствовать реальности:

1. У нас достаточно хорошее представление о том, как провести проект от начала до конца.
   • В частности, в начале проекта у нас есть хорошее представление о том, какие компоненты следует разработать.
   • В проекте нет точек, которые могут кардинально изменить последующие операции или вернуть к более ранней задаче, в зависимости от каких-либо условий.
2. Завершение проекта в срок или раньше имеет огромное значение.
3. Своевременное завершение проекта тесно связано с выполнением спецификаций и бюджета проекта.
4. Контроль за прогрессом и согласование по времени находятся в наших руках.
5. Мы планируем непрерывно работать над критической цепью. Без этого определение критической цепи как того, что определяет длительность проекта, бессмысленно.

 Что произойдет, если одна или более исходных предпосылок не соответствуют действительности?

Рассмотрим два примера:

Предположим, что клиент должен подтвердить определенные этапы в проекте и не торопится с этим. Два допущения неверны: четвертое и пятое. Четвертое недействительно, так как мы не можем заставить клиента придерживаться нашего графика. Пятое — так как весь проект находится в подвешенном состоянии до того, как клиент примет решение. Можно включить возложенную на клиента задачу в планирование и предположить примерно 50% времени[ii] на ее выполнение. Суть в следующем: если клиент откладывает сигнал о продолжении, каким образом участники проекта могут уложиться в срок?

В таком случае я советую разделить цельный проект на несколько подпроектов. Проектная команда контролирует процесс до тех пор, пока клиент не получает результаты и запрос на их утверждение; это завершает первый проект. Как только клиент подтверждает готовность двигаться дальше, даже вынеся новые требования, начинается второй проект.

Другой проблемный вид проекта – это проект с обязательным фиксированным сроком окончания и невозможностью отсрочки. В таком случае состав «готового проекта» может быть гораздо меньше первоначального плана, или же могут резко увеличиться затраты. Это означает, что третье допущение является недействительным. Буфер времени не защищает все действительно важные переменные. При планировании такого проекта следует сделать четкое разграничение между «обязательными»[iii] и «желательными»[iv] компонентами. Я вижу решение в установлении буфера желательных компонентов вдобавок к буферу проекта, защищающему обязательный срок завершения.[v]

Общее замечание: Я считаю CCPM наименее целостной методикой теории ограничений. Она ориентирована на решение проблем довольно общих, но не обязательно ключевых для компании. Меня волнует, что мы устраняем нежелательные явления (НЖЯ), не видя общей картины. Вы можете улучшить управление проектами, но организация так и не приблизится к цели.

В заключение анекдот: Мне повстречался руководитель высшего ранга огромной международной группы корпорации. Когда я упомянул отличную реализацию CCPM в Израиле, он прокомментировал: «Они раньше закончили НЕ ТОТ проект!»

Не должна ли ТОС не только участвовать в планировании и осуществлении проектов, но также проверять, что это ПРАВИЛЬНЫЕ проекты с правильными содержанием и требованиями?

Можем ли мы делать это, не участвуя в Стратегии организации?

 

[i] В оригинале «perforance» – прим. переводчика

[ii] Возможно речь идет о питающем буфере для этой задачи, равном 50% времени от защищаемой цепи, но это предположение не однозначно. – прим. переводчика

[iii] В тексте «must-have» – прим. переводчика

[iv] В тексте «nice-to-have» – неплохо-чтобы-было, в данном переводе я решил отказаться от этого варианта перевода. – прим. переводчика

[v] Подробнее об этом можно прочитать в другой статье Эли Шрагенхайма на эту тему, перевод которой опубликован у меня на сайте.

В конце прошлой недели Эли Шрагенхайм опубликовал в своем блоге материал посвященный различиям применения ТОС для краткосрочного и долгосрочного повышения эффективности. Он дает вариант ответа на обвинение в сторону решений ТОС, как направленных только на краткосрочный результат и предлагает свое видение ограничений, которые действуют в области непрерывного улучшения в долгосрочной перспективе и разработки прорывных решений.

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

От себя добавлю, что я крайне раздосадован тем, что издательство Альпина, сочло не рентабельным переводить и издавать книгу Эли Шрагенхайма “Управление цепями поставок на невероятной скорости”. Между тем, тираж книги “Производство с невероятной скоростью” уже полностью распродан и найти книгу в магазинах РФ невозможно, как и заказать через интернет. Между тем книги Эли с соавторами Кэролин Птак и Уильямом Детмером – это прекрасные практические и методические пособия уровня “бери и делай”. Если среди читателей переводов есть люди способные донести эту информацию до издательств, то я с удовольствием поучаствую в переводе и редактировании “Supply Chain Management at Warp Speed”, мне кажется книга достойна дойти до читателя на русском языке.

Как обычно, ссылка на оригинал и картинка из поста автора.

Ваш Дмитрий Егоров

Два различных потока, каждый из которых ограничен разными ограничениями.

TOC критикуют за фокусировку только на краткосрочной перспективе.  Максимальное использование ограничения мощности и подчинение всего остального этому решению, это типичный результативный и быстрый способ достижения цели в краткосрочной перспективе.

В долгосрочной перспективе, при условии, что ограничение уже используется максимально и все подчинено его максимальному использованию, нам нужно расшить ограничение.[i] Тогда ограничение передвинется на рынок. Применение «предложения мафии» для дальнейшего расширения рынка приведет к возвращению ограничения внутрь организации. Таково классическое описание того, как работают пять фокусирующих шагов в долгосрочной перспективе.

Когда рынок является ограничением – как менеджерам принимать решение на чем сфокусировать свои усилия для увеличения спроса?

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

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

Хорошо ли это – иметь внутреннее стратегическое ограничение?

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

TOC никогда не игнорировала влияние на долгосрочную перспективу, но, давайте признаем, что максимальное использование ограничения было, главным образом, сфокусировано все-таки на краткосрочной перспективе. Этому есть простое объяснение:

Чем дальше мы заглядываем в будущее, тем выше влияние неопределенности

И потому, любые подходы к долгосрочной перспективе – это объект возможной неудачи. Тем не менее, мы не можем и не должны игнорировать то,  что мы СЕЙЧАС можем сделать для достижения желаемого в будущем процветания.

Фокусировка на краткосрочной перспективе принимает во внимание ресурсы, способности и возможности, которыми мы уже обладаем. Она не рассматривает вопросы создания новой ценности для потенциальных клиентов. Разработка решающего конкурентного преимущества требует времени на синхронизацию, интеграцию различных частей для результативного запуска, который увеличит рыночный спрос. Нам также необходимо создать соответствующую инфраструктуру, ресурсы, способности и ясные процессы, чтобы справиться с этим ростом.

Таким образом, мы легко можем определить два критических потока внутри любой организации:

1. Существующий поток ценности – генерация прохода в краткосрочной перспективе.
2. Поток инициатив для увеличения ценности для потенциальных клиентов, выхода на новые рынки и, возможно, лимитирования роста OE и I относительно роста Т. Все вместе, эти инициативы создают актуальную Стратегию организации.

Эти два потока в основном используют разные ресурсы. Существующий поток ценности полностью занять вопросами получения заказов, быстрого отклика и обеспечения хорошего качества. Основные усилия требуются от подразделений Продаж и операционных подразделений[ii].

Поток инициатив совершенно иной. Он включает Маркетинг, как функциональную область занятую поиском новых возможностей, и НИОКР (R&D), который дает новые ответы на потребности различных рынков.  Ключевые крупные инициативы пытаются поднять рыночный спрос или увеличить восприятие рынком предлагаемой ценности. Инициативы по подготовке соответствующей инфраструктуры, такой как приобретение новых способностей, ресурсов или новых процессов, проистекают от эти ключевых инициатив. Другие инициативы создают механизмы контроля для предупреждения развивающихся угроз.

Ресурсами для потока инициатив выступают преимущественно руководители и профессионалы высокого уровня. Достаточно большой бюджет – это еще один необходимый ресурс.

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

Оба потока ограничены, но разными ограничениями!

С середины 90-х у меня сформировался собственный взгляд на ограничение потока: текущий поток почти всегда ограничен рынком, а иногда, еще и нехваткой мощности внутреннего ресурса. Принуждение клиентов к подчинению внутреннему ограничению их поставщиков – это очень вредно для будущего организации.

Однако, поток инициатив всегда ограничен внутренним ресурсом. Идей, которые могут улучшить будущую эффективность[iii], должно быть больше, чем мощности или бюджета или человеческих ресурсов.

Вот так я интерпретирую высказывание Эли Голдратта, что предельным ограничением является внимание менеджмента!

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

Но, когда дело доходит до стремления к обеспечению будущего роста и стабильности, внимание менеджмента становится стратегическим ограничением. Наиболее очевидный способ максимального использования ограничения – это фокусировка на наиболее выгодных идеях.  Тщательное планирование Стратегии, основанное на TOC, предпочтительно – с использованием S&T[iv], – это наилучший способ достижения не только максимального использования ограничения, но также и правильного процесса подчинения этому решению, давая правильные приоритеты для все остальной организации.

Таким, по моему мнению, должно быть применение ТОС для долгосрочной перспективы.

 

[i] В тексте «elevate comstraint» – классическая формулировка четвертого шага из пяти фокусирующих шагов. – прим. переводчика

[ii] В тексте «Operations » – операционные подразделения, не только производство, но и весь логистический комплекс. – прим. переводчика

[iii] В тексте «performance» – прим. переводчика

[iv] S&T – дерево стратегии и тактики, один из мыслительных инструментов ТОС – прим. переводчика

Как и обещал на этой неделе Эли Шрагенхайм в своем блоге опубликовал продолжение кейса, для научения на одном факте. Весь кейс не уместился даже в двух публикациях, продолжение обещано.

Как обычно ссылка на оригинал, а картинки в этот раз пришлось переводить.

Читайте, комментируйте, обсуждайте. Первая часть здесь.

Ваш Дмитрий Егоров

Команда по расследованию продолжила свои поиски, чтобы извлечь правильные уроки из разрыва между ожиданиями и результатами.

Формальная структура рассматриваемого разыва:

При выдвижении гипотез задача состоит в том, чтобы быть открытым[i] для всех возможностей,  основывающихся на очень небольшом количестве известных фактов. Каждая гипотеза в последствии потребует от команды поиска информации, которая или подтвердит, или опровергнет гипотезу.

Команда выдвинула следующие гипотезы:

Гипотеза 1: Ожидания были нереалистичными с самого начала – невозможно создать идеальную систему, которая бы поднимала тревогу, когда необходимо, и не поднимала, если в этом нет необходимости.

Гипотеза 2: Участники проекта разрабатывали то, на что были способны. То, что казалось слишком трудным, не разрабатывалось.

Гипотеза 3: Участники проекта сфокусировались на защите от ложных тревог, даже за счет отказа от подачи сигнала тревоги, когда происходит реальное проникновение.

Гипотеза 4: Не было четкой и детальной спецификации того, что должны делать Wise-Cameras, утвержденной топ-менеджментом.

Гипотеза 5: К разработке системы недостаточно привлекали профессионалов в области безопасности.

Гипотеза 6: Проектная команда не обладала необходимыми навыками для решения этой задачи, и они попытались скрыть это от топ-менеджмента, заявив об успехе.

Гипотезы были вербализированы членами команды обычным повседневным языком. Между некоторыми гипотезами существуют причинно-следственные связи. Поэтому несколько гипотез могут оказаться обоснованными[ii]. На этом этапе команда просто проверяет каждую гипотезу, на предмет объясняет ли она разрыв.

Вербализируем потенциальное объяснение:

Обратите внимание, что дополнительные эффекты, которые требуются для того, чтобы объяснить разрыв, на самом деле, являются новыми гипотезами, которые должны быть проверены точно также: проверкой известный фактов, которые покажут, существует ли эффект в данном конкретном случае.

Проверка фактов продолжается до того момента, пока причина не станет ясна.

Вербализируя некоторые возможные объяснения, выведенные из основных гипотез, команда без труда выяснила к некоторым очевидным фактам:

• Топ-менеджментом была сформулирована спецификация высокого уровня, содержащая следующие основные требования:
  • Система должна идентифицировать пытающихся проникнуть в защищаемое здание до того как они достигнут двери или окна.
  • Число ложных тревог должно быть минимальным – не более чем 5%.
  • Система должна иметь ясные преимущества перед любой другой системы защиты, основанной на камерах.
  • Письменно менеджмент не указал, что система должна исключать необходимость человеку-охраннику наблюдать за экранами. Тем не менее, это требование неоднократно возникала в нескольких неформальных разговорах.
• Руководитель проекта Рафаэль Турина сообщил топ-менеджменту, что в проекте реализованы все требования, которые записаны, и стремиться достичь точки, где наблюдение за экранами не будет необходимым.
• Сэм Фуллер, исполнительный директор, сказал, что Рафаель обещал дать топ-менеджменту знать, существует ли необходимость наблюдения за экранами.
• Рафаель сказал, что он уведомил Сэма, что все записанные требования были удовлетворены.
• Идея, что люди будут перекатываться по направлению к зданию, в команде не возникла и, потому, не рассматривалась.
• The main technical challenge was to distinguish between a person and an animal moving.  The team assumed animals have four legs and based the ultra sophisticated image recognition on this idea.
• Было установлено, что все сотрудники проекта обладают высочайшими профессиональными навыками.
• Как Рафаэль, так и Алекс обладают широким опытом в области обеспечения безопасности.
• Никто из сотрудников проекта или внутренних менеджеров не был привлечен к планированию теста системы.

Факты, которые были подтверждены косвенно:

• Команда проекта неохотно информировала топ-менеджмент о неудачах или спецификация, которые не были реализованы.
  • Рафаэль, Алекс и другие члены команды отрицают эту тенденцию.
  • Тем не менее, проверка почты и отчетов для топ-менеджеров показала детальные отчеты об успешных внутренних тестах и ни одного отчета о трудностях.
  • Об одной явной неудаче по определению движения в плохих погодных условиях не было доложено
• Топ-менеджмент был уверен, что системе не нужно вмешательство человека на этапе идентификации.
  • Гилберт, менеджер внешней тестирующей команды и глава команды по расследованию, показал, что он понял, что люди, наблюдающие за экранами, не нужны.
  • Никто не должен был наблюдать за экранами во время внешнего тестирования.

Резюме установленных фактов:

Проекту не хватило ясного определения требуемых характеристик. Он стремился охватить все, но проявились некоторые проблемы. Две проблемы были ясно определены:

1. В условиях плохой погоды камеры были неспособны идентифицировать движение человека.
2. У проектной команды был конфликт между необходимостью идентифицировать подозрительную попытку приблизиться к зданию и поднятием ложной тревоги. Этот конфликт привел к решению, что движение человека идентифицируется, если он двигается на двух ногах. Возможные исключения и обходы не обсуждались.

Топ-менеджменту о проблемах не докладывали, и тот пребывал под впечатлением, что система идеальна и исключает необходимость наблюдения за экранами. Проектная команда была под впечатлением, что все записанные требования были реализованы. Проектная команда думала, что нет необходимости упоминать о вопросах, не обозначенных письменно. Руководство было под впечатлением, что все требования, а не только записанные, получили соответствующее воплощение.

Вопросы:

1. Мы знаем, что случилось – есть ли еще что-то, о чем нам надо знать?
2. Что нам сейчас делать? Расследование завершено?

Продолжение следует!

 

[i] В тексте «to keep the open mind», есть также вариант перевода «быть непредвзятым», но мне по контексту это вариант не понравился. – прим. переводчика

[ii] В тексте «valid» иногда переводят как «истинными» или дают кальку «валидными» – прим. переводчика

Честно скажу, я всегда сомневаюсь, стоит ли переводить кейсы, которые публикует в своем блоге Эли Шрагенхайм.

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

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

Спасибо компании Юнискан-Резерч за поддержку в мощности перевода.

Как обычно ссылка на оригинал и картинка из публикации автора.

Дмитрий Егоров

Я использовал этот вымышленный кейс на мастер-классах по Обучению на ОДНОМ событии, чтобы продемонстрировать процесс. Мне хотелось бы, чтобы по ходу чтения вы останавливались и задавались вопросом о том, как бы повели себя в этой ситуации. Также задумайтесь, насколько случай применим к менее эффектным провалам и что можно обрести из изучения ПРАВИЛЬНЫХ уроков. Это первая часть кейса, вторая выйдет через неделю.

Повод для обучения и начало процесса

Первый крупный тест камер Wise-Cameras, которые должны были стать новым бриллиантом в короне TopSecurity, был организован для двух сотен представителей армии, военно-воздушных сил, полиции и секретных служб. Он обернулся полной катастрофой. Сэмюэл Фуллер, исполнительный директор TopSecurity, прошедший весь путь превращения  компании в гиганта стоимостью 5 млрд. долларов, сформировал команду из трех человек, чтобы проанализировать это позорное событие: Wise-Cameras не смогли зафиксировать, как профессиональная группа из пяти человек проникла в здание Top Security, несмотря на изощренность и сложность испытуемой системы.

Руководителем команды по расследованию стал Гилберт, менеджер SecurityCheck, независимой организации, отвечающей за проверку функционала и эффективности различных технических средств обеспечения безопасности. Компанию SecurityCheck попросили проникнуть в штаб-квартиру TopSecurity. Их успех стал крупнейшим провалом в истории TopSecurity. Линда, блестящий директор ThoughtWare, компании-разработчика ПО, не связанной никакими деловыми контактами с TopSecurity, также вошла в команду. Организационный консультант Джейкоб стал третьим участником.

Проект по разработке Wise-Cameras стартовал три года назад и был рассчитан на два. Идея заключалась о том, чтобы использовать камеры слежения для автоматического определения любой попытки приближения к защищенному зданию. Идентификация потенциальных злоумышленников должна была проходить автоматически и с высокой точностью. Также ожидалось, что система будет безошибочно определять количество людей, совершающих попытку взлома, и фиксировать особые приметы нарушителей, в частности межглазное расстояние, чтобы ускорить опознание, даже если они были в масках.

 

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

 

Естественно, неудача обескуражила Сэма. Она мгновенно оказала влияние на TopSecurity, с экономической и оперативной точек зрения. Фактическая стоимость проекта составила около 5 млн долларов, но ожидалось, что в будущем он будет приносить около 100 млн в год!

Стоит ли включать участников группы, работающей над проектом, в команду, занимающейся научением на одном событии?

 

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

 

Однако какая цель стоит перед обучением? Неужели найти нескольких виновных или же выявить некоторые ошибочные парадигмы, общие, вероятно, для многих участников, и исправить их?

 

Джейкоб, организационный консультант, предложил включить в команду кого-нибудь из проектной группы, чтобы донести до других намерение не искать виновных. Линда добавила, что необходимы по меньшей мере двое, кто бы знал и понимал произошедшее. Таким образом к команде присоединились Алекс, главный инженер проекта, и Марта, специалист по ПО, отвечающая за распознавание движений.

Новая команда, теперь состоящая из пяти человек, собралась с целью решить первую проблему:

Вербализация разрывов между ожиданиями и фактическими результатами

 

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

Разрыв №1:

Первоначальные ожидания: Важные гости, являющиеся также потенциальными клиентами, останутся под большим впечатлением от показателей Wise-Cameras.

 

Фактический результат: Огромное разочарование, приводящее к снижению репутации и плохому первому впечатлению от системы и компании TopSecurity как надежного и новаторского поставщика.

 

Разрыв №2:

Первоначальные ожидания: Система способна отследить даже самое хорошо продуманное проникновение в защищенное здание.

 

Фактический результат: Умная команда обманула систему.

 

Разрыв № 1 основан на планировании события. Возможно, компания поймет, что стоит репетировать перед представлениями такого рода или же налаживать более тесное взаимодействие между разработчиками и командой исполнителей.

 

Расхождение 2 строится на вопросе: почему за три года не удалось создать результативый продукт?

 

Руководитель команды Гилберт задал Алексу простой вопрос:

Был ли провал вызван незначительной и быстро устранимой технической проблемой?

Алекс: «В спецификациях было очень четко указано, чтобы никакое случайное движение со стороны животных, таких как собаки, не смогли бы активировать сигнал тревоги. Другими словами, ложная тревога не допускается! Таким образом, мы допустили, что любой человек подходит к зданию на двух ногах. Алгоритм распознавания образов основывался на этом допущении».

 

Таким образом мы понимаем, что разрыв № 2 реален и существенен. Касательно ценности лучшего понимания того, что именно привело провалу в части достижения технологической цели проекта, и уверенности, что подобный провал не повторится, следует указать на второй разрыв.

Важно понять, что при анализе обоих разрывов сразу команда теряет способность фокусироваться, что снижает возможность вынести полезный урок о ценности.

Вопросы: Каким должен быть следующий шаг? Нуждаемся ли мы в дополнительной информации и анализе? Если да, какой информации не достает?

 

Новый материал опубликовал в блоге Эли Шрагенхайм. На этот раз он посвящен не учету прохода, стратегии или известным решениям ТОС. Тема этого поста – как на ранних этапах определить возникновение угрозы, и что свидетельствует о наличии у нас ошибочной парадигмы.

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

Как обычно, ссылка на оригинал и картинка на оригинал публикации.

Ваш Дмитрий Егоров

 

Эли Голдратт говорил о необходимости обращать внимание на несоответствия. Он даже заявлял, что нам необходимо мужество, чтобы это делать. Осознав несоответствие, вам настоятельно рекомендуется его устранить[i], даже если это означает обновить одну или больше своих базовых предпосылок[ii].

Я не уверен, называется ли то, что нам надо, «мужество», потому что, если мы выберем игнорирование несоответствия, то в результате мы подвергаем себя угрозе невозможности[iii] понимания нашей реальности. Что нам нужно сделать – это признать тот факт, что мы чего-то не знаем и, таким образом, делаем ошибки; и нам необходимо их устранить[iv] их, чтобы никогда не повторять одни и те же ошибки.

Когда я учился программированию, я понимал, что делал чудовищное количество ошибок, багов в терминологии программистов. Я должен быть принять тот факт, что я не настолько умен, чтобы сделать все правильно с первого раза. Хорошие новости состояли в том, что любой программист генерирует множество багов, и поэтому культура разработки программного обеспечения состояла в том, чтобы вынуждено признать существование багов и ожидать, что каждый программист будет устранять ошибки как можно быстрее. Я предполагаю, что и сейчас это обычная культура в разработке программных продуктов, но только там. Пугающим было осознание того, что я возможно делаю много ошибок в «другой жизни», но у меня там нет компьютера, чтобы бросить их мне в лицо.[v]

Неспособность определить угрозу – это ошибка игнорирования сигналов, которые порождает эта угроза.

Это область нашей ответственности – определять появляющиеся угрозы как можно раньше  и находить соответствующие действия для их нейтрализации.

Некоторые угрозы могут быть предположены до того, как проявятся в нашей реальности и поставят под угрозу нас или нашу организацию. Что мы можем сделать, так это установить «механизм контроля». Вот мое определение термина «контроль»:

Механизм реагирования[vi] для работы с неопределенностью путем мониторинга информации, которая указывает на угрожающие ситуации, и принятия соответствующих корректирующих действий.

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

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

Что мы можем сделать для идентификации возникновения новой угрозы,  о которой мы даже не думали?

Возникающая угроза порождает сигналы, которые несовместимы с нашими ожиданиями..У нас есть название для такого странного чувства, что случилось что-то неожиданное. Мы называем это чувство УДИВЛЕНИЕ (СЮРПРИЗ).[vii]

Сюрпризы могут быть хорошими или плохими, но общий эффект в том, что каждый сюрприз указывает на ошибочную парадигму, которую наш мозг использует автоматически. В действительности парадигма – это маленькая ветка причинно-следственных связей, которые мы автоматически принимаем за истину. Например:

Разве эта парадигма ВСЕГДА работает? Случается, что мои подчиненные не делают того, что должно быть сделано. Это сигнал того, что в логике есть изъян. На этом этапе неясно, где этот изъян.

Ядро сигнала – это разрыв между ожиданиями и результатами:

Мои ожидания: мои подчиненные делают в точности то, что я попросил их сделать!

А теперь я сталкиваюсь со следующим инцидентом: Я попросил Дейва записать все факты относительно Сделки Х. В ответ я получил одну страничку с наиболее очевидными фактами и множеством упущенных важных событий.

Я зол на Дейва. Это не то, чего я от него ожидал. Что мне следует сделать?

Обычно мы имеем дело с разрывом между тем, чего мы хотим и тем, что мы получаем. Организации часто проверяют разрыв между планом и исполнением. Я хочу показать, что разрыв между реалистичными ожиданиями и фактическими результатами – это ключевая возможность обновить ошибочную парадигму.

Давайте еще раз взглянем на простой случай с Дейвом, предоставившим слишком короткий отчет по Сделке Х. Разрыв указывает на ошибочную парадигму, но в чем она состоит? Я объяснил, что необходимо сделать и я все еще босс.

Три (должно быть больше) первоначальных возможных объяснений:

• Дейву наплевать на то, что я попросил его сделать
• Дейв был слишком занять множеством других дел, которые он должен был сделать
• Дейв не понял требуемый уровень детализации

Для того, чтобы понять, что же на самом деле пошло не так, существует потребность проверить факты и затем погрузиться в парадигмы, которыми мы оба, и я и Дейв, оперируем.

Не проводя здесь полного анализа, давайте представим, что проявилось следующее понимание:

Если я недостаточно четко объяснил вопрос «для чего?» нужно то, что я попросил сделать, возможно, что результат будет не таким, как должен быть на мой взгляд.

Если это новый выученный урок – можете вы увидеть возможности[viii] положительных последствий? Возможность того, что их инструкции не будут выполнены – это угроза для каждого руководителя. Если они усвоят необходимость объяснять, зачем необходимо сделать то-или-это, то большая часть этой угрозы не будет материализована. Однако, похожий разрыв может по прежнему появиться как результат другой ошибочной парадигмы. Мы по прежнему должны быть открыты для того, чтобы обнаруживать сюрпризы и продолжать процесс обучения.

 

[i] В тексте «reconcile», буквально «согласовать заново». – прим. переводчика

[ii] В тексте «assumptions» – прим. переводчика

[iii] В тексте «failing» – прим. переводчика

[iv] В тексте «fix», может быть переведено как «зафиксировать», «выявить», но обычно этот глагол используется в значении «найти и устранить» – прим. переводчика

[v] В тексте «to throw the mistakes in my face», я постарался максимально сохранить смысл фразы оригинала. – прим. переводчика

[vi] В тексте «reactive mechanism». – прим. переводчика

[vii] В тексте «surprise», я не смог отдать предпочтение варианту перевода – прим. переводчика

[viii] В тексте «scope» «содержание», «возможности», «рамки». Часто используется в проектном управлении для определения содержания проекта. – прим. переводчика

 

Я продолжаю публиковать переводы материалов блога Эли Шрагенхайма. И сегодня пост, посвященный одной из ключевых концепций Теории ограничений – концепции Прохода.

В этом материале есть момент, который меня озадачил и заставил чуть ли не сутки осмысливать, сделанное Эли предположение или предложение, не знаю как точно выразиться. Озадачил насколько, что у меня появилась потребность предварить перевод собственными размышлениями. Выводы, к которым я пришел, лично для меня оказались полезными.

В своем посте Эли поставил под сомнение целесообразность учета стоимости материалов, как абсолютно переменных затрат, в случае, если продукт, который мы продаем, снят с производства, и материалы, закупленные для его производства, не могут быть использованы больше ни для какого другого продукта.

Эли утверждает, что в этом случае возможно негативное влияние на решение о продаже по сниженным ценам, так как формально, проход будет отрицательным, хотя по факту компания от этого только выиграет.

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

Поясню на простейших примерах. (Во всех примерах использована формула расчета денежного потока для единичной продажи – CF = (P – TVC) – delta OE – delta I)

Пример первый. Мы продаем продукцию и пополняем запасы материалов ровно настолько, насколько потребили материалов, т.е. списание материалов приводит к пропорциональному увеличению запасов. Денежный поток равен (100 – 50) – 0 – 50 итого 50, т.е. равен проходу по сделке.

Пример второй. Мы продаем продукцию по цене ниже стоимости материалов и НЕ ПОПОЛНЯЕМ запасы сырья и материалов (продукция снята с производства), но сумму материалов не учитываем как TVC. Денежный поток равен (80 – 100) – 0 – (-100) итого 180, т.е. расчетный денежный поток БОЛЬШЕ, чем выручка от продажи. Это нонсенс и искажение.

Пример третий. Мы продаем продукцию по цене ниже стоимости материалов, сумму материалов учитываем как TVC и не пополняем запасы сырья и материалов. Денежный поток равен (80 – 100) – 0 – (-100) итого 80. В этом случае, мы не занимаемся дополнительными манипуляциями с учетом, но, несмотря на то, что проход по сделке отрицательный (-20), сделка в целом дает положительный денежный поток в размере выручки, т.е. выгодна.

Эти примеры я написал в комментарии к публикации Эли, посмотрим, что он мне ответит.

А я получил для себя еще несколько подтверждений того, что, во-первых, учет построенный по принципам ТОС позволяет принимать правильные управленческие решения, а, во-вторых, правило смотреть на систему в целом, а не на ее локальные оптимумы и показатели, универсально работает даже для классических подходов ТОС :)

Читайте оригинальную публикацию и делитесь своими вопросами, замечаниями и предложениями. Также в посте есть ссылка на ближайшую сессию по Учету прохода, которую Эли Шрагенхайм будет проводить в Париже. Кто владеет английским языком и имеет возможность – настоятельно рекомендую поучаствовать.

Как обычно, ссылка на оригинал и картинка из публикации автора.

Ваш Дмитрий Егоров.

Проход (T) – это центральная концепция в ТОС и должен быть центральной концепцией для всего управления. Я рассматриваю ее как объяснение добавленной ценности[i], созданной организацией. Я фокусируюсь на ценности использования T, I и OE для принятия высококлассных решений.

Формальное определение T для коммерческой организации: Выручка минус абсолютно переменные затраты (TVC).

Не забудьте про стоимость воды при расчете  T

Мы используем  T как показатель эффективности в периоде времени, так и как показатель для оценки экономического влияния единичного решения – дельта-Т, порождаемого решением, минус дельта ОЕ (операционные расходы), связанные с принимаемым решением.

Доходная часть определения T относительно однозначна. До сих пор, идет обсуждение следует ли указывать в определении время получения выручки. Является ли  T в $1,000, который будет получен в следующем году, таким же, как  T в $1,000 сегодня? Это тема для обсуждения в другое время.

Еще более актуальным является вопрос влияния неопределенности на доходы. Поскольку все решения направлены в будущее, предположение о генерации дохода всегда основано на прогнозе.

Но важнее, чем предсказание доходов, вопрос: что мы должны включать в TVC? Эли Голдратт добавил понятие «абсолютно»[ii] к «переменным затратам», чтобы предупредить нас об осторожности с тем, что мы включаем в TVC.

Я хотел бы подчеркнуть две важные проблемные области, связанные с TVC.

Первая: всегда ли стоимость материалов является TVC?

Вторая: решения высокого уровня могут включать затраты, которые не меняются при принятии боле мелких решений. Следует ли нам рассматривать эти затраты как TVC?

Почему мы утверждаем, что стоимость материалов является абсолютно переменными затратами?

Приобретение сырья и материалов обычно происходит задолго до получения твердых заказов на конечную продукцию. Это означает, что расходы были понесены безотносительно того, продали мы что-либо или нет. Таким образом, расходы прямо не вызваны продажами! Итак, почему же мы обычно рассматриваем расходы на материалы как часть ТVC, а не как часть операционных расходов (ОЕ)?

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

В этом случае следует обращаться с затратами на материалами как с TVC, как мы и привыкли.

Это наблюдение означает, что когда принято решение об остановке дальнейшего производства конкретных изделий, то последующие продажи не должны относиться к стоимости материалов как к TVC. Будет ошибкой воздерживаться от продажи изделий, производство которых прекращено, потому что рыночная цена ниже, чем стоимость материалов. Единственные два вопроса, имеющих отношение к делу: имеется ли у нас достаточно доступной мощности, которая не может быть задействована для удовлетворения имеющегося спроса, и вызовет ли продажа старых продуктов по сниженным ценам снижение продаж основной продукции и не нанесет ли ущерб имиджу бренда на рынке.

Предположим, вы услышали, что стоимость материалов поднялась на 20%. К счастью, у вас достаточные запасы материалов на следующие два месяца. Когда вам следует обновить TVC, вызывающие значительное снижение вашего прохода на единицу продукции?

На мой взгляд, расчет T должен быть обновлен немедленно!  Помните предпосылку: каждая продажа запускает пополнение материалов. Это базовая предпосылка для включения расходов на материалы в TVC.

Другой случай, это рассмотрение переменных затрат решения высокого уровня. Пример: TVC от добавления еще одного пассажира на авиарейс очень низкие, главным образом, это влияние дополнительного веса на расход топлива. Однако, когда принимается решение об отмене или добавлении авиарейса, мы сталкиваемся с очень разными уровнями переменных затрат. Расход топлива на весь перелет – это определенно значимый элемент затрат. Затраты на экипаж включают переменные элементы, которые зависят от времени полета и пребывания в удаленном городе. Я утверждаю, что даже расходы по обеспечению полета должны рассматриваться как TVC, потому что эти расходы являются обязательными для Х часов полета, таким образом,  любая отмена полета снижает будущие расходы на обслуживание.

Тем не менее, должны ли быть эти «более высокие TVC» частью расчета T?

Я предлагаю называть TVC только абсолютно переменные затраты ЕДИНИЧНОЙ ПРОДАЖИ? Для такой продажи у нас есть четкое определение прохода, и любое решение высокого уровня, такое как добавление или отмена авиарейса, будет в любом случае включать конкретные дельта-ОЕ, которые включают все расходы, вызванные этим решением. Таким образом, критерий принятия решения  дельта-T – дельта(OE) > 0 остается неизменным.

Читателям, которые живут в Европе и стараются понять потенциал применения учета прохода в своем бизнесе и принять участие в распространении силы T, I and OE, я бы рекомендовал обратить внимание на мою сессию в Париже в октябре. Ознакомиться можно здесь: http://www.marris-consulting.com/en/Formation-Throughput-Accounting-253.html

[i] Перевод «добавленной стоимости» будет также абсолютно корректным. Но, поскольку Эли в своих текстах, большое внимание уделяет, в том числе, и вопросам «перевода ценности в деньги», то, как переводчик, я предпочел использовать вариант «добавленная ценность» – прим. переводчика

[ii] В тексте «truly» – «истинно», но в официальном переводе на русский этот термин переводится как абсолютно переменные затраты. – прим. переводчика