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

23-24 мая 2013 года

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

Докладчик: Оливер Конке, старший бизнес-консультант в SAP Business Transformation Services

Построение внутренних компетенций управления организационными изменениями

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

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

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

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

Важность управления изменениями

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

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

Когда вы внедряете SAP или занимаетесь другим IT-проектом – вы описываете новые роли, новые зоны ответственности. Как правило, появляются новые задачи для существующих сотрудников. И, конечно, нужно что-то сделать для обучения сотрудников, предоставления им новых навыков. Но тренинги – это только один кусочек этого паззла управления изменениями. А вот то, о чем часто забывают – то, что описано в нижней части данного слайда – нематериальные факторы. Они настолько же важны, насколько важны и материальные элементы.

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

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

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

Вот исследование 2002 года, которое провела компания McKinsey.

Исследование показывает ценность управления изменениями в компании. Что они сделали? Они взяли бизнес-кейсы, которые были разработаны до запуска проекта трансформации бизнеса. В данном случае эта трансформация бизнеса предполагала ряд проектов: внедрение новых стратегий, IT-структуризация, проекты по реинжинирингу и так далее. McKinsey, как правило, тоже часто приглашают на этап бизнес-кейсов. Они посмотрели, каким образом изначально в бизнес-кейсе были описаны KPI: «снижение расходов», «скорость процессов», «производительность процессов» – это то, что было написано до. Затем сравнили это с результатом и оценили их с точки зрения эффективности управления изменениями.

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

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

Следующий вопрос проиллюстрируем другим исследованием – от Boston Consulting Group. Какие организационные компетенции нужны для правильного управления изменениями? Какие навыки и знания должны быть у компании, чтобы ей не нужно было привлекать внешних поставщиков?

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

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

Итак, пример: наш клиент, английская компания, работающая на мировом рынке. Она постоянно покупает новые компании в разных странах и все время находится в состоянии каких-то изменений. Эти изменения связаны не только с IT: большинство изменений, которые переживает эта компания, так или иначе должны получать IT-поддержку. Когда мы начинали проект по управлению изменениями, у них было 20-30 маленьких IT-проектов: перевести, мигрировать Outlook, перенести почтовые ящики – маленькие задачи, но на глобальном уровне. Были проекты и покрупнее: гармонизация и стандартизация процессов на базе ЕRP-решения от SAP, и другие проекты разного масштаба.

С какими основными проблемами сталкивалась эта компания? У них не было собственных внутренних компетенций управления изменениями. Когда я говорю «управление изменениями», я имею в виду и тренинги тоже, обучение, потому что без обучения управления изменениями быть не может. У них не было собственных компетенций. В результате они сильно зависели от внешних подрядчиков. Они постоянно нанимали каких-то независимых консультантов: Deloitte, PwC и других. И что же происходило? Каждый раз, когда консультанты уходили из проекта, они забирали ноу-хау с собой. В компании знания не оставались, не фиксировались. Когда вместо Deloitte приходил Accenture, а вместо Accenture - какие-нибудь независимые консультанты, они каждый раз приходили со своей собственной методологией. Представьте себе лидера бизнеса, который понимает, что управления изменениями важны. Но в прошлом проекте ему говорили, что для этой задачи есть только такая модель, а в новом проекте приходит новый консультант с новой моделью. Отсутствие единообразного подхода было названо третьей проблемой этой компании. Оно приводило, в свою очередь, к отсутствию доверия, а это абсолютно недопустимо: когда нет доверия, неправильно интерпретируется информация, принимаются неверные решения, возникают задержки в реализации и так далее.

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

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

1. разработать единую модель, структуру, на которую согласятся все в компании. Эта модель должна была опираться на единую методологию управления изменениями.

2. организовать работу по этой модели.

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

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

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

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

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

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

До запуска проекта была сформулирована миссия: «Мы предоставляем наилучшую практику по управлению изменениями, обучение в целях поддержки IT-проектов и в целях обеспечения изменений во всей компании для получения максимальной ценности для бизнеса».

Ожидаемые результаты

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

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

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

Более эффективная реализация IT-проектов, конечно, тоже важна. Здесь можно опираться на разные стандарты управления изменениями - PMI, PMBOK. В Англии есть локальный стандарт – Prince 2. В каждом из них заложено, что управление изменениями – это непрерывный процесс, причем процесс, которому учатся все. Несколько лет назад в управлении изменениями ничего не говорилось про обучение. Сейчас все больше внимания уделяется и обучению, и взаимодействию с людьми на всех уровнях, рассматривается не столько техническая, сколько психологическая, социальная сторона.

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

И еще один важный элемент – «Performance-менеджмент», управление эффективностью или производительностью. Наверняка у вас есть какие-то инструменты управления кадрами: бонусы, стимулы и так далее. Представьте себе, что у ваших менеджеров есть KPI, есть ресурсы, проект. 30% зарплаты менеджера зависит от достижения целевых показателей. Если такая взаимосвязь выстроена, менеджер более активно поддержит ваш проект.

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

Вот пример того, как мы взаимодействуем со стейкхолдерами, с заинтересованными лицами. Сначала мы их идентифицируем, потом их анализируем, потом мы смотрим какой эффект окажут эти изменения на этих заинтересованных лиц.

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

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

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

Были в этом проекте и другие аспекты управления изменениями. Мы разработали весовые показатели для каждого из этих критериев. За каждым пунктом стоит ряд вопросов: «Получаете ли вы регулярно сообщения от материнской компании? Удовлетворены ли вы качеством информации, представляемой в этом проекте?» – и так далее, и так далее.

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

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

Организационный аспект управления изменениями

Прежде всего, необходимо было определить подотчетность. Мы сформировали команду, которая глобально отвечала за внедрение всех организационных изменений во всей компании. Если кому-то надо было что-то изменить, то этот «кто-то» в компании знал, что нужно обращаться к лидеру этой команды. Чем занимается эта команда? Она разрабатывает, обслуживает и отвечает за глобальное управление изменениями и обучение. Ее работа строилась на базе SAP Productivity Pak – это инструмент для разработки контента обучения, поддержания его в актуальном состоянии и распространения.

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

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

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

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

1. учить людей без отрыва от производства

2. разрабатывать методологии управления изменениями при участии и сотрудничестве с сотрудниками этой компании – так и передача знаний происходила.

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

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

Результаты и выводы

Уроки, которые мы извлекли из этого проекта, можно разбить на три категории.

1. стратегии и инструментарий управления организационными изменениями. Мы очень внимательно и избирательно отобрали из предыдущего опыта все, что можно было оставить. Вся эта работа велась при участии сотрудников компании, так что они сразу учились.

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

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

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

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

Отдельно хочется сказать о специфике управления изменениями в эпоху облачных технологий. У нас есть свой подход и своя методология управления изменениями, так как SAP сейчас активно работает на этом рынке. И мы можем оказывать такую поддержку не только на территории клиента. Когда внедряется ЕRP, консультанты всегда работают на территории клиента. Что касается новых продуктов, новых стратегий SAP, то одним из очень важных направлений нашего развития являются облачные решения. И у нас очень агрессивные планы по развитию на ближайшие годы.

В прошлом году мы купили Ariba, и это один из наших факторов успеха для успешной стратегии в «облаках». Мы адаптировали наш подход к управлению изменениями к контексту «облаков». Мы абсолютно убеждены, что с «облаками» многие изменения, особенно в самом начале, происходят в IT, в зависимости от уровня стратегии.

Если вы реализуете стратегию инфраструктуры как сервис или платформу как сервис, у вас SaaS-стратегия – вы подписываетесь, скажем, на функциональные модули HR, и хостинг предоставляется внешним партнером. То есть в данном случае – компанией SAP. Другими словами, вы IT передаете на аутсорсинг, и даже, возможно, HR и кадровое делопроизводство. Это серьезное изменение – когда вы переходите от локального внедрения к «облакам», когда вы переносите часть функционала в «облака». И вот этот переход, с моей точки зрения, должен поддерживаться управлением изменениями и обучением – это очень важно. Через пару лет, когда компания завершит этот процесс перехода в «облака», управление изменениями уже не будет требоваться в таком объеме - изменения будут более локальными, не критичными для общего стандартного процесса. Если программное решение понятное, интуитивное – пользователю легко к нему привыкнуть, легко включиться в новый функционал, для этого может быть достаточно короткой лекции или вебинара. То есть таким процессом можно будет управлять все легче и легче. И мы можем учиться на собственном опыте управления изменениями даже в рамках традиционных проектов внедрения SAP. И мы можем эти знания переносить в облачные внедрения, по крайней мере, я это так вижу.

Почему возникают возражения против изменений и как работать с ними? Зачастую люди недооценивают важность системного управления организационными изменениями. Иногда это лежит на уровне ментальных различий. Я участвовал во многих международных и локальных, и региональных программах, когда внедрялись какие-либо решения SAP, которые требовали изменений. Люди в разных странах по-разному воспринимают эти изменения. Например, в скандинавских странах люди активно участвуют в управлении - мало кто сомневается в необходимости изменений, и все очень активно участвуют в этом процессе. Аналогично и страны с англосаксонской культурой – у них не возникает сомнения в том, что изменения нужно проводить и ими надо управлять. Может быть, эта работа не всегда ведется структурированно, но в ее необходимости не сомневаются. Что касается стран Востока, то там возникают другие культурные сложности, возможно – исторически обусловленные.

Об авторе

Оливер Конке – главный бизнес-консультант SAP Business Transformation Services. Он пришел в SAP в 2002 году из McKinsey & Company. Оливер получил степень PhD по индустриальной и организационной психологии в университете Мангеймаю. Оливер Конке уже 17 лет занимается поддержкой маштабных проектов по трансформации бизнеса и по внедрению ИТ-систем.