Онтология предприятия и метод инженерии предприятия. Существенная модель предприятия складывается из четырёх аспект-моделей: кооперации (CM), действий (AM), процессов (PM) и фактов (FM). Фирменное разведение — координационный мир и производственный мир: PM задаёт пространство состояний и переходов координационного мира, FM — производственного, а CM и AM покрывают оба. Кооперация описывается через транзакторные роли акторов и координационные структуры между ними.
Заказ на деталь ушёл изготовителю, письмо «готово» вернулось. Но в какой момент изготовитель принял обязательство, где именно возник результат и кто признал, что он соответствует договорённости, — из переписки не видно.
Процессы обычно описывают как последовательность действий и документов: заявка, согласование, уведомление, акт. Такое описание живёт, пока живёт система, в которой эти документы ходят; сменили портал на почту — и схему рисуют заново. DEMO смотрит сквозь документы. Любое взаимодействие в нём — транзакция между двумя ролями: инициатор запрашивает результат, исполнитель обещает, выполняет, заявляет о результате, инициатор принимает. Два шага до работы и два после — это координация, договорённости; сама работа — производство. Способ отправить запрос может меняться, смысл обязательства — нет.
В раздатке — пять шагов основного успешного хода транзакции на примере заказа детали; четыре аспект-модели, из которых складывается существенная модель предприятия: кооперации (CM), процессов (PM), фактов (FM) и действий (AM); все 17 карточек со страницы реестра — сами модели, их диаграммы, таблицы и спецификации — и план первой недели. Понятий с бытовыми аналогиями у DEMO на странице пока нет, поэтому определения здесь — переводы спецификации языка DEMO-SL версии 4.7.2, и читать их стоит вместе с примером.
Главное разведение школы — координационный мир и производственный мир. В координационном мире живут запросы, обещания, заявления и принятия; его пространство состояний задаёт процессная модель. В производственном мире живут факты — «деталь изготовлена», «заказ принят»; их описывает фактологическая модель. Модели кооперации и действий покрывают оба мира. Это разведение и делает модель существенной: в ней остаётся только то, что не зависит от способа реализации.
Уведомление «готово» — координационный акт. Готовая деталь — производственный факт. Пока модель держит их порознь, она не зависит от системы, через которую отправлено уведомление.
Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.
Выберите элемент схемы — откроются объяснение и пример.
Инициатор запрашивает у исполнителя определённый результат. На этой точке появляется предмет координации, но обязательство исполнителя ещё не подтверждено.
Покупатель просит изготовить деталь с согласованными характеристиками.
Упрощённый успешный сценарий. Полный паттерн транзакции включает также отказ, отклонение и другие координационные ситуации. Аспект-модели DEMO доступны в каталоге.
Авторский учебный пример. Организация и решения придуманы для объяснения подхода; это не обязательный порядок работ из стандарта.
Определяем инициатора, исполнителя и результат, вокруг которого возникает обязательство.
Процесс не сводится к пересылке документов между отделами.
Отдельно описываем договорённости и фактическое создание результата.
Понятно, где обязательство принято и когда результат создан.
Рассматриваем условия принятия решений и возможные отклонения от успешного хода.
Сохраняется смысл взаимодействия при изменении ИТ-реализации.
Инструментальная методология целостного моделирования и оптимизации бизнес-процессов и информационных систем. Устроена «домом ARIS»: пять видов — Data, Function, Organization, Product/Service и Control — на трёх уровнях описания; именно Control view, собирающий связи между остальными, руководство называет тем, что отличает ARIS от прочих подходов.
Международный стандарт конструкций для моделирования предприятий: определяет и детализирует набор совместимых, ориентированных на пользователя конструкций языка моделирования, которые несут общую семантику и позволяют унифицировать модели, разработанные разными сторонами на разных этапах разработки модели предприятия. В реестре школа представлена русским идентичным изданием ГОСТ Р ИСО 19440-2010.
Координационное сообщение и производственный факт — разные вещи. Уведомление о готовности не равно самому изготовлению детали.
Перед проработкой согласуйте вопрос: Какой результат запрашивается? Ответ должен быть понятен участникам рассматриваемой работы.
Пройдите весь пример от исходной ситуации до результата: Сохраняется смысл взаимодействия при изменении ИТ-реализации.
Общие оси — нейтральные названия частей предприятия: деятельность, данные, приложения, инфраструктура и другие. Здесь показано, какие элементы подхода сопоставлены с этими осями и насколько совпадает их охват.
Есть сопоставление с 3 осями из 17
| Ось реестра | В DEMO | Сопоставление | Пояснение |
|---|---|---|---|
| Деятельность: функции и процессы | Process Model (PM)точка зрения | Охват тот же, что у оси. | Процессная модель. |
| Информация и данные | Fact Model (FM)точка зрения | Охват тот же, что у оси. | Фактологическая модель — предметные данные. |
| Организация и ответственность | Cooperation Model (CM)точка зрения | С осью пересекается частично. | Кооперация акторов: организация, но взятая как сеть транзакционных обязательств, а не как оргструктура. |
| Деятельность: функции и процессы | Action Model (AM)точка зрения | С осью пересекается частично. | Правила действий акторов: деятельность, но на уровне бизнес-правил. |
Полное описание предприятия — работа на месяцы. Первый полезный результат получается за пять рабочих дней, если не пытаться описать всё сразу.
Возьмите одну область интереса — заказ детали — и выпишите результаты, которые один участник запрашивает, а другой обеспечивает: деталь изготовлена, материал закуплен, оплата получена. Для каждого назовите транзакторную роль исполнителя и продукт как факт. Это таблица транзактор-продукт (Transactor Product Table, TPT).
Соедините роли: кто инициирует какую транзакцию, кто её исполняет. Покупатель инициирует изготовление, изготовитель может инициировать закупку материала. Это диаграмма координационной структуры (Coordination Structure Diagram, CSD) — сеть обязательств без должностей и систем.
Для главной транзакции пройдите пять шагов: запрос, обещание, выполнение, заявление, принятие — и отметьте, каких шагов других транзакций она ждёт: изготовление не начнётся, пока не принят материал. Это диаграмма структуры процесса (Process Structure Diagram, PSD). Здесь становится видно, где обязательство принято, а где работа идёт без него.
Выпишите типы фактов, которые создаются выполнением транзакций, и их свойства: деталь, заказ, характеристики. Объектно-фактологическая диаграмма (Object Fact Diagram, OFD) показывает, что истинно в производственном мире; таблица создания и использования (Create Use Table, CUT) связывает факты с шагами транзакций.
Для одного координационного события — получен запрос на изготовление — запишите правило: при каких условиях исполнитель обещает, при каких отказывает. Это спецификация правила действия (Action Rule Specification, ARS). Затем проверьте всю модель: в ней не должно быть ни одной системы, документа или должности.
Запрос — обещание — выполнение — заявление — принятие: так бывает, когда всё хорошо. Полный паттерн транзакции включает отказ исполнителя обещать, отклонение результата инициатором и другие координационные ситуации, в том числе отзыв уже сделанных шагов. Споры между отделами живут именно там. Как только основной ход описан, пройдите отклонения: кто и на каком шаге может сказать «нет» и что тогда происходит.
У каждой транзакции один вид продукта, записанный как факт: «деталь D изготовлена». Без этой формулировки невозможно ни принять результат, ни отклонить его — непонятно, что именно сравнивать с договорённостью. Таблица транзактор-продукт (TPT) существует ровно для этого: в ней каждой транзакторной роли сопоставлен вид продукта.
BPMN описывает, как идёт работа: шаги, развилки, дорожки, документы. DEMO описывает, какие обязательства и факты за этой работой стоят, независимо от того, как она организована. Совмещать удобно: транзакция DEMO задаёт, что должно быть в процессе — запрос, обещание, результат, принятие, — а BPMN показывает, как эти шаги реализованы сегодня.
ArchiMate описывает предприятие слоями от услуг до оборудования; DEMO — только существенный бизнес-слой, без приложений и технологий. Транзакции и роли DEMO можно перенести в бизнес-слой ArchiMate как процессы, сервисы и роли, а дальше связать с системами. TOGAF задаёт порядок работы; существенная модель DEMO — хороший вход в его фазу бизнес-архитектуры.
Размер не важен: в компании на десять человек транзакций немного, и модель кооперации помещается на одну страницу. Отрасль тоже: продукт транзакции может быть деталью, консультацией, решением по заявке — фактом, который исполнитель обещает, а инициатор принимает. Пример в раздатке производственный только потому, что там границы обязательств нагляднее.
15 страниц: что это и чем не является, устройство подхода, 17 карточек словаря, учебный пример и план первой недели.
Пришлём ссылку сразу после отправки формы
Дословные выписки из стандарта с переводом. Строки с пояснением простыми словами отмечены.
Подходы, которые описывают предприятие целиком — от стратегии и процессов до данных и ИТ-инфраструктуры: язык, рамка или метод со своей моделью.
Владелец языка спецификации DEMO — Enterprise Engineering institute; авторство редакции 4.7.2 принадлежит Яну Дицу. Правило версионирования объявлено в самом документе: существенные изменения дают 4.8, 4.9 и далее, мелкие правки, прежде всего исправления ошибок, — 4.7.3, 4.7.4.
Первоисточник назван прямо: язык выражает существенные модели DEMO-4 (Design and Engineering Methodology for Organisations) в том виде, как они определены в главе 12 книги Дица и Мулдера «Enterprise Ontology: A Human-Centric Approach to Understanding the Essence of Organisation» (Springer International Publishing, 2020). При этом документ объявляет себя главнее книги: о расхождениях синтаксических выражений с главой 6 книги сказано «What is presented in the document in hand is leading, the ones in the book Enterprise Ontology need to be corrected».
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormАрхитектура систем и интеграцийБаза знаний и викиРеестр процессов
