DEMO — различия между версиями
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) |
||
Строка 1: | Строка 1: | ||
− | '''[http://www.demo.nl/ Подход DEMO]''' ([http://www.techinvestlab.ru/files/504456/demo_praxos_1.doc рус.]) описывает положения теории речевых | + | '''[http://www.demo.nl/ Подход DEMO]''' ([http://www.techinvestlab.ru/files/504456/demo_praxos_1.doc рус.]) - (Design and Engineering Methodology for Organisations) - методология проектирования и инжиниринга организаций. |
− | + | DEMO описывает положения теории речевых актов в отношении к [[Инженерия предприятия|инженерии предприятий]]. | |
+ | == Концепция == | ||
В DEMO все действия различаются на: | В DEMO все действия различаются на: | ||
* '''производственные''' (действия по изменению вещества или информации), | * '''производственные''' (действия по изменению вещества или информации), | ||
* '''координационные''' (поручения работы, обещания выполнить работу, сообщение о выполнении работы, подтверждение выполнения работы, отказ от выполнения или приёмки работы). | * '''координационные''' (поручения работы, обещания выполнить работу, сообщение о выполнении работы, подтверждение выполнения работы, отказ от выполнения или приёмки работы). | ||
− | + | Исполнители работ в DEMO называемые '''actor''' (актёр, исполнитель) имеют как компетенции по выполнению производственных действий (или отказу от них), так и полномочия по выполнению координационных действий. Каждое действие в DEMO называется '''трансакцией''' и проходит по следующему циклу: | |
− | Исполнители работ в | + | |
# инициатор трансакции желает получить какие-то результаты, | # инициатор трансакции желает получить какие-то результаты, | ||
# инициатор запрашивает их у выполнителя работ, | # инициатор запрашивает их у выполнителя работ, | ||
Строка 16: | Строка 16: | ||
# инициатор использует результаты работы в своей части производства. | # инициатор использует результаты работы в своей части производства. | ||
− | + | ||
+ | == Используемые модели == | ||
+ | === Транзакция === | ||
+ | Транзакция связывает координационные акты/факты и производственные акты/факты | ||
+ | * основное, что происходит в организации -- это транзакции. | ||
+ | * каждая транзакция проходит между двумя деятельностными ролями: инициатором и исполнителем | ||
+ | * каждая транзакция проходит следующий цикл: | ||
+ | ** инициатор делает запрос (координационный акт, порождающий координационный факт "запрошен производственный факт") | ||
+ | ** исполнитель дает обещание выполнить запрос (координационный акт, порождающий к-факт "п-факт обещан") | ||
+ | ** исполнитель выполняет производственный акт (порождающий п-факт "сделано") | ||
+ | ** исполнитель предъявляет результат работы (к-акт, порождающий к-факт "п-факт предъявлен") | ||
+ | ** инициатор акцептует производственный факт (к-акт, порождающий к-факт "п-факт акцептован") | ||
+ | * поскольку деятели автономны, выполняя свои роли, они могут также делать отказы на запросы, и предъявления, вступать в переговоры относительно сути запросов и предъявлений, аннулировать транзакцию по ее ходу и т.д. | ||
+ | * часто, если инициатор и исполнитель транзакции не могут договориться по ее поводу, они вместо работы попадают в режим дискурса, при котором обсуждается не столько сама транзакция, сколько их полномочия, ответственность, компетенции, правила работы и другие культурные нормы. | ||
+ | |||
+ | === Конструктивная модель === | ||
+ | * Определяет суть предприятия: организационные роли и транзакции между ними (кто что для кого делает). | ||
+ | * Основная трудность в понимании: что такое организационная роль (роль – это не подразделение, не должность, не конкретные люди, не функции). | ||
+ | * Полностью абстрагирована от реализации | ||
+ | * реализация – назначение организационных ролей организационным местам, затем заполнение этих мест конкретными людьми, затем делегирование этими людьми отдельных внутри транзакционных действий другим людям. | ||
+ | * Для мелких предприятий помещается на лист A4, для очень крупных – лист A0. | ||
+ | |||
+ | === Модель процессных шагов === | ||
+ | * DEMO: бизнес-процессы (социальные вопросы: запросов-обещаний, т.е. бизнеса). | ||
+ | * Не-DEMO процессные модели айтишников (IDEF0, Dataflow, Document flow и т.д.) – это «какие-то процессы», точно не бизнес-процессы, они не ухватывают социальную суть организации. | ||
+ | |||
+ | === Модель состояний (производственного мира) === | ||
+ | * Спецификация всех возможных состояний и изменений состояний производственногот мира: | ||
+ | ** Типы бизнес-объектов (часто хитро формулируемых: «членство», «займ») | ||
+ | ** Бизнес-факты (что сделано) | ||
+ | ** Законы состояний мира производства (как связаны между собой бизнес-объекты) | ||
+ | ** Законы изменения состояний мира производства (например что чему должно предшествовать). Тут связь с процессной моделью (производственный и координационный миры связаны через транзакции). | ||
+ | * Нотация: «родная» ORM-2 (программистский язык спецификации данных), возможен 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). | ||
[[Категория:Подходы]] | [[Категория:Подходы]] |
Версия 10:35, 16 декабря 2015
Подход DEMO (рус.) - (Design and Engineering Methodology for Organisations) - методология проектирования и инжиниринга организаций. DEMO описывает положения теории речевых актов в отношении к инженерии предприятий.
Содержание
Концепция
В DEMO все действия различаются на:
- производственные (действия по изменению вещества или информации),
- координационные (поручения работы, обещания выполнить работу, сообщение о выполнении работы, подтверждение выполнения работы, отказ от выполнения или приёмки работы).
Исполнители работ в DEMO называемые actor (актёр, исполнитель) имеют как компетенции по выполнению производственных действий (или отказу от них), так и полномочия по выполнению координационных действий. Каждое действие в DEMO называется трансакцией и проходит по следующему циклу:
- инициатор трансакции желает получить какие-то результаты,
- инициатор запрашивает их у выполнителя работ,
- выполнитель работ обещает выдать результаты,
- выполнитель производит их,
- выполнитель объявляет о готовности результатов работы,
- инициатор работ принимает результат работы,
- инициатор использует результаты работы в своей части производства.
Используемые модели
Транзакция
Транзакция связывает координационные акты/факты и производственные акты/факты
- основное, что происходит в организации -- это транзакции.
- каждая транзакция проходит между двумя деятельностными ролями: инициатором и исполнителем
- каждая транзакция проходит следующий цикл:
- инициатор делает запрос (координационный акт, порождающий координационный факт "запрошен производственный факт")
- исполнитель дает обещание выполнить запрос (координационный акт, порождающий к-факт "п-факт обещан")
- исполнитель выполняет производственный акт (порождающий п-факт "сделано")
- исполнитель предъявляет результат работы (к-акт, порождающий к-факт "п-факт предъявлен")
- инициатор акцептует производственный факт (к-акт, порождающий к-факт "п-факт акцептован")
- поскольку деятели автономны, выполняя свои роли, они могут также делать отказы на запросы, и предъявления, вступать в переговоры относительно сути запросов и предъявлений, аннулировать транзакцию по ее ходу и т.д.
- часто, если инициатор и исполнитель транзакции не могут договориться по ее поводу, они вместо работы попадают в режим дискурса, при котором обсуждается не столько сама транзакция, сколько их полномочия, ответственность, компетенции, правила работы и другие культурные нормы.
Конструктивная модель
- Определяет суть предприятия: организационные роли и транзакции между ними (кто что для кого делает).
- Основная трудность в понимании: что такое организационная роль (роль – это не подразделение, не должность, не конкретные люди, не функции).
- Полностью абстрагирована от реализации
- реализация – назначение организационных ролей организационным местам, затем заполнение этих мест конкретными людьми, затем делегирование этими людьми отдельных внутри транзакционных действий другим людям.
- Для мелких предприятий помещается на лист A4, для очень крупных – лист A0.
Модель процессных шагов
- DEMO: бизнес-процессы (социальные вопросы: запросов-обещаний, т.е. бизнеса).
- Не-DEMO процессные модели айтишников (IDEF0, Dataflow, Document flow и т.д.) – это «какие-то процессы», точно не бизнес-процессы, они не ухватывают социальную суть организации.
Модель состояний (производственного мира)
- Спецификация всех возможных состояний и изменений состояний производственногот мира:
- Типы бизнес-объектов (часто хитро формулируемых: «членство», «займ»)
- Бизнес-факты (что сделано)
- Законы состояний мира производства (как связаны между собой бизнес-объекты)
- Законы изменения состояний мира производства (например что чему должно предшествовать). Тут связь с процессной моделью (производственный и координационный миры связаны через транзакции).
- Нотация: «родная» ORM-2 (программистский язык спецификации данных), возможен 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).