Практика управления изменениями

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

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

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

Для успешного выполнения этой роли ИТ-директору необходима подготовка в трех областях: {PAID}

• Понимание бизнес-причин изменений.

• Осознание «факторов успеха», которые позволяют реализовать изменения с наибольшей вероятностью результата.

• Знание «рубежей обороны», которое препятствуют внедрению изменений.

Отправная точка

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

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

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

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

Слагаемые результата

Если сформулировать коротко, то для успешной реализации изменений необходимы:

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

• План.

• Процесс управления рисками и отклонениями.

• Коммуникации.

Вовлечение руководителей

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

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

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

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

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

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

Планирование

Любое организационное изменение представляет собой переход из состояния А в состояние Б и может быть организовано в виде проекта. Сложнее изменения — сложнее план, больше задач и вовлеченных сотрудников и служб. Компетенции ИТ-руководителя, как правило, достаточно для подготовки и управления довольно сложным планом (это не высшая математика). Наряду с этим, на мой взгляд, важны два момента.

Читайте также
Когда речь заходит о кибербезопасности, доверие — это опасная роскошь. Громкие утечки данных, взломы крупных компаний и бесконечные цепочки атак привели к рождению концепции, которая предлагает радикально новое решение: «Не доверяй никому и ничему». Zero Trust ворвался в мир как спасательный круг для бизнеса, уставшего от постоянных угроз, и стал новой мантрой для специалистов по безопасности. Но является ли эта модель настоящей революцией или это очередной маркетинговый ход? Эти и другие вопросы обсуждали на круглом столе IT-World «Цифровое доверие: киберщит или ахиллесова пята?», организованном журналом IT Manager.

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

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

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

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

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

Управление рисками

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

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

А далее срабатывает принцип «подводной лодки». Проблемы по одному-двум направлениям потянут ко дну весь проект.

Риски возрастают, когда в проект вовлечены десятки и сотни участников. Что делать? Первое — контролировать сроки каждой конкретной задачи. При возникновении проблем со сроками и качеством незамедлительно обозначать проблему, чтобы она была видна, не заметать ее «под ковер».

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

Коммуникации

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

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

Отсюда правило: коммуникации много не бывает, но желательно сделать ее структурной и направить на все уровни и все службы организации. Например, так:

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

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

• Раз в месяц на информационном портале размещается краткая информация о состоянии проекта.

Рубежи обороны

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

Читайте также
Еще совсем недавно от западных облачных сервисов зависело 30% крупных российских компаний. Их отключение, порой внезапное, должно было поставить рынок перед сложными вызовами. Но оказалось, что российские облака готовы предложить рынку вполне зрелые решения. Это и многое другое обсудили участники круглого стола IT-World «Импортозамещение в облаках».

Сопротивление изменениям естественно. Для большинства людей работа в режиме «завтра такое же, как и вчера» вполне комфортна. А вот новые регламенты работы со смежными службами, новые программы, новые продукты и незнакомые запросы клиентов — нет. Возможны и ситуации, когда реализация проектов изменений (например, внедрения новой системы управленческого учета или нового процесса управления закупками) позволяет вскрыть подлоги и должностные нарушения. Естественно, изменения этого рода также вызовут сопротивление, причем в данном случае оно может быть хорошо замаскированным.

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

А если отсидеться не получается?

• Мне сейчас некогда, я завален текущей работой.

• Я не прошел обучение в достаточном объеме.

• Я понимал свою задачу иначе.

• Это не входит в мои обязанности.

• Мне недостаточно платят.

• Я знаю только свой участок процесса

• Может ли это сделать кто-нибудь другой?

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

Работа с change resistance далека от собственно информационных технологий. В ней востребованы понимание других людей, умение вести переговоры и решать кризисные ситуации.

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

Опубликовано 29.04.2013