1. Метаонтология (не Upper Ontology, а собственно сам язык представления знаний). Бывает -- семантическая сеть (ОргМастер), бывает UML, бывает OWL. В этом месте мы договариваемся, что в мире бывают типизированные сущности и связи, а некоторые свойства сущностей наследуются вдоль некоторых типов связей.
2. Оргонтология (а это как раз Upper Ontology, но в одной предметной области). В этом месте мы договариваемся, что мы можем узреть в организации. Как правило, это ролевая структура, штатная структура, функции/процессы (тут мутное место), документы/данные, базы данных, архивы, статусы типа "утверждений" и "согласований, сотрудники и т.д. Эта оргонтология, как правило, должна быть расширяема, и поэтому сразу выражается в терминах метаонтологии. Выделяются три уровня (название произвольны): оргонтология -- минимальный набор сущностей и связей, необходимых для моделирования любой организации; опорная онтология -- это расширение оргонтологии для случая некоторого важного типа организаций (государство, фирма, церковь и т.д.), референсная онтология -- расширение опорной онтологии для какой-то образцовой организации. Работа в типичном случае -- это моделирование с использованием референсной онтологии, в редких случаях требуется обращение к моделированию на уровне опорной онтологии. Опорная онтология шевелится крайне редко, раз в год по итогам многих проектов. Каждое изменение организационной онтологии -- крупное событие в мире оргмоделирования.
Тут нужно заметить, что вполне можно представить себе оргонтологию, выраженную и в UML, и в орглане (в фирме БИГ этот язык называют OReL), и в OWL. Только выражение развитой оргонтологии в терминах конкретной метаонтологии -- весьма и весьма нетривиальная задача, которая должна включать в себя проверку на сотнях моделирований самых разных организаций самыми разными людьми. Проблема тут в том, что развитых организационных онтологий (формальных способов описания организации), операционно удобно синтезирующих самые разные знания об организации -- от стратегических ее целей до полей документов в каких-то конкретных процессах, от структуры холдинга до отражения статусов и содержания наполовину завизированного месячного кассового плана -- известно немного. Много известно про метаонтологии (например, любую организацию можно описать на фортране, или на UML, или на макроассемблере, если договориться со специалистами по организации, как это делать), но мало известно случаев, когда специалисты по организации договорились.
Отдельно ставится вопрос про машинного исполнителя процессов, описанных в моделях, или экспорта "исполнимого кода" (скажем, можно ли из информации модели синтезировать текст BPEL -- тут мне приходит в голову именно "синтез программ из описаний", ибо вряд ли процесс можно моделировать на BPEL, указывая где-то связь процесса с его стратегическими целями, показателями бюджетирования, привязкой к должностям исполнителей и прочим всяким, что там получается в процессе. Вопрос о том, как запускать планировщик типа critical chain или MRP II над десятком процессов, выраженных в BPEL, я вообще опущу). Конечно, код должен быть исполнимым, если дело дошло до кода. Но меня интересуют и те случаи, в которых дело до кода не доходит, а модель используется исключительно человеком с целью поразмышлять об организации. Получить отчет из модели для размышления над ним человеком и для размышления над ним каким-нибудь BPEL-движком -- это абсолютно однотипные операции.
3. Типовые отчеты. Это разные типы нотации для моделей, в которых для разных категорий пользователей модели (разработчиков, исполнителей, начальства, любопытных со стороны и т.д.) удобно обозревать разные формы. Для случайной работы очень удобны графические картинки, для профессиональной -- всякие текстовые формы (скажем, табличный эквивалент IDEF0-диаграммы. Видел, внушаить). Это все можно потестить на каких-нибудь фокус-группах. Если есть типовые отчеты, то можно говорить о каком-то WYSIWYG во вводе моделей, а если нет -- то это будет какое-то другое редактирование (более быстрое, удобное, но много менее понятное и интуитивное). Если есть типовые отчеты, можно учить людей их читать. Если есть типовые отчеты, то можно сравнивать модели разных организаций.
4. Софт редактора и других конверторов импорта, софт генератора отчетов и других конверторов экспорта. Тут, конечно, пусть расцветают сто цветов, если есть стандарты по предыдущим трем пунктам. Победит удобнейший и дешевейший. Пока самый дешевый софт этого рода -- программа ГосМастер (GPL), но она не является удобнейшей. Тем не менее, в нее заложено несколько очень крутых интерфейсных решений, которые дают ей фору перед многими другими "красивыми графическими решениями". Тут, правда, нужно сразу оговориться, какие пользователи будут у этого софта (так, в Ворде писать компьютерные программы совершенно неудобно, а в рабочих средах для программирования неудобно верстать документацию).
Наворочено в этих четырех сферах очень много всякого, от ARIS до безвестных университетских оргонтологий на OWL. Но каждый из подходов к оргмоделированию должен определиться с выбором в этих четырех областях -- и сравнивать эти подходы можно по достигнутым в каждой из этих областей результатам.
Я бы лично во всем этом месиве из computer science, usability и organizational engineering отдал приоритет качеству оргонтологии, а качество оргонтологии тестировал бы на легкости моделирования голдратовщины на предприятиях (да, с throughput accounting вместо ABC) и возможности описывать государство. Либо вы очень четко говорите, что такое организация в ее целостности, и какова должна быть методика ее описания, либо вам не поможет никакой стандарт метаонтологии и качественный софт.
Пока я считаю, что такой случай организационно-центричного описания (плохого и кривого, конечно, но существующего в природе) и сопутствующей практики более-менее единообразного подхода к оргмоделированию разных типов организаций есть в подходе фирмы БИГ. Метаонтология там -- семантическая сеть с весьма навороченными возможностями, организационная онтология тоже довольно кучерява, выходные формы небезинтересны. А главное -- все они согласованы друг с другом. Дьявол кроется, конечно, в семантике -- а она спрятана в исполнителях, которые ползают по этой сети. А исполнители воплощены в софте, что вроде как нехорошо, но поведение этих исполнителей может быть описано. Да и софт этот (в простейшем, правда, виде: программа ГосМастер -- без хелпа и с неправильно прописанной лицензией, но работает) доступен (http://www.elrussia.ru/62148, а методики и стандарты брать тут -- http://www.elrussia.ru/59559 UPDATE -- это обрезанная по свойствам ОргМастера, но рабочая версия, а учебная полная по свойствам, но ограниченная по размерам модели версия лежит в обмен на анкету с вашими координатами тут -- http://www.big.spb.ru/bigmaster/demo/edu/), что делает персонажей этого варианта весьма харизматическими лидерами при всех их прочих недостатках. А недостатков, конечно, более чем есть. У наличествующей и бесплатной вещи всегда больше недостатков, нежели у платной и отсутствующей, это понятно.