Моделе-ориентированный инженерный менеджмент (model-based engineering management)
Если есть моделе-ориентированная системная инженерия (MBSE, model-based systems engineering), то должен быть и моделе-ориентированный инженерный менеджмент (MBEM, model-based engineering management).
1. Понятие моделе-ориентированности.
Моделе-ориентированность чего-то (model-based something) означает использование моделей, опирающихся на какое-то формальное представление данных -- метамодель/схему/модель данных. По факту моделе-ориентированность (в отличие, например, от диаграммо-ориентированности) и датацентричность (в отличие от документоцентричности) сливаются в их определениях, несмотря на некоторые тонкости, связанные с особенностями определения документов. В моделе-ориентированной дисциплине различные группы описаний (views) выводятся из данных набора моделей, основанных на онтологии/схеме данных/справочных данных/метамодели/модели данных -- и это означает неминуемую датацентричность. С другой стороны, мы вполне можем рассмотреть набор моделей (models) как набор отдельных документов, с указанием правил соответствия (correspondence rules). Но сам этот подход к интеграции данных разных моделей с мэппингом между ними рано или поздно приведет, как показывает пример ISO 15926, к появлению общей нейтральной для всех использованных моделей объемлющей онтологии (upper ontology), в терминах которой только и можно говорить о соответствии (correspondence, mapping) элементов данных разных моделей.
Обычно понятие моделе-ориентированности связывают с использованием какого-то архитектурного языка (architecture description language, прежде всего SysML, таинственно замалчиваемый на странице http://en.wikipedia.org/wiki/Architecture_description_language, но все остальные там поминаемыме: AADL, ArchiMate и т.д.). Архитектурный язык обычно включает в себя как обязательную часть средства для выражения требований, хотя иногда моделе-ориентированность связывают и с собственно инженерией требований (см. обзор стандартов представления требований: http://ailev.livejournal.com/900086.html).
Дискуссия по современным архитектурным языкам показывает, что они обычно плохи в выражении необходимых для системной инженерии отношений по сравнению с онтологическими языками. С другой стороны, указывается на лучшую понятность этих языков для инженеров по сравнению с онтологическими языками. Из этой ситуации три главных выхода:
-- использование понятия architectural framework (типа TOGAF, MoDAF и т.д.), в которых предписывается какой-то набор viewpoints и правил соответствия между ними. Это классическое развитие ISO 42010, но у этого направления огромная критика (ибо детально разрабатываются ненужные модели, а нужные объекты и отношения оказываются неописанными)
-- предложение новых архитектурных языков, которые пытаются соединить лучшие свойства современных архитектурных языков и онтологических языков (тут прежде всего можно выделить работы по OPML: http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371).
-- констатацией факта, что разные viewpoints нужно будет объединять в подогнанный под конкретную ситуацию "небиблиотечный" architectural framework в рамках чисто онтологического языка, оставляя "понятность инженерам" на уровень domain-specific languages (типа нотаций P&ID, диаграмм GORE и прочих "узких" техник). Это подход, опирающийся на интеграцию данных, с такими примерами, как ISO 15926 и Simantics.
Мы сами пока движемся в третьем направлении, тесно связанном с ситууационной инженерией методов (situational method engineeering): набор языков/нотаций, нужный для каждого отдельного предпринятия уникален (language из ISO 24744), но все эти языки являются подмножеством общего набора понятий для необходимой совокупности компонент методов -- и этот общий набор понятий мы отражаем в библиотеке справочных данных ISO 15926. Именно в этом направлении мы двигаемся в dot15926.
2. Диаграммо-ориентированость и моделе-ориентированность в инженерном менеджменте.
В инженерном менеджменте по принципу нужно использовать как диаграммы, так и модели. Диаграммы используются на флип-чартах, когда нужно провести мозговой штурм, о принципиально чем-то договориться. Лучше фломастера и флип-чарта для этой цели ничего еще не придумано: диаграмма рождается и модифицируется прямо по ходу разговора, а неформальный уровень живого группового обсуждения полностью соответствует неформальной природе используемых диаграмм (хотя за этими неформальными диаграммами могут стоять довольно глубокие теории, например за диаграммами "скорописи стрелочками" жизненного цикла, пункт 2 в http://ailev.livejournal.com/917251.html).
Тем не менее, в инженерном менеджменте существует огромное количество моделей (формальных описаний, опирающихся на какую-то модель данных): за диаграммами MS Project спрятана именно такая модель, в организационных моделерах (типа Business Studio или БигМастер), порождающих кипы альбомов процессных диаграмм для системы менеджмента качества используются именно такие модели, да и бухгалтерские учетные системы, а также управленческий учёт -- это ведь тоже самые настоящие модели.
Другое дело, что эти модели никогда не рассматривались как основной артефакт (рабочий продукт), с которым работают менеджеры (в том числе -- инженерные менеджеры). Моделе-ориентированный инженерный менеджмент подразумевает, что модели в их взаимосвязи (ранее я говорил о "симултреке" -- вот предыдущий заход двухлетней давности: http://ailev.livejournal.com/610341.html и буквально через месяц http://ailev.livejournal.com/613594.html) являются основным артефактом, кроме собственно "системы в железе, бетоне и людях", по которому принимаются менеджерские решения -- так же, как инженерные решения принимаются по инженерным моделям (электрическим схемам, чертежам, прочностным расчётам и т.д.). Менеджерская модель делает невидимое видимым, именно модели позволяют увидеть "организацию", что невозможно сделать простым глазом, наблюдая за рабочей суетой входящих в эту организацию сотрудников (http://ailev.livejournal.com/510186.html, 2007г.).
3. Какие модели интересуют инженерного менеджера?
3.1. Модели продукта
Инженерного менеджера интересуют модели продукта (целевой системы), равно как и системного инженера. По этим моделям инженерный менеджер оценивает различные риски, и принимает менеджерские решения по снижению этих рисков: добавляет денег и других ресурсов, удлиняет сроки (в отличие от системного инженера, который для снижения рисков изменяет функции и конструкцию системы, т.е. изменяет архитектуру). Вполне можно думать о PLM-системе, поддерживающей эту модель продукта (product model). Эти модели поддерживают главным образом технические практики ISO 15288.
3.2. Модели проекта
Тем самым можно признать, что у инженерного менеджера в качестве целевой (той, которую менеджер "делает") обычно выступает обеспечивающая система -- расширенное предприятие. Часто о модели этой системы говорят как о модели проекта (project model). Тут нужно обязательно отметить:
-- речь идет о проекте в смысле проектного управления ("план производства работ", и обеспечивающие его ресурсы).
-- согласно современным воззрениями операционного управления (operational management, часть engineering managmenet), проектами можно управлять только в совокупности (см., например, factory physics или упрощенный вариант в форме Голдратовской теории ограничений).
Эти модели приближенно можно отнести к поддерживающим проектные практики ISO 15288.
Сюда же можно было бы отнести модели практик жизненного цикла (регламенты, нормы и правила выполнения работ, "шаблоны проектов"="бизнес-процессы").
3.3. Модели организации
Согласно закону Конвея структура организации/обеспечивающей системы и структура целевой системы тесно зависят друг от друга. Поэтому инженерному менеджеру нужно также знать об организации (конструкцию которой мы понимаем по DEMO: какие транзакции могут инициировать акторы, и какие люди назначены какими акторами). Это подчиненности (органиграммы), модели для talent management (компетенции, карьерные планы и т.д.), финансовые (бухгалтерские и управленческие) модели.
Эти модели совсем уж приближенно можно отнести к организационным (в оригинале -- "project-enabling processes") практикам и практикам соглашения ISO 15288.
4. Отличия от других подходов к моделям инженерного менеджмента
Ничто не ново под луной: модели в инженерном менеджменте использовались, используются, и будут использовать -- даже если саму деятельность не называют инженерным менеджментом, а используемые менеджерами модели не называют моделями. Тем не менее, укажем на некоторые отличия от других вариантов описаний, и подчеркнем преимущества нашего подхода.
Прежде всего, наш подход исходит из того, что инженерные менеджеры должны в конечном итоге обеспечить выпуск целевой системы, т.е. обеспечить процесс системной инженерии (не забываем, что системная инженерия -- это не только проектирование, но и интеграция тоже: у V-диаграммы два плеча!). Оно понятно, что перед general managers могут стоять и другие задачи, определяемые собственником (типа "вовремя провести IPO"), но рано или поздно всё равно встанет вопрос о том, что кто-то что-то для кого-то должен дёшево и вовремя произвести -- продукт ли, сервис ли. Инженерные менеджеры решают именно эту задачу, выпуска продукта или сервиса, они заняты делом. И модели поэтому им нужны соответствующие: почему в основу верхнего уровня классификации нами и был положен набор практик жизненного цикла системной инженерии (из ISO 15288).
Традиционные методы описания архитектуры предприятия (enterpise architecture) обычно плохо описывают важные для инженерных менеджеров аспекты организации, прежде всего связанные с мультипроектным управлением (factory physics). Архитектурные фреймворки, связываемые с enterprise architecture обычно плохо приспособлены для непосредственного использования менеджерами: они больше пригодны для организации работы айтишников, которым нужно отслеживать информационные системы. Т.е. айтишники в упор не видят менеджерско-инженерных моделей, им интересно только то, как эти модели раскладываются по информационным системам организации (см. горячую дискуссию по тому, что EA -- это чисто айтишная, а не менеджерская дисциплина: http://setandbma.wordpress.com/2010/05/05/is-enterprise-architecture-dying/). В нашем подходе собственно раскладка моделей по информационным системам ("что уходит в ERP, что уходит в EAM, что уходит в PLM" и т.д.) вторична, а на передний план выходят сами модели -- какие из них входят в какие инжерерно-менеджерские методы, и поэтому должны быть поддержаны.
Другой подход также идёт от айтишников: это нарезка моделей по типам информационных систем, которые их поддерживают: SCM (supply chain management), PM (project management), ERP (enterprise resource planning), EAM (enterpise asset management) и т.д.. Быстро выясняется, что за этими маркетинговыми терминами кроются самые разные (инженерно)менеджерские модели, да еще и гибко перестраиваемые -- и что функционал этих систем может существенно перекрываться. Беда в том, что даже гибкая перестройка этих моделей не даёт шанса на интеграцию данных этих моделей -- даже если применять агрессивную политику MDM (master data management). Наш подход подразумевает содержательное рассмотрение необходимых моделей, и только потом раскладывание этих моделей по информационным системам (ну, или на предприятиях с большим числом legacy моделей, содержательно рассматривается набор этих моделей, интегрируемый в рамках одной онтологии, например с использованием "ISO 15926 outside").
Третий подход связан с обсуждением многочисленных моделей, соответствующих лучшим инженерно-менеджерским практикам. Именно так устроены современные учебники инженерного менеджмента: открываешь их, а там спрятаны самые разнообразые модели. Но эти все модели абсолютно не связаны между собой! Никакой единой картины мира из этих моделей не составишь. Это не наш путь, наш путь -- интегрированная модель системы.
В любом случае, моделе-ориентированный инженерный менеджмент предполагает работу с проектными и организационными моделями (и представляющими их артефактами -- документами, экранными формами и т.д.) как явно выраженную во всех практиках и основную для повышения качества принимаемых решений, и унификацию подхода ко всем этим моделям на основе представления (в том числе расширенной) организации как системы (вернее, системы систем).
5. Основные задачи моделе-ориентированного инженерного менеджмента
Основными задачами моделе-ориентированного инженерного менеджмента (по аналогии с основными задачами моделе-ориентированной системной инженерии) являются:
-- сейчас: предотвращение коллизий в многочисленных менеджерских моделях (ср. СУЖЦ: http://ailev.livejournal.com/926668.html). Должна быть одна на всех версия не только инженерной, но и менеджерской правды. Это очень непросто, взять хотя бы свод отчетности в холдингах, где дочерние и зависимые организации не то чтобы заботятся об одной версии правды, но зачастую скрывают даже свою версию правды.
-- в ближайшем будущем: порождение моделей (generative management, по аналогии с generative design и generative manufacturing). Это потихоньку происходит с генерацией оптимальных производственных расписаний в операционном менеджменте, но далее должно касаться практически всех моделей. Сложности тут такие же, как и в проектировании: компьютер пока не может заменить талантливого (а часто даже и бесталанного) проектировщика, и ровно в этой же мере не может заменить талантливого (и даже бесталанного) инженерного менеджера, ответственного за создание и ведение инженерно-менеджерских моделей проекта и организации.
В моделе-ориентированном инженерном менеджменте тема управления технологиями (technology management, http://ailev.livejournal.com/928711.html), лидерства (lidership -- как уболтать людей согласовать свои цели, "катализирование сотрудничества"), маркетинга и прочих типичных менеджерских задач тоже затрагивается. Ибо с какими-то моделями эти практики выполнять легче, а с какими-то моделями -- труднее. В каких-то нотациях инженерно-менеджерские модели будут доступны только для разобравшейся в этих моделях элиты, а в каких-то -- для всех сотрудников (расширенного) предприятия. Хотя тут нужно опять вернуться к началу данного постинга и отметить, что диаграммы на флипчартах и диаграм-ориентированный инженерный менеджмент никто не только не отменял, но и вряд ли отменит в ближайшем будущем.
В любом случае, как и в системной инженерии, где нынешнее использование разнородных моделей отнюдь не свидетельствует о де-факто свершившемся переходе к моделе-ориентированной системной инженерии (а кое где и вообще о переходе хоть к какой-то системной инженерии), так и в инженерном менеджменте повсеместное использование моделей (даже поддержаных ERM, EAM и SCM системами) не означает свершившегося де-факто перехода к моделе-ориентированному инженерному менеджменту.
Итого: особенности нашего подхода к моделе-ориентированному инженерному менеджменту:
-- использование инженерного менеджмента в интерпретации "инженерного подхода к менеджменту" (enterprise engineering, организация как система)
-- использование каталога компонент методов PraxOS (т.е. не любых моделей для любых организационных/менеджерских практик/методов, а тщательно отобранных/разработанных моделей для тщательно отобранных методов)
-- использование онтологической интеграции данных для предметно-специфических моделей (ISO 15926 как платформа для интеграции моделей, представленных в разных DSL)
На наш век тут работы заведомо хватит, чем и займёмся.
1. Понятие моделе-ориентированности.
Моделе-ориентированность чего-то (model-based something) означает использование моделей, опирающихся на какое-то формальное представление данных -- метамодель/схему/модель данных. По факту моделе-ориентированность (в отличие, например, от диаграммо-ориентированности) и датацентричность (в отличие от документоцентричности) сливаются в их определениях, несмотря на некоторые тонкости, связанные с особенностями определения документов. В моделе-ориентированной дисциплине различные группы описаний (views) выводятся из данных набора моделей, основанных на онтологии/схеме данных/справочных данных/метамодели/модели данных -- и это означает неминуемую датацентричность. С другой стороны, мы вполне можем рассмотреть набор моделей (models) как набор отдельных документов, с указанием правил соответствия (correspondence rules). Но сам этот подход к интеграции данных разных моделей с мэппингом между ними рано или поздно приведет, как показывает пример ISO 15926, к появлению общей нейтральной для всех использованных моделей объемлющей онтологии (upper ontology), в терминах которой только и можно говорить о соответствии (correspondence, mapping) элементов данных разных моделей.
Обычно понятие моделе-ориентированности связывают с использованием какого-то архитектурного языка (architecture description language, прежде всего SysML, таинственно замалчиваемый на странице http://en.wikipedia.org/wiki/Architecture_description_language, но все остальные там поминаемыме: AADL, ArchiMate и т.д.). Архитектурный язык обычно включает в себя как обязательную часть средства для выражения требований, хотя иногда моделе-ориентированность связывают и с собственно инженерией требований (см. обзор стандартов представления требований: http://ailev.livejournal.com/900086.html).
Дискуссия по современным архитектурным языкам показывает, что они обычно плохи в выражении необходимых для системной инженерии отношений по сравнению с онтологическими языками. С другой стороны, указывается на лучшую понятность этих языков для инженеров по сравнению с онтологическими языками. Из этой ситуации три главных выхода:
-- использование понятия architectural framework (типа TOGAF, MoDAF и т.д.), в которых предписывается какой-то набор viewpoints и правил соответствия между ними. Это классическое развитие ISO 42010, но у этого направления огромная критика (ибо детально разрабатываются ненужные модели, а нужные объекты и отношения оказываются неописанными)
-- предложение новых архитектурных языков, которые пытаются соединить лучшие свойства современных архитектурных языков и онтологических языков (тут прежде всего можно выделить работы по OPML: http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371).
-- констатацией факта, что разные viewpoints нужно будет объединять в подогнанный под конкретную ситуацию "небиблиотечный" architectural framework в рамках чисто онтологического языка, оставляя "понятность инженерам" на уровень domain-specific languages (типа нотаций P&ID, диаграмм GORE и прочих "узких" техник). Это подход, опирающийся на интеграцию данных, с такими примерами, как ISO 15926 и Simantics.
Мы сами пока движемся в третьем направлении, тесно связанном с ситууационной инженерией методов (situational method engineeering): набор языков/нотаций, нужный для каждого отдельного предпринятия уникален (language из ISO 24744), но все эти языки являются подмножеством общего набора понятий для необходимой совокупности компонент методов -- и этот общий набор понятий мы отражаем в библиотеке справочных данных ISO 15926. Именно в этом направлении мы двигаемся в dot15926.
2. Диаграммо-ориентированость и моделе-ориентированность в инженерном менеджменте.
В инженерном менеджменте по принципу нужно использовать как диаграммы, так и модели. Диаграммы используются на флип-чартах, когда нужно провести мозговой штурм, о принципиально чем-то договориться. Лучше фломастера и флип-чарта для этой цели ничего еще не придумано: диаграмма рождается и модифицируется прямо по ходу разговора, а неформальный уровень живого группового обсуждения полностью соответствует неформальной природе используемых диаграмм (хотя за этими неформальными диаграммами могут стоять довольно глубокие теории, например за диаграммами "скорописи стрелочками" жизненного цикла, пункт 2 в http://ailev.livejournal.com/917251.html).
Тем не менее, в инженерном менеджменте существует огромное количество моделей (формальных описаний, опирающихся на какую-то модель данных): за диаграммами MS Project спрятана именно такая модель, в организационных моделерах (типа Business Studio или БигМастер), порождающих кипы альбомов процессных диаграмм для системы менеджмента качества используются именно такие модели, да и бухгалтерские учетные системы, а также управленческий учёт -- это ведь тоже самые настоящие модели.
Другое дело, что эти модели никогда не рассматривались как основной артефакт (рабочий продукт), с которым работают менеджеры (в том числе -- инженерные менеджеры). Моделе-ориентированный инженерный менеджмент подразумевает, что модели в их взаимосвязи (ранее я говорил о "симултреке" -- вот предыдущий заход двухлетней давности: http://ailev.livejournal.com/610341.html и буквально через месяц http://ailev.livejournal.com/613594.html) являются основным артефактом, кроме собственно "системы в железе, бетоне и людях", по которому принимаются менеджерские решения -- так же, как инженерные решения принимаются по инженерным моделям (электрическим схемам, чертежам, прочностным расчётам и т.д.). Менеджерская модель делает невидимое видимым, именно модели позволяют увидеть "организацию", что невозможно сделать простым глазом, наблюдая за рабочей суетой входящих в эту организацию сотрудников (http://ailev.livejournal.com/510186.html, 2007г.).
3. Какие модели интересуют инженерного менеджера?
3.1. Модели продукта
Инженерного менеджера интересуют модели продукта (целевой системы), равно как и системного инженера. По этим моделям инженерный менеджер оценивает различные риски, и принимает менеджерские решения по снижению этих рисков: добавляет денег и других ресурсов, удлиняет сроки (в отличие от системного инженера, который для снижения рисков изменяет функции и конструкцию системы, т.е. изменяет архитектуру). Вполне можно думать о PLM-системе, поддерживающей эту модель продукта (product model). Эти модели поддерживают главным образом технические практики ISO 15288.
3.2. Модели проекта
Тем самым можно признать, что у инженерного менеджера в качестве целевой (той, которую менеджер "делает") обычно выступает обеспечивающая система -- расширенное предприятие. Часто о модели этой системы говорят как о модели проекта (project model). Тут нужно обязательно отметить:
-- речь идет о проекте в смысле проектного управления ("план производства работ", и обеспечивающие его ресурсы).
-- согласно современным воззрениями операционного управления (operational management, часть engineering managmenet), проектами можно управлять только в совокупности (см., например, factory physics или упрощенный вариант в форме Голдратовской теории ограничений).
Эти модели приближенно можно отнести к поддерживающим проектные практики ISO 15288.
Сюда же можно было бы отнести модели практик жизненного цикла (регламенты, нормы и правила выполнения работ, "шаблоны проектов"="бизнес-процессы").
3.3. Модели организации
Согласно закону Конвея структура организации/обеспечивающей системы и структура целевой системы тесно зависят друг от друга. Поэтому инженерному менеджеру нужно также знать об организации (конструкцию которой мы понимаем по DEMO: какие транзакции могут инициировать акторы, и какие люди назначены какими акторами). Это подчиненности (органиграммы), модели для talent management (компетенции, карьерные планы и т.д.), финансовые (бухгалтерские и управленческие) модели.
Эти модели совсем уж приближенно можно отнести к организационным (в оригинале -- "project-enabling processes") практикам и практикам соглашения ISO 15288.
4. Отличия от других подходов к моделям инженерного менеджмента
Ничто не ново под луной: модели в инженерном менеджменте использовались, используются, и будут использовать -- даже если саму деятельность не называют инженерным менеджментом, а используемые менеджерами модели не называют моделями. Тем не менее, укажем на некоторые отличия от других вариантов описаний, и подчеркнем преимущества нашего подхода.
Прежде всего, наш подход исходит из того, что инженерные менеджеры должны в конечном итоге обеспечить выпуск целевой системы, т.е. обеспечить процесс системной инженерии (не забываем, что системная инженерия -- это не только проектирование, но и интеграция тоже: у V-диаграммы два плеча!). Оно понятно, что перед general managers могут стоять и другие задачи, определяемые собственником (типа "вовремя провести IPO"), но рано или поздно всё равно встанет вопрос о том, что кто-то что-то для кого-то должен дёшево и вовремя произвести -- продукт ли, сервис ли. Инженерные менеджеры решают именно эту задачу, выпуска продукта или сервиса, они заняты делом. И модели поэтому им нужны соответствующие: почему в основу верхнего уровня классификации нами и был положен набор практик жизненного цикла системной инженерии (из ISO 15288).
Традиционные методы описания архитектуры предприятия (enterpise architecture) обычно плохо описывают важные для инженерных менеджеров аспекты организации, прежде всего связанные с мультипроектным управлением (factory physics). Архитектурные фреймворки, связываемые с enterprise architecture обычно плохо приспособлены для непосредственного использования менеджерами: они больше пригодны для организации работы айтишников, которым нужно отслеживать информационные системы. Т.е. айтишники в упор не видят менеджерско-инженерных моделей, им интересно только то, как эти модели раскладываются по информационным системам организации (см. горячую дискуссию по тому, что EA -- это чисто айтишная, а не менеджерская дисциплина: http://setandbma.wordpress.com/2010/05/05/is-enterprise-architecture-dying/). В нашем подходе собственно раскладка моделей по информационным системам ("что уходит в ERP, что уходит в EAM, что уходит в PLM" и т.д.) вторична, а на передний план выходят сами модели -- какие из них входят в какие инжерерно-менеджерские методы, и поэтому должны быть поддержаны.
Другой подход также идёт от айтишников: это нарезка моделей по типам информационных систем, которые их поддерживают: SCM (supply chain management), PM (project management), ERP (enterprise resource planning), EAM (enterpise asset management) и т.д.. Быстро выясняется, что за этими маркетинговыми терминами кроются самые разные (инженерно)менеджерские модели, да еще и гибко перестраиваемые -- и что функционал этих систем может существенно перекрываться. Беда в том, что даже гибкая перестройка этих моделей не даёт шанса на интеграцию данных этих моделей -- даже если применять агрессивную политику MDM (master data management). Наш подход подразумевает содержательное рассмотрение необходимых моделей, и только потом раскладывание этих моделей по информационным системам (ну, или на предприятиях с большим числом legacy моделей, содержательно рассматривается набор этих моделей, интегрируемый в рамках одной онтологии, например с использованием "ISO 15926 outside").
Третий подход связан с обсуждением многочисленных моделей, соответствующих лучшим инженерно-менеджерским практикам. Именно так устроены современные учебники инженерного менеджмента: открываешь их, а там спрятаны самые разнообразые модели. Но эти все модели абсолютно не связаны между собой! Никакой единой картины мира из этих моделей не составишь. Это не наш путь, наш путь -- интегрированная модель системы.
В любом случае, моделе-ориентированный инженерный менеджмент предполагает работу с проектными и организационными моделями (и представляющими их артефактами -- документами, экранными формами и т.д.) как явно выраженную во всех практиках и основную для повышения качества принимаемых решений, и унификацию подхода ко всем этим моделям на основе представления (в том числе расширенной) организации как системы (вернее, системы систем).
5. Основные задачи моделе-ориентированного инженерного менеджмента
Основными задачами моделе-ориентированного инженерного менеджмента (по аналогии с основными задачами моделе-ориентированной системной инженерии) являются:
-- сейчас: предотвращение коллизий в многочисленных менеджерских моделях (ср. СУЖЦ: http://ailev.livejournal.com/926668.html). Должна быть одна на всех версия не только инженерной, но и менеджерской правды. Это очень непросто, взять хотя бы свод отчетности в холдингах, где дочерние и зависимые организации не то чтобы заботятся об одной версии правды, но зачастую скрывают даже свою версию правды.
-- в ближайшем будущем: порождение моделей (generative management, по аналогии с generative design и generative manufacturing). Это потихоньку происходит с генерацией оптимальных производственных расписаний в операционном менеджменте, но далее должно касаться практически всех моделей. Сложности тут такие же, как и в проектировании: компьютер пока не может заменить талантливого (а часто даже и бесталанного) проектировщика, и ровно в этой же мере не может заменить талантливого (и даже бесталанного) инженерного менеджера, ответственного за создание и ведение инженерно-менеджерских моделей проекта и организации.
В моделе-ориентированном инженерном менеджменте тема управления технологиями (technology management, http://ailev.livejournal.com/928711.html), лидерства (lidership -- как уболтать людей согласовать свои цели, "катализирование сотрудничества"), маркетинга и прочих типичных менеджерских задач тоже затрагивается. Ибо с какими-то моделями эти практики выполнять легче, а с какими-то моделями -- труднее. В каких-то нотациях инженерно-менеджерские модели будут доступны только для разобравшейся в этих моделях элиты, а в каких-то -- для всех сотрудников (расширенного) предприятия. Хотя тут нужно опять вернуться к началу данного постинга и отметить, что диаграммы на флипчартах и диаграм-ориентированный инженерный менеджмент никто не только не отменял, но и вряд ли отменит в ближайшем будущем.
В любом случае, как и в системной инженерии, где нынешнее использование разнородных моделей отнюдь не свидетельствует о де-факто свершившемся переходе к моделе-ориентированной системной инженерии (а кое где и вообще о переходе хоть к какой-то системной инженерии), так и в инженерном менеджменте повсеместное использование моделей (даже поддержаных ERM, EAM и SCM системами) не означает свершившегося де-факто перехода к моделе-ориентированному инженерному менеджменту.
Итого: особенности нашего подхода к моделе-ориентированному инженерному менеджменту:
-- использование инженерного менеджмента в интерпретации "инженерного подхода к менеджменту" (enterprise engineering, организация как система)
-- использование каталога компонент методов PraxOS (т.е. не любых моделей для любых организационных/менеджерских практик/методов, а тщательно отобранных/разработанных моделей для тщательно отобранных методов)
-- использование онтологической интеграции данных для предметно-специфических моделей (ISO 15926 как платформа для интеграции моделей, представленных в разных DSL)
На наш век тут работы заведомо хватит, чем и займёмся.