Я длительное время являлся руководителем проекта. Начинал с внедрения информационных систем в организациях первое время работал в маленьких компаниях, состоящих из нескольких сотрудников, затем занимался внедрением комплексных информационных систем в международных корпорациях. От ИТ-проектов перешел к проектам развития бизнеса вплоть до создания с нуля новой организации и отладки всех бизнес-процессов. В процессе реализации всех этих проектов я сталкивался с множеством проблем.
Поначалу мне казалось, что основная сложность при внедрении информационных систем состоит в том, что пользователи, как правило, не способны четко сформулировать свои требования. Это вызывает множество переделок, доработок, изменений бюджетов и т. д. Но ведь клиентов не выбирают, поэтому я стал искать другое решение. Возможно, подумал я, мне как консультанту и руководителю, а также моей проектной команде не хватает навыков работы с пользователями? Или, может быть, я не располагаю достаточными техническими познаниями в области внедряемой технологии? Я попытался изменить ситуацию, уделяя большее внимание квалификации команды и стараясь добиться лучшей структурированности работы с клиентскими запросами. После очередного сложного проекта я собрался силами и прошел обучение в Project Management Institute, получив аттестацию Project Management Professional.
Честно говоря, эти знания о процессах управления проектами, навыки составления подробной проектной документации помогли только в части перекладывания проектных рисков с консультанта на заказчика. Вот устав проекта, вот состав работ, вот изначальный график, план коммуникаций, распределение ответственности А вот, уважаемый клиент, большая папка заявок на изменения, которые были инициированы пользователями в ходе проекта, и папка измененных по разнообразным причинам планов проекта. Так что мы стараемся изо всех сил, но есть объективные причины, которые не позволяют нам уложиться в срок и бюджет. Знакома ли вам эта ситуация? Думаю, что в той или иной мере она привычна для подавляющего большинства работников.
Но что на самом деле мешало внедрять новые системы?
Все эти проекты вызывали, так или иначе, изменения в работе компании. Менялись бизнес-процессы, менялись полномочия людей, их функциональные обязанности, менялся характер их труда. Если раньше кладовщик выписывал накладную от руки и убирал копию в свою папку, то теперь он должен был создавать накладную в программе и печатать ее. Новые условия создают потребность в адаптации к ним.
Теперь нужно уметь пользоваться компьютером, знать, как подобрать товар в накладную, что делать в случае пересортицы или при появлении отрицательных остатков в системе. Помимо новых знаний в организации появляются новые функции: например, теперь вам понадобится сотрудник поддержки программы, который будет оперативно решать сложные вопросы от неисправности программы до устранения пользовательских ошибок. Появление новых функций и обязанностей фактически вызывает пересмотр иерархической матрицы в компании. Это заметно даже на таком простом примере, как внедрение программы складского учета. А теперь представьте себе, что происходит в случае внедрения крупных корпоративных систем. Нередко параллельно с внедрением идет процесс реинжиниринга бизнес-процессов и их оптимизация. Это не только касается изменения характера труда, но и заставляет пересматривать структуру управления компанией.
Главные проблемы в таких проектах, которые и увеличивают сроки в два-три раза, равно как и бюджеты, отнюдь не технические сложности, не квалификация команды консультантов или уровень пользователей. Основная проблема это реакция сотрудников на перемены.
Достаточно часто мне приходилось наблюдать такую ситуацию. Некоторое время пользователи делают вид, что инициативы начальства их не касаются, у них нет времени и желания изучать новые технологии. Через некоторое время появляются те, кто начинает присматриваться, интересоваться, что мы делаем. Но как только пытаешься на них опереться, начать их учить и делать из них ключевых пользователей системы, так сразу видно, как коллеги начинают их всячески отговаривать.
Такое поведение можно хорошо проиллюстрировать известным феноменом ведра раков. Если раков в ведре много, то его можно не закрывать, так как они не дадут друг другу выбраться из него. Если один рак начинает карабкаться вверх, другие его хватают, пытаются взобраться по нему, и в итоге все раки остаются в ведре.
Та рациональная часть проекта, которую мы обычно видим, это всего лишь макушка айсберга. А его основная часть, скрытая под водой, это наши привычки, страхи, сомнения, наши эмоции и переживания. Именно эта подводная, человеческая часть и сопротивляется переменам: мы не в состоянии моментально адаптироваться к новым условиям. Для того, чтобы начать адаптироваться, изменения необходимо принять.
Далее мы подробно рассмотрим процесс принятия изменений на примере кривой Кюблер-Росс (Kübler-Ross, 1997), а сейчас приведем небольшой пример из животного мира, объясняющий природу сопротивления изменениям.