DEMO
Материал из PraxOS
DEMO (Design and Engineering Methodology for Organisations) - методология проектирования и инжиниринга организаций.
Содержание |
Первоисточники
Наиболее полно изложена: Jan L.G.Dietz, «Enterprise ontology. Theory and methodology», Springer, 2006 (для получения книжки в электронном виде залогиньтесь на странице http://gigapedia.org/items/44155/enterprise-ontology--theory-and-methodology).
Основной вебсайт: http://www.demo.nl (английский и голландский языки)
Состав
Включает:
- Пси-теорию (организационную онтологию: из чего состоит организация)
- Методологию организационного моделирования (как сделать организационную модель для конкретной организации: что спрашивать и как записывать)
Применение
Использовалась
- В проектах крупных реорганизаций, в том числе:
- Royal Dutch Airways (KLM)
- ING-банк
- Rijkswaterstaat (государственное агентство дорожного строительства и водных путей Голландии)
- Многих других (защищены минимум две диссертации на материале практических проектов)
- В виде стандарта VISI, обязательного для использования в крупных государственных инфраструктурных контрактах Голландии (более 200 проектов)
- Множество академических исследовательских проектов в разных странах
Обучение
- Сообщество практики: http://www.demo.nl (английский и голландский языки)
- Cертификация:
- DEMO-профессионалы (экзамен)
- DEMO-мастера (диссертация)
Инструментарий
- Коммерческий софт:
- Essential Business Modeler (http://xprise.com)
- Моделлер Bizzdesign (http://bizzdesign.com)
- Собственные разработки организаций
- модуль к Metis (http://troux.com) в Rijkswaterstaat
- «ручка и бумажка» ввиду чрезвычайной компактности диаграмм, таблицы в MS Exel
Подход
Место в системной инженерии:
- DEMO – это технология и инструмент для процесса «Управление моделью жизненного цикла» (группа процессов поддержки проектов ISO 15288)
- Модель жизненного цикла с точки зрения организатора производства -- это модель DEMO.
- Модель DEMO служит основой для подготовки распорядительной документации (приказов об оргструктуре, процессных стандартов, правил работы, должностных инструкций и т.д.)
DEMO включает организационную онтологию, дающую ответы на вопросы "Из чего состоит организация?", "Что существенно в организации?":
- Теоретические основания:
- Онтология фактов (Бунге, Витгенштейн)
- Системный подход
- теория коммуникативного действия (Хабермас)
- Описывает суть организации, отвлекаясь от реализационных деталей:
- Организационная конструкция (кто что кому обещал)
- Состояние дел (информация о том, что происходит: учеты)
- Процессные шаги (кто что в каком порядке делает)
- Правила деятельности (какие правила работы)
- Поддержана методологией:
- Какие вопросы задавать при моделировании организации
- Какие нотации использовать для организационного моделирования
Связь организационных моделей DEMO и информационных моделей продукции:
- Andries van Renssen предложил Gellish-нотацию для организационной онтологии DEMO (кто что кому обещал, кто что для кого сделал и т.д.).
- Есть Gellish-нотация для информационных моделей продукции (трехмерные модели, процессные схемы, вычислительные модели). Gellish является вариантом реализации ISO 15926.
- Тем самым управленческие информационные системы (учет координационных фактов, назначения ролей) могут быть связаны с информационной моделью продукции (производственные факты).
Функция и конструкция: «черный ящик» и «белый ящик»
- Функция: поведение с точки зрения пользователя, «черный ящик» [автомобиль – это системы освещения, управления, выдачи мощности, торможения].
- Конструкция: структура с точки зрения изготовителя и ремонтника, «белый ящик» [автомобиль состоит из шасси, колес, мотора, ламп].
- Функциональная и конструктивная декомпозиции несводимы друг ко другу.
- DEMO – это конструктивный подход к организации, подход «белого ящика». DEMO онтология используется организатором (конструктором организации), а не менеджером (пользователем организации).
- DEMO не имеет дело с функцией (поведение организации) и назначением/целью организации (отношения со стейкхолдерами). Для анализа функций и целей организации должны быть использованы другие подходы.
Три организации в одной (по Юргену Хабермасу):
- Социальная (главная): кто что у кого/кому запросил, обещал, предъявил, акцептовал – нормология, вопрос менеджеров. Если тут сбой («обещал, но не выполнил») то вместо работы происходит дискурс (договариваются о том, что принято).
- Информационная: какая по содержанию информация нужна для дела (вычисления, рассуждения, формулирование) – инфология, вопрос специалистов-предметников.
- Данных: передача, хранение, копирование информации без понимания, о чем она – даталогия, вопрос айтишников.
Эти три типа организации объединяются тем, что люди имеют способность выполнять действия во всех трех ипостасях.
Два мира (производства и координации):
- мир производства и координации в разговорах о них даны людям в виде фактов -- координационных и производственных.
- люди называются деятелями (actors), которые в силу
- имеющихся у них полномочий занимают деятельностные роли, и обладают
- ответственностью (поэтому могут делать координационные акты, приводящие к появлению новых координационных фактов) и
- компетенцией (поэтому могут делать производственные акты, приводящие к появлению новых производственных фактов).
- Факты – интерсубъектны («между людьми» -- всегда есть предъявление факта и его акцепт: производственные факты не «объективны», даже если они относятся к материальному производству!)
Используемые модели
Транзакция
Транзакция связывает координационные акты/факты и производственные акты/факты
- основное, что происходит в организации -- это транзакции.
- каждая транзакция проходит между двумя деятельностными ролями: инициатором и исполнителем
- каждая транзакция проходит следующий цикл:
- инициатор делает запрос (координационный акт, порождающий координационный факт "запрошен производственный факт")
- исполнитель дает обещание выполнить запрос (координационный акт, порождающий к-факт "п-факт обещан")
- исполнитель выполняет производственный акт (порождающий п-факт "сделано")
- исполнитель предъявляет результат работы (к-акт, порождающий к-факт "п-факт предъявлен")
- инициатор акцептует производственный факт (к-акт, порождающий к-факт "п-факт акцептован")
- поскольку деятели автономны, выполняя свои роли, они могут также делать отказы на запросы, и предъявления, вступать в переговоры относительно сути запросов и предъявлений, аннулировать транзакцию по ее ходу и т.д.
- часто, если инициатор и исполнитель транзакции не могут договориться по ее поводу, они вместо работы попадают в режим дискурса, при котором обсуждается не столько сама транзакция, сколько их полномочия, ответственность, компетенции, правила работы и другие культурные нормы.
Конструктивная модель
- Определяет суть предприятия: организационные роли и транзакции между ними (кто что для кого делает).
- Основная трудность в понимании: что такое организационная роль (роль – это не подразделение, не должность, не конкретные люди, не функции).
- Полностью абстрагирована от реализации
- реализация – назначение организационных ролей организационным местам, затем заполнение этих мест конкретными людьми, затем делегирование этими людьми отдельных внутри транзакционных действий другим людям.
- Для мелких предприятий помещается на лист A4, для очень крупных – лист A0.
Модель процессных шагов
- DEMO: бизнес-процессы (социальные вопросы: запросов-обещаний, т.е. бизнеса).
- Не-DEMO процессные модели айтишников (IDEF0, Dataflow, Document flow и т.д.) – это «какие-то процессы», точно не бизнес-процессы, они не ухватывают социальную суть организации.
Модель состояний (производственного мира)
- Спецификация всех возможных состояний и изменений состояний производственногот мира:
- Типы бизнес-объектов (часто хитро формулируемых: «членство», «займ»)
- Бизнес-факты (что сделано)
- Законы состояний мира производства (как связаны между собой бизнес-объекты)
- Законы изменения состояний мира производства (например что чему должно предшествовать). Тут связь с процессной моделью (производственный и координационный миры связаны через транзакции).
- Нотация: «родная» ORM-2 (программистский язык спецификации данных), возможен Gellish.
- модель состояний DEMO -- это описание видов учитываемой информации: то, что обязательно следует записывать («информационные банки» для производственных фактов). Затем эта информация будет предоставляться и запрашиваться при выполнении транзакций.
Модель действий (правила работы)
- Правила, в соответствии с которыми нужно выполнять транзакции (что-то запрашивать, обещать выполнить, выполнять, предъявлять, акцептовать)
- Деятели используют правила, как рекомендации, а не как догму. Считается, что деятели – живые люди, а не роботы и должны регулярно нарушать правила, если они по-настоящему ответственны.
- Модель действий включает в себя информацию всех других моделей (конструктивной, процессных шагов, состояний).
- Нотация: похожа на язык программирования.
- Из-за сложности и всеохватности разрабатывается редко.
Методология организационного моделирования
- Дан метод построения модели конкретной организации: ответы на какие вопросы нужно искать, приведены нотации для записи моделей, в каком порядке какие модели разрабатывать.
- Место оргмоделей DEMO – в архитектуре организации (Enterprise Architecture, куда входят и другие модели организации – включающие функциональные и реализационные, которых DEMO намеренно избегает).
Литература
- 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).
