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-мастера (диссертация)

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

  • Коммерческий софт:
  • Собственные разработки организаций
  • «ручка и бумажка» ввиду чрезвычайной компактности диаграмм, таблицы в 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 намеренно избегает).
Источник — «http://praxos.ru/index.php/DEMO»