Цель
Наша организация занимается проектами в области строительства. Основная цель такой компании – выполнять задачи как можно быстрее, сохраняя при этом достаточно высокую валовую прибыль по каждому отдельному делу. Теория Ограничений (ТОС) использует термин Проход (Throughput) – разница между тем, что рынок заплатил организации, и тем, что она отдала внешним поставщикам. Суммарный показатель по всем проектам за год должен покрывать постоянные издержки компании (аренду, ФОТ, и так далее). В терминологии ТОС это «операционные затраты». Все, что остается после вычитания их из Прохода, – это прибыль компании.
Препятствия на пути к цели
Очень часто сроки выполнения проектов затягиваются по причинам, не зависящим от участников. Такие случаи слабо поддаются предсказанию, влиянию и контролю. И даже применение современных методик управления проектами часто не приносит ожидаемого результата. Менеджеры изучают различные способы управления рисками, PMI или IPMA-техники, компании тратят деньги на разработку и внедрение КСУП и прочих чудодейственных систем. А банальная ошибка или недоработка в проектной документации может привести к срыву срока выполнения проекта в несколько месяцев. Знакомая ситуация? И таких проблем в проекте возникает не одна и не две, а много. Руководитель и его команда каждый день сталкиваются с необходимостью сделать сложный выбор: какие «пожары» тушить сегодня в первую очередь, ведь «нельзя объять необъятное» и «в сутках только 24 часа».
Отдельно стоит упомянуть топ-менеджеров. Часто и у них имеются ограничения по ресурсам, которые нужно распределить между несколькими проектами. Это могут быть финансы, трудовые мощности, техника. Проблема выбора возникает именно потому, что какого-то ресурса не хватает на все проекты и нужно решить правильно: куда и сколько сил направить. Ведь если возможности не ограничены, то можно и людей на луну высадить…
Путь
В декабре 2011 года компания узнала о теории ограничений. Особый интерес представляла область управления проектами – CCPM (Critical Chain Project Management).
К этому времени у меня был достаточно убедительный опыт применения ТОС в производственной компании. За восемь недель мы сократили длительность исполнения заказов с семи до двух дней, увеличив возможности производства на 80% без повышения операционных затрат. Мы добились этого простыми пошаговыми действиями, следуя методике внедрения решения ТОС для производства, которую я получил в программе «Стратегические Решения ТОС». Я не видел оснований, почему бы ТОС не дала такой же эффект в управлении проектами. Тем более существует достаточно информации о результатах такого внедрения во многих компаниях по всему миру. Теория Ограничений дает руководителю, команде и топ-менеджерам организации инструменты, позволяющие более четко сфокусироваться на том, что действительно важно для проекта и предприятия в целом. Я и коллектив управленцев вернулись для получения знаний и методики в «Стратегические Решения ТОС».
Шаги
После обучения проектному управлению по ТОС мы провели анализ всей системы, выявили регулярно возникающие нежелательные явления в существующем положении дел, выстроили логические взаимосвязи между ними. Затем спланировали девять точечных изменений в процессах. И эти нововведения начали обкатывать на пилотных проектах.
Первое важное изменение: в уставах проектов мы начали фиксировать их длительность и генерируемый Проход. Так же мы рассчитываем Скорость генерации Прохода по проекту:
Скорость генерации Прохода = Проход / Длительность проекта
Во внутренних отчетах теперь отображается ожидаемая дата сдачи проекта. Также мы стали еженедельно документировать причины изменений Прохода и временных затрат.
Второе изменение: при разработке сетевой диаграммы проекта мы определяем исполнителей и для каждой задачи – напряженную, но достижимую длительность выполнения.
Третье изменение: в сетевом графике проекта устраняем «конкуренцию» за ресурсы. Во многих ИСУП это делается с помощью выравнивания мощностей. Правда не всегда алгоритмы у таких систем удачные или они применяются неверно. Устранение конкуренции за ресурсы лишает ресурс индульгенций типа «а я не успел выполнить работу, потому что срочно делал еще что-то», и вместо критического пути мы получаем Критическую Цепь.
Четвертое изменение: в стратегически важные точки проекта вводим буферы. Это механизмы, которые за счет намеренного создания защитного запаса времени и управления им предотвращают срыв сроков выполнения цепи работ в проекте («питающие буферы») или всего проекта («буфер проекта»). Буферы формируются по определенным правилам и позволяют руководителю и команде однозначно фокусироваться именно на тех участках, которые требуют пристального внимания. При этом отпадает необходимость в дополнительных расчетах типа метода освоенного объема – вы будете в любое время точно знать, где и насколько опаздываете, а где идете с опережением.
Пятое изменение: задачи выполняются в соответствии со статусом буфера. Ежедневные отчеты о ресурсах содержат информацию об ожидаемых сроках завершения работ. Ежедневный исчерпывающий отчет строительного подрядчика теперь занимает 10-15 минут и может быть получен по телефону.
Шестое изменение: мониторинг ресурсов для выполнения ближайших задач. Мы отслеживаем наличие материалов, трудовых мощностей, техники, согласований, финансирования по ближайшим действиям критической цепи.
Седьмое изменение: управление буфером для восстановления. Имея ежедневно обновляемую информацию о состоянии буферов, гораздо легче принимать решения о перераспределении ресурсов. Просто разрабатывать мероприятия, нацеленные на восстановления графика.
Восьмое изменение: на основе еженедельных отчетов о причинах проникновения в буфер проекта, которые регулярно анализируются, легко принимать решения о том, «что чинить в организации».
Девятое изменение: теперь мы можем вести мониторинг критических ресурсов, которые чаще других приводят к проникновению в буфер, чтобы управлять ими более эффективно или нарастить.
Очень быстро такой анализ выявил проблемы с финансированием. По второму проекту было обнаружено недостаточное обеспечение подрядчика трудовыми ресурсами.
Допустим, у нас имеется несколько проектов, каждый их которых генерирует Проход с определенной скоростью. И нам нужно распределить ограниченное количество ресурсов между ними. Раньше принятие таких важных решений делалось больше «интуитивно». Теперь можно использовать расчет. В случае непредоставления ресурсов в проект скорость генерации Прохода упадет. Это явление будет определяться двумя факторами:
1. Уменьшение суммы Прохода вследствие выплаты штрафных санкций по контракту пропорционально времени задержки;
2. Увеличение общей длительности проекта в связи с задержкой.
Для оценки эффективности использования ограниченного ресурса и принятия решений по финансированию разнородных по сути проектов необходимо оценить ROI, то есть продуктивность применения дефицитной мощности с точки зрения сохранения наибольшей суммарной скорости генерации Прохода по всем задачам. Его мы вычисляем по формуле:
ROI = Ожидаемое падение скорости генерации Прохода проекта / количество требуемого дефицитного ресурса
В идеале, если ресурс не ограничен, необходимо предоставить его во все проекты и сохранить наибольшую скорость генерации Прохода по всему портфелю. В случае нехватки мощности, нужно в последнюю очередь предоставлять ее в проекты с наименьшим показателем ROI. Они требуют большего количества ресурсов для защиты от незначительного снижения генерируемого Прохода. Безусловно, такой расчет не означает отмены оценки влияния важных политических факторов при принятии решения.
Новые инструменты, применяемые нами в пилотных проектах, уже сейчас дают возможность с высокой точностью ежедневно прогнозировать сроки завершения задач, фокусировать внимание команды на действительно важных потоках работ, своевременно разрабатывать и предпринимать корректирующие действия. Мотивация коллектива напрямую связана со скоростью генерации Прохода в проекте. Служба контроля качества теперь получает статистическую информацию о причинах, наиболее часто приводящих к задержкам, что дает нам возможность непрерывно улучшать деятельность компании. Инструменты Теории Ограничений дают реальный механизм для ускорения движения проектов. Следовательно, компания будет приносить больше прибыли в год, и в этом наша цель.
Спасибо! Как заядлый поклонник ТОС не часто вижу статьи где подход к теории выполнен столь осмысленно. Еще раз спасибо за столь замечательную статью.
Как то всё сильно ''вообще''.
Critical Chain Project Management - понятно, что это брэнд, созданный для заработка денег. ''буфер проекта'' - те или иные резервы проекта, и т.д. В общем ничего конкретного, понимание управления проектами достигается с помощью общих логических принципов и ничего уникального не имеет, кроме трех слов-брэндов - ''Critical Chain Project Management '', ''проход проекта'', ''буфер проекта''. В общем суть создавай резервы ресурсов/времени в критических точках. И направляй максимум ресурсов для достижения максимального результатата по проектам. Это и так понятно, объяснено еще Питером Ф. Друкером, не говоря уже о военной теории. Как всегда простые вещи облекаются в красивую обертку и продаются, а затем некие профи вещают на языке этой шелухи - ''CCPM'', ''Total Quality Management'', ''Management By Objectives'', и т.д.
Трижды прочитал данную статью, но так и не понял, в чем же принципиальная новизна предлагаемого метода(теорией это можно назвать только имея очень буйную фантазию) по сравнению с ''традиционным'' проектным менеджментом (по PMBOK).
Если руководитель проекта не знает стандартов по управлению проектами , то конечно ТОС - это уже шаг вперед в повышении менеджерской квалификации. И в таком случае изучение ТОС, как упрощенного (для чайников) подхода к УП, безусловно полезно. Но лучше все же изучить классику в виде PMBOK. Хотя бы в 3-й версии.
Человек поделился успешной практикой... В чем причина для недовольства? Новую теорию он Вам должен был создать? Во первых они так часто не рождаются и к сожалению чаще всего не в нашей стране. Во вторых и там нашли бы к чему придраться...
Поясню для тех, кто ''не был на стройке'' и не понимает моего восторга)).
Хорошо быть крутым специалистом и сидеть в крупном инвестиционном фонде в столице и быть Заказчиком). Но не у всех это есть. И причины разные. Есть лишь то, что есть. Так вот автор из не очень эффективного ''что есть'' сделал очень эффективное ''стало''.