Несколько лет назад к нам обратился клиент (крупнейшая логистическая компания в России) с проблемой – европейский головной офис отзывает все лицензии действующих ПО, и у клиента есть только год, чтобы импортозаместить 8 ключевых ИТ-систем и несколько дополнительных.

При этом проектного офиса в компании нет – ранее все ИТ-проекты делались силами головного офиса. А на то, чтобы создать проектный офис с нуля, времени уже нет. При этом, если не успеть до момента, когда все лицензии прекратят действовать… это приведет к остановке работы в 14 распределительных центрах России компании и ущербу в десятки миллионов рублей. Большинство подрядчиков, к которым клиент обратился до нас, отказались ввязываться в эту историю – потому что даже для внедрения одной ERP-системы требовалось месяцев 16. А тут, кроме ERP, еще 7, и времени всего год.

Так как у нас большой опыт в вытаскивании масштабных программ из кризиса, мы согласились. И сразу приступили к работе – в качестве проектного офиса на аутсорсе. Что конкретно мы сделали и как нам удалось помочь компании предотвратить многомиллионные потери, рассказываю в этом кейсе.

Начало работы и полное погружение

Программа трансформации включала 8 ключевых систем: система ERP, система управления складом WMS, система управления транспортными средствами TMS (включая систему учёта топлива и ТО, а также систему по оптимизации маршрутов), система управления воротами (синхронизация складов с грузовиками), клиентский портал B2B, шина данных, система регулярной отчетности и хранилище данных.

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

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

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

А именно: проблемы с отчетностью и автономной реализацией каждого проекта. Нашей целью стало устранить эти проблемы как можно скорее. 

Проблема с отчетностью

Главная проблема здесь заключалось в том, что контрольные точки во всей отчетности по проектам были сформулированы некорректно, а потому не давали объективного представления, что происходит. А именно: практически все из них были описаны в терминах активности, а не конкретного результата или слишком абстрактно (например, «Тестирование» вместо «Завершено тестирование»).

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

Это приводило к тому, что во время статус-встреч по программе руководители проектов не опирались на ясный статус в отчете, а просто своими словами рассказывали о том, что на их взгляд сейчас важно. Однако полноценной картины о том, что происходит в проектах, все же не было, потому что:

  • было неочевидно, какие результаты из запланированных достигнуты, а какие нет, и когда они будут достигнуты; 

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

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

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

2) Изменили форму статус-отчета, чтобы можно было отследить, меняется ли прогнозный срок завершения проекта, на каком этапе он находится и все ли с ним хорошо, а если по проекту возникли риски, проблемы или отклонения, то с чем они связаны. Ранее в отчете наличие проблем или рисков не было наглядным, поэтому мы добавили «светофор», отображающий уровень риска всего проекта с четким объяснением причины его возникновения. 

3) Переформулировали контрольные точки (в том числе с учетом зависимостей, но об этом ниже) и удалили абстрактные или непроверяемые точки, например, не «Тестирование», а «Начать тестирование» или «Закончить тестирование».

4) Выделили ключевые контрольные точки и зафиксировали их плановые даты. 

5) Определили правила простановки светофоров в случае отклонений по срокам. Для ключевых контрольных точек не допускалось отклонение даже в 1 день (сразу зажигался красный светофор), а для других возможны были отклонения до 1 недели, и только тогда точка становилась «красной».

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

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

Кроме этого, чтобы обсуждение было максимально сфокусировано на проблемах и методах их решения, мы предложили модерировать статус-встречи, так как уже хорошо представляли программу целиком, были нейтральной стороной и наша команда обладала навыками управления временем встреч. 

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

Проблема с автономностью проектов

Как я уже писал выше, в процессе погружения во все проекты мы также выяснили, что каждый проект велся независимо и взаимосвязи практически не учитывались. Главным образом, это происходило из-за того, что руководители не общались друг с другом регулярно, а потому планы разных проектов не согласовывались между собой. В общем, каждый проект велся отдельно и – где-то самим руководителем, а где-то и вовсе подрядчиком. 

Неучет зависимостей проектов друг от друга приводил к тому, что было невозможно отследить, как изменения в одном проекте влияли на другие. И это, конечно, тоже порождало огромные риски, что программа не будет реализована в нужные сроки. 

Например, у проектов системы управления транспортом, системы управления складом, ERP-системы и шины данных была ключевая зависимость – единовременное проведение UAT (User Acceptance Test). Однако из-за несогласованности планов даты были разные во всех проектах:

  • ERP: 23.06.23

  • Система управления складом: 01.06.23

  • Система управления транспортом и шина данных – даты вовсе отсутствовали

Из-за такого расхождения на три недели все сроки задач, запланированных после 1 июня  (в проекте системы управления складом), автоматически становились нереалистичными, так пройти UAT вовремя без участия других проектов было невозможно. 

Чтобы решить эту проблему, сначала мы предложили создать единый реестр зависимостей.

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

Однако каждый раз, когда мы собирали статус-отчеты, приходилось в ручном режиме выгружать оттуда все нужные нам КТ в реестр зависимостей, проверять изменения даты и в случае расхождений обсуждать с руководителем и синхронизировать их снова. Это отнимало очень много времени, и нам даже пришлось поставить отдельную встречу для обсуждения зависимостей длительностью полтора часа. 

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

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

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

Что в итоге

Решение проблем с отчетностью и зависимостями – стало фундаментом для создания единого представления, что реально происходит в программе и какие есть отклонения. А это, в свою очередь, помогло руководителю программы быстро принимать нужные решения, заранее предотвращать проблемы и успеть реализовать трансформацию в срок, продиктованный европейским головным офисом. 

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

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

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

Наш главный результат как проектного офиса на аутсорсе это то, что компания успела реализовать важнейшую часть ИТ-трансформации всего за 9 месяцев. А именно: запустила 8 ключевых ИТ-систем на пилотном складском комплексе и тиражировала их на остальные склады в нужный срок.

И все это без ущерба для текущего бизнеса. При этом в отсутствии внутреннего проектного офиса и профессиональных руководителей проектов (в основном руководителями проектов были или эксперты в ИТ, или руководители подразделений в бизнесе). 

Коллеги, больше интересных кейсов и статей читайте в моем телеграм канале Андрей Малахов | От проектов к масштабу. Также делюсь там проверенными инструментами и подходами к разработке методологий и систем управления проектами и изменениями.