Разбираем, почему ИТ-проекты буксуют не на технологиях, а на сопротивлении пользователей, как нулевой этап помогает подготовить команду к изменениям и почему вовлеченность людей еще до старта внедрения напрямую влияет на результат.
В ИТ-проектах принято тщательно контролировать сроки, бюджет, функциональные требования и интеграции. Но даже при сильной проектной дисциплине результат часто зависит от менее очевидного фактора – насколько команда готова принять изменения.
Когда пользователи не понимают, зачем перестраивается их работа, а на тревоги и сомнения не обращают должного внимания, проект быстро сталкивается с сопротивлением. На бумаге все может идти по плану, но согласования начинают затягиваться, привычные инструменты продолжают использоваться параллельно, а вместо новой рабочей модели компания получает напряжение между бизнесом, ИТ и пользователями.
Именно поэтому до старта внедрения полезно пройти нулевой этап – подготовку команды к изменениям. Это не про технологии. Это про людей, роли, ожидания и внутреннюю готовность, без которой даже хорошо продуманный проект начинает буксовать.
Почему сопротивление возникает почти неизбежно
Любой проект – это изменение привычного порядка работы. Меняются инструменты, процессы, зоны ответственности, а иногда и сами правила принятия решений.
Компании часто предполагают, что достаточно выбрать систему, описать требования и провести обучение. Но на деле пользователи нередко оказываются вовлечены в проект по остаточному принципу: после основной работы, «если будет время». Формально команда участвует, но не воспринимает изменения как свои. В итоге решения зависают, новые процессы не приживаются, а старыми практиками – чаще всего Excel – продолжают пользоваться как ни в чем не бывало.
Это не обязательно саботаж в прямом смысле. Чаще люди просто выбирают понятное и безопасное. Если новая модель выглядит как лишняя нагрузка, потеря влияния или риск не справиться, сопротивление становится естественной реакцией.
Особенно остро это проявляется там, где уже был неудачный опыт внедрений. Тогда любое новое изменение быстро вызывает у команды привычную реакцию: переработки, стресс, хаос и отсутствие результата.
Где на самом деле накапливается напряжение
В проектах обычно говорят о трех уровнях изменений: инструменты, процессы и управление.
С инструментами все относительно понятно: новые формы, сервисы и отчеты можно поддержать обучением. Процессы требуют регламентов и дисциплины. Управление – новых правил принятия решений.
Но наибольшее напряжение возникает не здесь, а на уровне ролей – формальных и неформальных. У каждого подразделения есть люди, на которых реально держится работа. Иногда они не занимают высоких должностей, но обладают уникальной экспертизой или сильным влиянием на коллег. Если таких людей не увидеть заранее, проект рано или поздно столкнется с сопротивлением, которого не было ни в одном плане.
Люди сопротивляются не потому, что хотят помешать проекту. Чаще они защищают свое профессиональное положение. Сотрудник понимает, за что его ценят сегодня, и боится, что новая система обесценит накопленную экспертизу или сделает его роль менее значимой.
Поэтому простое «надо объяснить пользователям» работает не всегда. Если за внешним согласием остаются невысказанные страхи и сомнения, они все равно проявятся – в кулуарных разговорах, затягивании решений и возврате к привычным инструментам.
Что такое нулевой этап
Нулевой этап – это управленческая работа с готовностью команды к изменениям. Его задача – не продавить проект «сверху», а создать условия, при которых пользователи сами включаются в обсуждение будущих изменений и начинают воспринимать их как ответ на свои реальные проблемы.
Речь идет о том, чтобы общение с людьми начиналось еще до классического сбора требований. В этот момент важно не только определить стейкхолдеров, роли и карту изменений, но и понять, что именно мешает подразделениям работать эффективнее и чего они сами ждут от будущего проекта.
Когда это получается, технология перестает быть целью и становится инструментом.
Как это работает на практике
Один из показательных кейсов в моей практике связан с производственной компанией, работающей на международном рынке. У нее был сложный финансовый контур: поступления из разных стран, расчеты в золоте, драгоценных камнях или крипте и сильная зависимость от команды аналитиков, где каждый отвечал за свой регион.
Проблема заключалась в том, что ключевая экспертиза существовала в головах конкретных людей. Процессы менялись, но знания почти не были формализованы. Один из эпизодов это особенно хорошо показал: сотрудница, отвечавшая за Корею, ушла в декрет, и направление фактически остановилось. Чтобы сохранить управляемость, ей пришлось организовать полноценное рабочее место дома.
Компания уже пыталась автоматизировать этот контур силами своей ИТ-команды и внешних подрядчиков. Под задачи бизнеса даже разработали отдельный финансовый блок. Но Excel никуда не делся. Пользователи конфликтовали с ИТ и интеграторами, а затем возвращались к привычным инструментам. Доверие к любым внедрениям оказалось практически исчерпано.
В этой ситуации было решено начать не с новой системы, а с нулевого этапа: провести двухдневную стратегическую сессию до проекта. Принципиально важно, что она не была завязана на обсуждение конкретной платформы или учета. Разговор шел о работе подразделения и о том, что реально мешает людям.
Участники работали в группах с фасилитацией. Им не навязывали готовые решения и не подталкивали к заранее выбранной технологии. Их задача была другой – самим сформулировать, что именно нужно менять, чтобы подразделение работало лучше.
Это быстро вывело разговор за пределы чисто ИТ-повестки. Обсуждали не только процессы и отчетность, но и вполне приземленные вещи: неудобные рабочие места, потери времени на бумажные отчеты, бытовые раздражители. Но именно через такие детали команда вышла на более глубокие проблемы и начала формулировать содержательные решения.
На выходе получились вполне прикладные результаты: карта процессов, список ограничений, перечень улучшений, приоритизированный бэклог, дорожная карта первых шагов и распределение ролей. Но главное было не в этом. Пользователи перестали быть объектом изменений и стали их соавторами.
Что это меняет для проекта
После такой подготовки команда входит в обследование уже в другом состоянии. Люди не ждут, что им в очередной раз принесут чужое решение и попросят «просто работать по-новому». Они сами понимают, какие проблемы хотят решить и чего ждут от изменений.
Это принципиально меняет динамику проекта. Снижается скрытое сопротивление, быстрее идут согласования, а у спонсора появляется возможность показать быстрый результат в первые недели – а это критично для удержания доверия.
В описанном кейсе именно это и стало поворотной точкой. Руководство получило более прозрачный финансовый контур и снизило зависимость от носителей уникальной экспертизы. Но еще важнее было то, что сама команда приняла идею изменений, потому что воспринимала ее как свою.
Почему это важно бизнесу
Нулевой этап не гарантирует, что проект пройдет без сложностей. Но он создает среду, в которой изменения становятся управляемыми.
Когда пользователи включены в процесс осмысленно, снижается уровень конфликтов, команда меньше выгорает, а сам проект перестает быть противостоянием между заказчиком, исполнителем и внутренними подразделениями. Вместо этого появляется ощущение общей работы на результат.
Главный эффект в том, что проект переходит из режима «нам навязали изменения» в режим «мы сами хотим получить результат». А это и есть та точка, с которой обычно начинаются устойчивые изменения.
Чтобы проект не сорвался – начните с людей
Мы не просто внедряем 1С, а готовим команду к изменениям и сопровождаем проект до результата. Узнайте, как работает наш подход на странице Проектного офиса.
