Академия передовых практик внедрения  и поддержки SAP

23-24 мая 2013 года

Бизнес-Школа «Сколково»

Докладчик: Ольга Костерина, JTI

Управление изменениями в работе пользователей

История и рамки проектов

В нашей компании серия проектов по бизнес-трансформации и внедрению решений SAP идет c 2000 года. До этого у каждого филиала была собственная система управления, своя структура, свое программное обеспечение. Было принято решение о полной интеграции: создании единого управленческого приложения, которое будет охватывать все области бизнеса, и реализации единой модели управления во всех областях – ее назвали Global Reference Model. Эта модель была разработана в 2001 году.

В 2002 году начался пилотный проект по внедрению – в качестве пилотного рынка была выбрана Турция, где у JTI есть не только клиенты, но и собственное производство. Затем тремя «волнами» SAP внедрили по всем 22 странам, где в то время работала компания.

SAP был реализован как main instance: у нас полностью интегрированы все модули: производство, финансы, закупки, продажи, все работает как единый модуль. Соответственно, поменялась вся модель жизни JTI. Во-первых, все финансовые службы были консолидированы в три основных сервис-центра для поддержки бизнес-процессов: в Петербурге, в Манчестере и Куала-Лумпуре. Это была очень серьезная бизнес-трансформация, она завершилась в 2004 году.

После этого руководство приняло решение в течение года сформировать центры компетенций, всю новую структуру IT, новую структуру поддержки и работы в системе. А в 2006 году начался большой проект по внедрению HR-модуля SAP. Он длился почти два года.

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

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

С 2009 года в единой системе работают все предприятия – в том числе и те, которые раньше принадлежали Gallaher. Кроме того, мы приобрели еще несколько табачных бизнесов. До этого компания JTI занималась только закупкой табака, обработкой табака и производством сигарет. Теперь мы еще и сами выращиваем табак, то есть освоили абсолютно новый для нас бизнес. Как раз сейчас у нас идет проект, который называется Global Live Implementation: мы внедряем SAP на тех рынках, где растят табак, то есть на наших новых рынках.

Какова наша структура, какое место в ней занимает IT и в чем состоит роль CIO? У нас есть шесть регионов, которые производят и продают табак и сигареты. Также у нас есть поддерживающие их глобальные функции. Они находятся не только в нашей штаб-квартире, это виртуальные организации по поддержке функций, которые касаются всех регионов, а не только какого-то одного или нескольких. Одной из таких глобальных функций является IT. Наш CIO находится в Женеве, но наши центры компетенции распределены по всему миру. Люди из одного центра компетенции могут работать в абсолютно разных местах: в Манчестере, в Женеве, в Канаде, в Куала-Лумпур, в Азии и в России. В Санкт-Петербурге у нас очень серьезный центр компетенции, и в Москве несколько человек тоже есть. Мои функции входят в состав Global ITИз чего состоит Global IT: центр компетенции, центр глобальных разработок (Global Development Center), Global Development Center, первая линия поддержки пользователей (helpdesk) и технический центр (Global Technical Center) – это все, что касается поддерживающей инфраструктуры (компьютеры, сети и так далее).

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

По структуре: в ведении CIO находятся четыре больших блока, каждым из которых руководит глобальный вице-президент. Управление изменениями и обучение находятся в ведении глобального вице-президента центра разработок. Так исторически сложилось, что функция управления изменениями принадлежит Global Development Center. Этому же вице-президенту подчиняется SAP PMO, program office. То есть управление изменениями не является частью проектного офиса программ трансформации, но мы работаем вместе, внутри, скажем так, одного отдела. В IT у нас работает семьсот человек по всему миру. Мы практически ничего не аутсорсим, за исключением бизнес-консультантов для проектов. То есть внутри компании есть функция, которая определяет методологию, говорит, как это должно быть сделано – и есть человек (или команда), который отвечает за выполнение этой функции.

Управление изменениями

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

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

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

Что касается проектов JTI: у нас идет примерно 24 проекта в год одновременно. Это не маленькие изменения: здесь и техническое управление изменениями (change management process), когда пользователь говорит, что надо что-то поменять, новый отчет добавить – это достаточно стандартный процесс. Есть определенный набор параметров, по которым мы классифицируем изменения. Если они соответствуют этому набору параметров по сложности, то классифицируются как проект и становятся проектом. Вот так идет управление изменениями. У нас всегда есть «параллельная жизнь», когда идут какие-то небольшие изменения и competency centre их поддерживает, и «проектная жизнь»: в среднем 24 проекта в год. Из них 2-3 – масштабные, типа ведущегося сейчас Global Live, когда мы добавляем пять новых стран. Остальные – небольшие: например, внедрение одной новой функциональности. Один из проектов - «Мерчендайзинг каталог»: внедрение онлайн-каталога на базе решения, SAP, по закупке маркетинговых материалов и других дополнительных материалов. Этот проект новые страны нам не добавляет, однако он расширяет функциональность тех стран, которые уже работают, закупают уже у нас маркетинговые материалы.

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

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

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

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

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

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

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

Коммуникации в проекте

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

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

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

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

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

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

Как мы выстраиваем коммуникацию? Определяем аудиторию, определяем заинтересованных лиц (стейкхолдеров). Какие моменты здесь важны? Мы классифицируем нашу аудиторию. Это руководители, это IT-специалисты — то есть IT-отделы, которые участвуют в проекте. Остальные отделы — Центр компетенций (Competency Center), Глобальный центр разработки (Global Development Center), первая линия поддержки пользователей п- также участвуют в проекте, так как им придется в дальнейшем делать разработки, осуществлять поддержку пользователей. Соответственно, это тоже часть нашей аудитории. Есть еще региональные IT — они будут отвечать за закупку сканеров, обеспечивать компьютеры или другое оборудование для нового решения. И, конечно, конечные пользователи — те, кто будет непосредственно работать с создаваемым решением, пользоваться им каждый рабочий день. Для каждого проекта мы определяем эти кластеры аудитории и их состав. Моя задача - кластеры выделить, а менеджер проекта определяет, кто конкретно в них войдет, какие люди, поименно. Далее мы определяем ключевые сообщения — что именно будем людям рассказывать, чему учить, какая информация о проекте в течение проекта и после будет к ним поступать. Расскажем о преимуществах и выгодах проекта, о возможных сложностях, расскажем о том, что они будут делать после того, как проект внедрили. Также мы рассказываем, как будет проводиться тестирование, обучение, какие задачи будут у проектной команды, как мы будем общаться.

Например, если это большой проект, как с предприятиями по выращиванию табака, где внедряется абсолютно новое решение, новые процессы, у нас для каждого типа аудитории существуют способы общения. В чем его сложность этого проекта? Это так называемый агробизнес: там растят табак, там нет компьютеров, там нет офисов. Там есть фермеры, которые собирают табачные листья, и есть люди, которые потом этот урожай сгружают в сушилки. Им невозможно отправить письмо по электронной почте, с описанием системы и ее преимуществ. Соответственно, нам нужно привлечь другие каналы коммуникаций. Например, когда мы внедряли в России SAP, на фабрике в Санкт-Петербурге, на производстве не было компьютеров. Поэтому мы приходили, разговаривали с сотрудниками, выпускали разные листовки. В комнате для курения повесили экран так называемого «бизнес-ТВ» и по этому телеканалу транслировали информацию. Важно задействовать все возможности внутрикорпоративных коммуникаций, найти те практики, которые для каждой компании, каждого рынка наиболее действенны. Лучше всего спросить, как это устроено в данной компании, на данном предприятии — и использовать для каждой страны привычные, принятые методы. Если говорить о функции закупок, об отделе маркетинга, тут все проще — можно разослать сообщение по электронной почте, сделать какиие-то календарики или листовки — в зависимости от того, что позволяет бюджет каждого проекта, это всегда по-разному. И, естественно, мы определяем частоту коммуникации. Потому что, напомню, у нас идет 24 проекта в год, и аудитория этих проектов зачастую может пересекаться. Представляете, если конечный пользователь будет по каждому проекту получать раз в неделю статус-апдейт? Ему либо работать будет некогда, либо он будет их просто удалять, не читая. Поэтому мы определяем, с какой частотой людям рассказывать об этом проекте, что от них будет требоваться в данном проекте.

Вот пример нашего коммуникационного плана на год. В нем указаны кластеры аудитории: руководители бизнес-подразделений, те, кто отвечает за внедрение SAP, наш CIO, руководитель нашего центра компетенций (Competency Centre Lead). У нас есть и группа ответственных за SAP, и сотрудники, которые, возможно, не имеют к этому проекту никакого отношения, но их хорошо бы проинформировать, и так далее. Есть блок, который посвящен всем общим проектам — то есть какие-то вещи сообщаются от офиса программы по внедрению SAP (PMO) на все проекты централизовано. Например, это — регрессионное тестирование: в какие дни оно пройдет, какие задачи охватит, что нужно будет подготовить бизнесу для этого тестирования – это мы делаем централизованно, так как сам процесс этого тестирования — централизованный, единый на все проекты. Затем в этом календаре идут отдельные блоки по каждому проекту — в каждом из них есть свой коммуникационный план. Сотрудник, который отвечает за эту задачу, может посмотреть в общий план — когда идет централизованная коммуникация, а когда можно сделать свою — отдельно или присоединиться к общей. Этот план составляется в Excel, и можно просмотреть более подробное описание данной коммуникации, кто за нее отвечает, зачем она нужна, что будет в конкретном сообщении и каким способом она будет выполнена – e-mail, плакат или еще что-то; в план можно внести изменения.

Эффект от такого плана мы оцениваем в конце года: все отделы, в которых велись проекты, нам шлют отчеты – что было эффективно, а что — нет. Например, большой хит сейчас у нас в компании – это desktop wallpaper («обои», заставка на мониторах компьютеров). На них размещается информация, это достаточно легко централизованно сделать по всей компании. Сотрудник не может сам поменять рисунок рабочего стола, такова наша корпоративная политика, зато он всегда может увидеть важную информацию, которую компания ему сообщает. Это один из способов, которые мы используем. Еще нам очень важно понять, не слишком ли много коммуникаций, чтобы не было эффекта спама, информационного шума.

Организационные изменения

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

1. как это изменение влияет на людей? Что поменяется с точки зрения сотрудников?

2. как это изменение влияет на существующие процессы? Изменятся ли они?

3. как это изменение влияет на технологии? Нужны ли будут интерфейсы?

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

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

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

Важно, чтобы те сотрудники, у которых изменятся задачи, рабочие процессы, знали об этом заранее. Их надо обучить, причем до проекта. С проектной командой мы эти роли описываем, потом проводим процесс назначения этих ролей. А затем мы делаем, то что у нас в компании называется organizational functioning — когда вся информация об изменениях, которую мы собрали, направляется локальному менеджменту. Мы заранее их предупреждаем о том, какие изменения, какую реструктуризацию необходимо будет проводить. Организационно все эти изменения проводятся с участием отдела кадров, так как бывает необходимо изменить должностные инструкции, оргструктуру.

Организация обучения

Самое важное для нас в этом процессе — то, что в компании называется market assessment: оценка рынка. Мы знакомимся с тем, что уже есть, уже сложилось. Есть ли у нас аудитория, которая уже в SAP работает и в их системы просто будет добавлена новая функция или новый модуль? Или у нас люди, которые компьютер никогда в глаза не видели? Есть ли у нас возможность провести online-обучение, или нам придется людей собирать в класс, чтобы их учил инструктор? На одном из первых проектов мы людей учили «мышки» в руках держать. А сейчас уже наших сотрудников иногда и обучать не нужно — просто объяснить суть изменений, показать, какие транзакции меняются, в каком поле теперь нужно будет вводить информацию. Но для того, чтобы знать, как построить обучение, нам нужно такой анализ провести. И мы его проводим в самом начале проекта. Перед началом обучения мы для каждой страны, для данного проекта заполняем форму: сколько сотрудников, какая страна, кто является контактным лицом, какой язык - основной, все ли англоговорящие. У нас в компании английский язык является основным рабочим бизнес-языком, но, естественно, есть люди, которые не говорят по-английски. В России, например, у нас не все сотрудники говорят по-английски, особенно на производстве, поэтому мы всегда должны понимать, надо ли переводить наши обучающие материалы и курсы или можно вести обучение на английском.

Важно учесть логистические моменты — например, в каждой стране свой календарь праздников, выходных дней. По каждому процессу и модулю, который внедряем, мы определяем, сколько человек необходимо обучать. Обучение необходимо документировать — это один из ключевых моментов. У пользователя должны быть обучающие материалы. Мы их основываем на тех ролях, которые данному пользователю будут назначены в системе. Плюс, мы берем описание бизнес-процессов. На их основе тренеры готовят обучающие материалы, добавляют упражнения с транзакциями. Таким образом, в курсе всегда сочетаются теория и практика. Мы используем для этой задачи продукт, который раньше назывался Info Pack, сейчас называется UP Form. Он позволяет достаточно быстро создать рабочие инструкции. Кроме этого, сейчас мы используем e-Learning, и это очень удобно для проектов, где квалификация пользователей уже достаточно высокая. Можно создать электронный курс, причем на разных языках, заранее людей зарегистрировать, и они, в удобное для них время, сами пройдут этот курс. В нашем каталоге сейчас около 200 разных SAP-овских курсов.

Организация логистики

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

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

Как мы проводим обучение? Если выбран электронный способ, то глобальная команда просто создает эти курсы, переводит их при помощи локальных отделов обучения, если есть необходимость, а дальше мы всех сотрудников регистрируем в корпоративной системе e-Learning на эти курсы, они их проходят. В зависимости от желания наших внутренних заказчиков мы можем отслеживать прохождение курса, делать его обязательным или факультативным, проводить или не проводить тестирование. Эти моменты определяет спонсор проекта или его руководитель. За основу мы берем обучение инструктора, затем он возвращается к себе и обучает остальнымх.

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

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

Мотивация персонала

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

Генератором изменений в компании, как правило, является бизнес. Иногда мы тоже можем что-то предложить бизнесу, но в основном потребность определяется бизнесом. Бизнес говорит: «Мне нужно новое решение, чтобы закупать табак», или «Мне нужно, чтобы этот процесс теперь работал не способом АВС, а каким-то другим». Как было и с маркетинговым материалом: бизнес пришел и сказал: «Ребята, нам нужен online-каталог».

Этот процесс управления техническими изменениями, которые определяют ключевые пользователи. Далеко не каждый бизнес-пользователь может придти и сказать: «Измените, пожалуйста, этот отчет, что-то мне не нравится, как он выглядит». Ключевой пользователь обращается в IT, в центр компетенций, и бизнес-консультанты, которые создают систему, анализируют - нужно ли вообще новое решение или просто пользователи не очень хорошо знают возможности системы. Во втором случае запрос вопрос возвращается ко мне, в команду по обучению, так как мы и текущим обучением занимаются. Если же мы реально понимаем, что решение перестало соответствовать требования бизнеса, может быть — поменялось законодательство или изначально была неоптимальная конфигурация. Тогда совместно составляется запрос на изменение (change request), который дальше проходит по довольно сложному пути одобрения. Это определенная процедура. Изменение, если оно масштабное, может быть выведено в отдельный проект. Эти проекты консолидирует SAP program office и планирует их реализацию. Какие-то проекты могут быть запланированы на следующий год, потому что в этом году все ресурсы уже расписаны. Или необходимо создать параллельный ландшафт, потому что в единой технической системе это не реализуемо. SAP program office каждый год составляет план работы, единый «тайм-лайн», и все проекты работают в соответствии с этим графиком.

Об авторе

Ольга Костерина отвечает в JTI за управления изменениями в ИТ и за глобальное обучение. Она определяет и внедряет лучшие практики и стандарты по управлению изменениями в ИТ и по ключевым инициативам. Ольга также занимается организацией учебного процесса по всем системам SAP, которые включают 1000 ключевых пользователей и 27000 ролей SAP (14000 сотрудников).