?

Log in

No account? Create an account
Разработка PraxOS Below are the 10 most recent journal entries recorded in the "Разработка PraxOS" journal:

[<< Previous 10 entries]

October 23rd, 2012
01:10 am
[ailev]

[Link]

PraxOS 3.0: архитектурные принципы
1. Используем театральный блендинг (концептуальная интеграция: использование слов, переносящих элементы значений из одной ситуации в другую, "склеивание миров", морфизм/мэппинг из одной предметной области в другую -- http://ailev.livejournal.com/1015195.html). Собственно, это мы уже неоднократно делали, в http://community.livejournal.com/dot15926/16745.html наиболее развёрнуто:
Театральная метафора

Основная метафора постановки методологии [метод и методология, как объяснено в ISO 24744 -- синонимы]– театральная.

Методология – это сценарий для прописанных ролей, который необходимо исполнить имеющейся труппой реальных людей, назначенных на роли. В ходе постановки пьесы проводится кастинг людей-актеров на роли, эти роли затем разучиваются, закупается реквизит, спектакль репетируется для осуществления правильного взаимодействия актеров друг с другом и реквизитом, а затем осуществляется игра актеров в спектакле соответственно их ролям.
Также я говорил немного на эту тему весной 2010 http://ailev.livejournal.com/818816.html ("Театральная метафора: методологии как сценарии, предприНятие как игра акторов по сценарию. Постановка"), а чуть раньше использовал при переводе на русский ISO 24744 (http://ailev.livejournal.com/816938.html -- "Театральная метафора тут не случайна, она еще много раз пригодится -- акторы, роли, труппа, режиссер-организатор, директор театра, пьесы и сценаристы, импровизация и т.д... Ну, или метафора музыкального ансамбля, которая очень похожа, но в немного более трудном для данного случая языке".).

Мы это делаем для двух целей:
-- если мы будем использовать слова "просто языка", то легко будет перепутать терминологические использования и бытовые. Именно поэтому в науке используют "простые слова" из другого (греческого, латинского) языка, чтобы подчеркнуть необычность значения. Вот мы будем использовать слова из театрального языка, он другой.
-- очень хотелось бы избежать использования иностранной терминологии и айтишного сленга. Нам нужно с простыми людми на производстве разговаривать, они про театр всё понимают, а про айти даже айтишники плохо понимают.

2. Опираться нужно не на подход ситуационной инженерии методов (это был "предварительный подход к снаряду", очень полезный в плане онтологических рассмотрений описаний деятельности), а на подход высокоуровневого моделирования архитектуры предприятия (АрхиМейт как нулевое приближение) и далее низкоуровневое полное моделирование предприятия (см. "PraxOS 3.0: адаптивная архитектура предпринятия", http://praxos.livejournal.com/13988.html). Из ситуационной инженерии методов тем не менее, нужно взять понимание разницы между endeavour и методологической предметной областью (набором паттернов работы -- описаний методов, сценариев).

3. Для того, чтобы учесть и постановочную природу деятельности, и импровизационный ее характер, будем использовать адаптивное управление кейсами (http://ailev.livejournal.com/946134.html) и чеклисты (http://ailev.livejournal.com/1029295.html).

Ключевой момент: мы будем называть сценариями (scripts) "паттерны из библиотеки" -- "template element library", она же community library for templates. В принципе, эти сценарии соотносятся и с user cases для реквизита этих сценариев (ведь тоже переводятся как сценарии). Чем это отличается от "процессов" и "практик"? Процессы и практики -- это именно действия, а вот сценарии -- это паттерны, описывающие для каких-то входных условий и сами действия, и все относящиеся к этим действиям объекты работы (реквизит) и выполнителей (роли).

Кейс же -- это endeavour, конкретное предпринятие-проект (аналог театрального представления по конкретному сценарию в конкретную дату). Отдельная организация-предпринятие -- это тоже такой большой кейс (со всеми его архивами в качестве кейс-файла и регулярным стратегированием на тему "как жить дальше". Это уже даже не представление от занавеса до занавеса, а целый театр со всеми его отдельными представлениями, репертуарными комиссиями и закулисными интригами). Я про предпринятия в части их масштаба и их отличия от community of practice писал чуть подробней тут: http://praxos.livejournal.com/14905.html

4. Ключевая идея -- это подход к предпринятию как к киборгу. Но если раньше я считал, что полезно было бы использовать более точный и продвинутый программистский язык для описания человечьей деятельности в этом киборге (вот, например: рассуждение 2007г., где я сначала говорю про необходимость описывать деятельность на человеческом языке, а затем сбиваюсь на "компьютерную грамотность" -- http://ailev.livejournal.com/470473.html), то после опыта русификации Архимейта (http://ailev.livejournal.com/988360.html, комментарии по этим переводческим "с программистского на менеджерский" решениям -- http://incose-ru.livejournal.com/33568.html) я склоняюсь к ровно противоположной идее: это программистские сценарии нужно описывать по-человечьи, а не по-птичьи (по-айтишному).

Мы считаем, что в инженерной части (выполнение содержательных работ по преобразованию объектов работы, а не операционная переброска реквизита со сцены на сцену) есть не только люди-выполнители, но и программы-выполнители: оптимизаторы (принимающие решения), солверы (придумыватели вариантов), алгоритмы машинного обучения (исследователи, которые дают компактные описания объектов). И взаимодействие этих выполнителей тоже можно описывать сценариями -- хотя детальные сценарии (скрипты на Питоне, например) для этих программ при их кооперации/коллаборации могут отличаться по форме от детальных сценариев (а хоть и на сильно аннотированном всякими подробностями Архимейте) кооперации/коллаборации людей.

Это значит, что моделеориентированную системную инженерию мы будем примерно одинаково описывать как в части работы людей, так и в части работы программ (и уж тем более в части коллаборации людей и программ -- поддержки программами работы людей). Это и есть компактификация знания, не нужно учить два учебника с их двумя разными языками для "кибернетической" и "организмической" частей предпринятия.

5. У кейса есть жизненный цикл -- период от его открытия (в оригинале -- "открытия дела", у нас -- открытия занавеса) до закрытия ("закрытия дела", а в нашем случае -- занавеса). Если для кейса известен его сценарий, то в этом сценарии вполне могут быть указаны стадии и "антракты" с принятием решений о продолжении игры, перехода к альтернативному сценарию или даже роспуску труппы.

Конечно, PLM в данном варианте -- это ACM-система, поддерживающая реализацию набора сценариев для каждого инжинирингового проекта/кейса на базе типовых сценариев (паттернов содержательной работы, паттернов организации работ). Но если в ACM-системе основное внимание уделяется именно сценариям ("скриптам"), то в нашем варианте не меньше внимания уделяется и справочным и проектным данным (PDM). Пока бы я говорил о PLM 3.0 (термин незанятый после демарша Dassault Systemes ;-) у которой:
-- семантическая работа с данными (решает проблемы объект-атрибутной модели данных, описанные в книжке BORO).
-- ACM-движок в части обеспечения сценариев работы (решает проблемы workflow и issue tracking движков)
-- реализованы возможности PDM-системы в части управления конфигурацией не только геометрической и "атрибутивной" информации, но и в части информации разнообразных систем экономического, мультифизического, эргономического и прочего моделирования (решает проблемы управления конфигурацией мегамодели на стадиях высокоуровневого и низкоуровневого моделирования -- http://ailev.livejournal.com/829028.html)

6. Проблема семантической части известна: нужен онтологический язык, удобный для работы с ACM и PDM. Можно считать, что ISO 15926, дополненный какими-то геометрическими (эксперименты Части 3), ACM (наша работа с ОнтоЛаном) и примитивами моделировая (внимательно смотрим на онтологию проекта http://simantics.org) явится решением в первом приближении.

Во втором приближении это может быть элиминирующий разницу между типом и экземпляром типа прототипный язык (одновременно решающий задачу сближения программирования на языках программирования общего назначения с их типами и запросов к хранилищам данных с их схемами данных). Такие исследования ведёт justy_tylor, внимательно следим, что у него происходит.

7. В части ACM-движка в PLM 3.0 должен быть соблюдён баланс кодов и скриптов.

Такой баланс получается за счёт создания специальных "оболочек" (IDE, shell), которые в диалоге работают со исполняемыми фрагментами (snippets) на скриптовых (сценарных, высокоуровневых, диалоговых, динамических -- в отличие от компилируемых) языках программирования, вызывающими разные коды из их библиотек. Эти языки обеспечивают:
-- оркестровку: централизованное координирование поведения независимо работающих акторов/выполнителей (людей или кодов). Каждый актор не знает о том, что происходит вокруг, он только исполняет свою централизованно выданную партию по заранее написанным нотам. За результат несёт ответственность тот, кто поручил работу.
-- хореографию: взаимокоординированное поведение группы совместно работающих акторов/выполнителей (людей или кодов), которые подстраивают своё поведение друг под друга.

"Код" -- это традиционное название для программно реализованных солверов и оптимизаторов, использующихся в инженерном моделировании. Коды обычно хорошо отлажены и стабильны (вплоть до практики сертификации этих кодов), их поведение хорошо известно. Они как-то обособлены (используются как "чёрные ящики" из библиотеки, внутрь кодов не принято залезать простым пользователям). Это программно реализованная "кибернетическая" часть организационного киборга, "думание" компьютеров по заранее запрограммированным программам-обработчикам: солверам, оптимизаторам, распознавателям/алгоритмам машинного обучения и т.д.. Собственно, импровизационная работа людей в режиме непосредственного исполнения с точки зрения ACM-движка выглядит как работа кодов -- но движок всё одно протоколирует эту работу, ведёт учёт изменений данных.

Коды и люди -- это внешние по отношению к ACM-движку сущности.

"Скрипт" -- это сценарий (паттерн, программа, алгоритм) либо работы людей, либо работы кодов, либо их совместной работы (часто называемой workflow). Это скриптование в научном компьютинге выполняется часто на языке Питон, а в операционном (operations management) компьютинге из языков типа BPMN.

Скрипты/сценарии/практики -- это "внутренняя" сущность ACM-движка, ибо этот движок является выполнителем этих скриптов/сценариев/практик, вызывая акторов/выполнителей (людей и кодов) как исполнителей.

Онтология описания кодов, доступных из сценариев в духе адаптивного управления кейсов -- это как раз то, что вынуждены были сделать люди из проекта Simantics для кейсов моделирования. Вот, например, основные классы в онтологии моделирования задачи многих тел (http://www.vtt.fi/inf/pdf/publications/2011/P766.pdf, стр.75. Специфичное для "мультительности" я выкосил):
-- Analysis, which collects all the necessary data associated to a simulation case; [such as analysis type, duration of the simulated time, and the size of the time step]
-- Case, a system simulation case, which holds all the elements of a simula-tion case organised under the elements model, analysis, and results; [which consists of at the most one component of the classModel, at the most one component of the class Analysis, and at the most one component of the class Results. Thus, the instances of the class Case are containers for all the modelling, analysis, and results data for one simulation case. ]
-- Model and SubModel, which collect all the data associated to a multibody system simulation model and enable modular modelling using nested submodels; and
-- Results, which collects the results data associated with the analyses of the case. [TheResults class is a container for the numerical data produced by the numerical solver for the analysis of the case, defined by the instance of the class Analysis].
8. Языки скриптования создаются по образу и подобию языков программирования, а там пока не пахнет операционным менеджментом (планированием использования ресурсов в части "критической цепи", прогнозами, доступа к конфигурации и т.д.). Вот я писал об этом в 2007г: http://ailev.livejournal.com/460198.html). Тем самым язык сценирования/скриптования проектов-в-смысле critical chain management или описания цепочки поставок может существенно отличаться от языка описания сценариев/практик в архитектуре предприятия или процессного описания, а этот язык может существенно отличаться от языка скриптования для управления оптимизацией мультифизической модели инженерной системы (т.е. языка скриптования для библиотек программ оптимизации и геометрического и прочих солверов).

И это только начало проблем с этими языками.

Подход ACM требует, чтобы скриптование было отдано самим актёрам: когда они импровизируют, они для удачных импровизаций сами должны в библиотеке сценариев записать типовой сценарий для последующего его использования. Ну, или такой сценарий они должны записать сами по итогам совещания о том, какой сценарий следует взять для выполнения работ (в том числе вычислений) следующей стадии кейса. Скриптование как на Питоне, так и на BPMN явно не подходит для "народных сценариеписателей". Работники предпринятия -- это не программисты, и не бизнес-аналитики. Даже предложение более высокоуровневых нотаций (например, Архимейт) не решает этой проблемы.

В сегодняшней моделеориентированной [системной] инженерии [и инженериям по специальностям] вопрос решается просто: "актёры не пишут свои сценарии, это пишут специально обученные драматурги". В PLM системах в части issue trackers/workflow описание сценариев работы (процессов)/скриптование делают программисты, используя внутренние языки этих систем (а эти языки весьма специфичны, это даже не Python и не BPMN). В системах моделирования (как инженерных, так и научных) описание сценариев работы кейсов моделирования/скриптование обычно делается на Питоне самими модельерами.

Важно признать, что проектирование и связанное с ним моделирование выполняется как exploratory computing, т.е. это не "водопадный" подход с последовательным однократным прохождением каждой заранее описанной практики/каждого заранее известного сценария. Нет, принимать решение, что делать дальше, нужно прямо в ходе вычислений -- и поправлять имеющиеся сценарии/скрипты прямо по ходу дела в зависимости от ситуации, а при отсутствии сценариев допускать "непосредственное исполнение" (импровизацию, пошаговую работу без сценария/скрипта -- при этом от "автоматизации" остаётся только помощь в ведении протокола, обязательного для ACM-систем. Учёт для аудита/audit trail и возможного последующей рефлексии с извлечением опыта в виде нового сценария или автономизации-с-оптимизацией какого-то сценария в виде эффективно выполняемого кода -- это святое.).

Конечно, в завтрашней моделеориентированной инженерии вопрос качественной методологической/методической/сценарной работы/скриптования/программирования будет решаться многими путями:
-- рост программистской квалификации инженеров (что не так уж невероятно. Тренд включать в образование инженеров программирование как основную дисциплину наряду с математикой и физикой уже налицо).
-- в рамках неизбежно возникающего разделения труда всё более и более частое включение в команды инженерных проектов профессиональных программистов, которые смогут работать со скриптами в ходе проекта (run time), а не во время подготовки производства (up-front "настройка процессов").
-- упрощение самих языков с учётом данных когнитивной науки (например, опора на image schema и блендинг в духе исследований Lakoff вместо опоры на абстрактные математические модели как в Haskell), это даст возможность работы с этими языками если не кухаркам, то простым инженерам.

В любом случае, тут не обойтись одним языком, скорее их будет целый букет и придётся думать в духе cooperative/collaborative languages для cooperative/collaborative solvers (термин по мотивам нынешних штудий группы Алана Кея по архитектурам с использованием разных солверов и разных языков для их скриптинга -- http://vpri.org/html/writings.php).

9. В данном подходе коды/люди/утилиты/приложения представлены не столько как "агенты", сколько как функционалы/capabilities, доступные вовне (сценариям/скриптам в оркестровке и друг другу в хореографии) как services. Но это не веб-сервисы (как и отсылка к семантике в пункте 6 -- это не отсылка к semantic web), с этими тормозами и этой невыразительностью от W3C не нужно иметь дело.

Конечно, выполнители/люди/коды могут быть устроены как "интеллектуальные агенты" -- но и тут непонятен вопрос, чьи они агенты, кто принципалы -- мы ведь не отказываемся обсуждать "актёрские агентства", просто не будем этого сейчас делать).

10. Начальный набор практик/библиотеки сценариев (конкретные практики из предыдущей версии в http://praxos.livejournal.com/14273.html ещё ждут своего прохода для включения в это уточнённое для моделеориентированной системной/специальной инженерии дерево. Да и дерево неплохо бы пересмотреть, включив в него анализ проблем из III в http://ailev.livejournal.com/1026262.html. Это должна быть отдельная работа, а тут кратенький примерчик просто, чтобы не терять целостности изложения):
Основная деятельность (сценарии, которым следуют люди-производственники)
-- маркетинг 
   --методы длинных продаж SPIN)
-- инженерия (моделеориентированная, в опоре на описания
   формальных систем -- http://ailev.livejournal.com/728605.html)
    -- системная инженерия
    -- инженерия системных целей
    -- высокоуровневое моделирование (инженерия системной архитектуры)
    -- низкоуровневое моделирование (мультифизика, мегамоделирование)
    -- обеспечение качества (верификация)
    -- порождающее производство (из битов в атомы)
    -- приёмка (валидация)
    -- эксплуатация и поддержка
    -- мусоропереработка (disposal)
    -- инженерия знаний, НСИ, справочных данных 
       [в части их создания, "инженерии" -- для переноса опыта 
       между предпринятиями по созданию отдельных систем.
       Cм. также "управление информацией"]
  -- инженерия по специальностям:
    -- механика
    -- электротехника
    -- ...
-- операции
   -- управление конфигурацией (учёт)
   -- управление кейсами [сценарии, планирование графика, 
      учёт факта/контроль выполнения]
   -- управление информацией (знаниями, НСИ, справочными данными)
       http://ailev.livejournal.com/1021613.html
   -- throughput accounting

Оргтехразвитие (сценарии, которым следуют люди-организаторы):
-- стратегирование
   -- деревья стратегии и тактики
   -- управление технологиями (и дилемма инноватора)
-- организационная инженерия (метаописания практик)
   -- архитектура предпринятия
   -- сценирование/описание практик/ситуационная инженерия методов up front
   -- учёт стадии жизненного цикла предприятия (Адизес)
-- ведение проектов развития
   -- leadership


11. ОнтоЛан должен отражать опыт множества ситуаций применения, а не быть заточенным на одну ситуацию, хорошо описываемую первым попавшим под руку для мэппинга стандартом.

Теперь нужно:
-- сделать "рассказ PraxOS" на основе данного текста утрясти терминологию (определиться со всеми синонимами, консистентностью использования блендинговых метафор и т.д.). То есть "доперевести на русский" с причьего языка, использованного в данном постинге.
-- сделать глоссарий из встречающихся по тексту Рассказа концептов, Конечно, в глоссарии уже не будет развёрнутого описания тех подходов, которые были использованы, и обоснования сделанных архитектурных решений. Это описание-с-обоснованием -- как раз данный текст. В глоссарии также не будет прописана связь между понятиями -- это должно быть понятно из Рассказа.
-- Первая итерация: именно из этого глоссария (а не, например, из Архимейта) сделать начальный набор классов ОнтоЛана.
-- Вторая итерация: сделать мэппинг для Архимейта, стандартов ACM, описаний систем exploratory computing и т.д., отредактировав и дополнив первоначальный набор классов.

(5 comments | Leave a comment)

June 25th, 2012
12:42 pm
[ailev]

[Link]

Софт PraxOS 3.0
Софт PraxOS 3.0 представляет из себя систему
-- масштаба предпринятия (т.е. масштабируемую от маленькой рабочей группы или сектора в отделе до холдинговой компании), то есть распределенную
-- операционного менеджмента (класса PLM и ERP)
-- операций жизненного цикла стадий проектирования и сооружения/строительства/изготовления (стратегирование и эксплуатация пока не трогаются)

Это система первого уровня интеллектуальности по шкале Мэтью Веста и его друзей из Kalido Ltd. (http://ailev.livejournal.com/878210.html), ибо она обеспечивает
-- аккуратное представление мира
-- спроектированное заранее взаимодействие с системами в своём операционном окружении
-- содержит данные о себе (т.е. "настраиваема")

Основные функции софта PraxOS -- поддержка набора практик операционного управления уровня предпринятия на стадиях проектирования и сооружения/изготовления:
-- управление конфигурацией
-- управление изменениями (в том числе -- "шина данных предпринятия")
-- управление данными (включая поддержку справочных данных, в том числе каталоги комплектующих/предметов снабжения; онтологическое федерирование инженерных систем: САПР, моделирования)
-- планирование работ проектирования и сооружения/изготовления (включая цепочки поставок): ACM, процессная, проектная, ERP/MES парадигмы -- то есть включая up front и динамическое планирование, поддержку шаблонов и т.д.
-- учёт факта работ (контроль прохождения работ)
-- управленческие финансы (throughput accounting)

Предполагается, что инженерные функции будут выполняться в отдельных САПР. Возможно, что для софта PraxOS потребуется разрабатывать специальные САПР или добавлять функции в классические САПР (например, добавлять функции 4D для классических 3D САПР).

Архитектурно речь идёт о платформе программирования, настраиваемой на условия конкретных предприятий. В этой платформе программирования выделяются несколько компонентов:
-- информационная модель целевой системы (3D, поведенческие модели и т.д. -- as design, as build), поддерживает управление конфигурацией целевой системы
-- информационная модель предпринятия (выполнители, работы -- объекты работ будут в информационной модели целевой системы), поддерживает управление конфигурацией предпринятия
-- организационный САПР (редактор информационной модели предпринятия, сиречь редактор ОргЛана) + библиотека шаблонов работы (библиотека методов PraxOS)
-- движок выполнения работ + интеграционная система ("семантическая шина"), обеспечивающая мэппинг данных инженерных систем и софта PraxOS) + библиотека справочных данных, включающая мэппинги к распространённым инженерным системам (САПР) и другим типам организационного софта (PLM issue trackers, процессы ERP, софт проектного управления)

(2 comments | Leave a comment)

June 1st, 2012
03:21 pm
[ailev]

[Link]

Стратегирование, инженерия, операции.
Меня лично интересуют максимально большие предпринятия, на которые способно человечество. Построить атомную станцию, запустить космический корабль, создать сеть сотовой связи и т.д.. Ну, и чтобы это было без предписанного законом насилия (инженерные шарашки, космические запуски на отобранные у налогоплательщиков деньги, привелигированная в силу закона "естественная монополия" в электроэнерегетике и т.д.) -- о полномочиях и ответственностях должна быть договорка, они не должны появляться в силу принуждения. В маленьких предпринятиях очень легко договориться о разделении труда. В больших предпринятиях очень трудно договориться: какого-то вида труда будет избыток, а какого-то вполне может не будет хватать. Поэтому полезны чеклисты, проверяющие проверить наличие у предпринятия всех необходимых возможностей (capabilities)/сервисов, позволяющих этому предпринятию выполнить своё назначение и произвести на свет целевую систему/целевой сервис. Эти же чеклисты могут лечь в основу образовательных программ, готовящих специалистов для крупных предпринятий. Ниже -- классификаторы самого верхнего уровня для такого чеклиста деятельностей/дисциплин/практик. Это я пишу в развитие http://praxos.livejournal.com/14627.html.

Предпринятие -- это когда кто-то конкретный (а хоть и сговорившаяся группа людей) хочет что-то предпринять, и есть договорка о разделении ресурсов и труда (полномочиях по распоряжении ресурсами и ответственностях за какие-то работы).

Сообщество -- это когда есть люди с близкими интересами, которые трепятся друг с другом, и каждый занят своим собственным делом (т.е. нет договорки о разделении ресурсов и труда, а каждый работает самостоятельно).

Больше размер -- больше роль сообщества, меньше предпринятия:
-- Общество, страна, город -- сообщества.
-- Эко-система (business eco-system, современное понимание "отрасли", ибо выходит за рамки традиционных "отраслей". Например, эко-система мобильной телефонии, в которую входят и провайдеры, и производители телефонов и планшетов, и программисты операционных систем и приложений, традиционно относящиеся к разным "отраслям") -- сообщество.
-- Расширенное предприятие (все компании из цепочки поставок какого-нибудь сложного продукта: атомной станции или самолёта) -- предпринятие, разделение полномочий и ответственности в силу явных контрактов.
-- Холдинг, предприятие -- предпринятие, разделение полномочий и ответственностей в силу уставных документов.
-- Подразделение предприятия, корпоративный проект, рабочая группа и т.д. -- предпринятие.
-- Субботник во дворе, проведение концерта и прочие "проекты" -- предпринятие.


Всю основную (направленную на получение целевой системы/сервиса) деятельность предпринятия я делю по назначениям (целям) дисциплин этих деятельностей:
-- низкоуровневое (т.е. маркетинг) стратегирование: заказ того класса целевых систем, которым нужно было бы заняться (формулирование требований к продукции).
-- инженерию: обеспечение функциональных (других ведь не бывает) требований заказчика и других заинтересованных сторон.
-- операции: обеспечение минимального по использованию ресурсов прохождения работ по сети выполнителей.

Кроме основной деятельности предпринятия я отдельно выделяю его организационно-технологическое развитие (организовывание -- замысел, изготовление, модернизация сети выполнителей/сервисов основной деятельности, а технологическое развитие -- смена технологических платформ, "управление технологиями"):
-- высокоуровневое (т.е. формулирование миссии и видения) стратегирование: заказ организации. Это предпринимательская активность, угадайка по поводу будущего. Кто смел, тот и съел. Ну, или того и съели.
-- организационную инженерию: обеспечение технологии (сети выполнителей/сервисов и способов маршрутизации работ между ними) создания целевых систем.
-- организационные операции: обеспечение минимального по использованию ресурсов прохождения работ по организационно-технологическому развитию.

Каждое из этих направлений предполагает два вида работ:
-- содержательную: собственно выполнение работ по стратегированию, инженерии, операциям.
-- лидерскую: катализирование сотрудничества в стратегировании и инженерии (евангелизм), операциях (традиционно понимаемое лидерство менеджеров). Это деятельность по согласованию личных интересов, убеждений и предпочтений (стратегических, инженерных, операционных) и требуемых организацией как машиной по созданию целевой системы.

Тем самым на предприятии я бы выделил стратегов (предпринимателей), инженеров (целевых систем и организационных), инженерных/операционных менеджеров (обеспечивающих операции по созданию целевой системы/сервиса и операции оргразвития). Ещё есть "просто менеджеры", которые удерживают целостность всего описанного: основную деятельность и развитие в их стратегической, инженерной и операционной части, наличие как содержательных работ, так и необходимого стратегического, инженерного и менеджерского лидерства.

В этом списке интересно всё, но "нельзя объять необъятное", профессионализироваться "во всём" невозможно. Пожалуй, ключевой для масштаба предпринятия деятельностью является операционная. Операции по созданию пиццы существенно отличаются от операций по созданию атомной станции или стадиона просто потому, что требуют осознанной координации огромных потоков материалов, денег, людей, работ, данных. Атомную станцию или стадион не построит "рынок" или "сообщество", это должно сделать какое-то предпринятие, а это предпринятие нужно организовать.

Собственно, всем этим много лет и занимаемся. Вот, например, постинг 2007г. "Организация операций" -- http://ailev.livejournal.com/462573.html. Но с тех пор много воды утекло и появилось как новое понимание представления хода работ (не только "проектное управление" или "управление процессами", но и "адаптивное управление кейсами"), а также новые добавки в тамошний список вариантов специализации (поддисциплины, практики). Это более-менее отдельные дисциплины/специализации, которые раньше были "размазаны" кусочками по остальным дисциплинам:
м) управление конфигурацией и управление изменениями (нарезка на объекты работ, которые затем проходят по сети выполнителей предпринятия). Это про PLM (тема "управление жизненным циклом").
н) управление данными и информацией. Это тема федерации систем, интеграции данных жизненного цикла, ISO 15926
о) управленческий учёт (throughput accounting) -- учет "прохода денег" по сети выполнителей (проход денег обратен проходу объектов работ). Это мы занимались Голдраттом.

Теперь нужно освободить содержание всех этих "специализаций" (дисциплин, практик) операционного менеджмента от неизбежного в силу профессионального шовинизма (за многими этими специализациями стоят отдельные профессии -- специализации ВУЗов, профессиональные ассоциации, специализированный софт и т.д.) дублирования практик других специализаций/дисциплин и особенностей принятой тем или иным сообществом терминологии. То есть нужно срочно продвинуться в теме классификации/типологизации/структурирования/прототипирования специализаций/дисциплин/практик.

(5 comments | Leave a comment)

May 26th, 2012
08:22 pm
[ailev]

[Link]

Классификация практик инженерного предпринятия по отношению их к целевой системе
Художник, паталогоанатом и политик смотрят на женщин в ходе своих профессиональных занятий абсолютно по-разному. Разные практики работают с одними и теми же объектами работ абсолютно по-разному. Эти практики можно классифицировать разными способами, в зависимости от того, что вы собираетесь с этими практиками делать.

В постинге "системная инженерия, инженерный менеджмент и инженерные сервисы" (http://ailev.livejournal.com/1005515.html) я приводил классификацию дисциплин как группирование практик по "социологическому" основанию: какие есть профессиональные тусовки с их конференциями, учебниками, ассоциациями и сертификациями. Эта классификация удобна для закупки/подготовки специалистов и закупки софта. Проблемы начинаются там и тогда, где и когда требуется обеспечить интеграцию всех этих практик в работе конкретного предпринятия. Для такой интеграции нужно описать практики содержательно: чтобы можно было легко найти дублирования практик отдельных дисциплин (в силу неизбежного профессионального шовинизма), чтобы иметь достаточную детальность описания типовых практик для выбора из них нужных шаблонов и увязывания фрагментов практик в целостный набор сервисов предпринятия, способный породить целевую систему.

Для этого рассортируем практики по отношению практикующих (выполнителей, деятелей) к целевой системе, уточняя почти трёхлетней давности постинг "Четыре группы описаний жизненного цикла в PraxOS" (http://ailev.livejournal.com/764492.html).

Минимально есть три отношения выполнителей к целевой системе (любой -- от коробка спичек, до марсохода):
1. отношение целеполагания: со стороны внешних системы, в которой целевая система является частью с определенной функцией (назначением).
2. инженерное отношение: со стороны устройства самой системы (части системы и их взаимодействие) -- 4D проект "в классах", а затем и "в бетоне и железе", как его видят проектанты с технологами.
3. логистическое отношение: со стороны работы обеспечивающей системы по протягиванию конфигурации целевой системы по жизненному циклу, как его видят специалисты по операционному менеджменту.

А поскольку у нас появилась еще и обеспечивающая система, то введем дополнительно косвенное для целевой системе отношение к обеспечивающей системе:
4. (косвенное) отношение организовывания и развития: практику создания и развития предпринятия, как обеспечивающей системы из выполнителей, их сервисов и объектов работы.

Тут, конечно, много спорных мест (например, выделение целеполагания вместе с инженерией требований в отдельную группу практик, но у меня есть основания считать, что так будет лучше).

Это очень похоже на группирование практик жизненного цикла системной инженерии в ISO 15288 (куда тоже попали отнюдь не только "инженерные", т.е. технические, практики). Но есть и множество отличий. В качестве упражнения, найдите их сами. Хинт: обратите внимание на подход с "описыванием жизненного цикла" vs подхода с "архитектурой предпринятия", обращение к теории ограничений и adaptive case management против подхода проектного управления и ISO 9000 -- ну, вы поняли идею. Ну, и терминологические замены. Я всегда с трудом объяснял людям про "обеспечение проектов" в ISO 15288. Так что я постарался выбирать слова, наиболее точно отражающие специфический профессиональный взгляд на целевую систему со стороны той или иной практики. Один и тот же болт может быть одновременно для совместно работающих выполнителей разных практик и "элементом конструкции", и "конфигурационной единицей", и "элементом очереди на обработку", и "комплектующим", и "предметом снабжения". Вот я и постарался как то подчеркнуть в названиях специфику разных по типу отношения к целевой системе групп практик:

1. Практики целеполагания (стратегирования, мотивирования, определения требований, маркетинговых исследований).
Внешние требования к целевой системе, которые может понять заказчик, надзоры, операторы и другие стейкхолдеры времени эксплуатации целевой системы: назначение, эксплуатационные свойства и требования к операционному (времени эксплуатации) окружению. Получением этих описаний занимается инженерия требований. Ключевое тут -- "польза", value.

Для собачьей будки это будут:
-- интерфейс к собаке: внутренние размеры, размер входа, нетоксичность, теплопроводность пола и стенок, наличие крепления для привязи и т.д.
-- интерфейс ко двору: внешние размеры, внешний вид
-- интерфейс к оператору: удобство уборки, удобство крепления на месте и последующего переноса,
-- интерфейс к собственнику будки: срок службы, стоимость эксплуатации и ремонтопригодность, стоимость приобретения.
-- интерфейс к собственнику предпринятия-будкостроителя: прибыльность начинания.

Из софта используется бумажный блокнот и скайп.

2. Инженерные (технические) практики.
Инженерное задание целевой системы, и технологическая часть производства: как функция поддерживается конструкцией (какие там части системы -- 3D модель) и механизмом (как части системы взаимодействуют -- "модель поведения", процесс времени эксплуатации), и инженерные планы (планы разработки -- говорят о 4D, процесс времени проектирования). Получением этих описаний занимается архитектурное проектирование (куда входят как инженерия системной архитектуры, так и разные специальные инженерии, включая работу технологов). Ключевое тут -- "4D проект: геометрия, схемы и имитационные модели, технологические карты хода изготовления".

Для собачьей будки это будет:
-- 3D модель из крыши, разных стенок, крепежа.
-- прочностные модели, модели теплообмена (имитационные собаки в имитационной будке в имитационном климате)
-- заказная спецификация на детали (сами детали делаются инженерами по специальности, а также закупаются)
-- технологическая последовательность изготовления, а затем и сборки (4D)

Из софта тут используются самые разные САПРы и системы инженерного моделирования.

3. Инженерные сервисы и логистика: "оперативное управление".
Задание движения объектов (как материальных, так и привязанных к носителям данных) в пространстве-времени: по пространственно размещенным выполнителям в ходе жизненного цикла:
-- оформление объектов работы (конфигурационных единиц), которые нужно передавать по логистическим маршрутам. Это configuration and data management.
-- оформление маршрутов (передач конфигурационных единиц между выполнителями). Это шаблоны adaptive case management. Часть знания о маршрутах при этом приходит из инженерных технологических описаний (методологий разработки и технологических карт), а часть задаётся принятым способом учёта инженерной неопределённости (change management) и тесно связано с практиками configuration and data management.
-- определение и снятие ограничений (заторов) на маршрутах. Это operation research в разных его вариантах (например, теория ограничений).
-- работа с логистикой особого объекта: денег (throughput accounting, подход "прохода денег через производственную сеть" к управленческому финансовому учёту).

Для собачьей будки это будет:
-- выбор системы кодирования, идентификация конфигурационных единиц 4D проекта (будка breakdown structure, breakdowd structure работ по сборке будки и т.д.), определение процедуры "выпуска" (окончания изменений, готовность к передаче дальше -- для согласования или использования) по облегчённой процедуре (ибо вопрос "кому сидеть" для будок не такой острый).
-- оформление маршрута проектирования по рабочим местам, а затем маршрута закупки, изготовления, сборки и испытаний с учётом существующих производственных мощностей-сервисов (взятых из моделей архитектуры предприятия). Подготовка рабочих заданий, контроль их исполнения.
-- компьютерное моделирование хода разработки и изготовления, калибровка моделей.
-- ведение учёта переменных финансовых издержек (затрат и расходов) на проектирование и производство будок.

Из софта тут используются PLM (как интегрирующие инженерные данные) и ERP-системы (в которых важны алгоритмы планирования), системы supply change management, issue trackers и системы документооборота для работы с кейсами и процессами, 1С бухгалтерия для финансовой работы, спец.софт управления проектами (в которых важен алгоритм определения критического ресурсного пути -- "критической цепочки работ") -- то есть софт для "единого информационного пространства", "управления процессами", "управления проектами" и "управленческой бухгалтерии".

4. Организация и развитие предпринятия как пула доступных сервисов необходимых выполнителей: добыча/развитие качественных личностей и закрепление за ними ответственности и полномочий по распоряжению ресурсами, включая оборудование, деньги, и выдачу поручений другим людям (организация обеспечивающей системы), а также удовлетворение потребностей производства в технологиях (оборудовании).
-- практики организационной инженерии: задание архитектуры предпринятия (из людей, софта и оборудования), выполняющей все необходимые работы практик из предыдущих пунктов, а также реализация этой архитектуры в жизни (включая снятие ограничений -- ибо оперативное управление может и должно не столько снимать ограничения, сколько подстраиваться под них) -- "управление изменениями" aka "проекты развития" (не путать с "управлением изменениями" у инженеров). Это вотчина организационных инженеров.
-- лидерство (какие конкретные люди какой деятельностью займутся: назначение живых индивидов на занятие позиций в неживой оргструктуре). Это вотчина менеджеров, которые умеют работать с людьми. Оргинженеры тут отдыхают.
Конечно, "инженерный менеджер" подразумевается при этом как профессия человека, который может и архитектуру предпринятия разработать, и с людьми договориться -- как амфибия, выжить в обоих мирах. Но нам сейчас это неважно, нам бы на типы практик указать, в которых целевой системой является обеспечивающая система первых трех (целеполагания, инженерии, логистики) практик.

Из софта изредка используется система моделирования предприятия (чаще органиграмма составляется в Ворде), и MS Office для всех мыслимых потребноестей, которые есть у менеджеров. Ну, и данные всех остальных систем, которые есть. И даже данные социальных сетей, а чо!

Для собачьей будки это будет:
-- проверить, всё ли у нас есть для старта будкоделательного предпринятия. Докупить софт моделирования (ишь ты, конкуренты начали публиковать тепловые характеристики своих будок!) в службу Проектирования обиталищ.
-- назначить Василия Петровича на все роли системных инженеров по этому проекту, он собак любит, и у него много друзей собачников (а во включении кинолога в команду разработчиков в качестве "голоса пользователя" -- отказать). И студента Колю поставить на все САПРы сразу, ему давно пора расти как инженеру. Не будет справляться -- терпеть, пока научится.
-- последовательное прокручивание цикла снятия ограничений (студент Коля зашился со своими САПРами, ему нужно срочно подмогу! Комплектующие приходят неправильные, от обратной логистики лихорадит всех -- срочно разобраться, почему у нас заказывают эту гадость!).
-- уговорить Дядю Петю потратить полдня на учёт интересов собаки при проектировании 3D, и уговорить Тётю Дусю всё-таки закупать метизы в фирме "Заваляшка", где ей грубят и хамят, но зато там не бывает задержек с поставками и грубых ошибок комплектации.
-- троих из сборочного кошачьих домиков, у которых аллергия к кошкам (вот идиоты! Кошек же на сборке этих домиков нет!) переучить на работу по сборке будок. Или даже лучше набрать новых, а тех троих уволить. Зачем нам люди с заморочками?

(1 comment | Leave a comment)

April 28th, 2012
12:20 am
[ailev]

[Link]

Roadmap PraxOS 3.0
1. OrgLan -- это концептуальная модель в ISO 15926. Назначаем в качестве OrgLan 0.1 мэппинг Архимейта к ISO 15926.

2. Мэппим теперь оттуда, где есть нужные данные: метамодель http://opfro.org/ в OrgLan 0.1 (то есть к ISO 15926), дополняем и исправляем -- получаем OrgLan 0.2.

3. Льём полное содержание OPFRO (примерно 1100 компонент методов), а затем редактируем [считаем, что более-менее удобное редактирование к этому моменту появится -- хоть "в деревьях", хоть "в таблицах", на диаграммы не надеемся] справочные данные -- переводим на русский, корректируем и дополняем методами из списка по пункту II в http://praxos.livejournal.com/14273.html (начального классификатора шаблонов практик PraxOS). Корректируем метамодель PraxOS по итогам этого редактирования, получаем OrgLan 0.3 (и, конечно, на нём в этот момент будет доступна начальная библиотека справочных данных PraxOS).

4. Обеспечиваем работу редактора архитектурного описания предприятия (очень надеюсь, что это будет на базе .15926 Editor -- ибо Archi совсем не подходит) для кастомизации (специализации, или клонирования-редактирования) справочных данных PraxOS -- для КонкОрга. Как минимум, на этой стадии "научные имена" заменяются на имена с отраслевой спецификой КонкОрга, сервисы распределяются по оргструктуре, и уточняется IT-решение (уровни программ и оборудования). Это, пожалуй, первая польза -- у нас появляется архитектурная модель КонкОрга, созданная на основе наших чудесных и правильных методов работы PraxOS.

5. Делается генератор распорядительной документации, чтобы из модели предприятия получить все необходимые должностные инструкции, положения об отделах и т.д. -- это сильно поможет проектам развития. В принципе. этот же генератор документации может отрендерить и вебсайт по практикам, аналогичный текущему opfro.org, только вот справочные данные PraxOS в этот момент уже легко и удобно редактировать (сейчас opfro.org можно редактировать только руками в виде HTML документов -- ужас-ужас!).

6. Делается генератор конфигурационных файлов для настройки корпоративного софта (например, для конфигурирования issue tracker в PLM).

В принципе, за последние лет пять таких "праксосов" развелся миллион и маленькая тележка (от "оглавлений полезной литературы по методам" типа http://www.npd-solutions.com/bok.html до http://www.bkcase.org/sebok-075/ -- со всеми промежуточными остановками). Наши отличия:
-- качество справочных данных по содержанию: мы считаем, что отобранные нами методы работы лучшие!
-- качество справочных данных по форме: они формальны по составу, и поэтому качество наших описаний выше. Это уже не столько "описание", сколько "модель".
-- возможность непосредственного использования в качестве начальных шаблонов (архитектурных паттернов) для архитектуры предпринятия (т.е. привязка практик и их ролей к оргструктуре, планирование IT-решения -- всё то, чем хороша архитектура предприятия, и чего не хватает в ситуационной инженерии методов). Можно генерировать регламенты, положения, инструкции, приказы, планировать проекты развития.
-- а поскольку у нас появляется формальная архитектура предпринятия (на ОргЛане, т.е. на ISO 15926 -- достаточно формальное представление), то можно думать о генерации конфигурационных файлов для прикладного софта (а хоть и такого сложного, как PLM-системы -- почему бы и нет?).

Ну, понеслась! Это ведь всё вполне обозримо и выполнимо. Не боги горшки обжигают.

(3 comments | Leave a comment)

April 16th, 2012
04:58 pm
[ailev]

[Link]

Релиз PraxOS 3.0
Общая цель релиза PraxOS 3.0 -- получить библиотеку архитектурных шаблонов для моделе-ориентированных инженерного менеджмента и системной инженерии (предыдущие планы релиза 2.3 -- http://praxos.livejournal.com/455.html).

I. Приложение методов -- консультирование
-- выполнение реальных консультационных проектов с использованием библиотеки паттернов. На эту тему мало что можно сказать подробнее: в Сети можно найти очень незначительное количество архитектурных диаграмм предприятий, потому что такая информация обычно не раскрывается. Это верно и для использования PraxOS: раскрыть можно только шаблоны, но не итоговые модели. Работа с клиентами не терпит публичности.

II. Пополнение библиотеки архитектурных шаблонов и их освоение -- профессиональный рост
Начальный (существенно неполный -- просто пример) классификатор шаблонов:
1. Инженерный менеджмент
1.1. Проекты развития
1.1.1. адаптивная архитектура предприятия
1.1.2. реализация изменений
1.1.3. целеполагание (стратегирование)
1.1.3.1. управление технологиями
1.1.3.2. теория ограничений (TOC)
1.2. Маржинальный финансовый учёт
1.2.1. KPI
1.2.2. Динамическое бюджетирование (beyond budgeting)
1.2.3. РСБУ+МСФО
1.2.4. Управление портфелем проектов
1.2.5. учёт прохода (throughput accounting)
1.3. Управление проектами
1.3.1. 4D реализация системы
1.3.2. adaptive case management
1.3.3. CCPM и factory physics
1.3.4. LastPlanner
1.3.5. SCOR (включая обратную логистику и прочие прелести)
1.4. Управление информацией
1.4.1. Интеграция данных жизненного цикла: ISO 15926 outside
1.4.2. Обмен информацией между контракторами: ISO 29481 (VISI)
2. Системная инженерия
2.2. Инженерия требований
2.3. Инженерия системной архитектуры
2.3.1. ТРИЗ, аксиоматический дизайн, DSM
2.3.2. Архитектурные языки
2.4. Верификация и валидация

III. Методология -- инструментарий
В текущем релизе методология должна уже быть поддержана софтом. На базе софта .15926 нужно сделать софт PraxOS, отличающийся от всем известного Archi следующим:
1. Поддержка модульности и управления конфигурацией (как библиотеки шаблонов, так и результирующего архитектурного описания КонкОрга)
2. Удобная специализация ("копирование с наследованием и возможностью уточнений")
3. Возможность работы с несколькими классификаторами одновременно (прежде всего, классификатор паттернов)
4. Реификация отношений
5. Семантика (отношения настоящие, а не "нарисованные" -- т.е. на них можно опираться при мэппинге)
6. Расширяемость типов (class_of_class) на базе полного ISO 15926
7. Поддержка мэппинга модели во внешние представления (как конфигурационные файлы разного работающего с индивидами корпоративного софта, так и генерация отчётов типа "Положение о подразделении")
8. Возможность создания учебных курсов (задач) по библиотеке шаблонов
9. Выход на детальное моделирование взаимодействия (interoperability): федерирование объектов работы (целевая система), работ (обеспечивающая система, ACM), трансакций (перформативы из LAP/DEMO).

(Leave a comment)

April 6th, 2012
03:10 pm
[ailev]

[Link]

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).

(3 comments | Leave a comment)

December 31st, 2011
10:07 pm
[ailev]

[Link]

Неформальное введение в понятия ОргЛана
Я решил, что черновой вариант, соответствующий начальным шагам реализации пункта 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!

(Leave a comment)

September 23rd, 2011
10:36 pm
[ailev]

[Link]

Дважды контринтуитивность Праксос: мощные идеи предмета и мощные идеи по его описанию
В моих поисках контринтуитивных мощных идей (http://ailev.livejournal.com/500732.html) я нахожу

1. Предметная контринтуитивность: за счет нахождения предельно эффективного метода. Примером может служить отобранный в пункте 7 моих десяти тезисов по ОргЛану короткий списочек организационных практик и связанных с ними метамоделей (http://praxos.livejournal.com/12907.html): EA (Archimate), SME (ISO 24744), ACM (CMMN), business rules (SBVR) и т.д.

2. Описательная контринтуитивность (использование Онтолана и Орглана, http://praxos.livejournal.com/13095.html): эти практики из пункта 1 я описываю с использованием 4D онтологии -- то есть пытаясь понять, "что такое" представляет из себя по онтологическому типу (индивид? класс? отношение? интервал времени? момент времени? физический предмет? и т.д.). Такой метод описания позволяет:
а) существенно компактифицировать результирующие описания каждого из предметных методов, заодно формализовав их в достаточной степени для работы с информационными системами (компактификация за счет использования 4D формализма -- это объясняется в работах типа книжки BORO, http://ailev.livejournal.com/938647.html). Формализм осваиваем в рамках проекта dot15926.
б) частично отождествить аналогичные описания в разных методах (выявить correspondence rules) и нормализовать эти описания уже для всего набора методов (http://ailev.livejournal.com/872954.html).

Обращу особое внимание, что работы нынешних организационных онтологов (поищите в Гугль organizational ontology -- увидите очень много материалов) меня полностью не устраивают. Они отличными онтологическими методами работают с допотопными представлениями об организации. Толку от этого немного.

Мы же применяем онтологическую работу к новинкам организационной работы. Тем самым получаем praxos как "новый товар в новой упаковке", контринтуитивно оформленные контринтуитивные идеи.

(Leave a comment)

September 17th, 2011
11:03 pm
[ailev]

[Link]

Орглан и Онтолан (Orglan and Ontolan)
Традиционно архитектурные языки и подходы (они же, как нам рассказали Захман и Диетц, теперь называются "организационные онтологии") структурируют свой предмет (scope) в виде каких-нибудь "матриц" или "трехмерных матриц". Для Архимейта это куб "субъект -- поведение -- объект / бизнес -- приложения -- технология / внутреннее -- внешнее" (то, что это не "таблица", а именно "куб", подробно рассказывается в книжке) и треугольничек "общие понятия -- понятия Архимейта -- понятия предприятия". Для подхода Захмана в версии 3 -- это матрица "что-где-когда-как-почему / уровни реификации".

Оказывается, что в enterprise architecture не так много специфических именно для этой архитектуры различений. Огромное их количество оказывается связано с upper ontology -- выбором того, как мы представляем мир. Предприятие -- это часть мира, и онтологические выборы оказываются крайне важными для описания предприятия. Если вы в мире не выделяете системы из их окружения, то архитектура предприятия у вас тоже будет бессистемной (pun intended).

Для определения предмета (scope) Орглана нужно как-то взглянуть на предметную область с птичьего полёта -- задать что-то типа таблички и треугольничка Архимейта, или матрицы Захмана. В качестве шага для этого можно предложить следующие возможные "размерности" (различения) для этих треугольничков и табличек:

1. "Пирамида знаний"
Обычно "пирамида знаний" рисуется треугольничком отдельно от всяких "матриц", в которые пытаются упихнуть разные другие различалки. В этой пирамиде показываются "уровни общности понятий".

1.1. формализм -- representational ontology, мета-мета-модель. В SysML/UML это MOF, в ISO 15926-2 это EXPRESS, в ISO 15926-7 это FOL, в Archimate -- это квадратики разной формы и разнообразные стрелочки (т.е. формализм в явном виде не задан, и это очень плохо).

Мы выбираем в качестве формализма .15926L (т.е. не FOL, не EXPRESS, а сразу тьюринг-полный язык).
Это обычно в "треугольничке" пирамиды не показывают: это тот материал, из которого сделана сама пирамида, тот холст, на котором нарисована её картинка.

1.2. Онтолан (Ontolan, от ONTOlogy LANguage -- странно, такого слова Гугль еще не знает), upper ontology -- "школьное" (т.е. для изучения в средней школе) подмножество ISO 15926-2, или аналогичное "улучшенное", но отмэпленное в ISO 15926-2 (например, подмножество HQDM). Вряд ли стоит сейчас замахиваться на собственное "улучшение" типа HQDM, которое потом нужно будет самостоятельно мэппить в ISO 15926, но наверняка придется озаботиться выбором более точных и удачных слов.
Что точно должно войти:
-- множественные специализации (классификации, хотя речь идет не о членстве в классе: ненавижу эту запутывающую терминологию)
-- многоуровневая конкретизация-порождение (уровни абстракции, мета)
-- мереология (части и целое, в том числе темпоральные части)
-- время: моменты и интервалы
-- системный подход: функциональные места и модули
-- агенты, действия, продукты
-- информация, данные, информационные продукты
-- "география" (места, адреса, площадки)
Что точно не должно войти (ибо должно попасть в "расширения" Орглана):
-- стереометрия (3D, формы)
-- "естественные науки" (молекулы, атомы, живое-неживое)
-- парсинг (правая-левая часть имени) и прочая информатика
В чем есть сомнения:
-- свойства и UoM (обычно нужно ддля описания продуктов, но в архитектурных языках часто этого просто нет -- например, в ArchiMate). С другой стороны, как в школьном языке без свойств?

Про всякие кардинальности и ограничения пока умолчу.

1.3. Орглан (Orglan -- ORGanization LANguage): организационная онтология (мета-модель), т.е. специализация понятий и отношений Онтолана до специфически организационных понятий и отношений -- на которых можно выразить предметную область PraxOS (заметим, что сам PraxOS -- это каталог компонентов методов. Методы же написаны с использованием понятий Орглана. Тем самым PraxOS -- это тексты, написанные с использованием понятий Орглана (а без учета нюансов -- "Праксос написан на Орглане"). PraxOS относится к Орглану как "Сказка о царе Салтане" Александра Сергеевича Пушкина к словарю Владимира Ивановича Даля (со всей прилегающей дискуссией о влиянии поэзии Пушкина на состав словаря Даля).

При рассмотрении сегодняшних мета-моделей архитектурных языков оказывается, что значительная часть их понятий относится к Онтолану (т.е. выражает общеонтологические понятия, а не специфические именно для организации), а вот собственно специфичный для организации Орглан (специализация общеонтологических понятий, использующихся именно для организации и enterprise architecture, он же -- микротеория организации, он же -- middle level ontology for organization) оказывается не такой объемный.

Моя сегодняшняя гипотеза: Орглан состоит из тех понятий из разных организационных дисциплин, перечисленных в пункте 7 моих 10 тезисов (http://praxos.livejournal.com/12907.html), которые связаны между собой различными correspondence rules.

1.4. Мета-модели организационных дисциплин. Они связаны между собой corresponding rules, ибо мэппированы к связке Онтолан+Орглан.

1.5. Расширения (для выражения внешних моделей -- моделей продуктов, моделей экзотических организационных дисциплин, имитационных моделей и т.д.).

2. Разбиения (сборка-разборка, части-целое).
Системный подход -- это как раз оно: выделение холархий (т.е. иерархий по отношению часть-целое), модульность и связанные с модульностью интерфейсы.
Я нарочно не использую слово "детализация", потому как оно обычно используется и для разбиений (часть-целое), и для уровней абстракции. C другой стороны -- метасистемный переход обычно подразумевает смену типа описания при переходе к очередному уровню холархии (так, описывать работу органелл в клетке нужно одним способом, работу клеток -- другим, работу органов -- третьим, работу организма -- четвертым). Но это не разные уровни абстракции описания, это разные виды описаний для разного уровня разбиений.

3. Уровни абстракции (как туманно выразился Захман -- "реификации", уровни воплощения идеи в реальность -- от свёрнутых высказываний через порождение/generation к системе "в бетоне и металле", а в случае организаций -- "в людях и компьютерах"). Это совсем "детализация целого на уровне частей", а построение мета-модели с оглядкой на мета-мета-модель, модели с оглядкой на мета-модель, системы в реальности с оглядкой на модель.

4. Различение акта деятельности -- высказывания "продюсер/агент -- работа -- продукт" (в Архимейте это активная структура -- поведение -- пассивная структура).

5. Альтернативы (выборы и принятие решений, как в Goal).

6. Динамика (архитектура as is, архитектура to be, архитектура as built).

Еще раз обращу внимание, что практически все эти различения (если не все!) относится к общеонтологическим (ну, и немного инженерным -- у нас ведь деятельностная онтология), а не специфически организационным. Архитектурные языки -- это языки, описывающие основные принципы организации чего угодно, необязательно организации.

На первый взгляд, это всё сильно сложнее того же Архимейта или Захмана. Но это только на первый взгляд: просто часть сложности из неявной вышла наружу и названа явно. И эта часть разделена между Онтоланом и Оргланом.

Сразу оговорюсь, что дискуссия по Архимейту подвела черту под тем, как используется архитектура в целях коммуникации: архитектурные артефакты предназначены прежде всего для понимания специально обученными людьми, а для топ-менеджеров и прочих стейкхолдеров от рядовых сотрудников до заинтересовавшихся вдруг архитектурой приглашенных консультантов по случаю готовятся разные презентации (ага, в PowerPoint и без использования формализмов). Так что я не боюсь, что Онтолан+Орглан окажутся контринтуитивны и потребуют специального обучения. Любая хорошая контринтуитивная идея поначалу является непопсовой, и широко не распространяется. Затем мощность этой идеи берет своё, и она становится интуитивной. Мы надеемся ровно на такой сценарий с Онтоланом и Оргланом.

Итак, теперь нужно сделать Онтолан (и сразу -- учебный по нему курс, чтобы быть уверенными, что люди понимают его контринтуитивность).

(2 comments | Leave a comment)

[<< Previous 10 entries]

My Website Powered by LiveJournal.com