Проектный подход для Лин-преобразований и не только (опыт применения)

В этой статье я хочу рассказать о применении проектного подхода на предприятии, где профессионально проектами не занимались никогда. О синергетическом соединении двух полюсов: Lean Thinking и Project Management. О трудностях внедрения проектного подхода и путях их преодоления. Я уверен, что современный проектный подход можно с пользой применять для более организованного перехода из устоявшейся неприглядной рутины к желаемому целевому состоянию предприятия, основанному на принципах Lean/TPS. Это также хороший инструмент для вовлечения в преобразования лучших сотрудников и отсеивания балласта. Одно условие – истинными лидерами преобразований должны стать первые лица компании.

Ежедневная рутина на предприятии движется по инерции, словно бессознательное существо. Новый человек, приходя на производство, словно садится в поезд и едет туда, куда проложены рельсы. От него мало что зависит, всё давно уже заведено и «налажено». Сначала он присматривается к обстановке и людям, вникает, что-то подхватывает, потом в нём формируется привычка и мозг почти отключается. Думать вредно, нужно просто делать. Это касается всех: рабочих, специалистов, топ-менеджеров. Это только кажется, что в «текучке» работа топ-менеджеров или специалистов куда более творческая, чем у рабочих. Нет, просто у рабочих механика больше мышечная, а у специалистов и менеджеров рутина умственная. И те, и другие едут по накатанной.

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

Начиная с 2006 года я несколько раз был на Лин-форумах и Лин-школах, а также на конференциях и семинарах по управлению качеством. Осенью 2008 года я посетил ежегодную конференцию московского отделения PMI по управлению проектами. Я был удивлен тем, что это две совершенно разные тусовки, словно два параллельных мира. И это несмотря на то, что и там, и тут говорят примерно об одном и том же, о создании ценности, о клиентоориентированности, о процессах, об эффективности. На конференцию по управлению проектами приходят, в основном, строители (девелоперы), айтишники (разработчики программного обеспечения), консультанты. На Лин-форумы и конференции по качеству приходят представители автопрома, обрабатывающей промышленности, заводчане, другие консультанты, но редко приходят строители и айтишники. У меня возник вопрос: почему такое разделение?

С проектным подходам я знаком давно и практически. Применял его при разработке и внедрении информационных систем. Когда в 2006 году мы начали осваивать и пытаться применить методы и инструменты бережливого производства на конкретном предприятии, мы назвали эту работу Проектом (чтобы не создавать отдела и придать работе динамику). Но с первых недель стало ясно, что применить проектный подход в чистом виде к этой работе не удаётся. Планировать сложно из-за большой неопределенности и отсутствия выделенных для проекта ресурсов. В обычном проекте (согласно методикам PMI и других школ проектного менеджмента) выделяются необходимые ресурсы, создается проектная команда, люди подчиняются руководителю проекта и делают то, что он вместе с ними запланировал. Здесь же не так. Люди из разных цехов и отделов подчиняются своим начальникам, загружены текучкой, к проекту относятся как к чему-то второстепенному, факультативному. Планы с трудом согласовывались, сроки срывались, объяснения были стандартные: «а когда я буду делать свою ОСНОВНУЮ работу?», «мне за это не платят», «мой начальник не за это с меня будет спрашивать», «зачем нам это нужно?».

Чуть позже стало ясно, что вести всю эту работу как один проект нереально и неправильно. Работу нужно разбить на несколько проектов, которые можно будет выполнять параллельно, разными людьми, разными командами. Важно при этом обеспечить хорошую координацию, чтобы все проекты вместе согласованно двигались в нужном направлении. Мы создали реестр всех проектов (список), определили вес каждого проекта, назначили руководителей (с их «добровольного» согласия). Но увидели, что мало кто понимает, что такое проект и как правильно организовывать проектную работу. Люди, привыкшие к рутине (см. выше), оказались не готовы двигать проекты. Они привыкли работать только со своими подчиненными, привыкли делать только то, что умеют сами. Например, если руководитель проекта из отдела продаж, он не хотел отвечать за ту часть проекта, которая связана с производством. И наоборот. Если немного перефразировать: руководители проектов считали, что всё запланированное они должны делать сами, в крайнем случае, с привлечением своих подчиненных. Обращаться в другой отдел за помощью и договариваться о выделении ресурсов было непривычно, неудобно.

Возникла потребность в обучении управлению проектами.

Для начала обходились собственными силами. Сделали образцы (шаблоны) для презентации новых проектов (постановка задачи) и для периодического отчета по проектам. Провели пару внутренних обучающих семинаров и вперед. Далее начали регулярно собираться, чтобы обсуждать ход выполнения проектов. Результаты были неутешительные. Кто во что горазд. Предложенная дисциплина не приживалась. Кто-то не успевал сделать всё как надо, ссылаясь на занятость. Кто-то задавал вопросы в последний момент, за час до совещания (синдром студента – готовиться к экзаменам в последний день). Руководство на это не обращало особого внимания, мол, люди не только этим занимаются, у нас тут производство всё же.

Бывают компании, где проекты – основная деятельность, там на проектах зарабатывают. А потому там жёсткая проектная дисциплина. У нас же основная деятельность – процессы (повторяющиеся операции). Для чего же нам нужны проекты? Объясняли людям так: проект – это ответ на некую проблему или возможность. При этом статус проекта присваивали работе только в том случае, когда проблема не могла быть решена быстро и в режиме выполнения текущей деятельности (за счет небольшого улучшения или доработки), и когда требуется специальная или нестандартная организация этой работы, когда нужна межфункциональная команда, когда высоки риски. Аналогично, если появлялась возможность дополнительно заработать, а текущая организация работы была неспособна реализовать эту возможность, запускали проект.

Проекты высшего уровня предложили называть бизнес-проектами. Любой бизнес-проект должен быть направлен на создание или развитие конкурентных преимуществ, на рынок и клиентов, на достижение стратегических целей (а здесь был вопрос, какие они?), он должен в итоге приносить прибыль. Бизнес-проекты должны подпирать Стратегию и Виденье, как ножки стола подпирают стол и его содержимое. Руководителем бизнес-проекта должен быть либо топ-менеджер, либо опытный менеджер среднего звена. Далее, каждый бизнес-проект мог быть развёрнут в несколько технических проектов второго и третьего уровня. Руководитель бизнес-проекта автоматически становился главным заказчиком и спонсором проектов второго уровня. И так далее.

Идея была красивой, но почему-то не пошла. Собирались нерегулярно, словом «проект» называлось всё, что в голову придёт. Работы начинались без согласования целей проектов, часто без учёта мнений заказчиков, без более-менее ясного плана, хаотично. Нужно было создать определённую дисциплину и существенно повысить статус проектов. А когда предприятие процессное, руководство не готово видеть в проектах нечто сопоставимое по важности с текучкой. В оргструктуре есть цеха и отделы, штатное расписание, оклады, начальники подразделений. Там нет проектов. На ежегодном бюджетировании опять же мыслили в терминах бюджетов подразделений, а не проектов. Проекты были как бы в тени. И это сложно для людей, привыкших только к текучке, параллельно с «основной» работой ответственно работать в проектах.

Нет пророка в своём отечестве. Чтобы руководство услышало из других уст, что же такое проекты и как ими нужно ПРАВИЛЬНО управлять, я предложил провести обучение с привлечением внешних консультантов по управлению проектами. За ними я и пошёл на ту самую конференцию PMI. Там познакомился с несколькими людьми из разных компаний, договорился о встречах, которые и состоялись позже. Из трех претендентов выбрал одну компанию, с которой и начали работать. Сначала провели однодневный (8-ми часовой) семинар для топов, включая генерального директора. У топов появился некоторый интерес, правда, до конца все не усидели. Наметили 3-х дневный, более углублённый семинар для группы из 15 человек (среднее звено, специалисты). Выделить три дня подряд из текучки было не просто. То один не может, то другой. Всё же провели: четверг, пятница, суббота. В субботу пришли далеко не все. Топы могли бы поучаствовать и в этом 3-х дневном семинаре, но не захотели (при подчиненных-то решать задачки, показывать свои способности – не каждый на это пойдет). Да и подчиненные не привыкли при руководстве быть раскованными.

В реестре проектов у нас были, например, такие проекты: Предупреждение брака, Реконструкция новой фабрики, Модернизация узлов погрузки, Ремонт дорог, Благоустройство территории, Обновление информационной системы, Быстрое закрытие месяца, Аутсорсинг обслуживания тепловозов, Выравнивание отгрузок, Обеспечение радиосвязи в карьере (рации), Склады смешивания, Обучение Excel и статистическим методам, Изменение системы оплаты труда, Создание системы управления проектами, Реорганизация компании и другие. Проекты очень разные и было непросто их увязать в единое целое. Более того, было невозможно их все выполнять параллельно. Постоянно поднимался вопрос о приоритетах. Сами придумали простую систему управления приоритетами, подобную трём цветам светофора: Зелёный, Желтый, Красный. Проекты, находящиеся в зеленой зоне, должны активно выполняться (им дан зеленый свет). Проекты в красной зоне – приостановлены, либо закрыты. Проекты в желтой зоне выполняются в фоновом режиме. Т.е. если с зелеными проектами всё в порядке, можно часть усилий переложить на жёлтые проекты. Периодически приоритеты менялись. Если проект казался уже не очень актуальным или на него просто не хватало ресурсов, его зеленый цвет менялся на желтый или даже красный.

Консультанты предложили совместно разработать простую облегчённую (light) методику и систему документов для более формализованного управления проектами. Кроме всяких общих положений, которые почти никто так и не прочитал, ввели следующие обязательные документы по каждому проекту: Паспорт проекта, Календарный план, Статус-отчет. В паспорте проекта развернуто формулировалась цель проекта, участники, основные этапы, сроки, бюджет, риски и другое. К паспорту проекта прикладывался укрупненный (в крупную клетку) базовый календарный план, который, по идее, должен меняться не часто, в котором сроки были с запасом. Рабочий календарный план делался на основе базового, более детально (ближайший период), с более напряжёнными сроками (чем в базовом).

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

Идея всем была «понятна», но не всё гладко было на практике. Важным участником проекта должен был быть СПОНСОР проекта. Он должен быть кровно заинтересован в достижении поставленной цели, в получении значимых результатов. Его роль в том, чтобы помогать руководителю проекта преодолевать трудности, разрешать конфликты, принимать решения по рискам, проблемам, ресурсам, финансированию. Однако топы были сильно заняты другими делами и не всегда имели возможность погрузиться в суть и детали проектов, где они числились спонсорами. В связи с этим, они далеко не всегда выполняли свою роль – быть главным заказчиком. Это расхолаживало руководителей проектов и других участников. Привычная текучка опять побеждала в отдельных случаях. Ведь гораздо проще делать то, чем ты занимался много лет, чему учился в институте, к чему привыкло твоё руководство.

И, тем не менее, мы увидели, что проектный подход даёт результаты. Без него в сложной нестандартной работе наступает полный хаос и безответственность. Для нас проектный менеджмент – это способ организации нестандартной, сложной и разовой работы, обеспечивающий хоть какую-то прозрачность и куда большую эффективность, чем просто поручения руководства (устные или через формальный приказ): «Всё понятно? Иди делай!... Как дела?... Нормально!... Есть проблемы?... Всё сделаем, шеф!».

С другой стороны, мы увидели, что в этой работе появилось много формальностей, которые не всегда оказываются полезными по разным причинам. Безусловно, четко записать и согласовать цель проекта – это большое достижение по сравнению с тем, как было раньше. Безусловно, если понятна цель проекта, то нужно составить какой-то план её достижения и привязать его к срокам и ресурсам. Но из-за отсутствия практики календарного планирования получалось так: план делали, а работали не всегда по плану, календарный план (в MS Project) открывали на мониторингах, но на экран проектора почти никто не смотрел, ограничиваясь устными обсуждениям (так привычнее, «комфортнее», просто поговорить). Т.е. календарные планы (что именно руководитель проекта предлагает делать для достижения целей) не подвергались анализу, а потому во многом делались формально («сказали надо – сделаем»).

Многие наши проекты действительно имели большую степень неопределенности, из-за отсутствия опыта у участников, из-за изменения внешних условий, особенно в последний год, из-за недостатка ресурсов и неправильной оценки рисков (часто риски путали с проблемами). Я увидел, что стандартный (громоздкий и жесткий) подход (в стиле PMI) не совсем пригоден для нас, даже его сильно облегчённая версия (дух подхода оставался прежним). И это не только из-за отсутствия опыта. Если всё делать по методике, уходило слишком много времени на оформление и в голове вертелось слово «muda». И тут мне приходили мысли о том, чтобы эти две тусовки (см. выше) узнали друг про друга. Проектный менеджмент способен помочь осуществлять Лин-преобразования компаний, а богатый арсенал TPS и Lean Thinking способен обогатить проектный подход и уменьшить потери (muda) в его процессах. Это синергетическое сближение большая возможность для взаимного роста. В проектном подходе тоже есть процессы, в которых может быть перепроизводство, избыточные запасы, неиспользованный творческий потенциал людей, дефекты, излишняя обработка и т.д. К проектным методикам нужно применять Кайдзен.

Еще давно я понял, что управление проектами должно быть гибким, что цель не стоит на месте, а меняется, поскольку цель – это ментальный образ желаемого результата. Стоя не берегу, невозможно составить детальную и точную картину будущего движения (календарный план). Итерационный подход, развитие по спирали, - всегда были мне ближе, чем жесткое исполнение высосанного из пальца плана, сделанного в стиле «водопад». И вот появилась книга Дуг ДеКарло «Экстремальное управление проектами», как глоток свежего воздуха. Это придало уверенности в том, что могут быть очень разные подходы к управлению проектами, что это дело развивается. Выдержки из книги Дуг ДеКарло можно прочитать в статье «Экстремальное управление проектами: новое в управлении современными проектами».

Традиционный подход требует примерно следующего. На первом этапе мы проводим обследование, выясняем всё что можем, остальное додумываем и записываем, ставим задачу. Получаем кучу бумаг (документов), утверждаем их и обклеиваем этими «обоями» всё вокруг, включая «окна» с видом на Реальность. И вот мы уже оторвались, реальность нас не интересует, мы смотрим на бумаги, на старые «фотографии» реальности, которыми закрыто окно. Глядя на них, мы считаем, что на улице (в реальности) день и солнце. Но если сорвать эти обои со стёкол или открыть окно, то мы увидим, что Реальность изменилась, на улице уже ночь и идёт дождь, а наш план никуда не годится, как и наше представление о цели. Бессмысленно тратить патроны и палить туда, где когда-то сидела утка.

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

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

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

В управлении проектами ключевая роль отведена управлению рисками. На эту тему есть хорошая книга Тома ДеМарко и Тимоти Листера «Вальсируя с медведями». Выдержки из этой книги приведены в статье «Управление рисками».

Подчеркну мысль, о которой я кратко уже упомянул. Систему Lean/TPS можно применять не только для традиционного производства, но и для улучшения деятельности проектных организаций.

В заключении хочу спросить: а есть ли альтернатива? Мы знаем, где мы находимся и куда должны прийти. Мы видим огромный разрыв между «as is» и «to be», понимаем, что кроме непрерывного улучшения (чего? бардака!?) нужно делать более быстрые и значительные шаги, делать это организованно. Чем ещё мы можем воспользоваться кроме проектного подхода для организации работы групп? Напомню, что существует несколько школ проектного менеджмента и дело это не стоит на месте. Здесь тоже нужно делать выбор. Удачи всем в освоении проектного подхода и соединении его с философией, методами и инструментами бережливого производства.

Я готов в комментариях к статье или в ветке форума отвечать на любые вопросы и дополнения.

Cтатья или другие материалы сайта оказались для Вас полезными? Авторы сайта и все члены сообщества будут Вам очень признательны, если Вы поддержите проект в любой, доступной и удобной для Вас форме. О различных способах поддержки портала LeanZone.ru подробно рассказано в статье "Поддержать LeanZone.ru". Поддержав портал Вы будете способствовать повышению популярности ресурса и привлечению более широкого круга посетителей к решению рассматриваемых на сайте проблем.