По следам:
и сокращая творческий и заодно и технический долг…
операционныйпоток операционныйменеджмент цифровойдвойник
А что собственно (я) Мы создаем?
Первое, что нужно выявить перед тем, как приступать к описанию и последующему разворачиванию системы (любой, не только управление операционным потоком) на систему выше по отношению к себе для строительства предприятии - определение самой Целевой системы (ЦС). Этот шаг важен фундаментально. Неправильное определение ЦС ведет к невозвратным потерям, потерям времени.
Вторым делом необходимо смоделировать связанные причинно-следственные цепочки по графам создателей положительного влияния от поведения создаваемой системы в период ее эксплуатации/использования на Целевую систему.
Создаваемая система проекта [[П.12. Инженерия цифрового двойника операционного потока проектного департамента предприятия]] - Цифровой двойник потока работ как производственных актов траты ресурсов на создание и поставку ценностей в окружение.
Если создаваемая система не влияет никак на точность в изготовлении, скорость воплощения ЦС (в нашем случае на скорость воплощения целевых объектов выпуска: УДС, Мосты, Дороги, Здания), и иные важнейшие архитектурные характеристики, типа надежность, безопасность, стоимость, ремонтопригодность и пр., то трата ресурсов будет напрасна.
То есть если система никак по своему ролевому/функциональному поведению никак не встраивается в граф создателей и никакой связи там нет, то проект нужно просто перестать делать. От этого пользы будет больше, как минимум польза освободившихся ресурсов.
Система как физический объект в 4D пространстве, а не описание или документация описания
Наш проект [[П.12. Инженерия цифрового двойника операционного потока проектного департамента предприятия]] в конечном итоге направлен не на то, чтобы существовал трекер как сам по себе в виде какой-то программы, а на то, чтобы в конечном итоге физические объекты - мосты, участки УДС и автомобильных дорог, магистральные сети, здания (целевые объекты) - появлялись в мире точнее и с меньшими потерями ресурсов. Трекер, регламент, метрика - средства. Мера успеха - не “внедрён двойник”, а по разработанной на нашем предприятии документации воплощаются успешные целевые системы.
Успешными называем системы, в которых интересы всех проектных ролей системы и проектов по созданию в цепочке создателей учтены/удовлетворены, включая роль Проектировщика (!), то есть наше предприятия.
Что изменится в физическом мире, если проект закрыть прямо сейчас?
Наш проект - инженерия цифрового двойника потока производственных актов расходования ресурсов физического двойника, то есть самих цепочек производственных линий проектного департамента с их поведением/работам по методам.
Если закрыть именно этот проект, то инженеры не перестанут работать, документация не перестанет разрабатываться, мосты, дороги, сети, здания продолжат проектироваться - так, как проектировались до внедрения трекера, то есть без общей видимости очереди работ.
Документация при этом будет разработана, но дороже, с большим числом ошибок, медленнее, хуже контролируемой, менее гибкой к изменениям и с меньшей эффективностью потока, чем достижимо при том же составе людей, и с большим числом коллизий проявленных на поздних стадиях этапа воплощения. Например, в процессе строительства могут “всплыть” коллизии уже “в бетоне”, устранение которых может потребовать на порядки больше денег, чем решение их на этапе моделирования/проектирования.
Что такое цифровой двойник операционного потока.
Физический двойник здесь - это реальное поведение рабочих станций инженеров в цепочках производственных линий проектного департамента: то, как фактически расходуется временной ресурс и накладные в синтезе решения задач (не важно какая категория). Система показывает где реально возникает ожидание (скапливаются кучки заготовок перед станком) рабочих продуктов смежника.
Цифровой двойник операционного потока на платформе подходящей программы отображает эту реальную ситуацию потока работ физического двойника и за счёт этой видимости и принятия решения на местах соответствующего системного уровня оказывается влияние на работы/поведение всего департамента.
Как в итоге это влияет на целевые системы
Причинная цепочка эффекта устроена так:
→ Цифровой двойник (создаваемая система проекта) проявляет фактическую работу физического двойника - инженерию работ специалистов управления, анализа и разработки - и обеспечивает управленческие решения по управлению операционным потоком выпуска на местах, на соответствующих системных уровнях
→ это меняет работу, сервис и поведение проектного департамента
→ это определяет успешность и точность конфигурации моделей проектной документации, скорость разработки и выпуска документации моделей и описаний целевых систем на этапе их создания и воплощения (эксплуатации)
→ это определяет успешность (учёт интересов и потребностей проектных ролей), точность (выполнение требований, минимизация коллизий и переделок) и скорость (успешность варианта с наиболее быстрым разворачиванием и строительством площадки, а также возведением самой целевой системы, включая оперативность корректировки ошибок модели в документации и решения проблем в процессе жизненного цикла строительства ЦС)
→ и в итоге определяет успешность воплощения архитектурных характеристик и срок появления каждой отдельной целевой системы.
Точность на входе цепочки (устранённые коллизии между разделами, единая версия решения) определяет, что реальная несущая способность, геометрия и соответствие нормам построенного объекта совпадают с расчётной моделью, а не расходятся с ней после того, как исправить это уже физически невозможно. Скорость на входе цепочки, достигнутая без потери точности, определяет, насколько раньше объект переходит от design-time знания к работающему физическому воплощению.
Как это соединяется с целевым выпуском и финансовой устойчивостью проектного предприятия (нас)
Один спроектированный, изготовленный и построенный объект с нужной точностью и в срок - это польза для одной целевой системы, но департамент ведёт не один объект, а портфель из нескольких одновременно (5–10 объектов и больше).
Та же цепочка точности и скорости, повторяясь по всем объектам портфеля одновременно, продолжается ещё двумя эффектами уровня предприятия:
- Целевой выпуск. Способность департамента выпускать документацию по плановому графику для контрактных обязательств одновременно по всем ведущимся объектам — не за счёт перегрузки конкретных инженеров, а за счёт устранённых потерь на ожидание и переделки. Рост Flow Efficiency при том же штате — это рост фактической пропускной способности департамента без пропорционального роста численности.
- Финансовая устойчивость. Для контрактов по 44-ФЗ и аналогичных договоров просрочка и выявленные экспертизой дефекты документации напрямую конвертируются в неустойки, пени и репутационный риск для будущих тендеров. Стоимость переделки, не пойманной цифровым двойником на этапе проектирования, а всплывшей на экспертизе, изготовлении или стройке, - это не абстрактная потеря времени, а прямые незапланированные затраты, которые не всегда можно предъявить заказчику и которые съедают маржу проекта. Предсказуемый, управляемый по данным поток документации делает доход и маржу предприятия менее зависимыми от скрытых потерь, обнаруживаемых постфактум.
Что не будет хорошего, если цифровой двойник управления операционным потоком не использовать
В знаниевых отраслях выявление Ограничения в цепочке производственных линий устроено сложнее и менее очевидно, чем в производстве: не видно ни станка, ни очереди заготовок перед ним, можно опираться только субъективное ощущение загруженности инженера или руководителя.
Цифровой двойник операционного потока поможет проявить “скрытые” Ограничения и применить Теорию Ограничений [[Голдратт Элияху М.]] для развития департамента в своих работах.
[[Steve Tendon]] в своей книге [[Книга. TameFlow]] пишет, что по отрасли интеллектуального труда в мире этот показатель обычно находится в диапазоне 2–7%, - то есть потери ресурсов примерно 93 - 98%.
Без проявления этого распределения предприятие не может системно проводить работы по 5 ступенчатой фокусировке снятия ограничений на предприятии без растрачивания в пустую ресурсов.
Польза для целевой системы по стадиям её жизненного цикла может быть представлена в табличной форме:
| Стадия ЖЦ ЦС | Роль-создатель на этой стадии | Тип системы-создателя | Предмет интереса системы-создателя | Статус ЦС на этой стадии | Что меняется в физическом двойнике | Что меняется в ПД описания ЦС | Польза в воплощении ЦС |
|---|---|---|---|---|---|---|---|
| Проектирование | Подрядчик по проектированию (мы) | Система создания (наша система, прямой объект инженерии двойника) | Комплект ПД как непротиворечивое описание воплощения целевой системы | Design-time знание: ЦС физически не существует, появляется документация и описанием создания успешной ЦС | Инженер видит смежные разделы на общей доске и фиксирует решение в карточке, а не в переписке; ГИП видит WIP и застревания по своим людям и переставляет приоритет по буферу; начальник отдела видит throughput и явное системное ограничение, решает о фокусировке по данным; директор видит предсказуемость сроков по портфелю объектов и риски заранее | Коллизии между разделами выявляются ближе к левой стороне воплощения: на этапе разработки модели. Решения принимаются по актуальной версии. Время карточки в ожидании (а значит и физических простоев работ) и число переделок (как потерь трат ресурсов) сокращаются. |
В основу объекта закладываются верные, непротиворечивые архитектурные характеристики с значительно уменьшенным числом коллизий конфигурации в модели ЦС: стремимся оперативно проявлять возможные коллизии/противоречия именно на этой стадии (так как это несравненно дешевле и по времени и по деньгам !!! на многие порядки). Следим за учетом интересов важных проектных ролей: создаем именно успешную ЦС, а не просто физический объект. Задача стоимость устранения потерь в будущем (в физическом воплощении) решить при моделировании. |
| Изготовление конструкций (ж/б и металлоконструкции) | Заводы-изготовители ЖБИ и МК | Система создания (производство компонентов по РД) | Физические компоненты/модули ЦС: опоры, пролётные строения, фермы и пр. | Компоненты производятся изолированно от площадки, ещё не собраны в целое | Инженер выпускает КМД/РД как единый релиз с явным статусом актуальности, а не рассылкой правок напрямую заводу; ГИП контролирует переданную версию; начальник отдела видит запросы завода как поток с приоритетом и буфером; директор видит зависимость сроков поставки конструкций от сроков выпуска РД | РД, уходящая на завод, содержит модели без конфликтов. Запросы завода обрабатываются быстрее и не теряются. |
Элементы изготавливаются точнее - исправить уже изготовленную конструкцию почти всегда невозможно без полной замены, поэтому точность здесь необратимо определяет физическую годность будущего объекта. |
| Строительство | Генеральный подрядчик (СМР) | Система создания (физическое возведение и монтаж ЦС) | Строительная площадка как платформа физического воплощения ЦС. Цепочка производственных линий воплощения как развернутое строительно-монтажное предприятие/завод на стройплощадке. Оперативное внесение изменения в ПД с учетом актуализации адекватности окружения и контекста. |
ЦС физически собирается и монтируется: переход от разрозненных компонентов/модулей/частей целого к целому (ЦС) в соответствии с проектной документацией описания ЦС | Инженер обрабатывает запросы с площадки (RFI, авторский надзор) как видимую очередь с приоритетом; ГИП отслеживает возраст таких запросов; начальник отдела видит нагрузку на площадочную поддержку в общей картине потока; директор видит, где строительство простаивает из-за ожидания решения проектировщиков | Запросы с площадки закрываются быстрее; сборка идёт актуальной и адекватной версии документации без внутренних коллизий. | Сохраняется архитектурная целостность и соответствие нормам, заложенные на проектировании: объект раньше готов к вводу в эксплуатацию. |
| Эксплуатация | Эксплуатирующая организация | Система создания (эксплуатация и текущий и капитальный ремонт ЦС) | Надежность, безопасность и ремонтопригодность в период заявленного срока службы ЦС | ЦС функционирует и приносит пользу пользователям. | Инженер (при повторном привлечении) видит запрос на реконструкцию как задачу в том же управляемом потоке; ГИП и начальник отдела применяют тот же принцип приоритизации по буферу; директор видит историю решений по объекту как трассируемый актив | As-built документация и история решений прослеживаемы и непротиворечивы. Сдача-приемка в эксплуатацию происходит с сокращением времени за счет более точных моделей стадии Проект и соответствия Исполнительной документации Проектной, получившей положительное заключение ГосЭкспертизы |
Продлевается срок безопасной службы объекта, диагностика опирается на точные данные, снижается риск аварийного отказа от ошибок, унаследованных с проектирования. |
Стоимость исправления ошибки на этапе физического воплощения модулей и самой ЦС растёт значительно с каждой пройденной стадией: что стоит условную единицу на этапе проектировании, может стоить на порядки больше при изготовлении конструкций, еще на порядок больше на строительстве, и предельно дорого - вплоть до невозместимого вреда - на эксплуатации: предположим, мы все вместе создали вообще не то, что нужно.
Цифровой двойник, работающий на стадии проектирования, вмешивается в самую дешевую, но в оказывающую самое сильное воздействие точку всего жизненного цикла целевой системы.