PraxOS 3.0: адаптивная архитектура предпринятия
АРХИМЕЙТ ПО-РУССКИ: ОПУБЛИКОВАНА РУСИФИКАЦИЯ ARCHI
важно
Оригинал взят у ailev в PraxOS 3.0: адаптивная архитектура предпринятия
1. Предпринятие (endeavour или endeavor) -- это организованные на достижение какой-то цели люди. Организованные -- это с понятными полномочиями, и ответственностями по имеющимся в их распоряжении трудом, программами, оборудованием и объектами работы.
Типичные предпринятия -- это:
-- традиционное предприятие (и его работы -- проекты/кейсы, процессы, практики),
-- расширенное предприятие (работы нескольких предприятий в рамках одного проекта),
-- эко-система (http://www.investopedia.com/terms/b/business-ecosystem.asp, http://en.wikipedia.org/wiki/Busineгss_ecosystem -- где нужно говорить уже не столько о проектах/кейсах, сколько о производственных программах),
-- любые другие организованности (банда, церковь, бригада, рабочая группа, департамент, филиал, октябрятская звёздочка и отряд бойскаутов).
Есть цель и достигающая её группа людей с оборудованием и предметами работы -- есть предпринятие для её достижения.
2. Каждое предпринятие может (и должно) рассматриваться в совокупности его:
-- выполнителей работ, т.е. людей (с их компетенциями, соответствующими ролями в работах) и технологий (технологической платформы -- программы и оборудование), вместе дающие возможности (capabilities)
-- работ (процессы, проекты/кейсы/жизненные циклы конечных объектов работы, программы), в том числе внутренних и внешних сервисов
-- объектов работы (в том числе исходных, промежуточных и конечных).
-- предпринятий развития (в которых объектом работы становится само исходное предпринятие, рекурсивно).
Выполнители работ, работы и объекты работы одинаково важны в системном рассмотрении предпринятия, но разные люди могут выпячивать одно или другое. Так, многие предпринятием называют именно структуру выполнителей работ (по аналогии с предприятием -- это люди и оборудование), но в последний десяток лет появилось много людей, которые предпочитают говорить о предпринятиях как о сервисах, проектах и программах, кейсах ("процессно"). Пока очень мало тех, кто говорит о предпринятии как потоках обрабатываемых объектов работы -- но уже есть и такие.
Тем самым предпринятием вполне может называться и проект (который так и определяется, как временное предпринятие -- A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives -- http://en.wikipedia.org/wiki/Project_management).
3. Предпринятие уникально и находится в реальности (нашем пространстве-времени). Онтологически это individual -- оно имеет протяженность (extension) в пространстве-времени. Примеры:
-- ООО "ТехИнвестЛаб.ру" (в названии выпячен структурный аспект -- выполнители: люди, программы и оборудование)
-- проект развития "интеграция данных жизненного цикла PLM-систем" в ОАО "Газнефтьводка России" (выпячены работы, это именно проект)
-- эко-система мобильной телефонии (с одной стороны, выпячен структурный аспект -- выполнители, с другой стороны они поименованы косвенно, через конечный объект работы)
-- кейс устранения ошибки, найденной клиентом (выпячены работы с заранее неизвестной структурой, направленные на достижение определенной цели)
4. Каждое предпринятие (в том числе структурные организованности, соответствующие отдельным проектам/кейсам/жизненным циклам конечных объектов работы) имеет архитектуру -- самое важное, что можно сказать про то, как организовано предпринятие как система: каким образом конструкция/структура (выполнители и объекты работы) и механизм (выполняемые работы) предпринятия позволяют достигать его целей (эти цели определяются заинтересованными сторонами, имеющими влияние на предприятие).
Эта архитектура может быть выражена в одном или нескольких архитектурных описаниях.
В архитектурном описании (да и в детальных описаниях предпринятия, "организационной рабочке" -- если можно так говорить о регламентах работы, "бумажных текстом" для людей и выполняемых софтом "электронных формализованных") показываются:
-- типовые выполнители: организационные звенья и их роли (оргструктура), а также виды программ и оборудования (структура: развернутая в организации технология производства работ, гарантирующая воспроизводимость результатов работы), ибо составляющие эти организационные звенья живые люди, исполняемые программы и экземпляры устройств вполне могут быть заменены без изменения архитектуры.
-- типовые работы: шаблоны проектов (ибо сами проекты -- не в архитектуре, а в предпринятии, т.е. в жизни), практики и процессы (ибо в самом предпринятии -- экземпляры работ), виды жизненного цикла (ибо сами прохождения жизненных циклов -- в предпринятии, т.е. в жизни), типы кейсов (ибо сами кейсы -- в жизни)
-- типы объектов работы (а сами экземпляры объектов работы -- в жизни).
Типовые объекты -- это означает, что речь идёт о классах (множествах) реальных объектов "из жизни". От абстрактной идеи (абстрактного объекта, не имеющего протяженности в пространстве и времени -- например, "типа", "класса" и даже "класса классов", "вида") до существующего в реальности объекта (индивида, имеющего протяженность во времени и пространстве) может быть много ступенек членства в классе (уровней классификации).
Архитектурное описание (да и рабочее описание) предпринятия выполняется обычно как "типовое", как будто этих предпринятий может быть по этой архитектуре создано много. Это пример так называемого "проектирования в классах" (хотя на эту тему и ведутся многочисленные дискуссии с приверженцами "проектирования в индивидах") -- архитектура отражает типовые аспекты предпринятия, верные для многочисленных (проводившихся, ведущихся и будущих проводиться) в нём работ.
Понятное дело, что речь идёт об "архитектуре предпринятия" (т.е. и проекта в том числе), но мы будем сознательно в речи путать "архитектуру предпринятия" и "архитектуру предприятия" -- считая, что это одно и то же. То есть мы, говоря об "архитектуре предприятия" не будем ограничиваться архитектурой одного юридического лица, а будем говорить об общей архитектуре той или иной организованности людей для выполнения каких-то целей.
5. Архимейт (http://ailev.livejournal.com/988360.html) -- это один из лучших на сегодня арихтектурных подходов (включающий набор групп описаний и архитектурный язык) к описанию предпринятий.
Архимейт имеет не слишком аккуратный и богатый язык для описания предпринятий, но "за неимением гербовой будем писать на простой".
Ограниченность Архимейта проявляется главным образом в отсутствии возможности показать классификацию (отношения "реализации" Архимейта очень близки в некоторых случаях по сути, но выражают они совсем другое и имеют явные ограничения). Это означает, что в Архимейте трудно показывать что-то "типовое" по отношению к чему-то более конкретному. Некоторые исследователи предлагают вместо отношений классификации пользоваться отношениями специализации (приговаривая при этом "онтологи этого не любят, но простые люди вряд ли заметят подвох" -- предложено Donald Firesmith в его метамодели описания метода OPF, http://opfro.org).
5. Между предпринятиями развития других предпринятий и этими другими развиваемыми предпринятиями как раз отношение классификации/реализации: проекты (а в случае "департамента развития" можно говорить и о программах -- это ведь всё тоже "предпринятия") развития воплощают разработанные абстрактные "типовые архитектуры" (информационные модели) в реальности.
Есть два времени проведения таких "проектов развития":
-- явный, перед целевой работой, когда разворачивается технология (обучаются люди, закупаются и настраиваются/разворачиваются программы и оборудование), а потом получившееся предпринятие начинает выполнять свои работы. В Архимейте 2.0 для описания таких проектов существуют отдельные расширения (extensions) "целеполагания" и "реализации и перехода к новой архитектуре".
-- неявный (и тогда это даже "развитием" или "организовыванием" не называется), то есть прямо во время целевой работы. Такого сорта работы принято называть не "проектами" или "процессами", а "кейсами". В "кейсах" предпринятие создаётся кейс-менеджером по ходу дела (например, лечение пациента или устранение аварии -- в этих случаях можно много сказать про имеющихся в наличии потенциальных выполнителей, но много меньше про выбранных из них в конечном итоге реальных выполнителей и проводимые ими работы, а также объекты работы: они будут выясняться постепенно по ходу кейса). Предпринятие-кейс адаптивно "творит себя" в рамках основной деятельности родительского предпринятия-по-ведению кейсов, и поэтому адаптивное управление кейсами (http://ailev.livejournal.com/946134.html) нужно описывать средствами ядра (core) Архимейта (а вот организацию адаптивного управления кейсами как метода работы родительского предпринятия -- в рамках проектов развития, средствами расширений целеполагания и реализации и перехода к новой архитектуре).
Я как-то замечал, что в проектном подходе проект-предпринятие отражён во всех учебниках, но в софте проектного управления также можно встретить "шаблон проекта" -- это как раз фрагмент архитектурного описания родительского предпринятия для подобных типовых проектов. В процессном подходе в учебниках именно описан процесс как фрагмент архитектурного описания предпринятия, а в жизни можно обнаружить не типовое "описание процесса", а лишь его экземпляры (например, прохождения конкретного договора с его индивидуальным номером) -- эти экземпляры тоже можно встретить в софте, но в учебниках о них практически ничего не говорится.
Кейсы в этом плане много сложнее процессов и проектов: нет "типового кейса", но вполне могут существовать какие-то шаблоны организации кусочков работ, которые будут использованы примерно так же, как "шаблоны проекта" или "описания процессов" -- с той лишь разницей, что:
а) речь будет идти наверняка не о шаблоне всего кейса от открытия до закрытия, а только о каких-то отдельных шаблонах (например, шаблонах самой процедуры формального открытия и закрытия кейса, или процедурах формального назначения доступных людей для продвижения кейса). То есть для кейсов есть "библиотека/каталог шаблонов", и кейс приходится конструировать из элементов этого каталога описаний выполнителей-работ-объектов работ прямо по ходу дела, для каждого кейса отдельно.
б) большая вероятность не обнаружить какого-то нужного элемента в библиотеке/каталоге шаблонов: работы тогда должны быть спланированы непосредственно в момент обнаружения в них надобности (то, что потом можно будет сделать реверс инжиниринг этих работ и пополнить библиотеку новым шаблоном -- это только возможность, не факт, что ей воспользуются. В принципе, этот "обратный инжиниринг работ для выявления типов работ" называется process mining, это очень свежий тренд -- http://en.wikipedia.org/wiki/Process_mining. Грубо говоря, это попытки найти протоптанные людьми тропинки, чтобы их потом заасфальтировать. Другое дело, что сама постановка вопроса в "процессном управлении", предполагающем сначала проложить асфальтовые процессы, а затем карать за сход с асфальта, существенно извращает суть этого process mining).
в) процессы (и их экземпляры) и проекты (и их шаблоны) могут быть представлены как частные случаи кейсов -- когда значительная часть организационной работы и планирования работ делается up front, перед собственно выполнением работ. Но кейсы включают в себя и рутинную реорганизацию предпринятия-кейса по ходу дела, по мере обнаружения привходящих обстоятельств (что в проектном и процессном подходах рассматривается как ситуация кризисов).
6. Архитектурное описание должно выражать архитектуру -- самое важное в том, как организовано предпринятие:
-- для процессных предпринятий это классические "бизнес-процессы" из книжки (цепочки действий, провязанные отношением передачи "выходов" одних операций на "входы" других). Архимейт особо хорошо приспособлен для описания именно таких предпринятий, причем только для описания информационной работы в предпринятиях.
-- для проектно-ориентированных предпринятий (как это понимается в традиционных учебниках менеджмента) оно описывает жизненный цикл целевой системы как объекта работ и практики этого жизненного цикла (становящиеся процессами, как только мы говорим о развёртке выполнения этих практик во времени жизненного цикла). Для описания типовых жизненных циклов (шаблонов проектов разработки) чаще всего используется подход ситуационной инженерии методов (стандарты ISO 24744, OMG SPEM 2.0).
-- для кейс-ориентированных предпринятий (например, больниц, в которых любая процедура и лекарство типовые, но вот последовательность этих процедур невозможно предугадать. Ну, или программотехническая фирма, в которой никто не знает, какой баг вылезет завтра, и как его будут удавливать) отражаются не столько "процессы", сколько практики (группирование работ по ролям, чтобы их было легче назначать компетентным исполнителям) и какие-то короткие цепочки процессов, похожие не на типовой и длинный "бизнес-процесс, пересекающий границы подразделений и выходящий за границы предприятия", а на "шаблон проекта", выполняемого какими-то уполномоченными на это людьми. Специальных подходов для описания кейс-ориентированных предпринятий нет, и вполне можно использовать подходы архитектуры предприятия и ситуационной инженерии методов.
7. Также существуют и другие описания предпринятий, выражаемые какими-то стандартами, затрагивающими только один метод описания (тематическую группу описаний) из их множества.
Эти стандарты могут быть действительно стандартами (ISO 15288 как стандарт практик системной инженерии, например) или просто типовыми описаниями того, "как обычно бывает" (стандарты де-факто, и еще см. "об институты" -- http://ailev.livejournal.com/982274.html). В любом случае, можно говорить о том, что предпринятие соответствует (compliant) какому-то стандарту ("удовлетворяют требованиям стандарта"), или оно "реализует" этот стандарт, если предпринятие (в жизни) соответствует такому частному описанию. Конечно, одно и то же предпринятие может удовлетворять требованиям многих стандартов (если они не требуют чего-то прямо противоположного).
7. ОргЛан основан на идее, что предпринятия, их разбиения и отношения можно описать в рамках архитектурного подхода (системной инженерии, приложенной к предприятию как системе систем -- http://ailev.livejournal.com/991792.html).
Это, в частности, означает возможность использования архитектурного языка (Орглана -- http://praxos.livejournal.com/13689.html) не только для:
а) традиционно понимаемой архитектуры предпринятия, но и
б) описаний видов жизненного цикла (т.е. вместо ISO 24744, OMG SPEM 2.0), как методов разработки (ситуационная инженерия методов -- http://ailev.livejournal.com/905099.html), а также
в) создания библиотек шаблонов для кейсов, что очень похоже на каталоги компонент методов из предыдущего пункта (б), только происходит по ходу дела, а не заранее в момент организации работ. Сюда же отнесём частные случаи кейсов: описания процессов и планы проектов.
Для этой цели архитектурный язык должен включать в себя возможность выражения не только запланированных связных последовательностей работ (процессов), выполняемых определенными исполнителями, но и потенциальных работ, последовательность и исполнители которых неизвестны. Это ровно тот подход "каталогизации компонентов методов", который развивался в ситуационной инженерии методов (http://praxos.livejournal.com/9600.html, http://praxos.livejournal.com/11084.html), но дополненный до всех аспектов организации предпринятия (например, включающего сведения о распределении полномочий -- то есть дополненный до архитектурного "всё важное"), а не ограниченного только описанием метода.
Тем самым можно говорить (по аналогии с ситуационной инженерией методов -- http://ailev.livejournal.com/905099.html) о ситуационной архитектуре предпринятия, и обсуждать каталоги архитектурных компонентов -- из которых и набирать ситуационные архитектуры, как об этом рассказывается в ситуационной инженерии методов.
Но и этого мало: "ситуационная архитектура" примерно соответствует "динамическому управлению кейсами" (когда содержимое каталога известно до начала работы). Я бы склонялся к термину "адаптивная архитектура предпринятия", учитывая именно архитектуры предприятий, заточенные под адаптивное управление кейсами.
Соответствующие архитектурные описания включали бы в себя:
а) библиотечные (то есть уже имеющиеся в культуре, готовые "из коробки") компоненты (паттерны, шаблоны) поддержки кейсов, ведения кейсов, технические, координационные -- тут я явно процитировал типологию практик системной инженерии из ISO 15288.
б) специфичные для данного предпринятия компоненты (паттерны, шаблоны), которых не было в библиотеке. Тут важно еще и то, что данные архитектурные компоненты могут быть созданы в любой момент (проектами развития, или кейсами -- тут уже не так важно).
в) целевые архитектурные описания, выполненные с использованием наличных компонент.
8. Тем самым предпринятие PraxOS (pun intended) создаёт не каталог компонентов методов для создания ситуационных методов, но расширяемый и пополняемый каталог архитектурных компонентов для создания адаптивных архитектур.
Тем самым можно говорить о планах релиза PraxOS 3.0 (предыдущие планы релиза 2.3 уже совсем устарели -- http://praxos.livejournal.com/455.html).
важно
Оригинал взят у ailev в PraxOS 3.0: адаптивная архитектура предпринятия
1. Предпринятие (endeavour или endeavor) -- это организованные на достижение какой-то цели люди. Организованные -- это с понятными полномочиями, и ответственностями по имеющимся в их распоряжении трудом, программами, оборудованием и объектами работы.
Типичные предпринятия -- это:
-- традиционное предприятие (и его работы -- проекты/кейсы, процессы, практики),
-- расширенное предприятие (работы нескольких предприятий в рамках одного проекта),
-- эко-система (http://www.investopedia.com/terms/b/business-ecosystem.asp, http://en.wikipedia.org/wiki/Busineгss_ecosystem -- где нужно говорить уже не столько о проектах/кейсах, сколько о производственных программах),
-- любые другие организованности (банда, церковь, бригада, рабочая группа, департамент, филиал, октябрятская звёздочка и отряд бойскаутов).
Есть цель и достигающая её группа людей с оборудованием и предметами работы -- есть предпринятие для её достижения.
2. Каждое предпринятие может (и должно) рассматриваться в совокупности его:
-- выполнителей работ, т.е. людей (с их компетенциями, соответствующими ролями в работах) и технологий (технологической платформы -- программы и оборудование), вместе дающие возможности (capabilities)
-- работ (процессы, проекты/кейсы/жизненные циклы конечных объектов работы, программы), в том числе внутренних и внешних сервисов
-- объектов работы (в том числе исходных, промежуточных и конечных).
-- предпринятий развития (в которых объектом работы становится само исходное предпринятие, рекурсивно).
Выполнители работ, работы и объекты работы одинаково важны в системном рассмотрении предпринятия, но разные люди могут выпячивать одно или другое. Так, многие предпринятием называют именно структуру выполнителей работ (по аналогии с предприятием -- это люди и оборудование), но в последний десяток лет появилось много людей, которые предпочитают говорить о предпринятиях как о сервисах, проектах и программах, кейсах ("процессно"). Пока очень мало тех, кто говорит о предпринятии как потоках обрабатываемых объектов работы -- но уже есть и такие.
Тем самым предпринятием вполне может называться и проект (который так и определяется, как временное предпринятие -- A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives -- http://en.wikipedia.org/wiki/Project_management).
3. Предпринятие уникально и находится в реальности (нашем пространстве-времени). Онтологически это individual -- оно имеет протяженность (extension) в пространстве-времени. Примеры:
-- ООО "ТехИнвестЛаб.ру" (в названии выпячен структурный аспект -- выполнители: люди, программы и оборудование)
-- проект развития "интеграция данных жизненного цикла PLM-систем" в ОАО "Газнефтьводка России" (выпячены работы, это именно проект)
-- эко-система мобильной телефонии (с одной стороны, выпячен структурный аспект -- выполнители, с другой стороны они поименованы косвенно, через конечный объект работы)
-- кейс устранения ошибки, найденной клиентом (выпячены работы с заранее неизвестной структурой, направленные на достижение определенной цели)
4. Каждое предпринятие (в том числе структурные организованности, соответствующие отдельным проектам/кейсам/жизненным циклам конечных объектов работы) имеет архитектуру -- самое важное, что можно сказать про то, как организовано предпринятие как система: каким образом конструкция/структура (выполнители и объекты работы) и механизм (выполняемые работы) предпринятия позволяют достигать его целей (эти цели определяются заинтересованными сторонами, имеющими влияние на предприятие).
Эта архитектура может быть выражена в одном или нескольких архитектурных описаниях.
В архитектурном описании (да и в детальных описаниях предпринятия, "организационной рабочке" -- если можно так говорить о регламентах работы, "бумажных текстом" для людей и выполняемых софтом "электронных формализованных") показываются:
-- типовые выполнители: организационные звенья и их роли (оргструктура), а также виды программ и оборудования (структура: развернутая в организации технология производства работ, гарантирующая воспроизводимость результатов работы), ибо составляющие эти организационные звенья живые люди, исполняемые программы и экземпляры устройств вполне могут быть заменены без изменения архитектуры.
-- типовые работы: шаблоны проектов (ибо сами проекты -- не в архитектуре, а в предпринятии, т.е. в жизни), практики и процессы (ибо в самом предпринятии -- экземпляры работ), виды жизненного цикла (ибо сами прохождения жизненных циклов -- в предпринятии, т.е. в жизни), типы кейсов (ибо сами кейсы -- в жизни)
-- типы объектов работы (а сами экземпляры объектов работы -- в жизни).
Типовые объекты -- это означает, что речь идёт о классах (множествах) реальных объектов "из жизни". От абстрактной идеи (абстрактного объекта, не имеющего протяженности в пространстве и времени -- например, "типа", "класса" и даже "класса классов", "вида") до существующего в реальности объекта (индивида, имеющего протяженность во времени и пространстве) может быть много ступенек членства в классе (уровней классификации).
Архитектурное описание (да и рабочее описание) предпринятия выполняется обычно как "типовое", как будто этих предпринятий может быть по этой архитектуре создано много. Это пример так называемого "проектирования в классах" (хотя на эту тему и ведутся многочисленные дискуссии с приверженцами "проектирования в индивидах") -- архитектура отражает типовые аспекты предпринятия, верные для многочисленных (проводившихся, ведущихся и будущих проводиться) в нём работ.
Понятное дело, что речь идёт об "архитектуре предпринятия" (т.е. и проекта в том числе), но мы будем сознательно в речи путать "архитектуру предпринятия" и "архитектуру предприятия" -- считая, что это одно и то же. То есть мы, говоря об "архитектуре предприятия" не будем ограничиваться архитектурой одного юридического лица, а будем говорить об общей архитектуре той или иной организованности людей для выполнения каких-то целей.
5. Архимейт (http://ailev.livejournal.com/988360.html) -- это один из лучших на сегодня арихтектурных подходов (включающий набор групп описаний и архитектурный язык) к описанию предпринятий.
Архимейт имеет не слишком аккуратный и богатый язык для описания предпринятий, но "за неимением гербовой будем писать на простой".
Ограниченность Архимейта проявляется главным образом в отсутствии возможности показать классификацию (отношения "реализации" Архимейта очень близки в некоторых случаях по сути, но выражают они совсем другое и имеют явные ограничения). Это означает, что в Архимейте трудно показывать что-то "типовое" по отношению к чему-то более конкретному. Некоторые исследователи предлагают вместо отношений классификации пользоваться отношениями специализации (приговаривая при этом "онтологи этого не любят, но простые люди вряд ли заметят подвох" -- предложено Donald Firesmith в его метамодели описания метода OPF, http://opfro.org).
5. Между предпринятиями развития других предпринятий и этими другими развиваемыми предпринятиями как раз отношение классификации/реализации: проекты (а в случае "департамента развития" можно говорить и о программах -- это ведь всё тоже "предпринятия") развития воплощают разработанные абстрактные "типовые архитектуры" (информационные модели) в реальности.
Есть два времени проведения таких "проектов развития":
-- явный, перед целевой работой, когда разворачивается технология (обучаются люди, закупаются и настраиваются/разворачиваются программы и оборудование), а потом получившееся предпринятие начинает выполнять свои работы. В Архимейте 2.0 для описания таких проектов существуют отдельные расширения (extensions) "целеполагания" и "реализации и перехода к новой архитектуре".
-- неявный (и тогда это даже "развитием" или "организовыванием" не называется), то есть прямо во время целевой работы. Такого сорта работы принято называть не "проектами" или "процессами", а "кейсами". В "кейсах" предпринятие создаётся кейс-менеджером по ходу дела (например, лечение пациента или устранение аварии -- в этих случаях можно много сказать про имеющихся в наличии потенциальных выполнителей, но много меньше про выбранных из них в конечном итоге реальных выполнителей и проводимые ими работы, а также объекты работы: они будут выясняться постепенно по ходу кейса). Предпринятие-кейс адаптивно "творит себя" в рамках основной деятельности родительского предпринятия-по-ведению кейсов, и поэтому адаптивное управление кейсами (http://ailev.livejournal.com/946134.html) нужно описывать средствами ядра (core) Архимейта (а вот организацию адаптивного управления кейсами как метода работы родительского предпринятия -- в рамках проектов развития, средствами расширений целеполагания и реализации и перехода к новой архитектуре).
Я как-то замечал, что в проектном подходе проект-предпринятие отражён во всех учебниках, но в софте проектного управления также можно встретить "шаблон проекта" -- это как раз фрагмент архитектурного описания родительского предпринятия для подобных типовых проектов. В процессном подходе в учебниках именно описан процесс как фрагмент архитектурного описания предпринятия, а в жизни можно обнаружить не типовое "описание процесса", а лишь его экземпляры (например, прохождения конкретного договора с его индивидуальным номером) -- эти экземпляры тоже можно встретить в софте, но в учебниках о них практически ничего не говорится.
Кейсы в этом плане много сложнее процессов и проектов: нет "типового кейса", но вполне могут существовать какие-то шаблоны организации кусочков работ, которые будут использованы примерно так же, как "шаблоны проекта" или "описания процессов" -- с той лишь разницей, что:
а) речь будет идти наверняка не о шаблоне всего кейса от открытия до закрытия, а только о каких-то отдельных шаблонах (например, шаблонах самой процедуры формального открытия и закрытия кейса, или процедурах формального назначения доступных людей для продвижения кейса). То есть для кейсов есть "библиотека/каталог шаблонов", и кейс приходится конструировать из элементов этого каталога описаний выполнителей-работ-объектов работ прямо по ходу дела, для каждого кейса отдельно.
б) большая вероятность не обнаружить какого-то нужного элемента в библиотеке/каталоге шаблонов: работы тогда должны быть спланированы непосредственно в момент обнаружения в них надобности (то, что потом можно будет сделать реверс инжиниринг этих работ и пополнить библиотеку новым шаблоном -- это только возможность, не факт, что ей воспользуются. В принципе, этот "обратный инжиниринг работ для выявления типов работ" называется process mining, это очень свежий тренд -- http://en.wikipedia.org/wiki/Process_mining. Грубо говоря, это попытки найти протоптанные людьми тропинки, чтобы их потом заасфальтировать. Другое дело, что сама постановка вопроса в "процессном управлении", предполагающем сначала проложить асфальтовые процессы, а затем карать за сход с асфальта, существенно извращает суть этого process mining).
в) процессы (и их экземпляры) и проекты (и их шаблоны) могут быть представлены как частные случаи кейсов -- когда значительная часть организационной работы и планирования работ делается up front, перед собственно выполнением работ. Но кейсы включают в себя и рутинную реорганизацию предпринятия-кейса по ходу дела, по мере обнаружения привходящих обстоятельств (что в проектном и процессном подходах рассматривается как ситуация кризисов).
6. Архитектурное описание должно выражать архитектуру -- самое важное в том, как организовано предпринятие:
-- для процессных предпринятий это классические "бизнес-процессы" из книжки (цепочки действий, провязанные отношением передачи "выходов" одних операций на "входы" других). Архимейт особо хорошо приспособлен для описания именно таких предпринятий, причем только для описания информационной работы в предпринятиях.
-- для проектно-ориентированных предпринятий (как это понимается в традиционных учебниках менеджмента) оно описывает жизненный цикл целевой системы как объекта работ и практики этого жизненного цикла (становящиеся процессами, как только мы говорим о развёртке выполнения этих практик во времени жизненного цикла). Для описания типовых жизненных циклов (шаблонов проектов разработки) чаще всего используется подход ситуационной инженерии методов (стандарты ISO 24744, OMG SPEM 2.0).
-- для кейс-ориентированных предпринятий (например, больниц, в которых любая процедура и лекарство типовые, но вот последовательность этих процедур невозможно предугадать. Ну, или программотехническая фирма, в которой никто не знает, какой баг вылезет завтра, и как его будут удавливать) отражаются не столько "процессы", сколько практики (группирование работ по ролям, чтобы их было легче назначать компетентным исполнителям) и какие-то короткие цепочки процессов, похожие не на типовой и длинный "бизнес-процесс, пересекающий границы подразделений и выходящий за границы предприятия", а на "шаблон проекта", выполняемого какими-то уполномоченными на это людьми. Специальных подходов для описания кейс-ориентированных предпринятий нет, и вполне можно использовать подходы архитектуры предприятия и ситуационной инженерии методов.
7. Также существуют и другие описания предпринятий, выражаемые какими-то стандартами, затрагивающими только один метод описания (тематическую группу описаний) из их множества.
Эти стандарты могут быть действительно стандартами (ISO 15288 как стандарт практик системной инженерии, например) или просто типовыми описаниями того, "как обычно бывает" (стандарты де-факто, и еще см. "об институты" -- http://ailev.livejournal.com/982274.html). В любом случае, можно говорить о том, что предпринятие соответствует (compliant) какому-то стандарту ("удовлетворяют требованиям стандарта"), или оно "реализует" этот стандарт, если предпринятие (в жизни) соответствует такому частному описанию. Конечно, одно и то же предпринятие может удовлетворять требованиям многих стандартов (если они не требуют чего-то прямо противоположного).
7. ОргЛан основан на идее, что предпринятия, их разбиения и отношения можно описать в рамках архитектурного подхода (системной инженерии, приложенной к предприятию как системе систем -- http://ailev.livejournal.com/991792.html).
Это, в частности, означает возможность использования архитектурного языка (Орглана -- http://praxos.livejournal.com/13689.html) не только для:
а) традиционно понимаемой архитектуры предпринятия, но и
б) описаний видов жизненного цикла (т.е. вместо ISO 24744, OMG SPEM 2.0), как методов разработки (ситуационная инженерия методов -- http://ailev.livejournal.com/905099.html), а также
в) создания библиотек шаблонов для кейсов, что очень похоже на каталоги компонент методов из предыдущего пункта (б), только происходит по ходу дела, а не заранее в момент организации работ. Сюда же отнесём частные случаи кейсов: описания процессов и планы проектов.
Для этой цели архитектурный язык должен включать в себя возможность выражения не только запланированных связных последовательностей работ (процессов), выполняемых определенными исполнителями, но и потенциальных работ, последовательность и исполнители которых неизвестны. Это ровно тот подход "каталогизации компонентов методов", который развивался в ситуационной инженерии методов (http://praxos.livejournal.com/9600.html, http://praxos.livejournal.com/11084.html), но дополненный до всех аспектов организации предпринятия (например, включающего сведения о распределении полномочий -- то есть дополненный до архитектурного "всё важное"), а не ограниченного только описанием метода.
Тем самым можно говорить (по аналогии с ситуационной инженерией методов -- http://ailev.livejournal.com/905099.html) о ситуационной архитектуре предпринятия, и обсуждать каталоги архитектурных компонентов -- из которых и набирать ситуационные архитектуры, как об этом рассказывается в ситуационной инженерии методов.
Но и этого мало: "ситуационная архитектура" примерно соответствует "динамическому управлению кейсами" (когда содержимое каталога известно до начала работы). Я бы склонялся к термину "адаптивная архитектура предпринятия", учитывая именно архитектуры предприятий, заточенные под адаптивное управление кейсами.
Соответствующие архитектурные описания включали бы в себя:
а) библиотечные (то есть уже имеющиеся в культуре, готовые "из коробки") компоненты (паттерны, шаблоны) поддержки кейсов, ведения кейсов, технические, координационные -- тут я явно процитировал типологию практик системной инженерии из ISO 15288.
б) специфичные для данного предпринятия компоненты (паттерны, шаблоны), которых не было в библиотеке. Тут важно еще и то, что данные архитектурные компоненты могут быть созданы в любой момент (проектами развития, или кейсами -- тут уже не так важно).
в) целевые архитектурные описания, выполненные с использованием наличных компонент.
8. Тем самым предпринятие PraxOS (pun intended) создаёт не каталог компонентов методов для создания ситуационных методов, но расширяемый и пополняемый каталог архитектурных компонентов для создания адаптивных архитектур.
Тем самым можно говорить о планах релиза PraxOS 3.0 (предыдущие планы релиза 2.3 уже совсем устарели -- http://praxos.livejournal.com/455.html).