Комментарии по теме

«Ведение по­льзо­ва­те­льских до­ку­ме­нтов изменений»
Николай Кронский:
Виталий, информация по генерации преподнесена верно, но вот тема использования вызовов ФМ в собственной АВАР-разработке, мне кажется, раскрыта не полностью. Внесу пару дополнений, если не...
«Ведение по­льзо­ва­те­льских до­ку­ме­нтов изменений»
Виталий Ванин:
Спасибо, Николай! Очень полезная информация.
«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2012-2013) Все мероприятия

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

Предыдущая Следующая

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

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

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

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

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

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

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

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

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

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

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

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

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

Каким должен быть подход к коммуникациям? Я предлагаю 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 в основном отвечает за создание процедур, шаблонов, за общее руководство процессом. Если мы дадим ему управлять конкретными проектами, конкретными организационными изменениями, ничего хорошего не выйдет.
  2. На этом уровне мы видим функциональных людей, людей из бизнеса, тех, которые принимают решения. Например, это решение о том, как в рамках организации будут происходить изменения, вот они за это отвечают, и за внедрение тоже – это очень важный момент.
  3. Целый пласт разных ролей - у руководства проекта, у конкретных проектных команд. За всем за этим стоят в каждой программе свои шаблоны, свои процедуры, свои средства. Реально довольно большая вещь.

Кстати, не в качестве рекламы, а в качестве факта – я очень рекомендую для организации этой работы решение SAP GRC, оно реально помогает на всех этапах – от access control до process control. Внедрение SAP GRC в ходе проекта – если оно выполнено правильно – существенно облегчает эту задачу, по крайней мере, технически.

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

Обучение: чему, кого, когда и когда

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

  • Провести site assessment: где и как мы можем учить людей. Есть ли класс для обучения, есть ли в нем проекторы и другое нужно оборудование. Если это обучение компьютерное – надо организовать компьютер с доступом к сети, закачать туда курсы и так далее. Надо убедиться, что все, что нужно для обучения, имеется, или каким-то образом получить (купить, установить, переместить) недостающее.
  • Определить, сколько людей потребуется обучить, и распределить их по группам.
  • Разработать документацию на обучение - собственно, чему учить.
  • Организовать логистику: если мы внедряем SAP, мы учим SAPу, нам нужна тренинговая система, которую надо развернуть, в этой системе должны некие данные, приближенные к боевым. Обычно мы учим до того, как мы запустили SAP, поэтому возникает вопрос: откуда эти данные взять, и какие там сценарии должны быть?

«Обучи тренера, обучи учителя»

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

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

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

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

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

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

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

И самое последнее, но самое важное – это собственно обучение пользователя. Нужно выбрать метод обучения – практическая сессия в классе или лекция, удаленное обучение или очное. У SAP есть очень хорошие средства для e-learning, которым можно воспользоваться. В моей практике всегда оценка делалась на конкретном проекте, но при этом program office разрабатывал правила, процедуры, шаблоны и прочее-прочее.

Как определить формат обучения для конечных пользователей? Когда использовать курсы, удаленное обучение, а когда – очный тренинг с лектором? Есть несколько случаев, когда с лектором обучение более эффективно:

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

Конкретный пример: внедряли мы SAP, и в процессе внедрения нужно было создать share services-центры в области финансов, IT, HR – то есть появлялись абсолютно новые роли. До этого бухгалтерский учет везде делался по-своему, а тут объединили подразделения по всему миру в три крупных кластера, соответственно – каждый из трех центров работает с этим большим региональным кластером. Людей из разных стран нужно было собрать лицом к лицу, объяснить, почему будет теперь работа строиться по-другому, отвечать на вопросы, помогать освоиться с новыми задачами. А если у нас небольшие изменения, если нужно просто показать, как по-новому функциональность в системе организована – это можно делать с помощью удаленных курсов и самостоятельного обучения на компьютере.

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

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

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

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

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

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

Энтузиазм или мотивация?

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

Тут есть разные способы, с разной эффективностью и применимостью к конкретным компаниям. Есть примеры, когда таким пользователям назначали прибавку к зарплате. Можно, например, скорректировать их рабочие планы – официально выделить в них определенный объем времени, например, 10-15%, именно на эту задачу, соответственно скорректировать нагрузку по другим задачам. Можно также учитывать этот показатель – участие в проекте, участие в обучении пользователей – при оценке карьерного роста, планировании развития такого специалиста. Безусловно нужно говорить о том, что такой-то специалист участвует в обучении, показывать его как эксперта, опытного и авторитетного коллегу. Это тоже важная мотивационная составляющая.
Чтобы это заработало, над этим надо тоже работать, и это можно учитывать при планировании коммуникаций – что эта тема должна быть тоже там затронута. Нужно знать своих героев.

В заключение приведу пример из проекта по внедрению SAP, где мы за четыре года внедрили его полностью в 46 странах – только внедрений CRM не было. Спонсором проекта был второй человек в компании - старший вице-президент, который еженедельно участвовал в совещаниях по проекту и входил в каждую деталь. И однажды, когда была кризисная ситуация с венгерским представительством, что-то там пробуксовывало, венгры считали, что система для них не подходит и не учитывает их специфику, поэтому относились к внедрению достаточно прохладно, даже ресурсов на этот проект не выделяли в достаточной степени. Мы с моим старшим коллегой, после многочисленных попыток ситуацию выровнять, пришли к этому старшему вице-президенту и изложили ему проблему. И он принял очень простое и эффективное решение. Мы прилетели в офис в Венгрии, было лето, прекрасная погода, и вице-президент распорядился, чтобы все сотрудники собрались во дворе офиса. И произнес очень короткую речь: «Так, ребята, у нас 1 октября запуск системы, если вы запускаетесь вместе с компанией – все хорошо. Нет – мы закрываем офис и все операции переводим в Прагу». На следующий день мне позвонили несколько десятков человек с вопросом: «А что нам надо делать?». Пожалуй, это хороший, хотя и несколько эмоциональный, пример того, как важна роль спонсора проекта. Но и руководитель проекта, руководитель программы должен понимать, что в его распоряжении есть разные ресурсы – и уметь использовать для успеха проекта все.

Об авторе

Андрей Трегубов – занимает должность директора подразделения Globalization Services в SAP Lab CIS. Обладает опытом работы в сфере системного анализа и вычислений, занимал высокие руководящие и исследовательские посты в сфере ИТ, имеет уникальный практический опыт. С 1998 года занимается сложными внедрениями ERP-систем и решениями для управления логистическими цепочками. Андрей имеет богатый опыт в области управления программами и проектами в больших международных компаниях.

Опыт работы

Андрей внес большой вклад в развитие информационных технологий на территории бывшего СССР, управлял ERP-проектами в крупных международных компаниях AT&T, Technip, PepsiCo, Procter & Gamble, CdF, Gillette, BBH Brewing Holding, KONE и NOKIA.

Более 14 лет руководил внедрением проектов SAP в глобальном офисе JT International. Обладает богатым опытом внутрикорпоративного управления, планирования поставок и потребностей, а также в проектировании бизнес-процессов.