Как мы реализовали бизнес-критичную ИТ-трансформацию после 24.02.2022 без внутреннего проектного офиса

В сентябре 2022 года к нам обратился клиент – международная логистическая компания по грузоперевозкам и хранению в сегменте HoReCa.

Проблема: европейский головной офис отзывает действие лицензий на иностранные ПО, и у клиента есть только год, чтобы реализовать программу ИТ-трансформации. 

Компания «РУЛОГ» — эксперт в области управления цепями поставок для ведущих российских и международных брендов в сфере быстрого питания. Масштаб организации — 16 распределительных центров по всей России: от Калининграда до Владивостока. Ранее компания собственными силами ИТ-проекты не реализовывала – это делалось с помощью сервисов головного офиса. 

Цель ИТ-трансформации — за 18 месяцев внедрить восемь ключевых и несколько вспомогательных систем на базе отечественного ПО, включая ERP, TMS, WMS, Партнерский портал, Систему управленческой отчетности и т.д.

Проектный офис на аутсорсе вместо консалтинга

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

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

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

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

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

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

Так, вместо обычного консалтинга, мы взяли на себя функцию проектного офиса на аутсорсе, чтобы реализовать программу ИТ-трансформации в «РУЛОГ». 

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

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

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

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

Чтобы снизить градус, мы подстраивались под их напряженный график – иногда встречи могли быть в 7 утра, а иногда поздно вечером. Руководитель программы здесь также нам помогал: он не только давал направления, генерировал идеи и приоритизировал задачи, но и, что немаловажно, доносил ценность того, что мы делаем, до сотрудников компании. 

Что конкретно мы делали на этом этапе?

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

Программа трансформации включала в себя:

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

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

Нашими ключевыми целями на этом этапе были: 

• снижение рисков позднего выявления проблем;
• координация и синхронизация проектов, управление зависимостями;
• обеспечение прозрачной коммуникации внутри программы;
• и отслеживание «узких мест» на стыке проектов программы.

«Также был проведен аудит проектных совещаний, после чего проектным офисом были разработаны рекомендации по их организации, включая повестки, состав участников, правила приглашения и состав рассматриваемых документов. Благодаря этому мы пришли из состояния “никто ни с кем не разговаривает” к “регулярно общаемся и есть предмет разговора”. Это настроило команды на совместную работу, руководители проектов стали самостоятельно инициировать коммуникации.»

Александр Писаренко, руководитель программы, ИТ-директор «РУЛОГ»

Главные сложности, с которыми мы столкнулись

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

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

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

Ниже разберем это подробнее.

Непрозрачная отчетность

Сложность заключалась в том, что контрольные точки (далее — КТ) проекта были сформулированы в терминах активности, а не конкретного результата (например, “тестирование” вместо “завершено тестирование”) или слишком абстрактно (“изучение ИТ-ландшафта”). К тому же они распределялись неравномерно по времени: за две недели между статус-встречами могло не произойти ни одного события (КТ результата) или на следующий месяц в плане не было указано ни одного события. 

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

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

Что мы сделали

• Привели названия проектов к единому виду во всех проектных документах. В статус-отчетах, сводном отчете и дорожной карте проекты назывались по-разному и поэтому трудно было соотнести КТ статус-отчета с КТ дорожной карты. 
• Изменили форму статус-отчета, чтобы можно было отследить, меняется ли прогнозный срок завершения проекта, на каком этапе находится проект, и все ли с ним хорошо, а если по проекту возникли риски, проблемы или отклонения, то с чем они связаны. Ранее в отчете наличие проблем или рисков не было наглядным, поэтому мы добавили “светофор”, отображающий уровень рисков всего проекта. 
• Переформулировали контрольные точки (в том числе с учетом зависимостей, но об этом ниже) и удалили абстрактные или непроверяемые точки, например, не “Тестирование”, а “Начать тестирование” или “Закончить тестирование”.
• Выделили ключевые контрольные точки и зафиксировали их плановые даты. 
• Определили правила простановки светофоров в случае отклонений по срокам. Для ключевых контрольных точек не допускалось отклонение даже в 1 день (сразу зажигался красный светофор), а для других возможны были отклонения до 1 недели, и только тогда точка становилась “красной”.
• Интегрировали контрольные точки в календарные планы проектов, чтобы отчеты показывали реальную картину происходящего, а на рабочих встречах обсуждались зафиксированные в отчетах результаты. 

Как мы внедрили новую статус-отчетность?

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

Первая итерация заполнения отчетов показала слабые места этого процесса:

• Искаженное форматирование. Первоначально мы создали шаблон в Excel, где настроили автоматический расчет дельты и цветовое кодирование для пройденных и непройденных контрольных точек, отклонений, допусков, а также для отображения неверно заполненных строк (например, прогнозная дата КТ в прошлом, но КТ обозначена как непройденная). Однако, форматирование все время сбивалось. Оказалось, что в компании пользуются опен-сорс приложением для работы с таблицами. И при открытии нашего шаблона часть форматирования терялась. Для решения этой проблемы мы установили себе это же приложение и настроили форматирование в нем.

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

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

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

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

Автономность каждого проекта

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

Нечеткая фиксация зависимостей проявлялась в том, что: 

• какие-то зависимости не были учтены: объем работ, оценка ресурсов и сроков могли оказаться неверными;
• те зависимости, которые были учтены, не были согласованы по срокам в разных проектах, и из формулировок контрольных точек не всегда можно было понять, какие сроки одного проекта влияют на другой;
• задачи, находящиеся на стыке двух или более проектов, терялись, не попадая в зону ответственности ни одного из проектов.

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

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

Однако даты изначально были разные во всех проектах:

• ERP: 23.06.23
• Система управления складом: 01.06.23
• Система управления транспортом и шина данных – даты отсутствовали. 

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

Что мы сделали: для отслеживания зависимостей проектов друг от друга мы создали реестр зависимостей. 

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

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

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

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

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

Что еще мы сделали

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

На сессиях мы декомпозировали результаты проектов, выделяли конечные и промежуточные результаты: например, “утвержден проект” или “подготовлен отчет об анализе” — это промежуточные результаты, а “выбрано решение” или “ПО настроено” — это конечные результаты. 

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

«Еще одна проблема, с которой нам помогли справиться консультанты – перегрузка сотрудников, участвующих в нескольких проектах, которая приводила в том числе к их негативной реакции на программу и рискам срыва сроков. После того как проектный офис проанализировал потребность в ресурсах и их загрузку, стал виден дефицит конкретных специалистов, что позволило директору по HR разработать мероприятия по его профилактике. Люди поняли, что компания готова инвестировать в ресурсы, а у нас появился работающий механизм решения проблем с их дефицитом. В итоге мы смогли сформировать полноценные команды внедрения проектов, включив туда пользователей ИТ-систем (складских работников), а участники проектов оптимизировали свою загрузку и получили необходимую поддержку со стороны  HR.»

Александр Писаренко, руководитель программы, ИТ-директор «РУЛОГ»

Что в итоге

После внедрения изменений мы мониторили, как они “усваиваются” компанией. Когда возникали проблемы по заполнению каких-либо форм, мы снова встречались с РП и выясняли причины. 

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

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

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