Онтологические стандарты организационной модели PraxOS Версия 0.2

Минимальный набор Информационная модель проекта-design (целевая система) Информационная модель проекта-project (процесс ЖЦ) Информационная модель организации (обеспечивающая система) Минимальный набор информационных моделей

«Настоящий» системный подход Информационная модель проекта-design (целевая система) Информационная модель проекта-project (процесс ЖЦ) Информационная модель организации (обеспечивающая система) ПРОЦЕСС ОРГРЕФОРМЫ СИСТЕМНОЙ ИНЖЕНЕРИИ ОРГАНИЗАТОРЫ ОРГРЕФОРМЫ «Правильный» набор информационных моделей Рефлексивные модели (ВОС)ПРОИЗВОДСТВО

Типовые процессы ЖЦ: разные уровни детальности ЗамыселПроектирование...Пуск Технологические схемы.... Выбор оборудования Компоновка ПридумайНазначь кодНарисуй... Опубликуй в репозитории Жизненный цикл проекта Жизненный цикл проектного решения Жизненный цикл системы... Включить людей!

Разные решения = разные описания деятельности Деятельность описывается по-разному, в зависимости от того, какие решения вы принимаете по поводу деятельности, используя то или иное описание. Вот примерный текущих методов описания (viewpoint) деятельнсти для PraxOS: Решения о том, как увязать PBS-проектируемой системы и WBS-параллельного проектирования (plant и work breakdown structure) -- используются разные варианты DSM (design structure matrix, матрицы взаимозависимости). Решения о том, как взаимодействуют друг с другом разные участники процесса (какие сервисы они оказывают друг другу), какая последовательность событий происходит, какие артефакты передают друг другу участники -- используется OMG BPMN2 ("прямоугольнички со стрелочками", "логические процессы"). Решения о том, какие практики должны использоваться в работе, как эти практики распределяются по стадиям проекта, как -- используется OMG SPEM 2 ("горбатая диаграмма", hump diagram). Решения о критическом ресурсном пути (какие ограничения), ожидаемом времени завершения работ, распределении ресурсов по работам -- Gantt ("управление проектами"), например, в варианте Goldratt (с буферами). Каким образом выполняемые действия следуют из целей (общая стратегия) и какие есть KPI -- OMG BMM (про это же -- "деревья работ и результатов" Goldratt)

Ключевая стадия ЖЦ разных систем: «определение системы» (system definition, «проектирование») Оборудование: конструирование (3D-модель) Здания и сооружения: проектирование (4D-модель) Организация: стратегирование (4D-орг.модель) Новая технологическая платформа: (расчетная модель) моделецентрическая системная инженерия

Что такое «организация»? (группы описаний) ISO («схема многих знаний») -- много групп описаний, адресующих разные интересы и выполняемых по разным методам описания: Сообщества (и их специфическая терминология) Нормы Организационные процессы Стратегия (цели и средства) Оргструктура (полномочия) Финансы

Вокруг ISO нет оргстандартов

Выбор практики описывания организации Концепты и нотации фиксируются в стандартах: ищем стандарты многоаспектного описывания организации Не путать со стандартом ЖЦ персонала (ISO Human Centered Lifecycle Process. Аналог ISO для «железа», ISO для софта). Интересуют не просто описания (бумажные, неформальные), а модели (представимые в электронном виде, формализованные) – ищем не среди «менеджерских стандартов», а среди «айтишных стандартов». Среди айтишных стандартов ищем те, которые в состоянии прочесть «простые люди» без программистской подготовки (и такие стандарты есть!) Значительная часть описаний организации непосредственно выполняется организационным софтом (документооборот)

Выбор группы стандартов оргописаний: OMG MDA «универсальный язык описания системы». Он не задает никаких предписанных групп описаний, и никакой оргонтологии для этих описаний SysML «Верхнеуровневое описание организации и её IT» -- задают набор групп описаний, но не оргонтологию. Примеры: ISO (требования к описанию организаций, есть открытый вариант -- GERAM от IFAC/IFIP и ряд типовых шаблонов описания типа ISO RM-ODP), TOGAF (Open Group), ArchiMate (Open Group), архитектура Захмана,... Enterprise Architecture Стандарты моделирования (метамодели) организации в составе Model-Driven Аrchitecture OMG. Задают онтологию (метамодель) организации, соответствующую лучшим консультационным практикам с одной стороны, и формально удовлетворяющие требованиям айтишников по непосредственному исполнению. OMG MDA

OMG MDA (Object Management Group Model-Driven Architecture) OMG – международная организация стандартизации (стандарты бесплатны). Основная идея (2001г.): стандартизировать нужно не интерфейсы, а стандартизировать нужно модели. Модели живут дольше интерфейсов! MDA описывает не только разработку софта, но и разработку систем, в том числе – организаций. MDA сегодня наиболее близка к MBSE (model-based system engineering). Были интегрированы идеи двух сообществ, учитывающих интересы «простых людей», а не «программистов»: – Business Rules Group («поворот к людям» в 1997г., стандарты организационных норм и словари) и – BPMI (нотация процессов BPMN). Не утрачена возможность непосредственного исполнения компьютером («формальная нотация», но в то же время остается понятной людям в организации)

Стандарты оргописания OMG SBVR (Semantic Business Vocabulary & Rules) – для составления терминологических словарей, а также записи организационных норм SPEM 2 (Software and Systems Process Engineering MetaModel) – для создания информационных моделей жизненного цикла, требуемых ISO BPMN 2 (Business Process Management Notation) – для записи организационных процессов BMM (Business Motivation Metamodel) – для записи стратегий (целей и выбранных средств их достижения) OSM (Organizational Structure Metamodel) – для записи организационной структуры и полномочий. планируется продолжать разработку (описание ресурсов, финансов и т.д.) Важно: все эти стандарты предполагают наличие программных средств для записи организационных моделей в электронной форме для двух целей: Удобство внесения изменений, контроля версий, обмена информацией Возможность непосредственного исполнения компьютером (документооборот)

Организационный словарь (SBVR) Смысловое сообщество – люди, которые одинаково понимают концепт. Словарное сообщество – люди из смыслового сообщества, которые одинаково называют концепт. Не договорившись о терминах, не договоришься о концептах – и наоборот. Уйти от споров «о словах», перейти к спорам о концептах SBVR – это мостик между терминологическим сообществом и онтологическим (например, ISO 15926)

Организационные нормы (SBVR) Организационные нормы – это запрещения и разрешения. Нормы = основное организационное знание. Нормы должны быть формально полны и непротиворечивы, но в нотации, доступной для понимания простым людям в организации. Нормы выражаются с использованием организационного словаря, поэтому стандарт SBVR определяет как словарь, так и правила записи норм (13% объема стандарта посвящено онтологии и нотации норм, остальное – терминологии). Существует Манифест организационных норм, определяющий их место в информационной модели организации (например, необходимость поддержки независимости описания норм от описания процессов). Есть определенные проблемы с формальной записью норм на русском языке (controlled Russian трудно себе представить, а controlled English широко распространен)

Оргнормы и оргтребования Простые люди читают фактоориентированные записи: в нормах всегда есть – модальный глагол типа «должен» и – глагол, выражающий отношения между понятиями – понятия, определенные терминами из словаря Конструкторское решение не может быть опубликовано без визирования вышестоящим проектировщиком. Для реализации организационных норм могут быть выдвинуты дополнительные [часто ресурсные]оргтребования (нормами не являющиеся): «обеспечить визирование вышестоящим проектировщиком при помощи workflow САПР-софта»

Организационные нормы: понятные и айтишные Организационная норма (в нотации SBVR-RuleSpeak): A discount of 15% must be applied on the shopping cart if the shopping cart contains between 2 and 4 items and one of the following conditions are met: - the purchase value is greater than $100 and the customer category is gold - the purchase value is greater than $200 and the customer category is silver Та же организационная норма (в программистской нотации PRR-OCL): Rule discount ruleVariable: ?customer: Customer = Customer->any() ?shoppingCart: ShoppingCart = ShoppingCart->any(c: customer | c=?customer) Condition: (?shoppingCart.containsItemsInRange(2, 4) and (((?shoppingCart.items->collect(i:Item|i.value))->sum()>100 and ?customer.category == "Gold") or ((?shoppingCart.items->collect(value))->sum() > 200 and ?customer.category == "Silver"))) Action: shoppingCart.discountValue = shoppingCart.discountValue

Стратегирование: BMM (Business Motivation Metamodel) Формализованная запись популярных концептов стратегирования: «целей и задач» организации, миссии, видения, средств их достижения, и т.д. указывает на связи целей и средств с организационными нормами (SBVR), процессами (BPMN 2), оргструктурой (OSM) и т.д. Различение целей и средств (ends – means) Включает «влияния» и запись результатов SWOT- анализа этих «влияний»

Организационная структура: OSM (Organizational Structure Metamodel) Все оргмодели работают с ролями Роли не связаны с полномочиями Организационная структура – это про полномочия Организационная структура – это места привязки других оргмоделей (стратегии, процессов, орг.норм) разного уровня детализации

Выбор стандарта описания процесса, как цепочки действий: OMG BPMN Как «передача точки управления» (удобно программистам, метафора императивных языков программирования, диаграммы activity UML 2) Как «машина состояний» (удобно программистам, формализм Petri Net) UML, Petri Nets В терминах «раньше, позже, одновременно с» – единственно понятно простым людям. Формально этому соответствует язык описания процессов PSL (process specification language, опирающийся на формальную логику. Он же ISO Закреплено в нотации OMG BPMN 2, OMG BPMN 2 Проблема представления «динамических процессов» («договорились о процессе – сделали – опять договорились – сделали...») пока в стандартах отсутствует. agile

Процессы: BPMN Формальная модель времени, соответствующая «народной онтологии» Последовательность событий для одного актора (оркестровка) Последовательность взаимодействий нескольких акторов (хореография)

Использование практик системной инженерии в описаниях процессов: SPEM 2 (Software and Systems Process Engineering Metamodel) ЗамыселПроектирование...Эксплуатация Требования Архитектура... Пересмотры ПРОЦЕСС ПРАКТИКИ МЕТОД описание продукта описание практики ПРОЦЕСС инструкции использование продукта использование практики t ВPMN 2

Инструкции и повторное использование моделей ЖЦ: SPEM 2 позволяет выполнить требование ISO по описыванию жизненного цикла: довести описание до уровня инструкций Инструкции в модели представлены в виде «электронного справочника»: простота распространения Поддерживаются «библиотеки» практик для многократного использования одних и тех же практик в разных процессах

Инструментарий описания организации (софт) Современным аналогом глиняных табличек, доски с мелом и даже карандаша и бумаги является компьютер. Главным следствием перехода к компьютерным описаниям явился переход от документоцентрического подхода к датацентрическому («базам данных»), даже в бухгалтериях. В России Бухгалтеры используют 1С, SAP, Oracle для «инфрмационной модели» проводок – они понимают, что такая программа им нужна. Проектировщики и конструкторы начинают использовать Intergraph SPF, Dassault Systemes SmartTeam, AVEVA Vnet для «информационной модели» конструкторских решений– они понимают, что такие программы им нужны Организаторы не используют KnowGravity KnowEnterprise, IBM Rational Method Composer для «информационной модели» организации -- и не понимают, что такие программы им нужны. Это новый класс программ. Иногда такие «орг.программы» используют айтишники, но «для себя» (т.е. их записи непонятны простым людям)

24 Спасибо за внимание Анатолий Левенчук Виктор Агроскин TechInvestLab.ru +7 (495) Дополнительные материалы: