Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Организационное моделирование: DEMO

Поскольку нужно таки выбрать формализм организационного моделирования, походим еще по базару (вот, кстати, неплохой пример похода по базару: http://staff.science.uva.nl/~lgommans/pdf/archpres.pdf -- находится www.demo.nl, http://www.e3value.com/ и www.archimate.org).
* * *
Первое, на что натыкается рассеянный взгляд, это DEMO. Достоинства для наших целей:

а) особое внимание уделяется онтологии, есть формализм для UML, ORM, Gellish. Поэтому не должно быть никаких особых препятствий для стыковки с ISO 15926.

б) системный подход, который не хуже чем у других: полная модель бизнес-системы организации в DEMO называется существенной (essential, performa в отличие от informa и forma) моделью, которая состоит из четырех аспектных моделей (view):
-- структурной (construction) модели -- показ ролей деятелей (actors) и типов сделок (транзакций), в которых деятели участвуют как инициаторы и/или исполнители.
-- процессной модели (process) -- как сделки связаны причинно и по условиям,
-- модели состояний (state) -- типы фактов, которые создаются и/или используются в сделках,
-- модели действий (action) -- правила действий, которые деятели применяют в проведении сделок.

в) замечание (например, Martin Op 't Land в его диссертации), что для идентификации похожих деятельностей в организации "язык" структурной модели DEMO более предпочтителен, нежели язык функций или процессов. О том же говорит Mulder, говоря о необходимости структурного (constructional), а не только функционального взгляда на организацию в организационной инженерии. Функционально эквивалентные системы могут иметь разный дизайн. Для меня это главное замечание: начальники спрашивают у меня, как построить (construct) организацию, и я не могу им демонстрировать функциональные IDEF0-описания в ответ на этот вопрос! Мне нужно говорить в терминах акторов и их взаимодействий (сделок), а не сводить всю организацию к функциям и процессам. Функциональный (процессный) дизайн организации -- это только полдела,

г) DEMO дает только язык для описания организаций, но не предполагает никаких критериев организационного строительства. Эти критерии могут быть выражены в языке DEMO по мере их формулирования.

Недостаток (главный): отсутствие легко доступного софта и специалистов (они есть, но в далеких северных европах, на непонятных языках). Хотя для ORM есть софт (а DEMO и ORM -- теперь близнецы-братья, http://www.emmsad.org/2003/Final%20Copy/19.pdf, http://www.demo.nl/option,com_docman/task,doc_download/gid,50/): http://www.orm.net/.

С другой стороны, если на базаре обнаруживается распространенный софт организационного моделирования, то никаких особых теоретических глубин взгляда на организацию за этим софтом обычно не находится и наличие этого софта бесполезно.

У меня такое впечатление, что нужно просто брать DEMO, тяжело вздыхать, осваивать и не выделываться использовать. Другое дело, что терминологию нужно тщательно перевести на русский, как это делали с голдратовской Картой действий и результатов. В переводе оно должно стать проще и понятней на порядок. А вместо софта пока использовать ручку и бумажку -- а там посмотрим.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 0 comments