Анна Леммниц

Управление программами ИТ-трансформации можно разделить на три большие группы задач: управление масштабом, управление качеством, управление релизами. Пожалуй, самое важное для успеха программы – четко определить ее масштаб. Пример стратегической программы – перевод ERP-системы на платформу SAP HANA. Проект такого масштаба, безусловно, повлияет на другие проекты, которые в компании ведутся или уже запл анированы: придется перераспределять ресурсы.

В момент приобретения компании SYRUS в 2010 году я занималась управлением слияниями и поглощениями. Я знала, что одним из последствий этих перемен будет, например, то, что одного из моих системных архитекторов переведут на программу по внедрению SAP, как более важную для компании. Тем не менее, этот человек был мне нужен, без него я не могла завершить свою программу. Также требовалось объявить представителям бизнеса, участвовавшим в других программах, что эти начинания не будут реализованы, то есть, по сути, что я не выполню обещания, которые ранее давала. Но как об этом сказать?

Получить согласие стейкхолдеров – это ключ к успеху программы проекта. Когда мы начали программу по внедрению Sybase, у нас было много стейкхолдеров: наш исполнительный совет и бывший генеральный директор Sybase. Генеральный директор Sybase сказал, что он хочет подписать каждый план. А представители исполнительного комитета заявили: проект должен быть реализован в июле 2012 года (мы начали его в 2011 году), вот бюджет, все остальное нас не интересует. А бывший генеральный директор Sybase потребовал то, что считал нужным для успеха своей работы, невзирая на бюджет и сроки.

Иногда инициатива изменений идет сверху – практически, это приказ, и невозможно на него ответить отказом. Но можно сказать по-другому: например, что эта задача может потребовать дополнительных бюджетных средств. Если это стратегически важный проект, как перевод ERP на HANA, вы получите эти средства. Главное, сделайте все вовремя.

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

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

Много зависит от того, какое внедрение планируется. Например, интеграция Sybase изначально шла по методологии Agile, и спустя 4 месяца мы поняли, что это неправильно. Но таково было изначальное требование. Мы решили изменить принцип проведения этой программы. Да, мы потратили время и определенные усилия, возможно, напрасно, но в конечном итоге приняли правильное решение: изменить курс.

Как определяется масштаб?

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

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

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

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

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

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

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

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

Отношение к изменениям и мотивация

Как правило, новая программа полностью меняет привычный уклад работы. В этом случае люди начинают испытывать страх неопределенности. Когда вы обсуждаете с ними ожидания, пытайтесь «заглянуть за зеркало»: возможно, вам будут говорить, что готовы вас поддерживать. Но, как мы говорим в Германии, «за зеркалом», то есть за кулисами, может быть противодействие и непонимание. Попытайтесь в этом разобраться, увидеть эти сомнения и показать людям новые возможности изменить и развить себя.

Определение архитектуры решения

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

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

Управление коммуникациями в процессе изменений

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