Затем нужно ввести понятие организационной модели предприятия по типу информационной модели продукта. В методологии Gellish есть раздел о построении информационной модели здания/предприятия (http://gellish.wiki.sourceforge.net/Facility+Information+Models). Но я ничего не нашел в Gellish об информационной модели организации. Поэтому будем сочинять. По-хорошему, нужно бы на это потратить недельку, чтобы совместить все помянутые онтологии, выдать общий глоссарий с дефинициями в стиле Gellish (определение более специализированных понятий в терминах менее специализированных с указанием дискриминирующих аспектов).
Итак, система, которую мы хотим создавать, а для этого моделировать -- это организация (enterpise). Для модели этой системы выделяется несколько [концептуальных, архитектурных, реализационных, актуальных и т.д.] описаний (view), сделанных с разных точек зрения (viewpoints), соответствующих различным stakeholders, у которых есть различные concerns. Модель одна и едина (презентация, хранение. Например, Gellish Database), стейкхолдеров с их многочисленными concerns и соответствующими им viewpoints много, соответственно много разных порождаемых этими viewpoints view (диаграмм, схем, записей в различных нотациях и т.д. -- репрезентация).
Определим "традиционные фреймворки" Enterprise Architecture (типа захмановского) как viewpoint framework (это стандартный в системной инженерии ход, например в http://www.erikproper.eu/mvo/em.pdf, стр. 120). И забудем пока захмановский сленг, уводящий нас в айтишные функциональные модели. Ежели потом айтишники спросят, что мы делаем -- мы скажем им, что как раз Enterprise Architecture и методы ее реализации.
Для наших оргинжиниринговых целей нужна интеграция следующих уровней описания (тут мы идем вдоль намеченной в Gellish линии, дополняя "типами работы и их продуктами" из картинки в http://www.theenterprisearchitect.eu/archive/2007/05/15/architecture_a_definition):
-- upper ontology, позволяющая собрать разнородные описания, выполненные в соответствии с различными теориями, используемыми в разных view, в общую модель. Получается в итоге метафизических размышлений.
-- метаархитектурный фреймворк (концептуальное описание модели -- что такое система, что такое view, что такое viewpoint, как интегрировать разные описания. Данный текст именно на эту тему. В качестве примера такого фреймворка -- xAF, или архитектура Facility Information Model в методологии Gellish). Получается в итоге методологической работы в предмете системной инженерии.
-- viewpoint framework описания требований (функций) и спецификаций (конструкции) организации и целевой системы (неспецифические требования для предметных областей, относящихся к системе = принципы). Собственно, речь идет как раз об определении конкретного набора viewpoint. Получается в итоге специальной методологической работы (определение методов, построение предметов и определение нотаций их записи). Похоже, что процессно-проектный фреймворк является интегральной частью именно этого уровня описания организации.
-- (архитектурные) описания специфических требований функции и конструкции = архитектура. Получается в результате процесса архитектурного дизайна, совмещенного с процессами сбора и анализа требований. Дизайн обычно дается в отрыве от деталей имплементации, "онтологически". Например, идеальные конструкции ТРИЗ, модели DEMO.
-- (рабочие) описания, содержащие конкретные технологии и реализационные детали -- "рабочий проект", актуализированный до состояния as built. Получается в ходе дискурса/процесса организационных изменений.
-- банк координационных фактов работающей организации.
-- банк производственных фактов
-- банк фактов организационной структры
-- банк фактов о талантах (персонале и его компетенциях)
-- банк фактов об оборудовании
-- банк фактов, относящихся к технологическим состояниям и процессам
-- банк финансовых фактов
Тут нужно четко понимать, что результирующая модель едина (множество самых разных фактов по поводу самых разных объектов, но понятия из разных теорий объединяются с использованием общей онтологии), а различаются только view (ибо различаются viewpoint). Это означает, что какое-нибудь "завинчивание гайки X в корпусе Y работником Z" может быть классифицировано:
-- как рабочий пакет в проектном управлении;
-- как продуктовый акт в DEMO модели (с последующим порождением продуктового факта "гайка X в корпусе Y завинчена", и этот акт выполняется акторской ролью, назначенной на организационное место, на которое назначен работник Z.
-- как элемент транзакции в DEMO модели, выполняемой акторской ролью.
Теперь подробнее про управление проектами. Согласно Koskela сотоварищи, для проектного управления важны сразу три viewpoints:
-- независимые пакеты работ, выполняемые на workstations. Требует описания входных и выходных условий, ресурсов, компетенции, содержания работ и т.д. Именно это view пересекается с workflow в понимании айтишников, а также пересекается с координационным view из DEMO ("проект -- это сеть commitments")
-- логистическое view "потока работ", в котором важна дата завершения всех работ, очереди к воркстанциям, буферы времени и т.д.. Данные для вычислений CCPM или LastPlanner.
-- ценностное view, в котором содержательно обсуждается поток нарастания ценности для заказчика по ходу проекта.
Налицо "квазиклассификация" основных информационных объектов модели множеством views. По факту это позволяет добавлять различные views по потребности -- по мере выявления различных стейкхолдеров, которым они для чего-то понадобились и формулирования viewpoints, соответствующих различным concerns этих стейкхолдеров.
Наблюдение: айтишные viewpoints framework чаще всего устраивают как какую-то матрицу (вслед за Захманом), а любители онтологий больше любят показывать пирамидки (Gellish и xAF). Отложим на потом красивое 2D или 3D представление и сформулируем пока список потребных viewpoints для организационной (т.е. координационной) модели:
-- нормологическое описание организации (независимое от реализации) -- DEMO. Это описание учитывает координационные взаимодействия, необходимые для реализации процессов: важно для решений по сорсингу-аутсорсингу, распределения по подразделениям, разработке координационных (воркфлоу) приложений.
-- инфологическое описание банков фактов (схема данных всех учетов).
-- даталогическое описание организации (форматы сообщений, запросы и их протоколы, конкретные схемы баз данных, мэппинг данных разных приложений и т.д.).
-- технологические процессы (безотносительно разделения труда) плюс оборудование (workflow).
-- три проектных viewpoints: 1. производственный процесс (DSM, workflow и т.д.), 2. логистика (например, диаграммы CCPM), 3. требования и их выполнение (продуктные backlogs из Scrum, или даже "% выполнения работ", переписка в рамках Issue Tracking, сведения о дефектах-багах).
-- viewpoints для информационной модели системы-продукта (по разным САПР: 3D, электрика, цены и т.д.).
Каждое viewpoints существенно зависит от используемых тем или иным стейкхолдером методов (технологий). Так, описания проекта CCPM отличаются от таковых CPM.
Соответственно, нужно выбрать методы (технологии), для них выбрать средства viewpoints, отмоделировать необходимые данные (инфология), отмэппировать эти данные на общую онтологию (например, Gellish), реализовать взаимодействие приложений, поддерживающих разные viewpoint, используя подход ISO 15926/Gellish.
Теперь это все нужно прокритиковать, почистить, навести терминологический порядок, упростить, придумать складное изложение. Один из возможных вариантов -- это описание архитектуры "модели системы" (под которую попадут и Facility Information Model, и оргмодель), а затем в этих общих терминах уже описать оргмодель.