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

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

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

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

В этой статье пресейл-инженеры Sarex, Ирина Семёнова и Дарья Демьянова, поделятся ключевыми причинами, по которым внедрение нового ПО в компаниях оборачивается саботажем сотрудников, а также практическими решениями для их отработки.

Причина 1. Логика процессов не зафиксирована до настройки системы

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

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

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

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

Причина 2. Нет закрепленного за системой администратора

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

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

Чаще всего эту функцию берут на себя BIM-менеджер, ИТ-специалист или планировщик, при условии, что зона ответственности закреплена и не рассматривается как второстепенная задача.

Причина 3. Массовый запуск до окончания настройки системы ‍

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

Для проектной команды это означает отсутствие стабильных правил. Такая неопределённость воспринимается как риск. В ответ сотрудники возвращаются к привычным инструментам, потому что они привычны предсказуемы.

Причина 4. Ожидание, что система «сама приживется» 

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

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

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

Причина 5. Универсальное обучение «по всем функциям»‍

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

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

Причина 6. Отсутствие регламентов ‍

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

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

Причина 7. Одинаковый подход к сотрудникам и подрядчикам

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

‍

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

Причина 8. Игнорирование группы скептически настроенных сотрудников‍

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

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

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

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

Причина 9. Отсутствие быстрых и наглядных результатов‍

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

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

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

Причина 10. Отсутствие активной управленческой позиции руководства

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

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

Причина 11. Отсутствие поддержки в первые недели после запуска‍

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

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

Причина 12. Не проводится измерение использования системы‍

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

Это позволяет вовремя корректировать процессы и повышать ценность инструмента для всей команды.

Что в итоге действительно работает‍

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

Только при такой последовательной работе новое ПО становится инструментом координации и контроля, а не формальной частью «цифровой повестки».