Журнал «Отинофф»

По каким признакам остановить неудачный пилот: разбор для строительной компании

Строительство 10 авг. 2026 г.

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

Источник: mckinsey.com

Эта неопределённость стоит денег. Пока пилот «висит», компания платит за подписку, тратит часы ключевых людей и откладывает решение. Хуже всего не неудачный пилот, а пилот без критериев остановки — он может тянуться годами. Ниже — практический разбор: по каким признакам понять, что пилот провалился, как отличить временные трудности от системного провала и что сделать на этой неделе, чтобы не потерять ещё один квартал.

Что именно происходит, когда пилот «не взлетает»

Строительная отрасль сейчас активно осваивает цифровые инструменты: управление проектом, предпроектная координация, работа с данными, отчётность в реальном времени. Крупные отраслевые площадки — библиотека Procore, ресурсы Autodesk Construction, исследования McKinsey по инжинирингу и строительству — публикуют десятки материалов о внедрении таких решений. Характерно, что заметная часть этих материалов посвящена не самим технологиям, а именно внедрению: как добиться принятия инструмента командой, как обеспечить «единый источник правды» по проекту, как не потерять данные между отделами.

Это косвенно подтверждает главный факт: проблема почти никогда в самом инструменте. Пилоты в стройке чаще всего умирают по трём причинам:

  1. Инструмент не встроился в реальный процесс. Прораб заполняет бумажный журнал, а потом «когда-нибудь» переносит данные в систему. Двойная работа убивает любой пилот за месяц.
  2. Никто не назначен владельцем результата. Есть «ответственный за внедрение», но нет человека, который отвечает за конкретную цифру: сокращение времени на согласование, уменьшение числа переделок, скорость отчётности.
  3. Критерии успеха не зафиксированы до старта. Без них любой результат можно объявить «промежуточным», и пилот живёт вечно.

Почему это вопрос денег, а не технологий

Для небольшой компании неудачный пилот — это не абстрактная «цифровая трансформация не удалась». Это конкретные потери:

Что меняется Почему важно бизнесу Что проверить
Подписка и настройка продолжают оплачиваться Прямой расход без отдачи, 3–12 месяцев впустую Сколько уже потрачено и сколько будет стоить ещё один квартал
Ключевой сотрудник занят «внедрением» Его часы вынуты из реальной работы на объекте Сколько часов в неделю уходит на пилот у каждого участника
Команда видит очередной «проект, который заглох» Падает доверие к следующим инициативам Сколько пилотов за последние два года дошли до рабочего режима
Решение по процессу откладывается Конкуренты получают преимущество в скорости и контроле Какую задачу пилот должен был решить и решается ли она иначе

Отдельный риск — репутационный. Отраслевые материалы прямо подчёркивают: репутация подрядчика строится годами и разрушается быстро. Если пилот затрагивает данные по объекту или отчётность перед заказчиком, затянувшийся хаос виден не только внутри компании.

Семь признаков того, что пилот пора остановить

Ниже — рабочие признаки, которые владелец может проверить без привлечения IT-специалистов. Это практическая рамка, а не цитата из какого-либо одного источника.

  1. Прошёл установленный срок, а критерии успеха так и не сформулированы. Если на старте не записали «через 8 недель время на X сократится с A до B», остановитесь и зафиксируйте критерии сейчас — или закрывайте пилот.
  2. Данные в системе отстают от реальности больше чем на неделю. Отраслевые материалы по отчётности подчёркивают: у строительной информации есть срок годности. Если прораб узнаёт о коллизии утром, а в системе она появится через месяц, инструмент не работает.
  3. Пилот живёт на одном энтузиасте. Уберите этого человека на две недели (отпуск, другой объект). Если процесс встал — внедрения не было, была личная подпорка.
  4. Команда ведёт двойной учёт. Бумага плюс система, Excel плюс платформа. Двойная работа дольше 4–6 недель означает, что процесс не перестроен.
  5. Никто из руководителей не смотрит в систему для принятия решений. Если совещание по-прежнему идёт по распечаткам и устным докладам, инструмент — декорация.
  6. Стоимость владения растёт быстрее пользы. Дополнительные лицензии, доработки, обучение — а измеримого эффекта в деньгах или часах нет.
  7. Поставщик или внутренний владелец отвечает на вопросы об эффекте обещаниями. «Вот после следующего обновления» — это не результат.

Важно отличать эти признаки от нормальных стартовых трудностей. Первые 2–4 недели сопротивление команды и неполные данные — обычное дело. Тревожный сигнал — когда те же проблемы сохраняются на втором и третьем месяце без динамики.

Где ломается даже хороший план

Даже с критериями и владельцем пилот может провалиться по причинам, которые стоит признать честно:

  • Выбран не тот процесс. Пилотировать цифровой инструмент на самом сложном и политически чувствительном процессе (например, на взаиморасчётах с субподрядчиками) — почти гарантированный провал. Отраслевые материалы по внедрению цифровых инструментов на капитальных проектах рекомендуют начинать с управляемого, понятного участка.
  • Данные для пилота не существуют. Если проектная документация живёт в почте и личных папках, «единый источник правды» не появится от покупки платформы — сначала нужна минимальная дисциплина хранения.
  • Ожидания завышены маркетингом. Материалы вендорских библиотек полезны, но написаны производителями решений. Их стоит читать как описание возможностей, а не как гарантию результата в вашей компании.
  • Пилот остановлен слишком поздно. Самая дорогая ошибка — не закрытый пилот, а пилот, который «ещё немного подожжём» третий квартал подряд.

Что сделать на этой неделе

Если у вас сейчас идёт пилот — или вы планируете его на этапе проектирования — выполните эту проверку:

  • [ ] Запишите на одной странице: какую задачу решает пилот, в каких единицах измеряется успех (часы, дни, рубли, число переделок), какой срок — дата решения «продолжаем или закрываем».
  • [ ] Назначьте владельца результата — не «ответственного за внедрение», а человека, который отвечает за цифру.
  • [ ] Проверьте свежесть данных: когда в системе появилась последняя реальная запись с объекта? Отставание больше недели — красный флаг.
  • [ ] Посчитайте полную стоимость пилота: подписка, часы сотрудников, обучение, доработки. Сравните с измеримым эффектом.
  • [ ] Проведите тест «без энтузиаста»: спросите, что произойдёт с процессом, если ключевой человек уйдёт на две недели.
  • [ ] Если признаков провала три и больше — назначьте дату закрытия и зафиксируйте уроки: что именно не сработало — инструмент, процесс или данные.

Безопасный первый пилот для небольшой компании выглядит так: один объект, один узкий процесс (например, фиксация замечаний и коллизий на этапе проектирования), 6–8 недель, два-три измеримых критерия, заранее назначенная дата решения. Такой формат ограничивает убыток и даёт честный ответ.

Источники

Что почитать дальше

Теги

Андрей Отинов

Рекомендуем