Теория ограничений в действии. Системный подход к повышению эффективности компании
Шрифт:
Мортон подтвердил слова Джима, перечислив целый ряд продуктов, которые можно было бы разработать благодаря данной платформе. Он отрицал те очевидные проблемы, которые встали на пути реализации проекта, но все же считал, что из него вполне можно извлечь выгоду, если воспользоваться всеми знаниями и опытом, что были накоплены за время работ над системой. Джим согласился с Мортоном, сказав, что оборудование, выпущенное в рамках проекта, значительно превосходит многие аналогичные приборы. И в завершение он отметил: «Самое главное, что в конце концов мы полностью выполнили все задачи, которые поставили перед собой, и наша система соответствует всем заявленным характеристиками и демонстрирует запланированную функциональность».
Однако
Заметим, что платформа, созданная в рамках проекта «Глаз крокодила», позже была использована в ряде проектов, реализованных компанией Rand. И вполне возможно, что «Глаз крокодила» все-таки внес свой вклад в процветание фирмы. В свою очередь, Джим, работая теперь уже на компанию-конкурента, успешно реализовал тот же принцип в ряде крупнейших нестандартных проектов. Тем не менее словосочетание «Глаз крокодила» стало среди сотрудников Rand синонимом неудачи, плохого руководства проектом, ошибки, из которой следует извлечь урок.
Анализ ситуации
Все мы время от времени ошибаемся. Самое неприятное в этой истории то, что главные герои упорно не хотят делать выводы из своих ошибок. Вряд ли Эрнест Бур и другие руководители на собственном опыте усвоили урок, который дает Голдратт в работе «Критическая цепь» («Critical Chain»), но хоть что-то они должны были для себя вынести из описанной ситуации. Однако из истории следует, что не было предпринято ни единой попытки проанализировать однажды принятые решения, сделать какие-то выводы. Полагаю, что очень редко из подобных ситуаций извлекаются уроки для организации в целом. Возможно, кто-то и сделал какие-то отдельные выводы для себя лично. И очень хочется надеяться, что Джим Моррисон, по-настоящему хороший менеджер проекта, получил важный урок и в следующий раз будет осторожнее. Компания же, в которой он работал, – фирма Rand – так ничему стоящему и не научилась. Яркий пример – увольнение Джима по результатам реализации проекта. Это ошибочный шаг.
Я считаю, что на ошибках учатся лишь в том случае, когда на деле получают совсем не то, что ожидали получить изначально. Неожиданность заставляет людей задуматься о причинах того или иного явления. Если мы понимаем, что ожидаемый и полученный результаты не совпадают, значит, в нашем мышлении засела модель, которую надо пересматривать. Пересмотр моделей и есть процесс обучения. Многому можно научиться, когда выявлены расхождения между планами и реальными результатами, которые были получены. В этом случае можно заняться и процессом непрерывного совершенствования.
Чему нас учит данная история? Давайте сначала найдем главные расхождения между желаемым и задуманным. Несколько целей остались нереализованными. С какой начнем?
Для начала перечислим их. Итак, где планы разошлись с реальностью? Во-первых, время, потребовавшееся на создание опытной модели системы. Сначала планировалось, что на это понадобится два с половиной года, а на деле ушло четыре с половиной. Во-вторых, коммерческая сторона дела: вместо шести удалось продать всего две системы. И это особенно плохо, если вспомнить, что бюджет проекта превысил планируемый лимит. Третья неудача – неправильный выбор технологии, который чуть было не сгубил весь проект целиком. Этой проблемы не ожидал никто.
Рассмотрим все три несоответствия по порядку. Начнем с самого неприятного и болезненного для компании – с коммерческого аспекта. Почему именно он самый болезненный? Да потому, что если бы удалось продать шесть систем, как и планировалось, то вряд ли бы Эрнест Бур назвал этот проект величайшим провалом. При этом акцент сделан именно на том, что не удалось реализовать шесть систем, а не на том, что расходы превысили плановые показатели. Чтобы получить более полную картину причин
Диаграмма на рис. 9.1 вкратце объясняет провал по одному из аспектов.
На вершине диаграммы мы видим несоответствие между двумя противоположными утверждениями. Причинно-следственные цепочки дают нам представление о том, на чем основывались исходные ожидания, планы и чем вызвано появление именно такого результата. Простейшие логические рассуждения приводят нас к двум причинам неудачи. Первая: серьезные задержки с разработкой системы. Если бы опытный образец был готов в середине 1993-го, то к тому времени, скорее всего, еще не было бы внедрено альтернативное решение и флоту бы потребовалось более двух систем. Размышления о том, что было бы, если бы проект завершился вовремя, отображены на рис. 9.2. Диаграмма представляет собой логическое дерево, дающее предполагаемый сценарий развития событий в нереальных обстоятельствах – «если бы… то». Вторая причина сорванных планов продаж: иная точка зрения нового командующего на вопрос о необходимости системы.
Как следует из этих рассуждений, все-таки трудно угадать, сколько бы удалось продать систем, так как на должность заступил новый командующий, который не так высоко ценит важность «Глаза крокодила». Таким образом, даже если проект и был бы завершен вовремя, это вовсе не означает, что именно шесть систем понадобилось бы заказчику.
Получается, что ошибка кроется в изначальных оценках будущих продаж. Неправильно было ожидать, что удастся продать целых шесть систем. Принимая во внимание, что командование может смениться и новые люди не обязательно будут разделять мнение предшественников, можно увидеть, что в расчет не была взята реальная ценность системы для флота – то, насколько она действительно нужна ВМС.
Но при всем при том можно утверждать, что шанс продать все шесть систем был упущен именно из-за задержек в реализации проекта. Тут мы подошли к проблеме со временем.
Давайте разберемся, в чем же причины постоянных переносов сроков. Начнем с двух общих предположений и, опираясь на имеющиеся данные, посмотрим, к какому выводу мы придем. Возможны несколько объяснений несоответствия планов и результатов. Каждая версия нуждается в дополнительной проверке, так как лишь одна из них верная.
Версия первая: исходно ошибочные ожидания, неправильное планирование с самого начала – объясняет неожиданность и несоответствие реального результата тому, что было задумано.
Версия вторая: слабое управление проектом (плохой менеджер). Но это очень общее утверждение, которое необходимо рассмотреть более детально.
На рис. 9.3 даны весьма приблизительные оценки, причинноследственные отношения здесь выстроены не так строго, как того обычно требует ТОС. Например, утверждение «Разработка платформы заняла гораздо больше времени, чем планировалось сначала» влечет за собой следствие «Проект завершился лишь в июле 1995 г.». Но при этом исходное утверждение (причину) следовало бы объединить эллипсом с еще одним, говорящим, что на других этапах проекта подобных задержек не наблюдалось. Мы знаем, что так оно и было, поэтому строгое логическое построение не отражено в диаграмме. Есть еще одна причина, действующая независимо: «Результаты подпроекта 2 не подошли под новую конфигурацию системы». Поэтому две стрелки, идущие к результату, между собой не объединены.