ГенЦифра

Запустили пилот по видеоаналитике с компанией Qmonitoring.
Внедрение до нельзя простое: передаём ребятам видеопотоки с камер на площадке, коллеги делают небольшие доработки и система в эксплуатации.
За чем следим:
• наличие СИЗ у сотрудников;
• простой техники;
• задымление/пожары.
С какой целью:
• дисциплина сотрудников: весть о штрафах на основании видеоаналитики быстро расходится по площадке;
• по простоям прорабатываем метрики, через которые будем мотивировать производителей работ;
• про ЧП на стройке все ответственные лица должны узнать незамедлительно и сразу принимать действия.
С ребятами из Qmonitoring я взаимодействовал в предыдущей компании и в эффектах от внедрения не сомневаюсь: простои снизились на 40% и это только на реакции акционера, который увидел цифру, оплаченную за то, чтобы техника стояла у нас на площадке.
Но сейчас в ХСК решение о закупке услуг лежит на директорах проектов. Им нужно убедиться, что это не просто контроль за ними, а рабочий инструмент, помогающий эффективно реализовывать проект.
Вы бы на месте директора проекта взяли услугу? Стоимость 30% от месячной траты на одного специалиста ОТиТБ.

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

Как я заставил бизнес-заказчиков отчитываться за срыв сроков вместе со мной


Готовлюсь к отчёту перед акционерами по портфелю проектов. Просрочка — 3 проекта из 17. Разбираю причины.

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

Как это устроено у меня:
• Рабочая группа на проекте — ведёт протоколы, фиксирует операционные решения.
• ИТ-комитет — согласовывает график реализации. Может двигать задачи внутри итогового срока.
• Стратегический комитет — только здесь можно менять сам итоговый срок проекта.

Что это даёт?
Дисциплину не только у ИТ-блока, но и у бизнес-заказчиков. Они отчитываются за сроки вместе со мной. Если появляются доп. требования, которые тянут проект, — объяснять нужно не только мне, но и стратегическому комитету: почему их не было на старте?

Раньше я был крайним за каждый срыв. Теперь за сроки отвечаем все. И это честно.

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

И вот заказчики начинают всем известное

«всё херня, давай по новой»

или

«вот ещё это добавьте, без этого не заработает»

, а я пытаюсь не провалиться в историю

«процесс наладить не можете, а на ИТ валите».

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

Вы-то как?)

Доклад ДОМ.РФ «Бизнес-эффекты цифровизации девелопмента». Часть 2. Строительство.

Уровень цифровой зрелости (определялся анкетированием) тут 39% у крупных и 18% у мелких. Просто поле непаханое.

Что используют на стройке:

— Среда общих данных (СОД)
— Электронный документооборот
— Цифровые системы стройконтроля
— Видеоаналитика (в т.ч. с ИИ)
— Автоматизированные планировщики и дашборды
— SLAM-сканеры для проверки качества
— Роботизация и БПЛА

Куда подевалось календарное планирование? Или оно просто подразумевается по умолчанию? По опыту — как раз по умолчанию его чаще всего и нет.

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

Теперь к эффектам. Тут подпишусь под каждым словом:

"

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

Сделать оптимальный график — это даже не пол-дела, вопрос — как с этим работают дальше.

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

Тут тоже важно: поиск информации и обмен ею занимает немало времени у всех участников.

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

Всю прошлую неделю обсуждали новую модель от OpenAI GPT-6 Astra. Коллеги делали несколько экспериментов:
https://t.me/bimleaders2022/582
https://t.me/revit_bim_news/6813
https://t.me/bim_koordinator/301
Пока вывод — проектирует она на тройку, но проектирует.
А я смотрю на следующие возможности:
— Подъём моделей по 2D-чертежам. Может, сейчас не так актуально, как в 2010 году, но чертежей без моделей остаётся много.
— Проверка моделей и чертежей по заданным параметрам и сводам правил. Сейчас много экспериментов на эту тему и у нас, но большинство проверок сводится к проверке текста, а хочется и графику проверять.
Хорошая тенденция, что все сразу начинают в комментариях спрашивать, сколько токенов ушло — пришло осознание, что AI это не бесплатно, а иногда и дороже человека.
Кстати, помню, как те же 15 лет назад вели переговоры с компанией, которая утверждала:

Мы поднимаем BIM-модели с плоских чертежей за дёшево, за счёт того что работают вьетнамские студенты на одном компьютере в 3 смены.

Требования к модели даже не обсуждали тогда))

Пост субботний про праздник воскресный. Завтра День программиста.

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

Забавно: сами придумали свой AI, а одни из первых, по кому он проехался, как раз программисты.

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

Поэтому с праздником всех причастных! Непонятно, что будет, но точно будет интересно.

Как я неудачно внедрял управление требованиями. Часть 2-я.

Работал ИТ-директор в девелоперской компании, строим класс элит.

Гипотеза: есть иерархический справочник бюджетных и сметных статей, на нём же строим графики производства работ, и на нём же сируктурируем требования. Условно на 4-м уровне справочника у нас есть описание вида работы, время, необходимое на её выполнение, и её стоимость. Изменение одного из 3-х показателей влечёт изменение двух связанных. Получаем классический треугольник качество-цена-сроки.

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

Смотрел в сторону разработки нового продукта, и на одной из встреч партнёры говорят:

«Не парься, обычная wiki-система закроет все твои задачи»

Бинго. Смотрю несколько продуктов хотелось бы Confluence, но выбрал российский аналог Документерру.

Протестили, подготовили структуру, отдали бизнесу на заполнение. Для меня идеальное внедрение: продукт готовый, с настроенной поддержкой и понятным развитием. А вот для бизнеса...

1) далеко не все требования разработаны, а не «просто по разным Wordам разложены»
2) «не так удобно, как в Excel и Word»

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

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

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

В итоге, как говорил один мой знакомый:

«Хотели заработать денег, а получили вновь опыт»!

Главный итог для меня — все ТЗ команды теперь структурированы и разбиты на атомарные требования. Поскольку они не самые объёмные, Google Sheets достаточно. А если будем делать базу знаний в компании на основе wiki — переедем с требованиями туда.

Как я неудачно внедрял управление требованиями. Часть 1-я.

Первый заход был почти 10 лет назад. Проектировали и строили в роли тех.заказчика Международный терминал в Шереметьево. До этого был опыт реализации Терминала B, на котором уже было сложно утрясти все взаимоисключающие требования, а в международном появляются дополнительно: степени «очистки» пассажиров, погранслужба, таможня.

Задачка такая: 1000 страниц ТЗ разбить на атомарные требования и силами Дирекции проектирования увязать требования между собой.

Просмотрели весь рынок, по разным причинам (цена в том числе) остановились на 3SL Cradle. Продукт даже развернули, ТЗ прогрузили, но вот сотрудники Дирекции проектирования не потянули работу. Не хватило времени и аналитических задатков, также не хватило и желания — но это все айтишники так говорят.

В остатке увязку делал консультант (ГК «Спектрум»), в лице Сергея Терентьева — как он в итоге это сделал, только ему известно, но не даром теперь он главный инженер всей группы компаний.

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

Короче, купили Maybach, а поехали всё равно на Volkswagen — но и не на «Жигулях».

Терминал, кстати, построили за 21 месяц — от утверждения архитектурной концепции до ввода в эксплуатацию.

Про другие попытки— в следующей части.

Изучил доклад ДОМ.РФ «Бизнес-эффекты цифровизации девелопмента». Более близкий к жизни документ. Без заоблачных эффектов от внедрения ИИ, но и оставляет много открытых вопросов.

К примеру:

«Для девелоперов значимыми результатами цифровизации являются повышение прозрачности процессов, скорость принятия решений и рост управляемости».

Всегда такое задвигаю акционерам и руководству, интуитивно чувствую, что прав, но как это померить — не знаю.

Доклад затрагивает 5 областей: предпроект, проектирование, строительство, продажи и маркетинг, эксплуатация. Нам интересны 2, 3 и 4 пункты — разберу все три по очереди. Сегодня про проектирование.

47% девелоперов используют ТИМ/BIM-инструменты — тут, конечно, грустно.

Бизнес-эффекты от BIM:

«Ускорение работ. К примеру, по корректной BIM-модели можно получить ведомость объёмов работ на полный проект за два дня. Эту работу будет выполнять один сотрудник. При аналоговом формате такие работы будет выполнять группа из 5 сотрудников в течение двух недель».

А сколько нужно времени на подготовку этой самой «корректной модели»? Ну хорошо, что не моментально, как раньше, а уже 2 дня.

«Скорость внесения корректировок в финансовую модель».

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

«Повышение качества проектной документации. Внедрение BIM и прохождение экспертизы в формате 3D-моделей привели к смещению основной глубины проектирования на более ранние стадии проекта».

А вот тут согласен: качество стадии П растёт, особенно если далее EPC-контракт — наличие проработанной стадии П снижает неопределённости в цене контракта. Приходите к нам, разработаем подробно Стадию П.

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

И только я заметил тенденцию, что все BIMщики перебежали в стан ИИ-проводников?

Реализовали проект по переносу CRM с самописной системы, которая прослужила больше 10 лет, на Bitrix24.

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

Настройку выполняли силами собственной команды: РП от бизнеса, РП от ИТ, аналитик и два разработчика — те же самые, что параллельно ведут ещё несколько проектов и эксплуатируют разные модули Bitrix. Уложились в 4 месяца от инициации до конца опытно-промышленной эксплуатации.

Из необычного для этого проекта — бизнес-заказчик взял на ГПХ аналитика, который уже сопровождал подобные переезды раньше. Это сильно упростило и разработку, и согласование ТЗ, и тестирование с опытной эксплуатацией.

Буквально в пятницу передали систему в промышленную эксплуатацию.

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

Субботний пост или минутка инфоциганствамотивации!

На неделе было больше 10-ка звонков от различных продажников:

Личного характера
— фитнес-клуб, в котором не был лет 5;
— ТО на автомобиль — никогда не звонили, всегда сам записывался.

По работе
— железо — стандартно уже;
— программное обеспечение и разработка всех мастей.

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

В общем, похоже, продажи встают по всем направлениям. Не самая лучшая ситуация...

Нам везёт, заказы есть…

Но у каждого кризиса есть плюсы:

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

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

Самое простое внедрение, не требующее никаких усилий, — это "Возврат на Excel". А с остальным придётся повозиться!

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

Универсального рецепта, как провести внедрение я не знаю. Я когда-то наткнулся на модель Thompson, Higgins, Howell авторы предложили её ещё в 1991 году, и мне она показалась максимально универсальной. По их логике, использование системы человеком определяют пять факторов, и под каждый можно придумать конкретные действия — получается что-то вроде mind map диаграммы. Часть действий нужно закрыть ещё на выборе продукта, часть уже на самом внедрении. После реализации этих действий, пользователь оказывается в ситуации, где внедрение для него не просто необратимо и органично

Вот к примеру план что мы делаем по каждому фактору на проекте СОД (Среда общих данных):

Карьерные последствия - что человек получает в долгосрочной перспективе
— Выделяем активных проводников и предлагаю HR внести их в кадровый резерв компании
— Поощряем сторонников через PR в корпоративных новостях и их видит всё руководство

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

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

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

Аффективный компонент — эмоциональная реакция на работу с системой, тут самое сложное: на интерфейс нам трудно повлиять.
— Выбор продукта — за бизнесом, не за ИТ (отработали на самом старте)

Стимулирующие условия
— Новости о проекте в корпоративном Telegram
— Личная заинтересованность руководителя — внедрение тоже часть его KPI
— Нематериальная мотивация для РП от бизнеса — мерч, выделение на корпоративных мероприятиях

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

У всех руководство и акционеры просят AI внедрять, но хочется не просто внедрять, а профит с этого получать. Беру в работу простые и понятные кейсы.

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

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

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

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

Посмотрели метрики — использование эпизодическое. Юристы честно объясняют: типовые договоры глазами читать быстрее, чем идти в отдельную платформу, загружать документ и ждать результат. В ИИ-проверку идут только с нетиповыми.

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

Начали разбираться с API для интеграции — и тут выяснилось, что в течение ближайшего месяца у Noroots выходит нативный агент в приложении Bitrix24. Ждем.

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

А я решил оценить по этим критериям нашу компанию (ООО «Химсталькон-Инжиниринг»). Исключил из рейтинга 5 пунктов, которые не релевантны для генподрядчика (подбор площадок, энергоэффективность здания и прочее), и исключил баллы по ним у участников тендера. Потом проставил баллы для нас сегодня и после завершения программы трансформационных проектов — к началу 27-го года.

Как итог: сейчас мы уже в 15-ти лучших из 33 участников рейтинга, а к началу 27-го крепко засядем в 5-ке лучших.

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