DEMO — различия между версиями

Текущая версия на 11:56, 4 апреля 2024

DEMO (Design and Engineering Methodology for Organisations) — методология проектирования и инжиниринга организаций.

DEMO описывает положения теории речевых актов в отношении к инженерии предприятий.

Концепция

В DEMO все действия различаются на:

• производственные (действия по изменению вещества или информации),
• координационные (поручения работы, обещания выполнить работу, сообщение о выполнении работы, подтверждение выполнения работы, отказ от выполнения или приёмки работы).

Исполнители работ в DEMO называемые actor (актёр, исполнитель) имеют как компетенции по выполнению производственных действий (или отказу от них), так и полномочия по выполнению координационных действий. Каждое действие в DEMO называется трансакцией и проходит по следующему циклу:

1. инициатор трансакции желает получить какие-то результаты,
2. инициатор запрашивает их у выполнителя работ,
3. выполнитель работ обещает выдать результаты,
4. выполнитель производит их,
5. выполнитель объявляет о готовности результатов работы,
6. инициатор работ принимает результат работы,
7. инициатор использует результаты работы в своей части производства.

Используемые модели

Транзакция

Транзакция связывает координационные акты/факты и производственные акты/факты

• основное, что происходит в организации — это транзакции.
• каждая транзакция проходит между двумя деятельностными ролями: инициатором и исполнителем
• каждая транзакция проходит следующий цикл:
  • инициатор делает запрос (координационный акт, порождающий координационный факт "запрошен производственный факт")
  • исполнитель дает обещание выполнить запрос (координационный акт, порождающий к-факт "п-факт обещан")
  • исполнитель выполняет производственный акт (порождающий п-факт "сделано")
  • исполнитель предъявляет результат работы (к-акт, порождающий к-факт "п-факт предъявлен")
  • инициатор акцептует производственный факт (к-акт, порождающий к-факт "п-факт акцептован")
• поскольку деятели автономны, выполняя свои роли, они могут также делать отказы на запросы, и предъявления, вступать в переговоры относительно сути запросов и предъявлений, аннулировать транзакцию по ее ходу и т.д.
• часто, если инициатор и исполнитель транзакции не могут договориться по ее поводу, они вместо работы попадают в режим дискурса, при котором обсуждается не столько сама транзакция, сколько их полномочия, ответственность, компетенции, правила работы и другие культурные нормы.

Конструктивная модель

• Определяет суть предприятия: организационные роли и транзакции между ними (кто что для кого делает).
• Основная трудность в понимании: что такое организационная роль (роль – это не подразделение, не должность, не конкретные люди, не функции).
• Полностью абстрагирована от реализации
• реализация – назначение организационных ролей организационным местам, затем заполнение этих мест конкретными людьми, затем делегирование этими людьми отдельных внутри транзакционных действий другим людям.
• Для мелких предприятий помещается на лист A4, для очень крупных – лист A0.

Модель процессных шагов

• DEMO: бизнес-процессы (социальные вопросы: запросов-обещаний, т.е. бизнеса).
• Не-DEMO процессные модели айтишников (IDEF0, Dataflow, Document flow и т.д.) – это «какие-то процессы», точно не бизнес-процессы, они не ухватывают социальную суть организации.

Модель состояний (производственного мира)

• Спецификация всех возможных состояний и изменений состояний производственногот мира:
  • Типы бизнес-объектов (часто хитро формулируемых: «членство», «займ»)
  • Бизнес-факты (что сделано)
  • Законы состояний мира производства (как связаны между собой бизнес-объекты)
  • Законы изменения состояний мира производства (например что чему должно предшествовать). Тут связь с процессной моделью (производственный и координационный миры связаны через транзакции).
• Язык моделирования: ORM (язык спецификации данных), возможен Gellish.
• модель состояний DEMO — это описание видов учитываемой информации: то, что обязательно следует записывать («информационные банки» для производственных фактов). Затем эта информация будет предоставляться и запрашиваться при выполнении транзакций.

Модель действий (правила работы)

• Правила, в соответствии с которыми нужно выполнять транзакции (что-то запрашивать, обещать выполнить, выполнять, предъявлять, акцептовать)
• Деятели используют правила, как рекомендации, а не как догму. Считается, что деятели – живые люди, а не роботы и должны регулярно нарушать правила, если они по-настоящему ответственны.
• Модель действий включает в себя информацию всех других моделей (конструктивной, процессных шагов, состояний).
• Нотация: похожа на язык программирования.
• Из-за сложности и всеохватности разрабатывается редко.

Инструментарий

Коммерческий софт:

• Essential Business Modeler (http://xprise.com);
• Моделлер Bizzdesign (http://bizzdesign.com).

Собственные разработки организаций:

• модуль к Metis (http://troux.com) в Rijkswaterstaat;
• «ручка и бумажка» ввиду чрезвычайной компактности диаграмм;
• таблицы в MS Excel.

Литература

• Jan L. G. Dietz (русск.: Дитц). Enterprise Ontology: Theory and Methodology. — B., Heidelberg, N. Y.: Springer, 2006 (ISBN-10 3-540-29169-5)
• A. S. H. P. van Renssen. Gellish, A Generic Extensible Ontological Language: Design and Application of a Universal Data Structure. — Delft: Delft University Press, 2005 (ISBN 90-407-2597-4).

Ссылки

• Подход DEMO. Метод архитектурного описания организаций. PraxOS 1.0