Любая программа внедрения SAP связана с большими изменениями в области оргструктуры, проектных команд, документооборота и многих других аспектах. Я участвовал во внедрении SAP в 72 странах, и из них в 46 странах это были внедрения полного цикла, связанное с трансформацией всех ключевых бизнес-процессов. Поэтому, на мой взгляд, необходимо говорить о подходе не к бизнес-процессам, а к изменениям в организации в целом – то есть о том, что и входит в понятие «управление изменениями» («change management»). Почему стоит говорить об этом в таком глобальном аспекте?
Во-первых, основная тема сегодня – это трансформация бизнеса, а управление изменениями – это как раз та ситуация, когда необходимо погрузиться именно в специфику бизнеса, понять, на чем основаны его требования.
Во-вторых, именно с этого нужно начинать любую программу. Вообще говоря, завершения у этого процесса нет: программа закончилась, началась новая, начинались Benefits realization, и так постоянно, шаг за шагом.
В-третьих, статистика говорит, что от 70 до 75% неудачных проектов, связанных с внедрением SAP, связаны с тем, что вышеперечисленные вопросы 1 и 2 игнорируются.

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

Итак: каким образом должна быть построена программа по внедрению SAP? Прежде всего, каждой программы должен быть Устав (Charter), и у процесса управления изменениями такой устав должен быть – должны быть определенные зафиксированные правила, по которым изменения будут происходить. Можно дискутировать, что туда входит, а что нет, но точно там должно быть зафиксировано разделение ответственности, особенно в рамках самой программы, и состав команды управления изменениями (Change Management Team): как взаимодействуют бизнес, команда управления изменениями, какие проекты в рамках программы трансформации идут. И, конечно, должны быть зафиксированы требуемые и используемые ресурсы – иначе ничего работать не будет.

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

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

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

1. определить цели и результаты нашей коммуникации: чего мы хотим добиться и как это получим;
2. определиться с подходом к коммуникациям, с основными принципами;
3. работать коммуникационный план: кому, что, как и когда мы должны сообщать, кто наши основные заинтересованные лица, какие мы будем сообщения им генерировать, отправлять, по каким каналам и как часто.
4. зафиксировать документально и приступить к реализации, потому что это не должно остаться только в планах на бумаге.

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

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

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

Каким должен быть подход к коммуникациям? Я предлагаю 3 простых правила:
1. Подход к коммуникациям определяется той командой, которая управляет изменениями на уровне организации. Она определяет все политики и правила, и это находится под контролем того, кто отвечает за внедрение SAP в целом.
2. Поскольку в нашей программе всегда много разных проектов (в моей практике максимальное их количество в рамках одной программы составило 23), централизованно поддерживать разные по функциональности и географической локализации проекты очень сложно. Поэтому общие правила, подходы, шаблоны и другие инструменты коммуникаций должны быть переданы на уровень каждого проекта: коммуникация должна поддерживаться и руководством проекта, и соответствующими людьми, но при она идет в рамках централизованной стратегии.
3. Коммуникация должна сразу базироваться на уже имеющейся коммуникационной сети. Невозможно начинать программу или внедрять SAP, а параллельно с этим думать, как в организации работает e-mail, нужно ли создавать специальные журналы, бюллетени и прочее. Отталкиваться нужно от того, что в организации уже есть и работает.

Коммуникационный план: как создать и как использовать

В плане должны быть отражены 4 основных момента:

1. Ключевые заинтересованные лица и группы лиц, с конкретным указанием – имена, адреса электронной почты, местонахождение.
2. Инструменты коммуникации: будь то электронная рассылка или постеры в коридорах, они должны быть прописаны в плане.
3. Ключевые сообщения для разных коммуникационных групп и разных носителей информации: от просто устного общения, совещаний до корпоративных СМИ и информационных рассылок.
4. Календарь мероприятий по коммуникации: что, где и когда публикуется.

Что мы получаем в результате создания коммуникационного плана? Механизм обмена информацией. Он должен быть двухсторонний, всегда должна быть обратная связь. И так как у нас определенная программа - он должен быть иерархический. Если у нас есть офис управления програмой (Program Management Office), в рамках которого работает программа управления изменениями, ее требования накладываются на определенные проекты, а у каждого проекта есть определенные заинтересованные лица. Соответственно, вот этот механизм сверху вниз, снизу вверх должен быть сформулирован, и его разработкой и поддержкой надо заниматься. За всем этим стоят конкретные шаблоны, конкретные процедуры, конкретные процессы, конкретные средства.

Управление организационными изменениями

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

1. Оценить, как повлияет то, что мы собираемся делать, на существующие процессы (при этом мы помним, что это трансформация бизнеса, а не просто изменения в IT, то оцениваем именно влияние на бизнес-процесс), следовательно - на существующие роли, должностные инструкции и так далее.
2. Определить, какие изменения нужно внести в существующие конкретные роли: от описания их в должностных инструкциях до реальных изменений в работе конкретных людей. Если речь идет об уже существующей системе SAP у нас уже работает, с уже сформированными ролями пользователей, необходимо проверить – потребуется ли менять авторизацию, привязку транзакций, оргструктуру, пути прохождения данных, и как это скажется на работе конкретных людей – ведь именно они взаимодействуют с системой. Вот тут самый тонкий момент: проводя трансформацию бизнеса в целом, мы меняем бизнес-процессы, а следовательно – и требования к людям, и оргструктуру, и это самый болезненный вопрос. Надо понять, для чего мы это сделаем. Тут нужен Impact Assessment - оценка влияния наших процессов, чтобы понять, как каждый проект в рамках программы влияет на бизнес, на организацию и в конечном счете - на людей. Как это делается? Берутся существующие процессы и проводится анализ - как они работают. Обычно это либо Blue-Print, либо Fit-Gap, но не позже.
3. Когда роли в системе соотнесены с конкретными должностями, мы понимаем, кого и чему нужно обучать. Отсюда вытекает понимание того, как это повлияет на организационную структуру и на изменения внутри организации. Эту работу невозможно сделать без участия экспертов от бизнеса, причем именно тех людей, которые принимают решения. В конце концов, им надо будет принимать и жесткие решения: какие-то должности сокращать, какие-то - менять, что-то консолидировать, расконсолидировать и так далее. Есть руководитель проекта, который эту работу ведет, есть программа, которая шаблоны предоставляет, но если бизнес в этом не участвует, то с вероятностью 99,999% что-то будет не так. Когда мы перейдем к реальной работе в системе, кто-то не сможет какую-то кнопку нажать, кто-то будет кричать, что «я так работать не буду никогда, только через мой труп!», и, в общем, получится изсестное «хотели как лучше, а получилось как всегда». Без участия бизнеса в процессе внедрения никогда ничего хорошего не получалось.

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

Суммируя, можно представить себе 4 уровня в рамках нашей программы:

1. Program Office – те, кто знает, как это все технически организовать,
2. Руководство проектов
3. Команды внутри проектов, которые отвечают за функциональные конкретные области, бизнес-области
4. Бизнес-пользователи.

В этой структуре очень важно разграничить, кто за что отвечает.

1. Program management office в основном отвечает за создание процедур, шаблонов, за общее руководство процессом. Если мы дадим ему управлять конкретными проектами, конкретными организационными изменениями,

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

Андрей Трегубов. Управление изменениями: ИТ программы как рычаг развития бизнеса (RUS)CEP_Change.pdf814.87 KB