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