Организация как код

Задача «внести сведения о приборе» кажется простой. В учётной системе он называется «прибор», у технических специалистов фигурирует как «КИП», то есть контрольно-измерительный прибор. Человек может связать эти записи благодаря своему опыту. Агенту нужно явно указать, какой объект имеется в виду, где лежат нужные сведения и какое действие разрешено. На стенде «Организация как код» проверяем, как такое описание помогает агенту выполнить задачу.

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

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

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

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

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

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

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

Такой обновляемый договор называем динамическим стандартом. Каждая система развивается под свои задачи, а участники проверяют затронутые связи и согласуют новую версию описания. «Договор v2» на схеме обозначает такую следующую версию.

Теперь допустим, что пять процессов одновременно требуют одну и ту же вычислительную мощность. Все входы, выходы и связи описаны правильно, но ресурсов на одновременное выполнение не хватает. Какой процесс получит приоритет? Что задержится и какова будет цена задержки? Чтобы ответить, нужна модель поведения системы во времени.

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

Агент получает одну команду: «внести сведения о приборе». В сценарии используется АРМ метролога, автоматизированное рабочее место для учёта приборов и сведений о поверках. Участник сравнивает, как агент выполняет эту задачу без согласованного описания системы, с ним и после его изменения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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