Материал изначально задуман как способ мне лично погрузиться в ворох программных предложений помимо Power BI и Tableau, которые могли бы решить проблему: «на одном листе» и в динамике видеть объективную реальность проекта. Я рассчитывал на возможность использовать софт, доступный с текущего рабочего места, а также отдельные фрагменты решений при написании схожего функционала методом «ночного вайбкодинга» или с привлечением IT-персонала.

Как это обычно бывает, инициатива похоронила инициатора, а простой список с пометками «что | откуда | пригодится в...» перерос в чуть ли не исследование.

1. Боль докладчика

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

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

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

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

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

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

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

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

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

Через систему и свой календарь руководитель показывает, есть ли у него будущее в компании, есть ли у него на это "завтра" задачи, что он будет делать с этими задачами завтра и как.

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

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

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

Работа нескольких десятков или сотен человек, да ещё и в сравнении с прошлым периодом, должна быть упакована в 5–10 минут доклада. Презентация, график, дашборд, метрики и аккуратные карточки — не результат, а способ упаковать и уплотнить подачу.

Такой инструмент уже не может быть подобием Power BI или сводной таблицы Excel на AI-стероидах. Это должен быть управленческий слой, который сохраняет связь с системами-источниками, учитывает российскую региональную и отраслевую специфику и собирает разрозненные данные в рублёвый контур проекта.

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

2. Как отрасль пришла к одной задаче

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

На трёх секциях, которые я отсмотрел лично, прозвучало около двух десятков докладов. Почти каждый по-своему отвечал на один вопрос: как собрать проверяемую картину проекта из графиков, документов, BIM, факта СМР, договоров, КС, денег в 1С, поручений в трекерах и отчётах.

Это не очередная мода на интерфейсы или свободный вечер у директора-вайбкодера. Причина в другом:

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

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

Природа уже проделывала этот трюк с крыльями, глазами и эхолокацией. Девелоперы повторили его на 1С, Power BI и Excel. Вместо миллионов лет понадобились дорогой кредит проектного финансирования и несколько сотен совещаний с вопросом «Где актуальная цифра?». У корпоративной эволюции свои естественные хищники.

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

• диаграммы Ганта и шахматки обычно выдают решение, выросшее из строительных подразделений и генподрядчика;

• таск-трекеры, KPI-метрики наводят на мысли о заказчике из внутреннего проектного подразделения или генпроектировщика;

• API, шины, 1С, документооборот и КИС выдают заказчика из финансового контура, который подключил всё, до чего смог дотянуться.

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

Project LAB, собственные СОД, ИИ-поиск, Pilot Ice, Renga/Pilot BIM, Roadmap, Planair и SetlTech на Олимпиаде девелоперов показывали разные продукты. Но исходная проблема повторялась: в компании существует несколько версий реальности, а руководителю нужна одна проверяемая картина для решения.

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

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

В девелопменте механизм тот же, только вместо естественного отбора работают кредитная ставка, договорные сроки и Excel. Последний особенно эффективен, если рядом находится человек, который помнит устройство сорока листов и безошибочно отличает «Финал3дополненный» от «Финал_[дата] по итогу доклада [Имя]».

3. Архитектура управленческого контура

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

Данные из 1С, ERP, Excel, КСП, BIM, СОД, стройконтроля, СКУД и камер проходят интеграцию и нормализацию. Затем правила расчёта превращают их в сигнал об отклонении. Руководитель должен увидеть первоисточник, причину, последствие, ответственного, поручение, срок и результат повторной проверки.

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

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

3.1. Управленческое сжатие

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

Первичные записи / управленческие сигналы

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

Условная схема выглядит так:

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

Объём первички вторичен: десять тысяч строк или пять миллионов. Ценность определяется тем, какие решения инструмент помогает извлечь из этого массива.

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

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

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

В рабочем поле руководителя остаются, например:

• 3 проблемных подрядчика

• 5 конфликтов проектирования

• 7 критических лимитов

• 9 просроченных договоров

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

3.2. Где проходит граница между Excel, BI, СОД и пультом

Сравнение по числу строк и красоте графиков мало что объясняет. Power BI, Tableau и DataLens давно умеют подключать, преобразовывать и распространять данные. Excel тоже отлично управляет большим проектом, пока рядом находится человек, который узнаёт ошибочную формулу по оттенку заливки. Это выдающаяся квалификация сотрудника, но довольно дорогой способ заменить информационную систему.

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

Power BI, Tableau и DataLens работают как аналитический слой: помогают исследовать данные и строить отчётность. Отдельное название «пульт» оправдано, только если показатель связан с документом, графиком, BIM, ответственным, поручением и повторной проверкой. BI может оставаться аналитическим движком, а СОД, BIM, КСП и ERP сохраняют свои функции. Замена этих систем является отдельным проектом со своими сроками, бюджетом и рисками.

3.3. Лестница обработки данных

4. Семь входов в один управленческий контур

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

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

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

Большинство компаний показывали отдельные органы управления. А101 связывала производственную программу, график, факт и BI. ФСК строила контур вокруг подтверждённого производственного статуса. SetlTech вела цепочку от BIM к объёмам, тендеру и оплате. Larix на демо показали связку информационных инструментов застройщика от договорного контура, до камер видеонаблюдения и протоколов встреч с привязкой ответственных по аккаунтам сотрудников в корп. системе.

Уже после мероприятия с некоторыми выступающими у меня были встречи и разборы.

Описание кейса RoadMAP

На личной встрече с разработчиками из Нижнего посмотрели их демо и слегка реальных данных. Тут надо сразу отмечать, что самое интересное для меня лично было не столько перечень функций, сколько сама механика взаимного пересчёта графика и денег. Самое интересное в демонстрации видеть как перетащив работу, можно изменить зависимость и сразу увидеть, как вслед за сроками перестраивается ДДС. И наоборот: от изменения финансового контура проследить последствия для производственного сценария. План, факт, прогноз, договорные даты и денежный поток здесь не разложены по соседним вкладкам, а собраны в одну причинно-следственную модель. Показанное выглядело впечатляюще, особенно на фоне привычной практики, где перенос работы заканчивается новым файлом графика платежей, отдельным расчётом финмодели и затем совещанием о том, что теперь произошло с деньгами. Надо отдать должное заморочились над детализацией и текущей возможностью до 5000 (если не ошибаюсь) видов работ или строк. Для моих текущих задач такая глубина кажется избыточной. Но тут уже специфика заказчика с его верхним уровнем по сравнению с подрядчиком.

Описание кейса ФСК

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

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

Контролировать надо только тот уровень, где польза от контроля выше трудозатрат на его ведение.

На слух звучит почти очевидно. Но на практике до этой простой фразы нужно довольно глубоко провалиться в контекст. Потому что в стройке очень легко перепутать управление с обслуживанием базы данных или диаграммы Ганта на 7 000 строк. Этим подход отличается от универсальных и почти готовых к развёртыванию решений, ценность которых где-то в будущем: скоро всё свяжем, скоро всё интегрируем, скоро данные польются рекой, и наступит новая эра.

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

Разбор демо Larix

Пульт управления проектами от Larix — агрегация, в которой эти части собраны в одном рабочем кабинете руководителя. И в этом, я могу обоснованно утверждать, что на собственном опыте прекрасно понимаю, как эволюционно, от одной утилиты система разрастается в масштабный всеобъемлющий комплекс. Опыт моей личной разработки утилиты показывает, что подключив к системе 2-3 новых функционала всегда появляется ещё пять которые логично использовать.
Функционал демо - это был комплекс, в котором предполагается, что бюджет, платежи и задолженности тянутся из 1С, графики из PLAN-R, BI-отчётность, BIM. Как я могу предположить система исторически разраслась и вобрала в себя все доступные ей потоки информации: камеры, СКУД, документы, задачи, риски, команда проекта, видеоконференции и расшифровка встреч, которые будут доступны из одного места — личный кабинет руководителя или акционер (смотря по тому, какие права светят). Понятно, что по отдельности эти элементы уже привычны. Собранные вместе они, видимо, решают проблему по единому входу и уровням доступа.

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

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

Когда статус известен до совещания, совещание начинается с решения, а не с раскопок.

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

1. Из-за специфики работы меня зацепило решение Ларикс, как и некоторых других внедрить ИИ в базовый функционал. Раньше я считал это бесполезными "рюшечками". Однако сегодня, после вынужденного погружения в тему локальных моделей и после того как я лично собрал свою локальную ИИ-сборку, я могу уверенно утверждать, что заявленный функционал (от транскрибации речи до анализа данных, протоколов и сводок) вполне реально запустить даже на бытовом, пусть и продвинутом игровом ПК. Не нужно какого-то сверхмощного и сверхдорогого оборудования, персональные решения вполне обойдутся в несколько сотен тысяч рублей, а для небольшой группы, на затраты больше миллиона нужно уже смотреть как на избыточные.

   При этом с выходом последних локальных моделей, показывающих качество сопоставимое с облачными, такой сценарий становится не только реализуемым, но и практически применимым уже сегодня. В режиме офлайн и на ПК, и на ноутбуках. Всё зависит от реальной потребности и задач. Транскрибация например вообще оказалась наименее требовательной к оборудованию задачей, работающей на видеокарте в 16 гб. с результатами всего с 10-15% ухудшением по сравнению с Яндекс-Телемост.

2. Отдельно я бы проверил ИИ-мэппинг при подключении новых источников данных. Обычно проблема анализа тендерных таблиц и управленческого выполнения не в том, чтобы загрузить очередной Excel или выгрузку из 1С, а в том, что кто-то должен вручную свести наименования проектов, корпусов, договоров, контрагентов, видов работ, единиц измерения, полей и справочников. Один и тот же объект в разных системах называется по-разному, подрядчики записаны с сокращениями, а статьи затрат и виды работ не совпадают даже внутри одной компании. ИИ здесь может взять на себя первый проход: предложить соответствия по названиям, описаниям, типам данных, значениям и ранее подтверждённым связям. Как уже удалось выяснить: такие системы уже реализуются и на общестроительных работах показывают субъективно оценивоемую сходимость "почти всё", но внезапно ломаются на слаботочных системах выдавая результат лишь до "чуть больше половины".

3. Красивый экран может ускорить плохое решение

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

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

   Убедительная ошибка опаснее неубедительной.

Плохие данные на плохом экране раздражают.
Те же данные в хорошем интерфейсе убеждают.

6. Вместо вывода

Уверен, что те, кто дочитал до этой строки, ждут ответа на главный вопрос: «А какая система самая лучшая, чтобы я её взял и не тратил время на подбор?»
Но тут, увы, ответа нет.

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

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

Нельзя делегировать понимание реальности интегратору. Нужно видеть первичку не только своими, но и чужими глазами: заходить в чаты к архитекторам и проектировщикам, открывать SKP и Revit; идти в бухгалтерию к 1С, первичке и многоэтажным сводным; в вагончик подрядчика — к смете и MS Project. Нужно понимать структуру ВОР, логику КС и маршруты согласования в СОД. При этом нет цели получить лишние компетенции. Идея в том, чтобы перестать быть посторонним на собственном объекте.

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

Источники и ссылки

1. Олимпиада девелоперов. Ц06. Цифровизация строительства и проектирования.

2. Олимпиада девелоперов. У06. Управление строительством.

3. PLAN-R. Официальная документация о системе.

4. Setl Group. Автоматизация процессов на основе BIM-моделей.

5. Пульт управления проектами Larix. Материал о презентации.