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

Понятие организационных изменений

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

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

Те практики, те технологии, о которых мы с вами будем говорить, ориентированы на по-настоящему крупные изменения, затрагивающие организацию в целом или ее существенную часть, затрагивающие различные функции в этой организации, затрагивающие большое количество участников. Я приведу в качестве примера такую задачу. Организация принимает решение, например, о комплексной автоматизации бизнес-процессов на базе какого-нибудь решения ERP-класса. И что это означает? С точки зрения program management, program management organization, change management? Скорее всего, потребуется некоторая переработка бизнес-процессов, обновление IT-инфраструктуры, реорганизация деятельности IT-подразделения, которое отвечает за эксплуатацию и сопровождение инфраструктуры и поддержку бизнес-приложений. Это означает, что потребуется, скрорее всего, проводить миграцию «зоопарка» IT-решений, который был до этого – а у некоторых компаний даже не зоопарка, а заповедника дикой природы – на некоторое комплексное решение, с помощью которого оптимизируется сразу множество задач, и интеграцию этого решения со средой предприятия, в том числе - с IT-средой.

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

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

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

Кто предупрежден, тот вооружен

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

Есть несколько вариантов классификации драйверов организационных изменений. Здесь приведен лишь один из них, в общем, довольно широко известный.

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

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

Когда, например, предприятие купили или поглотили, во главе поставили нового человека, которые сказал: «Теперь здесь будет новый проект – такой, как я придумал, или как предписано центральным офисом, по принципу «Пусть безобразно, но единообразно».

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

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

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

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

Одна из областей нашей основной деятельности – процессы и проекты реорганизации управления ИТ – «ИТ-сервис-менеджмент» и тому подобные вещи. Поэтому познакомимся с некоторыми инструментами.

Инструменты изменений

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

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

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

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

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

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

Джон Коттер, автор методологии, которую мы рассмотрим далее, написал книгу «Наш айсберг тает», «Our Iceberg is Melting». Там наглядно, хорошо и метафорично описано, как изменения начинаются, как они проходят, и как им сопротивляются, и как можно сделать их успешными – и все это проиллюстрировано на примерах колонии пингвинов. Тех, кто сопротивляется изменением, представляет пингвин, которого так и зовут – Но-Но, в смысле, «нет-нет». В проектах тоже бывают люди, которые не скептики, а именно саботажники – «против, потому что против». И это отдельный, очень существенный риск для подобных проектов, это отдельная область внимания для менеджеров таких изменений.

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

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

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

Более того, есть установившиеся власть, порядок и процедуры. Вот это ощущение «мы продолжаем работать, бизнес идет, а вот изменения – это не про нас» является одним из основных источников снижения одного из необходимых условий для успешного проведения крупных изменений, так называемого «ощущения срочности». В модели Джона Коттера восемь шагов. Первый называется как раз «Создание ощущения срочности». Обратите внимание, что книжка, описывающая все эти восемь шагов, чуть-чуть тоньше, чем книжка, которая называется «Sense of Urgency» и посвящена целиком первому шагу. Это большая, интересная и важная тема, связанная с мотивацией, связанная с преодолением сопротивления, связанная с созданием способностей действовать по-новому, но главное – с осознанием потребности.

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

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

Второе – это ощущение ложной срочности, когда начинают бегать, суетиться и говорить: «Давайте, давайте скорей меняться, так жить нельзя» вместо того, чтобы засучить рукава и начать что-то делать.

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

Поэтому бизнес и ИТ работают в режиме «коня налево повернул, а сам направо поскакал». И когда организуется какая-то комплексная автоматизация – это дает совершенно неудивительный результат. Вы знаете, в области ИТ-сервис-менеджмента есть такая маленькая своя религия под названием ITIL – процессная модель про то, как организовать управление ИТ, в основном, операционной деятельностью. Там есть два понятия в отношении услуг, которые ИТ оказывает бизнесу: utility и guarantee, которые в русской редакции звучат как «полезность» и «гарантия». Чтобы объяснить, собственно, суть этих понятий, мы обычно используем такой пример. Utility – это те характеристики услуги или системы, которые обеспечивают функциональность, полезность, соответствие назначению. Фактически, реализация функциональных требований. Guarantee – это те характеристики системы, которые обеспечивают уверенность в том, что utility будет предоставлена в условиях заданных ограничений. На заданном объеме задач, с заданными объемом данных, с заданной производительностью, заданным уровнем безопасности и так далее.

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

А вот тут у нас супер-мега-ERP-система, которая на платиновой поддержке, со всем на свете совместима, сертифицирована для обработки различных типов данных, включая гостайну. Что она еще делает? Она наверняка будет и завтра, и любые внешние изменения переживет. И рост переживет, и новые законодательные требования. Жалко, делает не то. Потому что, когда ее внедряли, команде внедрения вместо бизнес-процессов подсунули, достав из сейфа и отряхнув пыль, описание бизнес-процессов, которые было сделано пять лет назад, когда, допустим, нужно было проходить сертификацию по ISO 9000, и положили в сейф. С тех пор они там и лежали. И команда внедрения честно автоматизировала эти бизнес-процессы. Собственно, это показывается аудиторам, но любые совпадения с реальностью, как говорится, случайны.

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

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

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

Люди как фактор риска
В триединстве people – process – technology более рациональный путь – это договориться с людьми о том, как оптимизировать и автоматизировать эти процессы. Мы довольно часто пытаемся решать эту задачку по принципу «хвост виляет собакой» - например, внедряем какие-нибудь средства автоматизации айтишной деятельности и комплексные системы, полагая, что от них тут же станут лучше бизнес-процессы, а от этого тут же лучше начнут работать люди. И они, конечно, начнут. Через 100-200 лет придет поколение людей, которое по-другому и не может. Но в ближайшие n лет нас ждет серьезное сопротивление людей, которые до этого привыкли работать по-другому и не видят очевидных преимуществ от нового. Среда, не поощряющая риск. Компании, которые стабилизировались, от высших руководителей и до руководителей небольших операционных подразделений, предпочитают не рисковать.

У меня был знакомый ИТ-директор, который, совершенно не иронизируя, ни шутя, не пытаясь спровоцировать обратное поведение, позвал как-то к себе своего заместителя по эксплуатации и сказал: «Вы у себя там навели какой-то порядок поддержки. Теперь статистика по этой поддержке показывает мне, что существенно важным источником инцидентов в нашей ИТ-среде являются криво проводимые изменения. Давайте-ка вы наведете у себя порядок в том, как вы в ИТ проводите изменения. Я не знаю, как вы там у себя это организуете. Меня детали не интересуют. Я – директор. Я не хочу ничего решать. Я хочу следующее. Вот лично твоя, дорогой заместитель, главная метрика с этого момента по части изменений будет такая: 100% отклоненных запросов на изменения при стабильно высокой удовлетворенности заявителей». Изменения – источник опасности. Долой их, в том числе и изменения ИТ-инфраструктуры. Еслои прибегает очередной маркетолог с очередной идеей, мы должны, как у Стругацких, все рацпредложения принимать, хорошо оплачивать и класть под сукно. Более того, ИТ-компания много месяцев такую политику последовательно развивала, с совершенно серьезным лицом. Я не шучу сейчас. Это реальная история, одно из проявлений стремления к минимизации рисков. Информационные технологии должны приносить пользу, не приносить вреда и делать это недорого. Больше ничего от них не требуется. Вот в этом примере главным стало: не приносить вреда, ну и заодно – недорого. Только вот с пользой проблема.

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

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

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

Здесь очень понятная рекомендация: надо по возможности использовать потенциал сторонников, тех, кто заинтересован в изменениях. Также важно стимулировать миграцию толпы безразличных в сторону сторонников. И, конечно, работать с активными сопротивленцами. Сам Коттер при этом говорит, что для работы с ними есть не так много способов: одна стратегия и три тактики. В конечном итоге это сводится к известной поговорке: if you can’t change the people – change the people. Прекрасно переводится на русский, поскольку у нас, в отличие от англичан, есть приставки: «если вы не можете изменить людей – замените людей».

Невозможно рассчитывать, что протестующие постепенно проникнутся и согласятся, или что если дать им возможность возглавить процесс, ситуация изменится. К сожалению, способов гуманного снижения этих рисков очень мало. Чаще всего возникает выбор: либо изменения, либо люди. Хорошая новость: их редко больше 20%. Плохая новость: пятая часть команды будет против, а пятая часть – это много.

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

В теории Левина для нас есть несколько важных тезисов, предположений, наблюдений. Первый: изменение предлагает освоение новых практик и отказ от старых. Практически всегда нам надо разучиться и научиться. Чтобы научиться, надо разучиться. Изменение не может пройти, если мы не хотим (или не умеем). Есть еще один интересный источник, из современной бизнес-литературы – книжка Influencer: The Power to Change Anything. Это очень техничный и технологичный набор рекомендаций, описывающих, как можно попытаться изменить свое или чужое поведение на микроуровне: на уровне людей, команд, себя самого. От «бросить курить» и «научиться пристегивать пассажиров на заднем сиденье», до «по-другому работать» и «изменение бизнес-процессов». Эта методика предлагает некоторую систему, основанную на очень простой матрице (два на три). Утверждается: чтобы люди могли менять поведение, свою деятельность, нужно, чтобы они хотели и могли (motivation и ability) это делать. Motivation и ability, в логике данной модели, реализуется на трех уровнях: personal, social и structure (личном, общественном и структурном). Утверждается, что если мы в своей деятельности по стимулированию изменения поведения (своего или других людей) уделяем внимание как минимум четырем из этих шести составляющих одновременно, то шансы на изменение этого поведения повышаются во много раз – по сравнению с моделью, когда мы сосредотачиваем усилия на одном аспекте, направляю на него шестикратную силу – все, что нужно и для остальных тоже.

Обычно мы уделяем в этой матрице внимание двум вещам. Во-первых, тому, что называется personal motivation: связь личных мотивов субъекта с целями деятельности, на которую мы его пытаемся мотивировать. Это как раз «пристегивайте, пожалуйста, пассажиров, потому что…». Это попытка убедить, что это нужно. Во-вторых, это personal ability – то есть, обучение. Люди должны мочь. Есть еще structure motivation – это то, к чему многие в своей практике и в своем представлении о структуре мотивации сводят саму мотивацию. Это кнут и пряник (премии и штрафы). – «Как вы стимулируете свой персонал?» – «Кнутом и пряником». – «Ну и как?» – «Пряником бить неудобно». Это премии и штрафы.
Но есть и другие аспекты - например, организация среды. Чтобы неудобно было действовать неправильно, а удобно было действовать правильно. Включая наглядную агитацию – допустим, невозможность поехать, пока все не пристегнулись, какой-то автоматизированный контроль.

Social-уровень – наиболее пренебрегаемый, пожалуй. Это вопросы того, что они называют авторитетом («давление близкого окружения»): так принято, так делают значимые люди, так делают лидеры, так делает большинство. Когда наш человек приезжает за рулем в Европу, он неожиданно начинает поворачивать направо из правого ряда, останавливаться перед стоп-линией, пропускать пешеходов, соблюдать скоростной режим. И не только потому, что уровень штрафов на порядок выше, а еще и потому что так там принято. Попробуйте вести себя так за рулем в городе Дели. Это невозможно. Там принято по-другому. Попытка соблюдать правила движения или какую-нибудь разметку, если вы ее там найдете, приведет к ДТП немедленно. А в Москве некое промежуточное состояние.

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

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

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

Распространенный пример аргумента в пользу проекта: «Мы сейчас все замечательно автоматизируем. В результате компания сэкономит 20% за счет сокращения 20% персонала». Как раз 20% персонала и появляется там у нас – те, кто против.

Для успешного изменения требуется закрепление нового поведения в отношении практик. Мало просто научиться. Мало сказать: «По-новому мы делаем вот так. Вот вам пятиминутный тренинг, вот вам на двух страницах инструкция. Вы ведь так и будете делать, да?» – «Ага. Сейчас!» Важно, чтобы новые практики прижились. Для этого тоже надо прилагать усилия. Исходя из этих предпосылок, предположений и наблюдений, мы получаем три очень понятных стадии: unfreezing, transition refreezing. Там модель была немножко позже дополнена, но остановимся пока вот на этих. Разморозка, переход, заморозка.

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

Изменения: разморозить, разогреть, заморозить

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

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

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

Использование управления по целям. Вот на этом этапе может помогать постановка целей и демонстрация возможностей искать пути к нему. Мы пока не навязываем новую практику, но мы стимулируем ее поиск у себя, на стороне людей, наших коллег, которых мы переводим в новое состояние. – «Вот почему плохо так, как сейчас. Давайте искать другие решения». Иногда мы сможем использовать эти решения в новой практике. Здесь очень важный момент: вовлечение в планирование максимального числа сотрудников. Если мы с самого начала привлекаем участников бизнес-процессов, например, к системному дизайну – понятно, что если их тысячи, то это сделать довольно сложно. Но, тем не менее, какие-то возможности для рацпредложений, инноваций, совместные обсуждения проблем стимулируют их подробное выявление и анализ. Создание вот такой инновационной среды помогает рядовым пользователям стать соавторами тех изменений, которые мы введем. Они потом всех остальных порвут, если по их процессу работать не будут. Потому что им не проектная команда навязала, в которой солидные мужчины в костюмах и с зарплатой больше, чем у них всех вместе взятых, а это их собственное изменение, они придумали, что будет так. «Это кнопка имени меня! Кто не пользуется кнопкой имени меня?!»

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

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

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

Создавайте четкие инструкции – что мы, собственно, делаем. Чем более массово это изменение, тем конкретнее нам надо инструктировать исполнителей, не ограничиваясь расплывчатым «давайте мы будем действовать по-другому».

Постепенное обучение, которое очень важно вовремя начать. Как бывает в реальности: «мы сегодня внедрим новую систему, а на следующий квартал для 25% персонала запланировали курсы», или обратный пример: «мы сегодня всех обучили, а через два года, может быть, внедрим новую систему». Все люди, которых мы сегодня обучили, будут иметь очень косвенное отношение к системе через два года. И система изменится, и персонал изменится – в общем, выкинули деньги на обучение зря. Своевременное адресное обучение тому, что нужно, тех, кого надо, тогда, когда надо. Достигнуть такого уровня совершенства очень сложно.

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

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

Об авторе:

Роман Журавлев
Cleverics

Роман отвечает за развитие персонала компании Cleverics.Он работает в области управления ИТ более 10 лет. Автор ряда учебных курсов и статей по управлению ИТ. Автори переводчик книг по управлению ИТ-услугами. Эксперт Форума по ИТ Сервис-менеджменту в России (ITSMF Russia). Преподаватель программ MBA РАНХиГС при президенте РФ и Государственного университета управления.