Теория ограничений: девять шагов к успешному управлению проектами

Цель

Наша организация занимается проектами в области строительства. Основная цель такой компании – выполнять задачи как можно быстрее, сохраняя при этом достаточно высокую валовую прибыль по каждому отдельному делу. Теория Ограничений (ТОС) использует термин Проход (Throughput) – разница между тем, что рынок заплатил организации, и тем, что она отдала внешним поставщикам. Суммарный показатель по всем проектам за год должен покрывать постоянные издержки компании (аренду, ФОТ, и так далее). В терминологии ТОС это «операционные затраты». Все, что остается после вычитания их из Прохода, – это прибыль компании.

Препятствия на пути к цели

Очень часто сроки выполнения проектов затягиваются по причинам, не зависящим от участников. Такие случаи слабо поддаются предсказанию, влиянию и контролю. И даже применение современных методик управления проектами часто не приносит ожидаемого результата. Менеджеры изучают различные способы управления рисками, PMI или IPMA-техники, компании тратят деньги на разработку и внедрение КСУП и прочих чудодейственных систем. А банальная ошибка или недоработка в проектной документации может привести к срыву срока выполнения проекта в несколько месяцев. Знакомая ситуация? И таких проблем в проекте возникает не одна и не две, а много. Руководитель и его команда каждый день сталкиваются с необходимостью сделать сложный выбор: какие «пожары» тушить сегодня в первую очередь, ведь «нельзя объять необъятное» и «в сутках только 24 часа».

Отдельно стоит упомянуть топ-менеджеров. Часто и у них имеются ограничения по ресурсам, которые нужно распределить между несколькими проектами. Это могут быть финансы, трудовые мощности, техника. Проблема выбора возникает именно потому, что какого-то ресурса не хватает на все проекты и нужно решить правильно: куда и сколько сил направить. Ведь если возможности не ограничены, то можно и людей на луну высадить…

Путь

В декабре 2011 года компания узнала о теории ограничений. Особый интерес представляла область управления проектами – CCPM (Critical Chain Project Management).

К этому времени у меня был достаточно убедительный опыт применения ТОС в производственной компании. За восемь недель мы сократили длительность исполнения заказов с семи до двух дней, увеличив возможности производства на 80% без повышения операционных затрат. Мы добились этого простыми пошаговыми действиями, следуя методике внедрения решения ТОС для производства, которую я получил в программе «Стратегические Решения ТОС». Я не видел оснований, почему бы ТОС не дала такой же эффект в управлении проектами. Тем более существует достаточно информации о результатах такого внедрения во многих компаниях по всему миру. Теория Ограничений дает руководителю, команде и топ-менеджерам организации инструменты, позволяющие более четко сфокусироваться на том, что действительно важно для проекта и предприятия в целом. Я и коллектив управленцев вернулись для получения знаний и методики в «Стратегические Решения ТОС».

Шаги

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

Первое важное изменение: в уставах проектов мы начали фиксировать их длительность и генерируемый Проход. Так же мы рассчитываем Скорость генерации Прохода по проекту:

Скорость генерации Прохода = Проход / Длительность проекта

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

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

Третье изменение: в сетевом графике проекта устраняем «конкуренцию» за ресурсы. Во многих ИСУП это делается с помощью выравнивания мощностей. Правда не всегда алгоритмы у таких систем удачные или они применяются неверно. Устранение конкуренции за ресурсы лишает ресурс индульгенций типа «а я не успел выполнить работу, потому что срочно делал еще что-то», и вместо критического пути мы получаем Критическую Цепь.

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

Пятое изменение: задачи выполняются в соответствии со статусом буфера. Ежедневные отчеты о ресурсах содержат информацию об ожидаемых сроках завершения работ. Ежедневный исчерпывающий отчет строительного подрядчика теперь занимает 10-15 минут и может быть получен по телефону.

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

Седьмое изменение: управление буфером для восстановления. Имея ежедневно обновляемую информацию о состоянии буферов, гораздо легче принимать решения о перераспределении ресурсов. Просто разрабатывать мероприятия, нацеленные на восстановления графика.

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

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

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

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

1. Уменьшение суммы Прохода вследствие выплаты штрафных санкций по контракту пропорционально времени задержки;

2. Увеличение общей длительности проекта в связи с задержкой.

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

ROI = Ожидаемое падение скорости генерации Прохода проекта / количество требуемого дефицитного ресурса

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

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

Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Младший партнер, Курск

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

Нач. отдела, зам. руководителя, Иваново

Critical Chain Project Management - понятно, что это брэнд, созданный для заработка денег. ''буфер проекта'' - те или иные резервы проекта, и т.д. В общем ничего конкретного, понимание управления проектами достигается с помощью общих логических принципов и ничего уникального не имеет, кроме трех слов-брэндов - ''Critical Chain Project Management '', ''проход проекта'', ''буфер проекта''. В общем суть создавай резервы ресурсов/времени в критических точках. И направляй максимум ресурсов для достижения максимального результатата по проектам. Это и так понятно, объяснено еще Питером Ф. Друкером, не говоря уже о военной теории. Как всегда простые вещи облекаются в красивую обертку и продаются, а затем некие профи вещают на языке этой шелухи - ''CCPM'', ''Total Quality Management'', ''Management By Objectives'', и т.д.

Директор по маркетингу, Москва
Андрей Рябкин пишет: Как всегда простые вещи облекаются в красивую обертку и продаются, а затем некие профи вещают на языке этой шелухи - ''CCPM'', ''Total Quality Management'', ''Management By Objectives'', и т.д.
Именно так. Чем больше нарабатываешь управленческой практики, тем отчетливей понимаешь, что в основе появляющихся как грибы после дождя аббревиатур, обозначающих якобы новые подходы, методики, системы, лежит все тот же старый добрый Питер Друкер, хотя и всячески перелицованный... Честно говоря, эта ''шестисигмовая'', etc. шелуха уже изрядно надоела...
Руководитель проекта, Москва
По поводу ТЕОРИИ Ограничений и ПРАКТИКИ управления проектами Коллеги, я с 1997 года занимаюсь проектами, и в 2005 году даже успешно сертифицировался на PMI PMP. Проведя много строительных проектов я изучил несколько наречий русского, английского и узбекского языков, применяемые в строительстве. Почти во всех проектах я сталкивался со срывами сроков их выполнения (или серьезными рисками срывов сроков). Я не стал продлевать сертификацию PMP, т.к. не видел практического смысла в этом. В попытках улучшить свои навыки управления я изучал сайт e-xecutive, и наткнулся на статью по Теории Ограничений. За два года я изучил массу литературы, видео, и прошел ряд тренингов по теме. И именно из-за высокой практической (прикладной) эффективности предлагаемых методов не прекращаю изучения этого инструмента. Поверьте, даже на стройке эти техники часто помогают даже больше, чем матерные слова. :) По поводу терминологии В статье использованы термины Теории Ограничений, принятые в среде практиков, её использующих. Термины ''Проход'' (вовсе не то, что кто-то мог подумать), ''Буфер проекта'' и другие можно посмотреть в словарях на русскоязычных сайтах по теме. По поводу ''шелухи'' (''CCPM'', ''Total Quality Management'', ''Management By Objectives'', и т.д.) На стройке не применяют модные инструменты. Применяют те, которыми можно построить. Мне их применение принесло (и приносит) пользу, может принесет еще кому-нибудь. Каждый руководитель проекта сам выбирает - улучшить свои результаты работы, сфокусировавшись на действительно важных вещах, или вести ''штабное строительство'' и тушить пожары в проекте по мере их возникновения. В первом случае вам пригодился бы инструментарий Теории Ограничений. Во втором случае вам нет необходимости читать сайты вроде e-xecutive - бегите лучше тушить пожары. Я в своё время не поленился, съездил в Новосибирск на предприятие, которое на практике применяет ТОС в производстве. Ребята мне много интересного показали и рассказали. Они на своем производстве делают сложные инженерные изделия на заказ в сроки, которые некоторым серийным производствам и не снились, по очень разумным ценам (не сильно выше серийного производства). И помогли открыть еще несколько таких предприятий своим партнерам. У этих практиков многому можно научиться. Кстати, для тех, кто действительно изучал различные инструменты, которые упоминались в комментариях: когда-то произошло слияние Бережливого Производства и 6-Сигм. Сейчас к ним присоединяется Теория Ограничений. Даже есть книжка с таким названием (может вы её даже читали). Так вот, интересно, что эти три подхода не конкурируют между собой (за звание лучшего, истинного, победного, единственного и т.д.), а очень органично дополняют друг друга. И даже есть на свете компании, которые, применяя эти подходы на практике, получают прирост бизнеса (в виде чистой прибыли), который исчисляется в десятках (а не в десятых долях) процентов в год. Про первоисточники Тем, кто хочет изучить ТОС можно для начала почитать книги Элияху Голдратта (разработчик TOC, физик (газо- и гидродинамика), имел много инженерных патентов (например, в сфере капельного орошения)) и его соавторов: ''Цель-1'', ''Цель-2. Дело не в везенье''. Они касаются производства, но и являются ''азбукой'' ТОС. Для руководителей проектов можно посоветовать книгу Лича Лоуренса ''Вовремя и в рамках бюджета''. Есть еще классные книги для тех, кто управляет производствами (любыми), розничными магазинами (и единичными и сетями), поставками.
Управляющий директор, Украина

Трижды прочитал данную статью, но так и не понял, в чем же принципиальная новизна предлагаемого метода(теорией это можно назвать только имея очень буйную фантазию) по сравнению с ''традиционным'' проектным менеджментом (по PMBOK).
Если руководитель проекта не знает стандартов по управлению проектами , то конечно ТОС - это уже шаг вперед в повышении менеджерской квалификации. И в таком случае изучение ТОС, как упрощенного (для чайников) подхода к УП, безусловно полезно. Но лучше все же изучить классику в виде PMBOK. Хотя бы в 3-й версии.

Генеральный директор, Уфа

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

Директор по маркетингу, Нижний Новгород
Статья классная! Конкретный пример ''было-применили-стало''. Смогли применить общие методы к конкретным проблемам и получили отличные результаты! А если учесть, что речь идет о строительстве, то это вдвойне отличные результаты!))
Владимир Глинский пишет: Трижды прочитал данную статью, но так и не понял, в чем же принципиальная новизна предлагаемого метода(теорией это можно назвать только имея очень буйную фантазию) по сравнению с ''традиционным'' проектным менеджментом (по PMBOK).
Если Вы не были на стройке, то Вам не понять насколько круто то, чего они добились))). А уж новизна/не новизна метода, аббревиатуры - это все ерунда по сравнению с конкретным результатом. И автор статьи по праву им гордится! Автору респект!
Директор по маркетингу, Нижний Новгород

Поясню для тех, кто ''не был на стройке'' и не понимает моего восторга)).
Хорошо быть крутым специалистом и сидеть в крупном инвестиционном фонде в столице и быть Заказчиком). Но не у всех это есть. И причины разные. Есть лишь то, что есть. Так вот автор из не очень эффективного ''что есть'' сделал очень эффективное ''стало''.

Менеджер, Москва
Наталья Черентаева пишет: Поясню для тех, кто ''не был на стройке'' и не понимает моего восторга)).
Я не понимаю Вашего восторга, так как не понимаю: ''При чем в этой статье ТОС?
в уставах проектов мы начали фиксировать их длительность и генерируемый Проход.
1. То есть, - на этапе ''Планирования проекта'' длительность и бюджет проекта не были зафиксированы ( п. 3.4.9 - 3.4.11 РМВоК-4).
при разработке сетевой диаграммы проекта мы определяем исполнителей и для каждой задачи – напряженную, но достижимую длительность выполнения.
2. То есть, - на этапе ''Планирование проекта'' не были выполнены п. 3.4.8 и 3.4.13 (там же).
в сетевом графике проекта устраняем «конкуренцию» за ресурсы.
3. То есть, - на этапе ''Планирование проекта'' не были выполнены п. 3.4.8 и 3.4.11 (там же).
в стратегически важные точки проекта вводим буферы.
4. На этапе ''Планирование проекта'' не был выполнен п. 3.4.9 (там же). .... далее - аналогично. Все о чем написано в статье - предусмотрено в РМВоК, но ... РМВоК - очень избыточен и человек, обладающий дипломом PMI должен был прочитать на самой первой странице в разделе ''Уведомление'' следующие слова:
При использовании данного документа использующее его лицо должно самостоятельно определять действия, необходимые в конкретных обстоятельствах, полагаясь при этом исключительно на свое суждение или, при необходимости, на совет компетентного профессионала.
Так что выбор того, что нужно в каждом конкретном проекте - всегда за менеджером проекта. Для разных проектов, в разных областях нужно брать разные разделы РМВоК, но для этого нужно быть ''компетентным профессионалом'' (знание ТОС - не обязательно :D ).
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии