Андрей Трегубов

После того, как будет достигнута ясность о том, что такое программы по внедрению SAP, как эффективно управлять объемами, релизами систем и как обеспечить правильную коммуникацию между теми, кто участвует в разных аспектах проекта, возникает вопрос о ресурсах - кто это может делать. И с эти связан очень интересный момент - разумная бюрократия на программах и проектах. Это в первую очередь относится к офису управления программами трансформации (PMO, Program management office).

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

Иными словами, Program management office – это некий центр, в котором ведется управление и гармонизация самыми разными процессами и проектами, связанными с внедрением SAP. Очень часто, особенно в крупных компаниях, ведется несколько проектов по внедрению SAP. По системам, которые уже внедрены, ведется операционная поддержка. Параллельно, если все идет нормально, всегда происходит benefit realization – оценка и управление полученными преимуществами, определение дальнейшего развития внедренных систем.

Все эти проекты по объему отличаются, все эти проекты относятся к различным функциональным областям, различные ресурсы нужны. Все это надо осмыслить, привести в единую систему, так как все эти процессы взаимосвязаны, организация-то одна, при всей своей сложности. Значит, нужен какой-то орган, где все это будет централизоваться и из этого центра управляться. Этим и занимается Program office.

В моей практике этот центр обычно управляет 4-мя видами деятельности:

1. Технические – базис, секьюрити, разработка, архивация – если они требуются в рамках проекта. Так как было бы неправильно эти задачи разложить по отдельным проектам и больше на них не обращать внимание.
2. Тестирование - в основном, регрессионные тесты, но и интеграционные тоже.
3. Управление интеграцией (integration management), так как проекты друг от друга зависят, вход одного – это выход другого. Есть масса видов деятельности, которую надо как-то связывать.
4. Управление изменениями (change management).

Program management office – это и есть те «бюрократы», которые придумывают все эти процессы и процедуры, а потом контролируют их выполнение. Именно PMO, по моему опыту, определял, каким будет ландшафт SAP, осуществлял оценку качества ведения проектов и определял правила, по которым проекты работают.

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

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

1. стратегия самой программы, подходы, структура, управление должны быть обсуждены и приняты до того, как мы ее начали. Если у нас спонсора проекта или программы нет – нельзя начинать проект. Если мы не согласовали все правила игры с партнерами – нельзя начинать проект. Или можно, но нужно быть готовым к серьезным сложностям.
2. высшее руководство компании, где будет проводиться программа, должно понимать, что реализация этой программы нужна бизнесу как воздух. Это тоже достаточно сложный момент, но очень важно его пройти. Должны быть наблюдательные советы из топ-менеджмента, должна быть их вовлеченность. То, что представители SAP входят в ваш наблюдательный совет, не просто желательно, это очень рекомендуется. И на самом деле очень удивительно, что этого не происходит почему-то в России. Насколько мне известно, в большинстве программ внедрений в других странах это просто обязательно требование. И, кстати, это одна из составляющих стоимости проекта.
3. понять, какая у нас юридическая и географическая структура, где, что и как мы будем внедрять. Невозможно, чтобы в середине проекта нам вдруг сказали: «Вы знаете, а мы теперь решили все переорганизовать и слить все наши юридические лица в одно». Либо это должно быть целью программы, тогда мы договариваемся, что в рамках этой программы, например, мы еще занимаемся созданием share services и делаем такой центр, например, по финансам. Понятно, что тогда, возможно, придется все объединить в одно юридическое лицо или, например, создать единую бухгалтерию. То же самое с организационной структурой.
4. Определиться с IT-инфраструктурой. У меня был пример, когда система SAP изначально была установлена на S-400 - нормальные, хорошие мэйнфреймы, DB2, все хорошо. И вдруг в середине проекта нам сказали: «А давайте-ка мы на Microsoft все переведем, на NT и на MS SQL, так нам будет дешевле». Пришлось сказать: «Давайте закончим, а потом будем думать о переводе и так далее».

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

Итак, рассмотрим первое, с чем придется работать PMO: план программы. Подчеркну: всей программы, а не отдельного проекта. Этот план создается как раз PMO, и не просто создается, а защищается и утверждается сразу после того, как мы утвердили объем нашей программы, и до того, как мы начали работать над ее реализацией. Если у нас плана нет, а мы начинаем уже что-нибудь внедрять - лучше бы мы этого не делали.

Важно, что план программы – это на самом деле не один документ, а целый набор документов.

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

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

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

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

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

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

Соответственно, как только мы создали такую программу, надо понимать, что у нас есть отдельные планы конкретных проектов. Здесь обязательно использовать стандартные шаблоны, некую методологию. Мы пользовались АСАПом (ASAP). Можно рассуждать об отличиях методологии ASAP и PMO, но главное – какая-то методология обязательно должна здесь использоваться.

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

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

Обязательно нужно использовать связи между проектами, чтобы понимать, как в целом процесс должен двигаться. Поэтому я использовал определенную вещь под названием depended c in, depended c out. То есть либо наша конкретная задача влияет на задачи других проектов, либо мы от кого-то зависим. И эти связи должны были быть установлены жестко и четко. Потому что, в конце концов, это нужно для того, чтобы избежать такого привычного ответа «это не моя проблема».

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

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

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

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

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

Кстати, самый интересный момент в управлении рисками - очень часто говорят о том, что сделать, чтобы этот риск не произошел. Но очень часто забывают продумать, что делать, если он все-таки случится? Такой план тоже должен быть. Что будет, если у нас миграция данных не состоится? Сломается что-то? Вдруг выясняется, что простые бэкапы не спланировали, и вернуться-то и некуда. Поэтому очень важно поставить контрольные точки и понять, как с точки риска откатиться до этой контрольной точки. Этот план должен быть изложен четко, как в армии: открыл конверт и побежал. Потому что в критической ситуации думать будет уже поздно, надо будет действовать.

И еще: мало «нарисовать» слайд риск в Power Point, его нужно отслеживать и быть уверенным, что либо он минимизирован, либо учтен. Должны быть инструменты управления рисками и стратегия управления ими, ответственные за эту область задач и так далее.

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

Материалы для скачивания

Андрей Трегубов. Управление ИТ программами: когда бюрократия может быть полезной (RUS)tregubov_buracracey_rus.pdf992.98 KB