Что делать, когда все корпоративные ИТ-системы, поддерживающие ежедневные операционные процессы, «полетели в трубу»? Как управлять такой масштабной программой восстановления всего ИТ-ландшафта, когда даже один день просрочки приводит к миллионным потерям?

Управлять по обычным правилам – не вариант. Важны высокая скорость работы и быстрое принятие решений. Никакого традиционного паспорта проекта, никакого талмуда с требованиями, реестра рисков, концепции, ТЭО и прочего. Максимальная упрощенка. Однако при такой скорости и упрощенном управлении… возникает большой риск что-то недосмотреть, упустить, что в итоге приведет к еще большим финансовым потерям.

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

Ситуация: кризисная

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

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

Необходимо было восстановить все системы в кратчайшие сроки.

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

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

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

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

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

С чего мы начали: перевод систем в проекты и жесткая приоритизация

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

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

Всего оказалось около 70 систем. Были как небольшие, так и крупные системы – например, ERP, восстановление которой могло занять много месяцев.

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

В общем, мы превратили объем работ по восстановлению всех 70 систем в проекты, а также приоритизировали их по классу критичности, выстроив более эффективное управление ресурсами в условиях острого дефицита – чтобы специалисты «не размазывались тонким слоем» по всем проектам, а фокусировались на наиболее приоритетных. Например, проект по восстановлению важной части ERP-системы, формирующей финансовую отчетность, стал одним из приоритетов №1, так как иначе компания могла попасть на огромные штрафы из-за сложностей предоставления отчетности перед регулятором.

В итоге получилось 200 проектов с разными приоритетами:

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

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

3. проект дальнейшего развития.

Как мы управляли таким объемным портфелем проектов, читайте ниже.

Единый реестр всех проектов для управления всей программой

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

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

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

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

Однако несмотря на то, что в реестре были все данные по каждому проекту, этого было недостаточно для прозрачного управления. В частности, на одной из встреч с заказчиком, изучая статусы каждого проекта в реестре, у нас возник вопрос – а на основании чего проставляется статус «Готово»? 

Оказалось, что статус проставлялся руководителем проекта со слов заказчика. Мы понимали, что делать это без каких-либо минимальных подтверждений… большая зона риска. Например, заказчик может принять работу и согласовать все устно, но через какое-то время он добавит новые требования и ситуация поменяется, а статус «Готово» перестанет быть актуальным. И это могло привести к неуправляемому разрастанию сроков. Так что, мы решили внедрить в реестр еще один инструмент – критерии успеха для каждого проекта. Что это такое и как он помогает управлять объемом требований, а также ожиданиями заказчиков, рассказываю ниже. 

Критерии успеха для управления объемом требований и ожиданиями заказчиков

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

Все эти критерии фиксировались также в едином реестре. И только после того, как все критерии со статусом «Согласовано» были выполнены (что также отмечалось в реестре), статус проекта переходил в «Готово». Как это выглядело на практике:

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

• каждую неделю руководитель встречается с заказчиком, чтобы определить, какие критерии уже выполнены (при этом они постоянно сверяются и проверяют, что уже выполнено, а что нет);

• раз в две недели руководитель вместе с заказчиком приходят на управляющий комитет и показывают результаты куратору, чтобы посмотреть динамику проекта и, если что-то идет не так, найти решение проблемы. Когда все критерии выполнены и проект считается завершенным, то в реестре проставляются статусы критериев успеха и меняется общий статус проекта на «Готово».

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

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

Однако на более масштабных проектах это не работало – например, по восстановлению ERP-системы или переходе на новую, которые могли длиться очень долго. Здесь получалось так, что достичь одного результата (критерия успеха) можно было бы только через пару месяцев. А значит, на управляющих комитетах раз в 2 недели, по сути, показывать и обсуждать нечего. Кроме этого, большинство проектов делалось подрядчиками, и оказалось, что в их бэклоге указано только 80% работ, так как остальные работы выполнялись сотрудниками заказчика. То есть, эти 20% нигде не были прописаны.

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

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

Что в итоге

За 3 месяца мы выстроили эффективное антикризисное управление масштабнойпрограммой восстановления всех ключевых утерянных ИТ-систем. А именно:

• превратили объем работ по восстановлению всех 70 систем в проекты и жестко приоритизировали их по классу критичности, внедрив управление ресурсами

• разработали многофункциональный реестр всех проектов с критериями успеха для каждого

• наладили регулярную коммуникацию для всех участников проектов

• настроили новый ИТ-инструмент и адаптировали под него разработанные нами дорожные карты для длительных проектов

Это, конечно, ДАЛЕКО НЕ ВСЕ, что мы сделали, но ЭТО – основные инструменты, которые сработали и помогли за 3 месяца запустить MVP ключевых систем с минимальными потерями для бизнеса. После этого мы продолжили помогать с проектами восстановления и запуском новых систем, но об этом я напишу уже в другой статье.

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