Неформальное введение в понятия ОргЛана
Я решил, что черновой вариант, соответствующий начальным шагам реализации пункта 7 из августовских "10 тезисов к разработке ОргЛана" (http://praxos.livejournal.com/12907.html) нужно публиковать в 2011, заканчивая первую стадию работы с ним по методу time boxing -- не "по готовности", а "в старом году".
Это описание нужно далее:
-- почистить и исправить очевидные ошибки. В 2012 году я буду потихоньку улучшать текст прямо в этом постинге, внося правку по месту -- пока не возникнет необходимость переписать всё заново. Так что возвращайтесь время от времени, текст будет меняться -- и набор понятий и их отношений, и используемая терминология, и определения. Все изменения будут без особого предупреждения.
-- сделать к нему парочку примеров для КонкОрга, чтобы потренироваться в разговоре на этом языке. У меня есть давняя мечта повторить проект "Ивановские ситцы" (был такой проект художественного описания приватизации, чтобы помочь отождествить многочисленные формальные регламенты с реалиями жизни).,
-- отмоделировать в ISO 15926, чтобы получить классы и шаблоны ОргЛана.
А далее уже с формальной микротеорией ОргЛана на руках:
-- придумать формальную нотацию (вернее, нотации) ОргЛана,
-- мэппинг ОргЛана в существующие стандарты (и тем самым обеспечение частичной поддержки софтами. Например, мэппинг в Архимейт даёт возможность пользования редакторами Архимейта),
-- реализацию непосредственной поддержки ОргЛана софтом ПраксОС.
Обращу внимание, что данный текст не является "Рассказом о ПраксОС", ибо он не предписывает лучшие методы организации: тут ничего не написано "как делать", только "из чего состоит предприятие" -- один из ввариантов организационной онтологии, а именно "онтология ПраксОС".
В данном тексте я буду выделять понятия ОргЛана (OrgLan), давая им русские и английские имена -- но на данном шаге такое выделение понятий не является ни полным, ни строгим. Я также почти не давал формальных определений (таковыми обычно считают "X -- это специализация Y в том-то и том-то"). Я буду там и сям давать ссылки на различные источники, знание которых необходимо для понимания этого рассказа (ибо не думайте, что всё написанное придуманно лично мной и представляет собой "онтологию одного человека"), и я не сверял немногие выданные определения с этим источниками.
Когда мы рассматриваем предприятие (enterpise), то нужно четко различать в нём:
-- предпринятие (endeavour): то, что происходит в действительности -- актуальные работы с железками, а также производственными (production) и координационными (сoordination) фактами (facts).
-- справочные данные (reference data): это "знания" -- то, что мы знаем про "жизнь вообще": общую для всех предприятий картину мира и методы, а также существование общих для всех предприятий объектов (каталожных классов рабочих продуктов, адресных баз других предприятий, клиентов).
Без понимания этого различения (между реальными объектами и отношениями, индивидами (individual) и классами (class) объектов и отношений) понять ПраксОС невозможно, это основа основ. Это понимание при моделировании примерно соответствует различению methodology domain и endeavour из ISO 24744, reference data и project data в ISO 15926. Тем самым "предприятие = предпринятие + данные = кусок мира + знания о внешнем мире".
Предпринятие, как имеющее отношение к реальности, имеет приоритет над справочными данными. Много разных вариантов справочных данных может быть соотнесено с одним и тем же предпринятием (то, что для одних -- таскание камней, для других -- строительство храма, для третьих -- бессмысленная трата сил).
Любое рассмотрение должно начинаться и заканчиваться с предпринятия, а не со справочных данных. С другой стороны, справочные данные дают возможность накопить опыт разных предпринятий, чтобы каждый раз не изобретать велосипед при описании предпринятий, их создании/выращивании/развитии -- но это только информация (сведения), в реальности объектов справочных данных нет. Можно летать на самолёте с серийным номером в какое-то конкретное время (этот алюминиевый самолёт и его полёт существуют в реальности, в предпринятии), но нельзя летать на классе самолёта в классе времени полёта (это знание, а на знаниях далеко не улетишь. Даже если это знание вынести в реальность в виде данных на носителях, то и на фрагменте диска с данными самолёта тоже далеко не улетишь). Простые тесты отнесения к реальному миру: "можно увезти на тачке", "можно указать пальцем".
Предпринятие (endeavour) -- это организованные (с определенными ролями, полномочиями и ответственностями) люди и оборудование, здания, сооружения, материалы и рабочие продукты. Такое определение полностью соответствует ISO 15288 (там оно использовано для предприятия в целом, включая справочные данные, но подчеркивается принадлежность к реальному миру). Предпринятие -- это разворачивающаяся в актуальном пространстве-времени физическая система (индивид -- хотя и очень сложно устроенный, и непрерывно меняющийся), об этом разворачивании во времени известны производственные и координационные факты (верные на какой-то момент актуального времени). Предпринятие (в отличие от юридически определяемого предприятия) характеризуется тем, что система-предпринятие имеет четко определенную функцию, которую необходимо максимизировать (goal по Голдратту), изменяя конструкцию предпринятия.
Напомню, что предприятие в юридических документах часто определяется как существующее не только "вечно", но и для достижения определенной цели. В том числе предприятие может не иметь юридического лица. Более того, предпринятие (в отличие от предприятия) вовсе необязательно целью имеет получение денег -- например, церковь целью имеет спасение людей, а политическая партия завоевание власти. Главным для нас является то, что предпринятие имеет цель -- какой-то критерий, по которому определяется глобальный максимум. В книжках по теории ограничений можно найти много обсуждений о разнице "стремления к максимизации показателя" как goal и "удовлетворению критерию, а дальше хватит стараться" как target. В юридической литературе тоже много обсуждений о предприятиях как юридических лицах или созданных без образования юридических лиц, созданных на время или для достижения какой-то цели, и созданных "навечно", но нам сейчас это неважно. Важно, что "глобальней предпринятия системы нет". Расширенное предприятие (extended enterprise), которое определяется как система предприятий, выполняющих крупный инженерный проект, а также новомодное слово эко-система (eco-system) для того же самого на потребительских рынках (например, "эко-система фирмы Apple, объединяющая саму фирму и ее поставщиков, телефонных операторов, разработчиков приложений, пользователей телефонов и т.д.") -- это всё тоже предпринятия, которые реальны.
Предпринятие ведёт кейсы (case) -- системы, некоторые аспекты которых нужно перевести из текущего состояния в целевое (не путать целевые состояния кейса с целевым состоянием предпринятия -- этого "целевого состояния", ведущего к "закрытию предприятия" и вовсе может не быть! А кейс обычно есть заинтересованность закрыть!). Кейсы именуются указанием целевой системы и указания на группу описаний состояния: "здоровье пациента" в больнице, "работоспособность прибора" в ремонтном предприятии, "справедливость для истца" в случае судебного дела, "катастрофа на местности" в случае спасательных мероприятий. Кейсы "открываются", когда предприятие становится обеспечивающей системой для этих кейсов, и закрываются, когда целевая система переходит в зону ответственности другой обеспечивающей системы. Кейсы (системы) тем самым проходят жизненный цикл кейса, включающий в себя стадии, контрольные точки, на них выделяются ресурсы, они являются предметом проектов (которые понимаются как постадийное выделение ресурсов на кейсы), с ними работают процессы (которые понимаются как последовательности работ, нужные для изменения состояния кейса). Кейс нетождественен целевой системе, кейс -- это темпоральная часть целевой системы. В этом плане максимизация результата кейса всегда подчинена достижению глобального максимума предпринятия (задаваемого обеспечивающей системой) и глобального максимума, задаваемого для владельцем целевой системы. Кейсом владеет обеспечивающая система, а целевой системой владеет ее владелец.
Впрочем, есть ситуация, когда владелец кейса и целевой системы -- одно и то же лицо: кейс, когда владелец предпринятия пытается добиться чего-то от собственного предпринятия (например, освоить ПраксОС, поднять прибыльность на небывалую высоту, выйти на зарубежные рынки, первыми высадиться на Марс). Обычно про такие кейсы говорят как про "организационное развитие" -- сюда в том числе относится кейсы M&A, кейсы управления технологиями, реорганизации.
Кейсы в свою очередь делятся на issues, затрагивающие мелкие аспекты изменения состояния системы и имеющие свои локальные цели. Кейсы отличаются тем, что закрытия кейса контролирует владелец целевой системы (валидация: то, что сделано, удовлетворяет владельца), а вот закрытия issues контролируются работниками предпринятия, как обеспечивающей системы. С этой точки зрения кейс задаёт глобальный максимум, а issues служат локальному максимуму.
Ведение кейса и его issues от открытия до закрытия включает в себя производство самых различных работ (work), которые занимают конкретное время и требуют возможностей предприятия по их совершению: сервисов (services) предпринятия. Предпринятие, как обеспечивающая система, имеет готовность проводить эти работы через определенные каналы (места, интерфейсы) -- т.е. внешнее поведение обеспечивающей системы (функции для клиентов) структурировано как сервисы. Сервисы понимаются так же, как в Архимейте: они представляют собой готовое к осуществлению поведение обеспечивающей системы, как активной структуры. В этом плане продукт -- это предоставление обеспечивающей системой-предпринятием для систем в его операционном окружении сервисов (работ по ведению кейса -- изменения состояния целевой системы), связанных контрактом. Это вполне архимейтовское понимание сервиса. Обращаем внимание, что функции предпринятия с точки зрения его (обеспечивающей системы) владельца и сервисы предпринятия с точки зрения владельца целевой системы -- это абсолютно разные сущности.
Кейсы и issue в предпринятии являются целевыми (т.е. над которыми ведется работа -- "пассивная структура" в терминах Архимейта, work product в терминах ISO 24744) системами-подсистемами разного уровня композиционной иерархии, причем эти целевые системы-подсистемы могут находиться в разные моменты времени в разных состояниях, не теряя при этом своей идентичности. Будем называть их "объекты" (подчеркивая пассивность). Возможны различные классификации объектов (в том числе и гибридные -- где основание классификации меняется на каждом уровне иерархии):
-- по уровню абстракции (деятельностные объекты, данные, "в железе")
-- по отношению к целевой системе (сама система, модель системы, документ с моделью системы),
-- по описанию в каком-то конкретном виде документации
-- по известным методам работы (обработки исходного состояния или получения целевого состояния).
-- по возможности закупки (каталожное оборудование, длинноцикловое оборудование)
Работы предпринятия выполняются акторами (в ISO 24744 producers, в Архимейте это "пассивная структура") -- людьми-деятелями (actors) и их агентами-инструментами, в том числе -- компьютерными. Агенты всегда работают в рамках полномочий, данных им деятелями-принципалами, деятели несут ответственность за деятельность их агентов. Если вам банкомат неправильно поменял купюру, вы будете искать телефон ответственного за этот банкомат деятеля, а не ругаться с самим банкоматом). Деятели и инструменты обычно назначаются на роли акторов (в частности, "автоматизация" часто выглядит как назначение робота-агента на ту же производственную роль, на какой раньше был деятель -- если отвлечься от того факта, что при автоматизации обычно меняются и роли).
Возможны различные (в том числе гибридные) классификации акторов:
-- по технологиям (соответствие акторов каким-то методам работы)
-- по полномочиям (органиграмма структура)
Соответственно, конкретные акторы предпринятия занимают те или иные роли в шаблонах описания акторов (в смысле ISO 15926) и согласно этим ролям называются "исполнители", "топ-менеджеры", "инфраструктура", "подразделения", "филиалы" и т.д.
Работы, осуществляемые в порядке осуществления сервисов, могут быть сгруппированы очень по-разному (в скобках -- дисциплины, описывающие способ группировки, но гибридные классификации тоже очень распространены, например в любой WBS можно узнать такую гибридную классификацию):
-- по единству полномочий и ответственности исполнителей работ (традиционные "орг.функции")
-- по единству учёта ресурсов для кейса (project management)
-- по последовательности осуществления (process management, total quality management)
-- по направленности на ту или иную целевую систему (case management)
-- по появлению ранее не встречающихся работ (adaptive case management)
-- по используемым в данном предпринятии методам работы (situational method engineering)
Соответственно, конкретные работы предпринятия занимают те или иные роли в шаблонах описания работ (в смысле ISO 15926) -- и согласно этим ролям называются "проекты", "экземпляры процессов", "работы кейса", и "работы по method enactment" и т.д.. Это всё "классификации", многие из которых абсолютно неспецифичны для конкретного предпринятия, и тем самым относятся уже к справочным данным.
Справочные данные (reference data) определяются по ISO 15926 -- как общие для нескольких предпринятий (чаще говорят о НСИ), или даже нескольких кейсов предпринятия (чаще говорят о мастер-данных, MDM. Заметим, что концепция MDM не работает для отраслевых случаев, а работает только для предприятий с жесткой организацией). Эти данные реализуют ("реализуют" понимается как в Архимейте -- реализацию данными для соответствующих объектов деятельности) сведения о:
-- внешних по отношению к предпринятию системах (операционное окружение самого предпринятия -- его партнеры, клиенты, надзоры и т.д.);
-- возможностях закупки (каталожное оборудование, справочники сервисов);
-- нормативах, стандартах, отраслевом и гос.регулировании
-- классификаторы, словари, тезаурусы и прочие справочники;
-- методы (библиотеки компонент методов, библиотечные архитектурных методов описания), куда входит знание о типовых работах (т.е. видах работ), типовых объектах (видах объектов), типовых акторах (видах акторов).
Важно заметить, что есть два способа формирования справочных данных:
-- непосредственно описывая виды объектов, работ и акторов как "классы классов" (подход ISO 15926). Это "традиционный научный способ объект-ориентированного описания": описывать классы, потом порождать соответствующие им объекты (особо заметим, что речь тут не идет о объект-атрибутной модели, а речь идет о платоновской парадигме "классы сначала, объекты потом").
-- используя предыдущие описания предпринятия в качестве основы для справочных данных: это примерно соответствует "прототипному подходу к объект-ориентированности", и весьма точно соответствует "производственному способу".
В этой части (порождения справочных данных по данным предпринятия -- а не наоборот, порождения данных предпринятия в соответствии со справочными данными, "по метамодели") исследований нет, и книжка BORO тут пока не помощник. Особо отметим, что речь идет только о способе описания. Ежели же брать ПраксОС как набор методов, то в части описаний поведения это модная сейчас и остродискуссионная тема process mining: там обсуждаются совсем другие вопросы -- нужно ли "асфальтировать протоптанные дорожки" в качестве шаблонов для процессов. Ибо это могут оказаться дикарские тропы, а не "правильные пути", которые можно было бы спроектировать при традиционном подходе upfront конструирования справочных данных.
С Новым Годом, с новым ПраксОС-2012!
Это описание нужно далее:
-- почистить и исправить очевидные ошибки. В 2012 году я буду потихоньку улучшать текст прямо в этом постинге, внося правку по месту -- пока не возникнет необходимость переписать всё заново. Так что возвращайтесь время от времени, текст будет меняться -- и набор понятий и их отношений, и используемая терминология, и определения. Все изменения будут без особого предупреждения.
-- сделать к нему парочку примеров для КонкОрга, чтобы потренироваться в разговоре на этом языке. У меня есть давняя мечта повторить проект "Ивановские ситцы" (был такой проект художественного описания приватизации, чтобы помочь отождествить многочисленные формальные регламенты с реалиями жизни).,
-- отмоделировать в ISO 15926, чтобы получить классы и шаблоны ОргЛана.
А далее уже с формальной микротеорией ОргЛана на руках:
-- придумать формальную нотацию (вернее, нотации) ОргЛана,
-- мэппинг ОргЛана в существующие стандарты (и тем самым обеспечение частичной поддержки софтами. Например, мэппинг в Архимейт даёт возможность пользования редакторами Архимейта),
-- реализацию непосредственной поддержки ОргЛана софтом ПраксОС.
Обращу внимание, что данный текст не является "Рассказом о ПраксОС", ибо он не предписывает лучшие методы организации: тут ничего не написано "как делать", только "из чего состоит предприятие" -- один из ввариантов организационной онтологии, а именно "онтология ПраксОС".
В данном тексте я буду выделять понятия ОргЛана (OrgLan), давая им русские и английские имена -- но на данном шаге такое выделение понятий не является ни полным, ни строгим. Я также почти не давал формальных определений (таковыми обычно считают "X -- это специализация Y в том-то и том-то"). Я буду там и сям давать ссылки на различные источники, знание которых необходимо для понимания этого рассказа (ибо не думайте, что всё написанное придуманно лично мной и представляет собой "онтологию одного человека"), и я не сверял немногие выданные определения с этим источниками.
Когда мы рассматриваем предприятие (enterpise), то нужно четко различать в нём:
-- предпринятие (endeavour): то, что происходит в действительности -- актуальные работы с железками, а также производственными (production) и координационными (сoordination) фактами (facts).
-- справочные данные (reference data): это "знания" -- то, что мы знаем про "жизнь вообще": общую для всех предприятий картину мира и методы, а также существование общих для всех предприятий объектов (каталожных классов рабочих продуктов, адресных баз других предприятий, клиентов).
Без понимания этого различения (между реальными объектами и отношениями, индивидами (individual) и классами (class) объектов и отношений) понять ПраксОС невозможно, это основа основ. Это понимание при моделировании примерно соответствует различению methodology domain и endeavour из ISO 24744, reference data и project data в ISO 15926. Тем самым "предприятие = предпринятие + данные = кусок мира + знания о внешнем мире".
Предпринятие, как имеющее отношение к реальности, имеет приоритет над справочными данными. Много разных вариантов справочных данных может быть соотнесено с одним и тем же предпринятием (то, что для одних -- таскание камней, для других -- строительство храма, для третьих -- бессмысленная трата сил).
Любое рассмотрение должно начинаться и заканчиваться с предпринятия, а не со справочных данных. С другой стороны, справочные данные дают возможность накопить опыт разных предпринятий, чтобы каждый раз не изобретать велосипед при описании предпринятий, их создании/выращивании/развитии -- но это только информация (сведения), в реальности объектов справочных данных нет. Можно летать на самолёте с серийным номером в какое-то конкретное время (этот алюминиевый самолёт и его полёт существуют в реальности, в предпринятии), но нельзя летать на классе самолёта в классе времени полёта (это знание, а на знаниях далеко не улетишь. Даже если это знание вынести в реальность в виде данных на носителях, то и на фрагменте диска с данными самолёта тоже далеко не улетишь). Простые тесты отнесения к реальному миру: "можно увезти на тачке", "можно указать пальцем".
Предпринятие (endeavour) -- это организованные (с определенными ролями, полномочиями и ответственностями) люди и оборудование, здания, сооружения, материалы и рабочие продукты. Такое определение полностью соответствует ISO 15288 (там оно использовано для предприятия в целом, включая справочные данные, но подчеркивается принадлежность к реальному миру). Предпринятие -- это разворачивающаяся в актуальном пространстве-времени физическая система (индивид -- хотя и очень сложно устроенный, и непрерывно меняющийся), об этом разворачивании во времени известны производственные и координационные факты (верные на какой-то момент актуального времени). Предпринятие (в отличие от юридически определяемого предприятия) характеризуется тем, что система-предпринятие имеет четко определенную функцию, которую необходимо максимизировать (goal по Голдратту), изменяя конструкцию предпринятия.
Напомню, что предприятие в юридических документах часто определяется как существующее не только "вечно", но и для достижения определенной цели. В том числе предприятие может не иметь юридического лица. Более того, предпринятие (в отличие от предприятия) вовсе необязательно целью имеет получение денег -- например, церковь целью имеет спасение людей, а политическая партия завоевание власти. Главным для нас является то, что предпринятие имеет цель -- какой-то критерий, по которому определяется глобальный максимум. В книжках по теории ограничений можно найти много обсуждений о разнице "стремления к максимизации показателя" как goal и "удовлетворению критерию, а дальше хватит стараться" как target. В юридической литературе тоже много обсуждений о предприятиях как юридических лицах или созданных без образования юридических лиц, созданных на время или для достижения какой-то цели, и созданных "навечно", но нам сейчас это неважно. Важно, что "глобальней предпринятия системы нет". Расширенное предприятие (extended enterprise), которое определяется как система предприятий, выполняющих крупный инженерный проект, а также новомодное слово эко-система (eco-system) для того же самого на потребительских рынках (например, "эко-система фирмы Apple, объединяющая саму фирму и ее поставщиков, телефонных операторов, разработчиков приложений, пользователей телефонов и т.д.") -- это всё тоже предпринятия, которые реальны.
Предпринятие ведёт кейсы (case) -- системы, некоторые аспекты которых нужно перевести из текущего состояния в целевое (не путать целевые состояния кейса с целевым состоянием предпринятия -- этого "целевого состояния", ведущего к "закрытию предприятия" и вовсе может не быть! А кейс обычно есть заинтересованность закрыть!). Кейсы именуются указанием целевой системы и указания на группу описаний состояния: "здоровье пациента" в больнице, "работоспособность прибора" в ремонтном предприятии, "справедливость для истца" в случае судебного дела, "катастрофа на местности" в случае спасательных мероприятий. Кейсы "открываются", когда предприятие становится обеспечивающей системой для этих кейсов, и закрываются, когда целевая система переходит в зону ответственности другой обеспечивающей системы. Кейсы (системы) тем самым проходят жизненный цикл кейса, включающий в себя стадии, контрольные точки, на них выделяются ресурсы, они являются предметом проектов (которые понимаются как постадийное выделение ресурсов на кейсы), с ними работают процессы (которые понимаются как последовательности работ, нужные для изменения состояния кейса). Кейс нетождественен целевой системе, кейс -- это темпоральная часть целевой системы. В этом плане максимизация результата кейса всегда подчинена достижению глобального максимума предпринятия (задаваемого обеспечивающей системой) и глобального максимума, задаваемого для владельцем целевой системы. Кейсом владеет обеспечивающая система, а целевой системой владеет ее владелец.
Впрочем, есть ситуация, когда владелец кейса и целевой системы -- одно и то же лицо: кейс, когда владелец предпринятия пытается добиться чего-то от собственного предпринятия (например, освоить ПраксОС, поднять прибыльность на небывалую высоту, выйти на зарубежные рынки, первыми высадиться на Марс). Обычно про такие кейсы говорят как про "организационное развитие" -- сюда в том числе относится кейсы M&A, кейсы управления технологиями, реорганизации.
Кейсы в свою очередь делятся на issues, затрагивающие мелкие аспекты изменения состояния системы и имеющие свои локальные цели. Кейсы отличаются тем, что закрытия кейса контролирует владелец целевой системы (валидация: то, что сделано, удовлетворяет владельца), а вот закрытия issues контролируются работниками предпринятия, как обеспечивающей системы. С этой точки зрения кейс задаёт глобальный максимум, а issues служат локальному максимуму.
Ведение кейса и его issues от открытия до закрытия включает в себя производство самых различных работ (work), которые занимают конкретное время и требуют возможностей предприятия по их совершению: сервисов (services) предпринятия. Предпринятие, как обеспечивающая система, имеет готовность проводить эти работы через определенные каналы (места, интерфейсы) -- т.е. внешнее поведение обеспечивающей системы (функции для клиентов) структурировано как сервисы. Сервисы понимаются так же, как в Архимейте: они представляют собой готовое к осуществлению поведение обеспечивающей системы, как активной структуры. В этом плане продукт -- это предоставление обеспечивающей системой-предпринятием для систем в его операционном окружении сервисов (работ по ведению кейса -- изменения состояния целевой системы), связанных контрактом. Это вполне архимейтовское понимание сервиса. Обращаем внимание, что функции предпринятия с точки зрения его (обеспечивающей системы) владельца и сервисы предпринятия с точки зрения владельца целевой системы -- это абсолютно разные сущности.
Кейсы и issue в предпринятии являются целевыми (т.е. над которыми ведется работа -- "пассивная структура" в терминах Архимейта, work product в терминах ISO 24744) системами-подсистемами разного уровня композиционной иерархии, причем эти целевые системы-подсистемы могут находиться в разные моменты времени в разных состояниях, не теряя при этом своей идентичности. Будем называть их "объекты" (подчеркивая пассивность). Возможны различные классификации объектов (в том числе и гибридные -- где основание классификации меняется на каждом уровне иерархии):
-- по уровню абстракции (деятельностные объекты, данные, "в железе")
-- по отношению к целевой системе (сама система, модель системы, документ с моделью системы),
-- по описанию в каком-то конкретном виде документации
-- по известным методам работы (обработки исходного состояния или получения целевого состояния).
-- по возможности закупки (каталожное оборудование, длинноцикловое оборудование)
Работы предпринятия выполняются акторами (в ISO 24744 producers, в Архимейте это "пассивная структура") -- людьми-деятелями (actors) и их агентами-инструментами, в том числе -- компьютерными. Агенты всегда работают в рамках полномочий, данных им деятелями-принципалами, деятели несут ответственность за деятельность их агентов. Если вам банкомат неправильно поменял купюру, вы будете искать телефон ответственного за этот банкомат деятеля, а не ругаться с самим банкоматом). Деятели и инструменты обычно назначаются на роли акторов (в частности, "автоматизация" часто выглядит как назначение робота-агента на ту же производственную роль, на какой раньше был деятель -- если отвлечься от того факта, что при автоматизации обычно меняются и роли).
Возможны различные (в том числе гибридные) классификации акторов:
-- по технологиям (соответствие акторов каким-то методам работы)
-- по полномочиям (органиграмма структура)
Соответственно, конкретные акторы предпринятия занимают те или иные роли в шаблонах описания акторов (в смысле ISO 15926) и согласно этим ролям называются "исполнители", "топ-менеджеры", "инфраструктура", "подразделения", "филиалы" и т.д.
Работы, осуществляемые в порядке осуществления сервисов, могут быть сгруппированы очень по-разному (в скобках -- дисциплины, описывающие способ группировки, но гибридные классификации тоже очень распространены, например в любой WBS можно узнать такую гибридную классификацию):
-- по единству полномочий и ответственности исполнителей работ (традиционные "орг.функции")
-- по единству учёта ресурсов для кейса (project management)
-- по последовательности осуществления (process management, total quality management)
-- по направленности на ту или иную целевую систему (case management)
-- по появлению ранее не встречающихся работ (adaptive case management)
-- по используемым в данном предпринятии методам работы (situational method engineering)
Соответственно, конкретные работы предпринятия занимают те или иные роли в шаблонах описания работ (в смысле ISO 15926) -- и согласно этим ролям называются "проекты", "экземпляры процессов", "работы кейса", и "работы по method enactment" и т.д.. Это всё "классификации", многие из которых абсолютно неспецифичны для конкретного предпринятия, и тем самым относятся уже к справочным данным.
Справочные данные (reference data) определяются по ISO 15926 -- как общие для нескольких предпринятий (чаще говорят о НСИ), или даже нескольких кейсов предпринятия (чаще говорят о мастер-данных, MDM. Заметим, что концепция MDM не работает для отраслевых случаев, а работает только для предприятий с жесткой организацией). Эти данные реализуют ("реализуют" понимается как в Архимейте -- реализацию данными для соответствующих объектов деятельности) сведения о:
-- внешних по отношению к предпринятию системах (операционное окружение самого предпринятия -- его партнеры, клиенты, надзоры и т.д.);
-- возможностях закупки (каталожное оборудование, справочники сервисов);
-- нормативах, стандартах, отраслевом и гос.регулировании
-- классификаторы, словари, тезаурусы и прочие справочники;
-- методы (библиотеки компонент методов, библиотечные архитектурных методов описания), куда входит знание о типовых работах (т.е. видах работ), типовых объектах (видах объектов), типовых акторах (видах акторов).
Важно заметить, что есть два способа формирования справочных данных:
-- непосредственно описывая виды объектов, работ и акторов как "классы классов" (подход ISO 15926). Это "традиционный научный способ объект-ориентированного описания": описывать классы, потом порождать соответствующие им объекты (особо заметим, что речь тут не идет о объект-атрибутной модели, а речь идет о платоновской парадигме "классы сначала, объекты потом").
-- используя предыдущие описания предпринятия в качестве основы для справочных данных: это примерно соответствует "прототипному подходу к объект-ориентированности", и весьма точно соответствует "производственному способу".
В этой части (порождения справочных данных по данным предпринятия -- а не наоборот, порождения данных предпринятия в соответствии со справочными данными, "по метамодели") исследований нет, и книжка BORO тут пока не помощник. Особо отметим, что речь идет только о способе описания. Ежели же брать ПраксОС как набор методов, то в части описаний поведения это модная сейчас и остродискуссионная тема process mining: там обсуждаются совсем другие вопросы -- нужно ли "асфальтировать протоптанные дорожки" в качестве шаблонов для процессов. Ибо это могут оказаться дикарские тропы, а не "правильные пути", которые можно было бы спроектировать при традиционном подходе upfront конструирования справочных данных.
С Новым Годом, с новым ПраксОС-2012!