Двойник, который действует,
а не описывает
Цифровой двойник здесь — не пассивная информационная карточка. Это активная сущность: она хранит историю объекта, прогнозирует его траекторию и сама договаривается о том, когда и что с ним будет сделано. Начинается всё не с управления, а с двойника и вопросов «что, если» — на ваших исторических данных.
Сначала — двойник и what-if
Сцена — живая модель вашего контура: объекты, заказы, ресурсы, службы и связи между ними. Она строится по онтологии и наполняется историческими данными из учётных систем.
Сцену можно клонировать. На клонах параллельно проигрываются сценарии: «возьмём ещё один контракт», «встанет станок», «задержка на два месяца» — десятки симуляций одновременно, не трогая рабочий план и рабочие системы.
Прогон на исторических данных — это и есть проверка: двойник «проживает» уже случившийся период, и его решения сравниваются с тем, что происходило на самом деле.
Это аргумент для входа в пилот. Управление не передаётся системе авансом: сначала двойник доказывает, что понимает ваш контур, на данных, где ответ уже известен.
Жизненный цикл как рой обязательств
Инвариант, который повторяется в десятках доменов: объект живёт — и непрерывно порождает регламентируемые потребности, а выполняют их ограниченные службы.
Двойник-стюард
Активный двойник объекта — станка, изделия, пациента, сертификата. Хранит состояние, отслеживает наработку и возраст, разворачивает регламенты в конкретные обязательства.
Обязательства с коридорами
Каждое требуемое воздействие — отдельный агент с триггером, целевой датой и коридором допустимых сроков. Внутри коридора можно маневрировать без нарушения регламента.
Контракты готовности
Экономический слой: оплата за готовность объекта, а не за объём работ. Двойник делает такие контракты управляемыми — он планирует именно готовность.
Как стюарды договариваются
Глобальный план парка не рассчитывается сверху — он возникает из переговоров двойников за дефицитные окна служб.
Пять типов триггеров
Календарь, наработка, состояние, событие, дедлайн — обязательство «созревает» по любому из них и само выходит на планирование.
Торг за окна служб
Дефицитные окна — операционная, пост, бригада, тренажёр — получают виртуальные цены; стюарды конкурируют и уступают за компенсацию.
Кампании «за один отзыв»
Обязательства группируются: несколько воздействий выполняются за один вывод объекта из работы.
Локальное перепланирование
Срочное обязательство встраивается в план, затрагивая только тех, кого оно касается, — остальное расписание не пересчитывается.
Пример из другой отрасли: клиника
Видение для многопрофильной клиники — иллюстрация того, как далеко переносится паттерн. Статус: концепция, внедрения нет.
Главным планируемым объектом становится не операционная и не койка, а пациент и весь маршрут его пребывания — от поступления до выписки. Под маршрут разворачивается связанный комплекс задач разных служб: диагностика, операция, койка, реанимация, реабилитация.
Система согласует их во времени и встраивает экстренные случаи с минимальным ущербом для плановых.
Критерии — клинические сроки, приоритет случая, загрузка дефицитных ресурсов, синхронность совместных ресурсов: операционная, бригада и койка должны сойтись в одном окне.
Этика зафиксирована в постановке: клинические решения остаются за врачом; приоритет определяется клиническим риском, а не «ценой» окна.
Путь в пилот
Управление не передаётся авансом — двойник сначала доказывает себя.
Двойник на исторических данных
Онтология контура, сцена, загрузка истории из учётных систем. Двойник «проживает» прошедший период.
What-if на клонах сцены
Параллельные сценарии на копиях: узкие места, риски, варианты решений. Сверка с тем, что происходило на самом деле.
Управляющий контур
Только после проверки двойнику передаются планирующие решения — сначала в советующем режиме, затем в рабочем.
