Рассматривая управление изменениями в российских компаниях, можно увидеть ряд отличий от тех практик, которые сложились в компаниях западных. Например, это часто проявляется в задаче проектных коммуникаций. Далеко не всегда удается убедить спонсоров проекта участвовать в этих задачах, хотя их мнение – это ведь, как правило, ключевые руководители компании – очень важно для всех сотрудников. В моей практике был пример, когда за 2 месяца до запуска системы оказалось, что еще никто не начинал работать с тренерами – это около 100 человек, которых выделили для обучения конечных пользователей. В общей сложности, этим тренерам предстояло обучить около 1000 человек. Однако одним из первых вопросов на нашей встрече с тренерами стал буквально следующий: «А что такое SAP вообще?». Надо сказать, что в тот момент внедрение в компании шло уже полтора года, завершился процесс тестирования и шла миграция данных. Но сотрудники, которым предстояло сыграть ключевую роль в адаптации коллектива к новой системе, за 2 месяца до ее запуска не знали о ней ничего. Это неправильно, но эта практика – к сожалению, норма в российских крупных компаниях.

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

Также важно знать, какое мнение о проекте имеют заинтересованные стороны. Для всех, кто внедрял, не секрет, что проект по SAP очень часто является в организации политическим вопросом, в котором у каждой стороны свои интересы. Естественно, при выявлении заинтересованных сторон надо понимать мотивацию каждого руководителя. Пример - внедрение SAP HR, процесс расчета зарплаты основных сотрудников.

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

Однако возникает парадокс: управление организационными изменениями часто воспринимается как нечто отдельное от управления проектом, от собственно проекта. Логика примерно такая: проект у нас – про ИТ, а управление изменениями - это трансформация бизнеса. И это в корне неправильно, потому что мы взаимодействуем, мы должны быть в одной лодке, вместе с проектной командой, мы часть ее. В противном случае просто ничего не получится.

Один из частных случаев такого неправильного подхода нередко демонстрируют HR-директора и PR-директора. В их восприятии внедрение SAP – это дело ИТ, а раз так, то никаких задач по коммуникации или обучению на себя они принимать не могут. У них всегда столько оперативной работы! Очень полезно сразу заручиться их поддержкой, так как в руках этих руководителей – инструменты коммуникаций, что очень важно для успеха проекта. Но хочу вас предупредить, что, по большому счету, им изменения не нужны, им нужна стабильность организации, стабильность своей деятельности. Они для вас такие же агенты сопротивления, как и все остальные. В моей практике именно так и получалось.

Мы не раз обсуждали, какие ключевые сложности внедрения существуют вообще в больших проектах, и выделили 8 таких моментов.

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

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

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

Четвертое – это управление организационным изменением.

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

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

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

Бизнес-процессы. Прием на работу

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

Что важно отражать на этих схемах?

1. подразделение, которое отвечает за этот шаг, в чьем ведении находится тот или иной этап бизнес-процесса. Например, регистрацию служебных данных (конкретной штатной позиции, оклада) осуществляют специалисты ОТиЗП (отдела труда и заработной платы). А, например, идентификацию распознавания кандидатов в базе данных – специалист управления кадров. Это абсолютно разные подразделения, с разными руководителями, разными сотрудниками. Это очень важно, потому что это пойдет потом и в каталог курсов, и в присвоение ролей, и во многие другие процессы.
2. Важно, чтобы сразу было понятно, какая транзакция, стандартный или нестандартный процесс SAP для нее будет использоваться, так как от этого зависит, потребуется ли дополнительная разработка. Таким образом, вы уже на этом уровне можете прикинуть объем разработок, которые у вас будут. Сейчас очень часто такие согласованные схемы включать в проектную документацию, в проектные решения. То есть это документ, который является очень важным для проекта.

Например, в рассматриваемом процессе формирование отчетности для аналитики происходит вообще вне системы. А вот идентификация распознавания кандидатов в базе данных – это PB40, стандартная транзакция.

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

Проектные решения

Правильно структурированное проектное решение – залог успеха. В доказательство этого тезиса рассмотрим два проекта.

• Первое проектное решение очень объемное: 1116 страниц. Разобраться в нем крайне сложно. Весьма весомый, насыщенный информацией документ. Очень хорошо, что он есть. Но работать с ним невозможно, это абсолютно «неуправляемый документ».
• Второе проектное решение – короткое, такиех решений по теме HR - порядка 50, они все короткие и структурированы очень четко.

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

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

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

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

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

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

1. Создание шаблонных, локализованных ролей в тестовой системе и в продуктивной системе. Основой этого является, в том числе, сопоставление ролей конечных пользователей. Этой работой занимается базис и, только имея эту матрицу присвоения ролей, он сможет хорошо сделать свою работу. Несмотря на то, что роли определяют, как правило, функциональные консультанты, это не задача менеджеров по управлению организационными изменениями. Но подход к планированию ролей, к тому, как эти роли будут настроены в системы, менеджеры по управлению организационными изменениями должны понимать очень глубоко, потому что от этого зависит последующий результат. Например, либо вы создаете немного ролей в системе – порядка 20, – и затем начинаете ограничивать их полномочиями. Тогда у вас будет ограниченный список ролей, и вы присваиваете конечным пользователям роли сразу с ограничением полномочий. Другой подход – это создание локализованных ролей, то есть множество ролей уже со всеми полномочиями. Потом у вас будут несколько другие курсы. Потом у вас люди пойдут учиться в разные группы. Еще раз повторю, это не делает консультант по OCM. Но это надо понимать – сам принцип, сам подход.
2. Сопоставление ролей и конечных пользователей. Этот блок тоже не делает консультант по управлению организационными изменениями, в том плане, что он не создает эти настройки сам. Но консультант по орг. изменениям обязательно должен управлять этим процессом и быть включенным в него. Например, я проводила рабочие встречи с каждым руководителем бизнеса, объясняла им, что это, зачем это, какие роли существуют, как надо присвоить, в какие сроки, и так далее. Иначе это превращается в неуправляемый процесс. Это очень большая работа, очень много коммуникаций и совещаний.

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

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

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

Типы организационных изменений

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

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

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

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

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

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

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

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

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

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

Каталог курсов. Это относится к обучению конечных пользователей. Но, опять же, он основан на работах по присвоению ролей. Это очень важно. Что здесь есть? Бизнес-роль: например, бухгалтер по расчету зарплаты. Для него доступны курс и конкретное название роли, транзакции, шаг бизнес-процесса, как он называется, закодированный.

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

Пример про самообучение. Сейчас, на текущем проекте, клиент, компания, которая внедряет SAP, за два месяца до продуктивного старта не задумывалась об обучении вообще. Они слышали о таких примерах, что к моменту продуктивного старта всем раздают инструкцию и говорят сотрудникам, что работа в новой системе началась и они сами должны все освоить, руководствуясь инструкцией. Их ситуация такова: за два месяца до запуска 1000 пользователей, включая ключевых, понятия не имебт о том, что такое SAP и какая система внедряется. Инструкции не созданы, материалы не созданы, система сырая. До интеграционного тестирования еще даже не дошли. Типичная жизненная ситуация.

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

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

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

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

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

Очень помогает формирование каталога курса по ролям. Если вы детально его проработали, у вас все управляемо. Если вы стали готовить материалы по курсу в целом, потом это очень сложно управляемо. Ваша задача как клиентов, как заказчиков, постоянно подталкивать консультантов к тому, чтобы они обновляли проектные решения. Другого варианта нет. Упустите – все, больше потом не вернетесь. Это сложно, но это надо.

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

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

Я еще вставила такой бенч-марк именно из SOAP – сколько сотрудников должно работать в центре поддержки, какого уровня они долны быть и для каких задач. Соответственно, 100 % сообщений должен получать ключевой пользователь. Примерный расчет – 1,5 специалиста техподдержки на 100 сотрудников, это лучшие практики SOAP. В реальности 1 человек поддерживает 10 сотрудников, причем это не ключевой пользователь как ключевой пользователь, это тренеры – коллеги конечных пользователей, которых просто номинировали на роль тренера, их задача чуть больше знать о SOAP. Распределение по уровням примерно следующее: ServiceDesk IT 0,24 человека на 100 человек, прием 80 % обращений. Второй уровень – 42 % и коэффициент несколько другой. И 1 % – уже в SOAP. Примерно вот так вот.

Вот несколько примеров кейсов.

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

Варианты сценариев:

1. организовать еще один отдел мастер-данных, 10 человек, и он будет стоить много денег, но на самом деле функцию этого отдела можно передать в HR. Согласно законодательству, не могут одни люди и вводить данные, и их обрабатывать, поэтому вводят кадры, обрабатывает бухгалтерия.
2. считать эту информацию мастер-данными и ответственность за их ввод возложить на HR, обосновать свою позицию на управляющем комитете: сравнив два процесса (имеющийся и предлагаемый), показать преимущества нового подхода. Заручиться, таким образом, поддержкой бухгалтерии. Именно так сделали в «Альфа-банке»: был предложен процесс «2B», по которому первоначальные изменения данных в системе проводят только кадровые службы.
3. исходя из того, что дело кадров – это занести все данные, их отслеживать и изменять, а дело бухгалтерии – это правильно определять налоговые выпаты, ввод и корректировку данных должна делать кадровая служба. А изменение ставок налогов можно автоматизировать, например, во Flow, либо договориться, что будет приходить уведомление определенному сотруднику бухгалтерии, который сделает изменение.
4. отдать данную функцию на аутсорсинг, но тут решение будет зависеть от объемов. Как вариант, наверняка в HR во всех компаниях есть сотрудники, которые ведут первичный учет и могут отслеживать далее всю информацию.

Кейс 2: Российская компания, энергетический сектор. Проект по внедрениб ТОРО длится год. Достаточно ограниченная, но сложная функциональность. На слайде видно процессы, которые внедряются, и распределение проекта по фазам. 700 конечных пользователей, которые не имеют опыта работы с SAP и должны обучаться с нуля. Выделено 11 ключевых пользователей, которые должны обучить эти 700 человек в ограниченные сроки. О том, что у нас 11 пользователей, которые должны обучить 700 человек, мы узнали в середине третьей фазы (фазы реализации). Остается не так много времени.

Задача № 1: выстроить стратегию обучения этими 11 ключевыми пользователями 700 конечных пользователей.

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

Задача № 3: параллельно со всем этим выстроить систему мотивации для 11 ключевых пользователей, чтобы они в ограниченные сроки обучили 700 человек. Для этой работы ключевые пользователи полностью освобождаются от своих обычных рабочих обязанностей на период проведения обучения.

1. Метод «живого внедрения»: брать тренеров и отправить к ним жить, чтобы у сотрудников появилось чувство, что их не бросили. Но есть риск, что после отъезда тренеров знания пропадут. Параллельно должен идти еще какой-то учебный процесс, то есть нужны обучающие материалы, записи курсов.
2. Учитывая проектный план, еще есть месяцев пять до конца проекта. 11 ключевых и 700 конечных – это 50 с небольшим на одного ключевого пользователя. Первый шаг – обучаем ключевых, проводим тренинг по тому, как преподавать. Второй шаг – в течение месяца мы обучаем их функционалу. Одновременно с этим готовятся материалы для обучения конечных пользователей в виде текстов и роликов. Третий шаг – график обучения конечных пользователей с использованием этих материалов. Мотивация ключевых пользователей на шесть месяцев: по завершении обучения их можно перевести в центр компетенции KPI по обучению всех пользователей: за качественное обучение получают бонус, если низкое – не получают.
3. В дополнение к прошлому ответу: 11 человек обучают всех, а к моменту проведения первого тренинга у 60-ти человек освобождается время, и они могут помочь точечно тем людям, которые не обучаются, помогать с обучением, зарабатывать дополнительные KPI.
4. Учитывая, что подразделения компании находятся в разных городах, ключевые пользователи должны принять участие в разработке документации, которая потом используется как eLearning. В качестве мотивации: они в дальнейшем возглавляют отдел по подготовке данных в систему. Сколько они смогли обучить, столько у них рабочих рук и появилось. Мы делаем акцент на последующее формирование собственных подразделений.
5. Ииз-за сменной работы сотрудников невозможно обучить всех вместе. Соответственно, большая нагрузка на начальника смены, от которого требуется оценить KPI. Предложили сделать соревнования. Кто проиграл – теряет премию, кто выиграл – получает две. У кого ошибок в системе по факту будет меньше, тот и выиграл.
6. Создание портала по обучению, где будет вся контактная информация ключевых пользователей, а также – возможность создания вебинаров, которые будут записываться и от сессии к сессии можно подключаться, то есть можно проходить один курс несколько раз. Можно создавать инструкции для закрепления материала, просить пользователей самостоятельно создавать инструкции для себя.
7. Для сохранения знаний привлечь тренинг-менеджеров к обучению 700 конечных пользователей, закрепить данную функцию и раз в месяц по итогам теста, где 80 % будет удовлетворительно для прохождения теста, оценивать KPI.

Решение, предложенное SAP Consulting

Была выбрана программа training-training, и 11 пользователей обучали 700. Курсы были составлены разные, eLearning был тоже в расписании тренингов. Наша основная задача была в том, чтобы обеспечить на каждом участке, на каждой ТЭЦ в каждой смене, как минимум, одного человека, который был достаточно компетентен для того, чтобы поддержать всех остальных. Мы делали упор хотя бы на одного пользователя, который сдал тест более чем на 80 %. Сразу замечу, что были консультанты, то есть проектная команда сотренерствовала. Первые группы тренингов были проведены практически совмести и консультантами, и тренерами (11 человеками).

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

Была отдельно взято время на то, чтобы подготовить этих тренеров как тренеров. У них была заранее проведена практика обучения, до того, как мы выпустили ЦК, они тренировались, обучались. Так была решена первая задача – «как обучить?».

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

Кейс 3. Графики и аналитика

В середине проекта было проведено исследование: как он движется, как люди себя чувствуют, получают ли информацию. Главную проблему – недостаточные коммуникации – озвучили 79 % опрошенных (IT, консультанты, внедренцы, подрядчики, ключевые пользователи). Не опрашивали конечных пользователей, так как это пока только середина проекта. Вторым фактором стало отсутствие мотивации сотрудников компании в программе внедрения. Айтишника – 25 %, консультанты – 13 %. И 32 % – треть ключевых пользователей - вообще не замотивированы, а даже демотивированы в том, что происходит.

Степень сомнения, что успех впереди – у 59 % ключевых пользователей, то есть со стороны бизнеса они не верят в то, что они делают, в то, что делают все остальные, что программа эффективна и так далее. Большая проблема в интеграции проектов: требуется большая программа, так как собирается порядка 8 крупных функциональностей, было решение «большого взрыва» в конце, параллельного ведения всех процессов. На результат, что 75 % опрошенных говорят о низкой интеграции проектов, из IT ответили, что «да, действительно, очень низкая, проекты между собой никак не интегрируют, не взаимодействуют, не коммуницируют, живут отдельной жизнью». Ключевых пользователей с таким мнением – 41 %, среди консультантов – 38 %. Издержки методологии. 100 % из IT сказали о том, что «Консультант» они внедряют неохотно, что есть большие издержи методологии. Из ключевых пользователей с этим тезисом согласна примерно 1/3.

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

1. взять еще немного времени на подготовку и вернуться к первым шагам – к определению заинтересованных сторон, проработке коммуникационного плана, реестра организационных изменений, плана работ. Опять оценили, улучшили – идем дальше. Не улучшили – повторяем.
2. мнение ключевых пользователей – это все-таки вторичная вещь. Главный конфликт здесь между ИТ и консультантами. Все считают, что консультанты выбрали не ту методологию. Предложение – передать разработку методологии в ИТ, а консультантов привлекать для финальной доработки, и двигаться дальше. Это решение быстрое, хотя, возможно, в чем-то и скандальное.
3. проблема с мотивацией, проблема с коммуникацией. Возможно, здесь есть общая причина. Первым делом выяснить у спонсора, насколько он заинтересован, потому что, возможно, он как-то потерялся. Если он заинтересован и готов немного расширить бюджет, мы, действительно, сделаем коммуникационный план – это будет и PR-кампания, и коммуникационная кампания, где мы все эти трещины между консультантами и айтишниками попытаемся замазать. И после этого «Биг Бена» мы должны выстроить уже грамотную коммуникационную программу. Начать, а после этого продолжать раскручивать. Что касается мотивации, то это точно также можно использовать.
4. IT 100 % называет проблемой проекта методологию, потому что верит в успех меньше, чем ключевой пользователь. В качестве решения, возможно, нужно Татьяну и Елену пригласить в этот момент и посмотреть, каково соответствие целей.
5. однозначно останавливать проект и пересматривать проектное решение. Может быть, неправильно учли процесс, в результате чего получили такие разногласия, может быть, идут разные бизнес-процессы, между собой абсолютно не связанные. Но не перекладывать разработку методологии на ИТ.
6. руководству компании надо задуматься над тем, есть ли смысл в таком проекте, правильных ли консультантов выбирали, правильную ли систему. И, если ситуация соответствует действительности, конечно, проект надо останавливать.

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

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

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

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

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

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

По поводу спонсора и управляющего комитета. Это было вынесено на управляющий комитет. Генеральный директор компании сказал следующее: «Коллеги, есть кто-то, кто не верит в успех? Список мне этих сотрудников на стол. Завтра они не работают в этой компании». Проблема решена. Все.

В реальности правильно было бы информировать, но по факту решение было такое. Генеральный директор спонсор. Ему было неинтересно вступать, ему было неинтересно рассказывать. Это было директивное решение с военной культурой внутри компании. Сказал – должны все построиться и сделать. Кто-то не доволен – свободен.

Кейс 4. Американская компания и ее российский филиал. Шесть заводов, шесть сайтов, два офиса. Около 1 500 конечных пользователей. Люди уже работали с SAP много лет, то есть ,олее-менее знают интерфейс. Много внешних пользователей – этих «третьих сторон», о которых уже говорили ранее. Компания-клиент взяла на себя ответственность и обязанность обучить еще и третьи стороны, то есть непосредственно тех людей (по одному человеку с предприятия), с которыми они будут работать, и не только своих сотрудников, но и совершенно внештатных подрядчиков.

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

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

1. делаем опрос обязательный для всех, из двух частей. Первый опрос - функциональный, чтобы понять, насколько люди понимают, как работать в системе, а вторая часть – это по проекту, насколько люди понимают, зачем проект, какие сроки запуска, цели и так далее. Собираем вот эти данные и смотрим, если есть какие-то белые пятна, например, по целям, то уже как-то в этой области работаем сильнее. Если мы понимаем, что у нас все неообучены, нужно откладывать проект. Здесь мы либо успеваем, либо нет. Успеваем обучить – обучаем.
2. если руководитель полтора года не интересовался процессом, у него все было хорошо, а потом у него вдруг появилась эта идея за месяц все это проверить, то надо выписать ему литр валерианки или в санатории нервы подлечить.
3. разработать сценарий тестирования с привлечением третьих сторон для внешних консультаций по поводу конкретного бизнес-процесса, в котором они участвуют. В момент проведения обучения выявятся слабые стороны, и можно будет сосредоточиться на их исправлении.
4. выдаем контрольное задание, обрабатываем результаты, по ним определяем группу, которую надо дообучить, дообучаем. На всякий случай еще раз обучаем ключевых пользователей, приводим периодическое обследование. На портале электронные материалы расшариваем для всех.
5. провести замер знаний, контрольный срез. Тесты, поскольку нет времени и ресурсов на подготовку, месяц до запуска – будет готовить проектная команда по ночам.
6. собирать анонимную обратную связь по информированности: «Насколько вам комфортно в тестовой системе работать? Насколько вы привыкли к интерфейсу? Какие проблемы возникают?». По результатам опроса понимаем, какое количество пользователей недовольно, не знает систему. Предлагаем запустить тестовую систему как пилотную версию и уже мониторим по ошибкам.

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

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

По остальным 15 процессам мы разослали письма линейным менеджерам, уведомляя их, что в течение 2 недель они должны протестировать эти процессы в тестовой системе, после чего будет сделана выгрузка и проверено – сколько и какие документы смогли создать в системе конечные пользователи. Дальше мы уже смотрели статистику: кто как минимум залогинился в систему по ID пользователя, и кто сколько каких документов сгенерил; совпадало ли это с тем целевым процессом, который мы хотели оттестировать.

Четвертый шаг – оценка готовности конечных пользователей, проводили опрос.

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

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

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

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

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

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

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

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

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

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

Об авторе:

Татьяна Козуб
Независимый бизнес-консультант

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