DEMO

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 — это описание видов учитываемой информации: то, что обязательно следует записывать («информационные банки» для производственных фактов). Затем эта информация будет предоставляться и запрашиваться при выполнении транзакций.

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

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

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

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

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

  • модуль к 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).

Ссылки

Комментарии