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