Kitobni o'qish: «Когда и почему ТИМ приводят к "Зоопарку софта" - Часть 1; Часть 2 и Часть 3»

Содержание

Содержание и назначение частей книги 3

Введение. Как читать эту книгу вместе с ИИ 3

У каждой части книги – своя задача: 3

Введение в ASIC Book — AI Snacks Knowledge Base 4

Кому нужна эта книга 4

Какой ресурс экономит этот формат 4

Как работать с книгой вместе с ИИ 5

Пример первого запроса к ИИ 5

Перекрёсток пониманий 5

От книги монолога к командной работе 5

Итог 6

Глава 1. Как строители пытаются надеть опыт СССР на современное управление инвестиционно-строительными проектами 7

1. От документной архитектуры СССР к информационной архитектуре ТИМ 7

2. Сравнительная матрица управления строительным проектом 9

Меняется архитектура управления 10

Проект учится постоянно видеть отклонения 10

Новая функция инструментов ТИМ, которая пока не используется из-за нехватки компетенций в цифровом управлении проектами 10

От абсолютной геометрии к динамической информационной модели (от 3D к 4D и 5D ISO 19650) 11

Информационное наращивание и прогноз 11

Новая мера качества цифрового управления 11

Вывод о динамической модели 12

3. Человеческий фактор в архитектуре управления 12

3.1 Человек как субъект и локальный центр управления 12

3.2 Коллектив и команда 13

3.3 Почему стандарты ISO иногда остаются на бумаге 13

3.4 От описания поведения к алгоритму 13

3.5 От агрегатного состояния документа к цифровому состоянию объекта 14

3.6 Новая роль эксперта в ТИМ 14

3.7 Оперативный тактический и стратегический уровни 14

Вывод о человеческом факторе 15

4. Формирование технического задания 15

5. Скорость подготовки технического задания 16

6. Проектирование по специальностям 16

7. Ошибки проектирования 17

8. Формирование локальных смет 17

9. Передача производственного знания рабочим 18

10. Скорость обнаружения отклонений и управленческой реакции 19

11. Как цифровизация старой цепочки создаёт «зоопарк софта» 19

Итоги части 1 21

Содержание и назначение частей книги

Введение. Как читать эту книгу вместе с ИИ

Эта книга допускает обычное чтение от первой страницы до последней. Однако её настоящая работа начинается в диалоге:

Текст становится не финишем мысли, а местом её следующего запуска.

У каждой части книги – своя задача:

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

Часть 2 помогает поставить диагноз. Читатель проверяет, действительно ли симптомы совпадают с практикой его организации, и составляет карту признаков:

функциональные колодцы;

ручные переходы между системами;

отсутствие единых идентификаторов;

несовпадение статусов;

раздельные BIM, ERP, ПТО, график и FACT;

зависимость от Excel и человеческой интерпретации.

Часть 3 переводит диагноз в действие. Она помогает подготовить операцию по трансформации организации. Читатель проходит описанные шаги, получает собственный анализ и готовит доклад о том, что именно не связывается в его ТИМ. Такие доклады могут пополнять общую Библиотеку знаний. В Части 3 рассматриваются:

этапы интеграции ЦИМ;

роли и ответственность;

входные данные;

контрольные точки;

типовые ошибки;

ожидаемые результаты;

критерии готовности компании.

Конкретная настройка этой схемы под организацию остаётся отдельной задачей методического консалтинга.

Введение в ASIC Book — AI Snacks Knowledge Base

Самая объективная и экспериментальная книга — AI Snacks Knowledge Base

Книга создана в формате «ASIC Book — AI Snacks». В её основу легли 98 практических кейсов «АйБиПи-Петербург» в строительстве, реализованных в 2014–2025 годах и связанных с внедрением автономного цифрового аудита строительных площадок.

Методология, структура и ключевые тезисы принадлежат автору. Модель G AI Snacks адаптировала стиль изложения, объединив системность и ясность Филипа Котлера и Рэймонда Чандлера.

Искусственный интеллект в среде ЦИМ использован для анализа и синтеза алгоритмов, закономерностей, результатов и накопленных знаний.

Кому нужна эта книга

Эту книгу можно читать подряд. Но замысел у неё другой: она должна работать рядом с читателем как профессиональная база знаний, к которой можно обращаться через ИИ-помощника.

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

ASIC BooK действует иначе. Автор собирает опыт, выделяет повторяющиеся закономерности, определения, модели, причинно-следственные связи и практические выводы. Из массива информации извлекается активная часть, способная изменить решение. Эту часть мы называем Знанием.

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

Автор → структурированное Знание → ИИ ↔ Читатель → Практическое решение

Какой ресурс экономит этот формат

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

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

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

Как работать с книгой вместе с ИИ

Шаг 1. Загрузите книгу в ИИ-профиль или рабочее пространство.

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

Шаг 2. Получите информационную карту книги.

Попросите ИИ подготовить короткое резюме, выделить десять главных тезисов, основные модели и ключевые выводы.

Шаг 3. Не просите ИИ только подтверждать ваши взгляды.

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

Шаг 4. Постройте перекрёсток пониманий.

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

Шаг 5. Используйте конфликт для получения нового знания.

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

Пример первого запроса к ИИ

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

Перекрёсток пониманий

Позиция автора → аргументы → модель → предполагаемый результат.

Позиция читателя → практический опыт → аргументы → модель → предполагаемый результат.

Пересечение → совпадения → различия → причины конфликта → вопросы для проверки → данные → возможный синтез.

Культура иных точек зрения в ASIC Book: «Я не согласен с вашей точкой зрения, но она сделала меня ещё на один взгляд богаче».

От книги монолога к командной работе

Книга перестаёт быть монологом автора и становится местом профессиональной дискуссии между Автором, Читателем и ИИ.

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

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

Обычная цепочка:

Автор → Книга → Читатель

Рабочая цепочка ASIC BooK:

Автор → Знание → ИИ ↔ Читатель → Конфликт пониманий → Анализ → Новое знание → Решение

Итог

Соглашаться с этой книгой необязательно. Полезнее заставить её спорить с вашим опытом. ИИ делает такой спор быстрым, системным и пригодным для практической работы.

В этом состоит назначение ASIC BooK / AI Knowledge Base: читатель получает структурированную базу знаний, которую можно подключить к ИИ и использовать для анализа, обучения, проверки гипотез и подготовки профессиональных решений.

Глава 1

Как строители пытаются надеть опыт СССР на современное управление инвестиционно-строительными проектами

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

1. От документной архитектуры СССР к информационной архитектуре ТИМ

В СССР строительство служило одним из главных инструментов экономического развития. Огромный объём капитального строительства требовал развитой системы стандартов, планирования, проектирования и административного контроля.

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

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

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

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

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

Здесь проходит граница между цифровизацией старой документной системы и ТИМ как информационной архитектурой управления. Цифровая трансформация меняет не носитель, а механизм формирования и движения управленческой информации. В ТИМ сведения изначально существуют как структурированные цифровые данные, связанные с требованиями проекта. Алгоритмы, аналитические модели и ИИ читают эти связи, выполняют расчёты, выявляют отклонения и готовят информацию для управленческого воздействия без обязательного человеческого перевода на каждом переходе. Человек не исчезает. Он перестаёт быть курьером между документами и поднимается на более высокий уровень: ставит требования, контролирует качество данных, анализирует исключения и отклонения, проверяет модели и принимает решения.

Определение 2. ТИМ как информационная архитектура. Информационная архитектура управления ИСП, в которой структурированные данные связаны с требованиями, объектами и процессами и пригодны для непосредственной обработки алгоритмами, аналитическими моделями и ИИ.

2. Сравнительная матрица управления строительным проектом

Возьмём условный объект площадью 10 000 м² и пять основных групп проектных дисциплин: АР, КР, ОВиК, ВК и ЭОМ/СС. Числовые диапазоны ниже — авторский сравнительный benchmark, а не государственные нормативы. Они нужны, чтобы увидеть различие архитектур, а не создать иллюзию абсолютной точности.

Показатель

Традиционная модель СССР / документное управление

Современная ТИМ/BIM-модель

Изменение

Первичная информация для ТЗ

≈25–40 отдельных справок, заданий, ТУ, ведомостей и источников

≈10–20 структурированных информационных пакетов / наборов данных

До –40–60% ручных информационных входов

Обработка информации для ТЗ

≈20–40 дней

≈5–15 дней при наличии цифровых исходных данных

Примерно в 2–4 раза быстрее

Проектирование основных специальностей

≈4–8 мес.; значительная часть обмена последовательная

≈2,5–5 мес.; параллельная разработка и координация моделей

–25–45% времени

Ошибки / коллизии проектной информации

Расчётный индекс 0,030 ошибки/м²; ≈300 на 10 000 м²

После BIM-координации 0,012 ошибки/м²; ≈120

Модельное снижение ≈60%

Подготовка локальных смет

≈15–30 дней

≈3–10 дней при связанной модели объёмов и классификаторов

–50–80% времени

Подготовка рабочих к процессу

≈1–3 мес. передачи опыта, инструктажей и освоения документации

≈0,5–1,5 мес. при цифровых ТТК, визуализации и структурированных заданиях

Ориентировочно –30–50%

Риск отклонения срока до обнаружения

≈15–30 дней

≈1–7 дней при регулярном план-факт-контроле

Окно реакции сокращается в 3–15 раз

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

Меняется архитектура управления

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

Проект учится постоянно видеть отклонения

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

В процесс снова входят проектировщики, ПТО, сметчики, планировщики, производители работ и руководство. Изменение бывает небольшим. Совещание — полноценным.

Информационная модель действует иначе:

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

Так проект постоянно сопоставляет текущее состояние с исходным планом. Отклонение не ждёт, пока вокруг него соберут новую человеческую цепочку.

Новая функция инструментов ТИМ, которая пока не используется из-за нехватки компетенций в цифровом управлении проектами

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

Срок, объём, ресурс, стоимость, последовательность работ или FACT изменились. Система определяет затронутые параметры, показывает отклонение и готовит основу для решения.

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

От абсолютной геометрии к динамической информационной модели (от 3D к 4D и 5D ISO 19650)

На ранних этапах BIM внимание приковано к точной геометрии и объёмам. Проектированию это необходимо. Управлению инвестиционно-строительным проектом этого недостаточно.

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

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

План₀ → Факт₁ → Отклонение₁ → Коррекция₁ → Прогноз₁ → План₁ → Факт₂ → Отклонение₂ → Коррекция₂ → Прогноз₂ → …

В такой архитектуре модель перестаёт быть фотографией проекта. Она становится системой, которая помнит план, видит FACT и помогает готовить следующее действие.

Определение 5. Динамическая цифровая модель. Модель, которая изменяется вместе с фактическим состоянием проекта и поддерживает непрерывный цикл: План₀ → Факт₁ → Отклонение₁ → Коррекция₁ → Прогноз₁ → План₁ → …

Информационное наращивание и прогноз

Следующий уровень зрелости BIM/ТИМ начинается за пределами геометрии. Система управляет информационным наращиванием, отклонениями и прогнозом изменения ресурсов во времени.

Новое фактическое состояние не должно оставаться мёртвым отчётом. Оно уточняет план-факт, показывает последствия, создаёт ограничения и даёт менеджеру основу для корректирующего воздействия.

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

Новая мера качества цифрового управления

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

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

Определение 6. Информационное расстояние. Разрыв между текущим фактическим состоянием физического объекта и состоянием, которое в данный момент отражает цифровая модель.

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

Старая парадигма

Новая парадигма ТИМ

Точность документа и модели на момент выпуска.

Скорость актуализации модели после изменения физического мира.

Повторный человеческий пересчёт и согласование после изменения.

Данные → отклонение → автоматический анализ связей → прогноз → подготовленная информация → решение.

Вывод о динамической модели

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

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

Определение 4. Трансформация информации. Последовательное преобразование: Информация → структурированные данные → анализ → знание → решение → воздействие.

3. Человеческий фактор в архитектуре управления

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

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

3.1 Человек

как субъект и локальный центр управления

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

Определение 3. Человек как информационный интерфейс. Участник процесса, который вручную получает информацию, интерпретирует её, преобразует в другую форму и передаёт следующему участнику или системе.

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

Внутри процесса появляются два центра управления. Первый защищает цель, стандарт и результат организации. Второй опирается на опыт сотрудника, его привычки, отношения и локальное решение.

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

3.2 Коллектив

и команда

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

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

Команда в современной процессной модели объединена общей целью, определёнными ролями, ответственностью, правилами взаимодействия и измеримым результатом.

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

3.3 Почему

стандарты ISO иногда остаются на бумаге

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

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

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

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

3.4 От

описания поведения к алгоритму

Сначала организация описывает поведение сотрудника: получил документ → проверил → заполнил форму → согласовал → передал → отчитался.

Человек начинает исполнять заранее сформулированный алгоритм. И тогда появляется неудобный вопрос: если последовательность уже описана как повторяемое правило, зачем каждый раз использовать человека как механизм её выполнения?

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

Определение 9. Стандартизация процесса. Формализация повторяемых состояний, событий, правил переходов, ограничений и результатов процесса, а не только описание требуемого поведения сотрудника.

3.5 От

агрегатного состояния документа к цифровому состоянию объекта

Управлять нужно не формулировкой «Иванов должен до пятницы проверить документ», а наблюдаемым состоянием объекта:

получен → проверен → согласован → отклонён или утверждён → передан → исполнен.

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

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

Вопросы «кто получил», «что сделал» и «почему задержал» уступают цепочке:

объект → статус → событие → ресурс → ограничение → действие → следующий статус → результат.

Определение 10. Цифровое состояние информационного объекта. Формализованное состояние документа, модели, задания, заявки, работы или другого информационного объекта, определяемое статусом, событиями, условиями и правилами перехода. Базовая конструкция: Объект → Статус → Событие → Ресурс → Ограничение → Действие → Следующий статус → Результат.

3.6 Новая

роль эксперта в ТИМ

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

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

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

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

3.7 Оперативный

тактический и стратегический уровни

Оперативный уровень: стандарт → технология → инструкция → алгоритм → предусмотренное действие. Цифровая модель использует формализованные правила и не создаёт лишних человеческих переходов.

Тактический уровень: отклонение → анализ причин и последствий → допустимые варианты → эксперт → выбор. Здесь человек отвечает за решение в условиях вариативности и неполной определённости.

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

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

Вывод о человеческом факторе

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

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

ТИМ делает следующий шаг. Человек перестаёт быть операционным мостом между документами и становится владельцем требований, качества, отклонений, исключений и решений.

Развитие архитектуры выглядит так:

человек выполняет процесс → стандарт описывает действия → алгоритм исполняет повторяемую часть → система контролирует состояния и отклонения → человек принимает тактические и стратегические решения.

Первый переход:

документ → данные.

Второй переход:

человек как интерфейс → алгоритм как интерфейс.

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

4. Формирование технического задания

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

Для условного объекта 10 000 м² примем 25–40 самостоятельных информационных входов. При ТИМ сведений может быть даже больше. Различие скрыто не в количестве, а в способе их существования и движения.

Традиционная цепочка:

документ → инженер → интерпретация → ТЗ. Цифровая цепочка: требование → структурированные данные → информационное требование → ТЗ/модель.

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

5. Скорость подготовки технического задания

При документной архитектуре новый источник информации запускает ещё одну проверку и согласование. В расчётной модели полный цикл формирования ТЗ занимает 20–40 дней. Общая цифровая среда и структурированные исходные данные могут сократить его до 5–15 дней. Если BIM появляется только после подготовки ТЗ, информационная архитектура ещё не изменилась. Настоящая модель начинается с требований к информации и правил её дальнейшего машинного использования. Трёхмерная геометрия приходит позже.

6. Проектирование по специальностям

Традиционная система тяготеет к эстафете:

АР → КР → инженерные системы → корректировки → повторное согласование.

Даже при одновременной работе специалистов координация идёт главным образом через людей и документы.

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

АР ↔ КР ↔ ОВиК ↔ ВК ↔ ЭОМ.

Изменение одной модели становится событием для остальных. Сравнительная оценка даёт 4–8 месяцев для традиционного цикла и 2,5–5 месяцев для интегрированного BIM-проектирования.

7. Ошибки проектирования

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

Для дальнейшего сравнения используется авторский индекс: 0,030 ошибки/м² для традиционного процесса и 0,012 ошибки/м² для ТИМ. На объекте 10 000 м² это около 300 и 120 потенциально значимых ошибок и коллизий. Это расчётный benchmark, который ещё предстоит наполнить фактической статистикой проектов.

8. Формирование локальных смет

В традиционном процессе сметчик получает чертежи, определяет или проверяет объёмы, классифицирует работы и связывает их с расценками. Изменение проекта возвращает его к началу расчёта. В модели на пакет локальных смет отведено 15–30 дней.

В структурированной BIM-модели цепочка выглядит иначе:

элемент → классификация → количество → работа → ресурс → стоимость.

Сметчик остаётся специалистом, но перестаёт служить постоянным переводчиком геометрии в объёмы, объёмов в работы, а работ в ресурсы и деньги. Когда связи представлены данными, алгоритм выполняет повторяемую обработку. Специалист контролирует правила расчёта, исходные данные, исключения и результат. Автоматизируется информационный переход, а не человек. Для расчётной модели принимается 3–10 дней.

Определение 12. Автоматизация информационного перехода. Передача алгоритму повторяемого преобразования информации между связанными состояниями, например: Элемент → классификация → количество → работа → ресурс → стоимость.

9. Передача производственного знания рабочим

Между проектом и рабочим часто стоит длинная человеческая цепочка: проектировщик → ПТО → производитель работ → мастер → бригадир → рабочий. На каждом уровне техническая информация получает новую интерпретацию. Адаптация к объекту, технологии и требованиям может занимать 1–3 месяца.

ТИМ сокращает число таких преобразований. Производственное задание собирается из связки:

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

Рабочий получает контекст операции, а не охапку документов, из которой этот контекст предстоит угадать.

Определение 13. Производственное знание. Подготовленная для конкретной операции связка: Объект → технология → операция → ресурсы → требования качества → инструкция → контроль результата.

При наличии ТТК и цифровых рабочих инструкций расчётная модель принимает 0,5–1,5 месяца адаптации. Здесь BIM начинает переходить из модели здания в модель производства.

10. Скорость обнаружения отклонений и управленческой реакции

Главное различие проявляется после начала строительства. В традиционной системе отклонение должно сначала произойти, затем попасться на глаза мастеру или ПТО, войти в отчёт, встретиться с планом и только после этого подняться к человеку, способному принять решение. При месячной отчётности отклонение может жить 15–30 дней. В цифровом план-факт-контуре проверка выполняется ежедневно или еженедельно, а часть сопоставлений берёт на себя алгоритм. Окно неконтролируемого отклонения условно сокращается до 1–7 дней. Преимущество ТИМ измеряется временем между изменением физического процесса и управленческой реакцией:

событие → данные → отклонение → обнаружение → анализ → прогноз последствий → решение → воздействие.

Красивый чертёж этого времени не сокращает.

Определение 7. Скорость управленческой реакции. Интервал между возникновением изменения физического процесса и подготовкой управленческого воздействия: Событие → данные → отклонение → обнаружение → анализ → прогноз → решение → воздействие.

11. Как цифровизация старой цепочки создаёт «зоопарк софта»

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

Проблема начинается, когда современными программами цифровизируют именно эти интерфейсы. Проектировщик получает BIM, сметчик — сметную систему, плановый отдел — календарное планирование, ПТО — отдельное приложение, производство — мобильный интерфейс, руководитель — BI-dashboard. Между ними остаётся человек, который выгружает, проверяет, переводит и передаёт данные.

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

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

Настоящий ТИМ строится по другой логике. Объект, работа, технология, ресурс, время, локация, стоимость и FACT становятся связанными состояниями одного процесса:

Объект → Работа → Технология → Ресурс → Время → Локация → Стоимость → Факт → Отклонение → Управленческое действие.

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

Определение 15. Единый информационный контур ИСП. Архитектура, в которой объект, работа, технология, ресурс, время, локация, стоимость и факт связаны между собой и могут обрабатываться различными программами без обязательного ручного преобразования информации человеком.

Итоги части 1

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

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

ТИМ меняет сам принцип цепочки. Единицей управления становятся структурированные данные, связанные с объектом, работой, технологией, ресурсом, временем, пространством, стоимостью и FACT. Эти данные создаются для обработки человеком и алгоритмами.

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

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

Ценность ТИМ определяется не только скоростью выпуска 3D-модели и документации. Главная мера цифрового управления — время между изменением процесса, обнаружением отклонения и управленческим воздействием.

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

Можно дать проектировщику одну программу, сметчику вторую, ПТО третью, плановому отделу четвёртую, производству пятую, а руководителю красивую BI-панель. Если между ними по-прежнему нужен человек-переводчик, архитектура не изменилась. Она только получила новые экраны.

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

СССР: документ движется через человека.

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

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

Определение 16. Главная формула Части 1. Цифровая трансформация ИСП — переход от человеко-документной архитектуры к архитектуре связанных данных, где алгоритмы выполняют стандартизированные информационные переходы, а человек управляет требованиями, отклонениями, исключениями и решениями.

Содержание

Глава 1. Подарки российскому строительному бизнесу 26

Бизнес, которому долго не требовалось управлять по-новому 26

Первый подарок: земля, превращённая в строительный актив 26

Высокая цена жилья как источник устойчивости 27

Продажа квартиры, которой ещё нет 28

Второй подарок: мировой супермаркет строительных технологий 29

Третий подарок: дешёвая и постоянно пополняемая рабочая сила 30

Что показывает статистика строительства 31

Рост без трансформации управления 32

Преобладающая управленческая модель российских строительных компаний в 2008–2020 годах 33

Чем доказывается единоначалие 34

Пять признаков практической линейности 35

Итоги главы 1 35

Глава 2. BIM приобрели, а систему управления оставили прежней 36

BIM в среде линейно-функционального управления 38

BIM — это геометрическая модель, построение которой автоматически создаёт самое главное в строительстве — данные для управления строительными процессами 41

Распределённая, но не размытая ответственность 41

Оригинальное ТИМ-противоречие 42

Две несовместимые архитектуры управления: BIM горизонтальный, управление вертикальное 42

Вертикальный жизненный цикл распоряжения 43

Почему BIM оказался внутри проектного отдела 45

Что приобрели и что должны были изменить 45

BIM-менеджер без управленческих полномочий 46

Функциональные колодцы получили собственные программы 47

Почему интеграция программ не решила проблему 48

Проблема заключалась не в наличии вертикали 48

Модель и отчёт — не одно и то же 49

Основное противоречие внедрения ТИМ 49

Главный вывод 51

Глава 3. Как преодолеть конфликт между горизонтальной BIM-средой и вертикальной системой управления застройщика 53

Параллельный информационный контур 53

Вертикаль власти должна сохраниться, монополия на информацию — исчезнуть 54

Что означает автономность 54

Принцип «Дигитальной Демократии» 55

Содержание

Архитектура параллельного информационного контура 55

От информации — к данным 55

Единый управленческий цикл 56

Автоматизация отчётности 56

Результат решения 57

Глава 4. Какой методологией объединить уже имеющиеся программы 58

Конфликт двух миров: геометрия и процессы, конкретика и системность 58

Странный сбой нашего мышления 58

Строительный проект как корабль 59

Мир моториста 59

Мир навигатора 60

Два профессиональных мира 60

Капитан не должен заменять навигатора и моториста 61

Методология соединения геометрии и процессов 62

Статус как точка соединения двух миров 62

Не менять все программы, а распределить их роли 63

Ритм двигателя и гибкость навигации 63

Основной вывод 63

Тезис 2. Узурпация общего информационного поля «мотористом» 64

Почему хороший моторист не всегда становится хорошим капитаном 64

Инженер тоже формирует гипотезы — но в другой среде 65

Как моторист захватывает информационный мостик в строительстве 66

Когда точность становится иллюзией управляемости 66

Ошибка в одной точке и ошибка в десятках точек 67

Импровизация не должна становиться методом 68

Кто должен формировать общее информационное поле 68

Как вернуть моториста в систему, не лишая его значения 69

Основной вывод 69

Заключение к части 2 71

Если диагноз понятен — можно переходить к лечению 71

Что показала Часть 2 71

Где находится первоисточник проблемы 72

Готовы ли мы перейти к практике? 72

Что будет в Части 3 73

Глава 1

Подарки российскому строительному бизнесу