Цифровизация в строительстве: как сделать цифровую трансформацию управляемой

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

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

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

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

Как этого избежать? Разберем ситуацию детальнее.

Часть 1. Вертикаль: возвращение к истокам

Давайте честно, мы часто слишком рано начинаем говорить о технологиях. Ключевой тезис, который я повторяю везде: цифровизация — это не первый шаг, а последний.

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

1. Цифровизация ради отчетности
   Создание «цифрового фасада». Когда данные собираются не для принятия решений на местах, а в лучшем случае для красивых отчетов и графиков для заказчика или руководства.
   Последствия: двойная работа, цинизм сотрудников, технологии как обуза.
   Цена: инвестиции в «картинку», а не в эффективность.
2. Цифровизация без ответа на вопрос «Зачем?»
   Внедрение модного инструмента/технологии потому что «уже пора», «данность времени», а не потому что есть четкая бизнес-задача.
   Последствия: инструмент дискредитирован, процессы не улучшены, бюджет потрачен.
   Цена: прямые затраты на лицензии и обучение, которые не дали отдачи.
3. Оцифровка хаоса
   Перенос неэффективных, запутанных бумажных процедур в цифровую среду без их реинжиниринга.
   Последствия: хаос получает «вечную цифровую жизнь», ускоряется и масштабируется.
   Цена: в лучшем случае — упущенная выгода от невозможности упрощения процессов.
4. Дом без фундамента
   Попытка внедрить сложные цифровые инструменты при отсутствии базовых стандартов, регламентов и измеримых целей.
   Последствия: технологии не работают или внедряются вечно, так как нет для них «почвы».
   Цена: крах пилотного проекта, после которого все говорят «цифровизация не для нас».
5. Лоскутная цифровизация
   Независимое внедрение разных систем по департаментам или даже внутри одного. Отсутствие сквозной связи между ними, образование «цифровых островов».
   Последствия: разобщенность данных, ручной труд на стыках, невозможность получить целостное представление о проекте.
   Цена: недополученная прибыль из-за ошибок, срывов сроков и неоптимальных решений.

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

Но даже если вы блестяще выстроили работу внутри каждого отдела, при комплексном рассмотрении деятельности организации, некоторые ловушки остаются за кадром.

Часть 2. Горизонталь: почему данные не доходят до адресата

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

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

Такие разрывы не только съедают часть рабочего времени инженеров, но и приводят к ошибкам, которые трансформируются в ощутимые убытки особенно на стадии СМР.

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

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

Поэтому все чаще запросы от чутких руководителей звучат в духе:

• «Хочу, чтобы задача в ГПР была связана с документацией или с процессами в среде общих данных»
• «У нас оцифровано МТО, но есть проблема с достоверностью объемов из документации»
• «Нужен актуальный еженедельный отчет, но журналы работ ведутся в бумаге, а график в MS Project»

Можно еще вспомнить про BIM/ТИМ‑модель, которая в лучшем случае становится музейным экспонатом после прохождения экспертизы. Но именно информационная модель может стать основой всех проектных данных вплоть до эксплуатации.

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

• Проектная документация
• Снабжение объекта
• Строительный контроль
• Ведение журналов работ
• Ведение графиков строительства
• Аналитика для руководства в сжатые сроки

Выделим три системные причины:

Причина первая. Данные не машиночитаемы

Самая тонкая, но критичная причина. Думаю, понятно, что смета в PDF — это не данные, а картинка. График в Excel с цветными ячейками — тоже не данные, пока он не имеет строгой структуры. Чтобы информация перетекала автоматически, она должна быть машиночитаемой (XML, IFC, структурированные форматы). Иначе на стыках все равно будет ручной ввод.

Причина вторая. Разная цифровая зрелость

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

Хорошо если Заказчик продвинутей остальных участников цепочки, но если наоборот — подрядчикам, генподрядчику навязать свои процессы вряд ли удастся.

Причина третья. Лоскутная цифровизация

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

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

В таких случаях данные неизбежно стыкуются между собой вручную.

Часть 3. Инструкция: как не заблудиться в двух измерениях

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

Шаг 1. Нарисуйте карту потоков данных (а не список ПО)

Забудьте на время про программы. Возьмите лист бумаги и ответьте на вопросы:

• Где рождается информация? (смета, планировка, предписание, заявка на материалы)
• Кто ее создает и использует дальше?
• В каком формате она передается?
• Где происходит транспорт данных в ручном режиме?

Вы удивитесь, сколько «ручных стыков» вы найдёте. Каждый такой рубеж — это потеря времени, риск ошибок и источник хаоса в будущем.

Шаг 2. Вернитесь к истокам: лечите процессы, а не симптомы

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

Ответьте на три вопроса:

1. Какую конкретную боль снимаем?
   • Сформулируйте одну ключевую метрику, которая улучшится. Например: «Сократить время согласования изменений с 10 дней до 3», а не «внедрить систему документооборота»
   • Найдите «крайнего» — человека или процесс, который является источником этой боли (например, ГИП, тонущий в бумагах)
   • Спросите: решит ли выбранный инструмент именно эту проблему для этого человека?
2. Что готовы изменить в процессах и людях?
   • Нарисуйте целевую схему процесса в 3 шага. Как должна выглядеть идеальная процедура после внедрения?
   • Проверьте на «цифровой мусор»: есть ли в новой схеме этапы «распечатать», «подписать», «загрузить в другую систему»? Если да — вы начинаете оцифровывать хаос
   • Посчитайте «цену изменений»: сколько часов обучения нужно? Чьи полномочия изменятся? Кто может саботировать и почему? Если ответа нет — вы игнорируете человеческий фактор
3. Как измерим успех и что сделаем с результатами?
   • Определите 2-3 ключевых показателя (KPI), напрямую связанных с болью из Вопроса 1. Они должны быть простыми: количество переделок, время простоя техники, процент отклонения от сметы
   • Назначьте ответственного за каждый показатель. Кто будет смотреть на дашборд и что он должен сделать, если цифры «пошли не туда»?
   • Заранее опишите сценарии: Если через 3 месяца время согласований не сократилось на 30%, мы... (разбираем процесс заново / меняем ответственного / отказываемся от инструмента)

Помните, если нельзя измерить — нельзя управлять. Цель — не отчитаться о внедрении, а получить данные для новых действий.

Шаг 3. Стройте мосты между островами

Когда алгоритм «Боль -> Новый процесс -> Измерение» отработан, пришло время обратить внимание на существующие цифровые инструменты.

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

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

Иногда — набор инструментов, которые умеют «разговаривать» друг с другом через APIAPI (Application Programming Interface — программный интерфейс приложения) — это набор правил, инструментов и протоколов, который позволяет одной компьютерной программе взаимодействовать с другой, обмениваясь данными и функциями. и имеют более чем понятные возможности по экспорту/импорту данных.

Имея на руках понятные схемы процессов (в том числе взаимодействия с заказчиком/подрядчиком), потоков данных и текущего ИТ-ландшафта, вопросы к поставщику софта сами лягут на белый лист бумаги.

Шаг 4. Начинайте с малого, но сквозного

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

• Отслеживание динамики и контроль выполнения работ с учетом всех участников проекта в ГПР
• Подписание и передача актуальной и достоверной документации в производство работ

Настройте его так, чтобы он шел без ручного труда. Когда результат по процессу будет как минимум удовлетворительным (например, сроки не увеличились) — масштабируйте подход на стыки «До» и «После» этого процесса.

Но идеальное развитие событий, если сначала вы придете к среде общих данных.Среда общих данных (СОД) — это цифровое пространство, где хранится, обрабатывается и согласуется вся инженерно-техническая документация. Такая среда объединяет всех участников строительного проекта — от заказчиков до исполнителей — и обеспечивает прозрачность на каждом его этапе. Благодаря СОД документы хранятся упорядоченно, замечания проставляются и отрабатываются централизованно, а согласования проходят по автоматизированным маршрутам.

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

СОД — это цифровой «штаб» вашего проекта для централизованного управления строительной информацией на протяжении всего жизненного цикла объекта.

Шаг 5. Назначьте «смотрителя»

Еще один важный винтик в экосистеме трансформаций — ответственный за этот процесс человек.

В идеале в компании должен быть сотрудник (или команда), который отвечает не за внедрение отдельной программы, а за целостность и транзит данных. Он следит, чтобы стандарты соблюдались, чтобы новые системы не создавали новых разрывов, чтобы люди не саботировали изменения. Можно назвать его администратором, или координатором, если хочется громкого слова — «IT‑евангелистом».

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

Вместо заключения

У нас есть два измерения. По вертикали — глубина проработки каждого процесса, честные ответы на вопрос «зачем». По горизонтали — связность, среда общих данных, закрытые разрывы в потоках данных.

Если вы занимаетесь только вертикалью, вы рискуете создать идеально работающие, но изолированные друг от друга острова стабильности. Если вы занимаетесь только горизонталью (покупаете суперплатформу), но не навели порядок в процессах, вы просто оцифруете хаос в масштабе всего проекта или компании.

Цифровая трансформация — это одновременная работа в двух измерениях. Это умение видеть и дерево (конкретный процесс), и лес (связи между ними). Это готовность менять не только цифровые инструменты, но и людей, и правила игры.

P.S.

И последнее, о чем редко говорят, но что является критически важным.

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

И вот тут наступает момент истины.

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

А правильный сценарий — третий.

Негативный результат внедрения — это тоже результат. Это не провал, это данные. Это обратная связь от реальности, которую вы сами создали.

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

Или внесли изменения в бизнес-процесс не на том этапе, или не учли человеческий фактор, или инструмент не решает ту проблему, которую вы планировали закрыть.

У вас есть выбор: либо честно разобрать, что пошло не так и скорректировать курс, либо сделать вид, что все в порядке, и через год купить другую систему, которая «точно поможет».

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

Поэтому, когда вы запускаете проект, заранее пропишите сценарий: «Если через N месяцев ключевой показатель не вырос на X%, мы...» — возвращаемся к исходной точке, пересматриваем процесс, меняем ответственного.

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

Это не катастрофа, это просто данные. Главное — сделать из них выводы. И идти дальше.