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

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

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

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

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

ББК (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» иногда переводят как «истинными» или дают кальку «валидными» — прим. переводчика