Всего на сайте:
166 тыс. 848 статей

Главная | Финансы, Менеджмент

Системы систем. Организационная инженерия  Просмотрен 97

 

Тема 7. Системы систем. Организационная инженерия.

Подход системы систем. Основные вопросы, особенности систем систем, эволюция. Классификация систем систем, примеры. Организация как система. Организационная архитектура и ее онтология. Уровни и проблема их интеграции. Методология DEMO и другие методологии. Ситуационная инженерия методов как методология организационной архитектуры. Стандарты ISO 24744 и OMG SPEM 2.0. Архитектурные подходы к описанию деятельности. Возможности ArchiMate 2.0.

Сегодня мы рассмотрим специфические системы, а именно – социо-технические (системы с людьми). Речь пойдет об организационной инженерии. Вначале рассмотрим более общее понятие «системы систем». Система систем – это объединение систем в рамках общей системы. Например, такая система как лекция может объединить различные системы – проектор, компьютер, лектор, авторучка и т.п. При этом компьютер, принадлежащий (хорошему) лектору, может взаимодействовать с компьютером, принадлежащим учебному заведению. То есть все системы совместно работают для проведения лекции – обеспечивают функционирование общей системы. Ключевые вопросы системы систем таковы:

Перед системным инженером может быть поставлена задача – создать подобную систему. В упомянутом примере она содержит различные системы, в частности, проектор и авторучку, которые создавались независимо друг от друга, включая требования, архитектуру и т.д. На слайде перечислены важные вопросы, связанные с системами систем. Стейкхолдеры у всех подсистем различны, у каждого из них собственные цели и полномочия по отношению к своей системе. Маловероятно, чтобы они содержали цель и полномочия соединиться с какой-то еще системой для обеспечения какой-то совместной функции для еще одного стейкхолдера в соответствии с его полномочиями. Цели и полномочия стейкхолдера общей системы игнорируются целями и полномочиями отдельных стейкхолдеров.

 

Поэтому для системы систем напрямую не работают обычные подходы системной инженерии. Такие знакомые термины, как стадия проектирования, теряют смысл. Однако, чем дальше развивается системная инженерия, тем чаще она сталкивается с системами систем и необходимостью работы с ними. Налицо некоторое противоречие: стандартная системная инженерия не работает в ситуациях, которых становится все больше и ими тоже нужно заниматься. Например, в армии есть несколько родов войск – сухопутные, танковые, морские, космические и т. п. Они по-разному обеспечиваются, подчиняются не связанным друг с другом командирам, имеют разные цели, их радиостанции работают на различных частотах, они награждаются за разные подвиги. В то же время они объединяются для решения общих задач и общих побед. Другой пример – «война браузеров», когда все они поддерживают HTML, но имеют свои особенности и интересы. Разработчики договариваются о стандартах, но не всегда выполняют договоренности.

 

Вообще инженерия системы систем не является дисциплиной. Она не имеет собственной терминологии, большинство звучащих там терминов происходят из обычной системной инженерии. Есть лишь 2 сущностных момента, связанных с системами систем. Первый – классификация видов (на слайде). Управляемая система систем собирается практически без специфических проблем, возможно, лишь несколько дольше. Хотя, конечно, сама управляемость не всегда идеальна и осуществима. Подтвержденная система организационно слабее. Там есть признаваемый общий архитектор и это достижение, так как он занимается общей системой, при этом поддерживаются общие чертежи. Однако он не руководитель, то есть не имеет полномочий командовать. Сотрудничающая система объединяет самостоятельные системы, которые способны договариваться, но не более того. Они несут коллегиальную ответственность, но вполне могут не договориться. При этом общих чертежей нет, общая система может не «собраться», например, ввиду отсутствия или различия интерфейсов. Но, по крайней мере, системам что-то известно друг о друге и они ведут переговоры. Следующий же вид систем не предусматривает и этого. В виртуальных системах частичные системы не знают о взаимном существовании и, соответственно, действуют полностью автономно.

Тем не менее, несмотря на отсутствие архитектора, они работают совместно (как Интернет).

 

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

Отрасль – это группа систем, выпускающих примерно одну продукцию. Ее можно рассматривать как виртуальную систему. Эко-система объединена некоторой общей продукцией. Например, эко-система мобильной связи объединяет программистов, операторов мобильной связи, Интернет-провайдеров, производителей аппаратуры (экранов, кремниевых чипов, пластиковых корпусов и т.п.). Это сотрудничающая система. Системам систем свойственен распределенный характер работы. Федерирование в системах систем означает некоторый аналог интеграции, выполняемой для отдельных систем. Есть независимые системы, которые должны работать как одна система. У каждой из них есть интерфейс, позволяющий включать ее в состав общей системы в произвольный момент времени. Этот процесс и называется федерированием. В качестве примера можно привести административно-хозяйственную область, которая может войти в федерацию, а может выйти и стать независимой. Интернет также поддерживает федерирование систем. Capability (перевод – способность, возможность) – это возможность системы систем выполнить что-то общее, выполнить общую функцию, достичь цели. Если рассматривать военное соединение с несколькими родами войск, то здесь capability – это способность, например, выиграть сражение совместными усилиями. Это не сервис, не требование, а свойство системы систем, ее потенциальная возможность. Networked означает, что система систем представляет собой сеть. Она некоторым образом объединяет в сеть свои подсистемы, находящиеся в ее узлах. По сети передаются деньги, материалы, продукция и т.п.

 

Итак, системы систем, как правило, не управляются и не имеют собственной дисциплины, науки. Однако они играют все большую роль в системной инженерии. Можно сказать, что системный инженер тратит на работу с системами систем около 80% своего времени, при этом на отдельные системы уходит примерно 20%. Следующий слайд демонстрирует создание карандаша как системы – множество работ в конечном счете сходится в одном результате. Для начала нужно срубить дерево, выкопать шахту для графита, далее – взять ингредиенты и варить лак (для покрытия карандаша) и т.д. Процесс оказывается неожиданно сложным, тем более что еще раньше нужно построить заводы и создать станки для производства всего необходимого. Конечно, гораздо сложнее построить нефтяную платформу в море, но и производство карандаша отнюдь не просто. По отдельности все это – не система систем. Карандаш – целевая система, то, что выше – все относится к обеспечивающей системе. Обеспечивающая система продвигает карандаш по его жизненному циклу. Есть предприятие, производящее карандаш, есть фирмы, добывающие графит, поставляющие древесину и т.д. Есть также рынок, где продается карандаш. Таким образом, если рассмотреть все необходимое для производства и сбыта карандаша вместе, то система систем появится. Всей совокупностью этих систем никто не управляет (кроме рынка), она находится в состоянии эволюции. Если на рынке чего-то не хватает, то на этот компонент повышаются цены.

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

Обеспечивающие системы – это обычно организации, фирмы (см. слайд). Они объединяют совокупность оборудования, механизмов, людей, полномочий и т.п. Они представляют собой системы систем на любом уровне, основная причина этого – в наличии людей, поскольку каждый человек преследует собственные цели. Каждый человек – система, объединение людей – тоже система. Люди объединяются в лаборатории, отделы, отделы – в предприятия, предприятия – в холдинги и т.д. Сказанное иллюстрируется следующей схемой.

 

 

Как показано на схеме, первый уровень образуют работники, занимающиеся традиционной системной инженерией. Они все вместе представляют обеспечивающую систему систем первого уровня (SoS-1) и поддерживают целевую систему (system-of-interest). Следующий уровень – системные менеджеры (SoS-2), которые поддерживают обеспечивающую систему систем первого уровня (SoS-1), влияя на системы-людей, чтобы те эволюционировали (как автономные системы) для возможности функционирования в общей системе (SoS-1). Основное отличие между работником и менеджером в том, что первый работает с изготавливаемой деталью. Она не сопротивляется, поскольку у нее нет желаний, нет культурно обусловленной позиции.

Второй работает с людьми, которые способны сопротивляться. Поскольку SoS-2 тоже нужно организовать, есть еще и третий уровень – консультанты по разработке, методисты (SoS-3), поддерживающие систему систем SoS-2. Мы сейчас также находимся на уровне 3, поскольку обсуждаем всю эту структуру, способы ее организации.

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

 

 

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

 

Один из них называется DEMO (Design and Engineering Methodology for Organisations). Он относится к коммуникативной парадигме и включает организационную онтологию (из чего состоит организация) и методологию организационного моделирования (как построить организационную модель конкретной организации: что спрашивать и как записывать). Согласно данному подходу, организация – это коммуникация полномочных деятелей (акторов). Есть деятельностная роль, выполняемая актором, имеющим полномочия, и его окружают два мира. Один мир – координации, который в любой момент имеет состояние. Второй мир – продуктивности (производства), также имеющий свое состояние. Координации сопоставлена ответственность. Производству сопоставлена компетенция, то есть для производства нужно что-то уметь. В мире координации люди договариваются, в мире производства они создают, производят. Мир координации обеспечивает координацию для производства.

 

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

 

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

Заметим, что сдача факта – это еще не приемка. В рассматриваемой парадигме главное – правильно найти ответственного человека (актора) для коммуникации. Чтобы сопоставить инициатору нужного исполнителя, используется информация о полномочиях и ответственности. Никакие инструменты данная парадигма не рассматривает, вся организация определяется полномочиями и ответственностью. Инструменты не умеют давать обещаний, выполнять обещания, и у них нет полномочий, они неспособны договариваться. Полномочия есть у людей – акторов.

 

Мы рассмотрели лишь одну из множества существующих моделей организации и ее коммуникаций. Однако, когда речь идет об организации, то находится много экспертов и еще больше мнений по поводу того, из чего состоит организация, как ее моделировать, что такое архитектура организации, где границы организационной системы, как правильно организовать людей, что здесь главное. Показательно в этом плане исследование, проведенное Томасом Дэвенпортом. На следующем слайде приведены некоторые его результаты – перечень 140 модных в различные времена идей и методов для управления организацией и протекающими в нем процессами. Это было еще в 2003 году, а сейчас, конечно, можно было бы их перечислить на порядки больше.

 

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

О ней говорилось на Лекции 3. Напомним, что эта дисциплина пытается построить технологию переноса методов из одних ситуаций (например, программирование) в другие ситуации (например, системная инженерия). Некоторый известный метод разбивается на мелкие части, называемые компонентами (виды рабочих продуктов, виды деятелей, виды стадий жизненного цикла и т.д.). Для этой цели нужно решить онтологический вопрос – из каких частей состоит метод (построить «метамодель метода»). Эти части вместе с компонентами других методов хранятся в «библиотеке». Рассматривая новую ситуацию, пытаются из компонент собрать новый метод (как из конструктора), который будет работать в этой ситуации. Данный подход привлекается и для синтеза методов организационной архитектуры.

 

На схеме приведена часть структуры метамодели метода (онтологии метода) с точки зрения стандарта ISO 24744 (Software Engineering – Metamodel for Development Methodologies). В корне диаграммы изображен элемент методологии – описываемый метод. Он использует шаблоны и ресурсы.

Ниже – то, из чего состоит метод, то есть его компоненты. Шаблон раскрывает методологическую часть. Он состоит из видов: рабочих продуктов (с чем работают), исполнителей (кто работает – люди, инструменты и т.д.), единиц работы (как работают), стадий работы (когда работают), моделей (как описывается работа). Ресурс раскрывает содержание того, что используется в описании метода. Он содержит: язык, ограничение, нотацию (обозначения), ситуацию на выходе (результат), руководство пользователя. Методу может соответствовать реальное выполнение (enactment), когда данный метод применяется. Однако такое описание метода не содержит никакой информации о действиях конкретных исполнителей (координация, производство, организация, полномочия).

 

Предположим, что есть консалтинговая фирма. Она должна время от времени описывать методы работы. Согласно стандарту ISO 24744, нужно описать в части Resource: используемые нотации и языки, кто применяет метод (профессии, квалификации), какие инструменты они используют (например, архитектор – компьютерную программу-modeller), ожидаемые результаты применения метода, инструкцию. В части Template: все объекты работы (с чем производится работа), сами работы (действия, практики, процессы), тип жизненного цикла и его стадии, виды моделей. Все детали важны. В результате можно считать, что описан метод.

 

Для ситуационной инженерии методов существуют основные стандарты ISO 24744 и SPEM 2.0 (Software Engineering Process Metamodel). Можно заметить, что ситуационная инженерия методов описывает содержательную часть работы предприятия как системы – в стандарте даже есть понятие стадии. Поэтому моделирование ситуационных методов представляет также способ описания жизненного цикла системы. Иногда это называют описанием процессов разработки ПО (SPEM 2.0). Для этой цели существуют специальные языки, например, язык и метамодель для SEMAT (Software Engineering Method and Theory). Пример подобного описания приведен на следующем слайде. Это очень похоже на стадии жизненного цикла: Determination of Needs (Needs Formalization, Needs Documentation), Definition (Requirements Specification, High-level Modeling, Technological Design, Deployment Planning, Construction Planning), Construction Build, Change, Retirement («выход в отставку»). Здесь можно показать также итерации (итерационный жизненный цикл). Видно, что есть практика моделирования нижнего уровня, которая применяется вместе с кодированием.

 

 

Данный инструментарий с соответствующим редактором может быть использован для сборки и описания методов реализации жизненного цикла. Он применяется в основном разработчиками программных систем. На следующей схеме изображен тот же жизненный цикл, но во времени. Показаны 2 его итерации – Construction Build 1 и Construction Build 2.

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

 

 

Продолжим обсуждение организационной инженерии. Какой бы ни была система, даже если она состоит из людей, у нее есть архитектура. Поскольку есть архитектура, то должно быть архитектурное описание (Description). В основе описания лежит онтология. В литературе встречаются 3 основные парадигмы архитектурного описания деятельности. Первая – коммуникационная (DEMO – предприятия договариваются работать в терминах полномочий, см. выше). Вторая – информационные объекты. Она основана на артефактах (обмен документами и другими объектами, действия – вторичны). Третья – процессы, трансформационная парадигма. Аббревиатура BPMN означает Business Process Modeling Notation. В ней первичны действия – операции, а объекты работы вторичны. Данная парадигма сейчас доминирует.

 

 

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

 

Существует также подход, называемый «кейс-менеджмент» – это управление процессом решения поставленной задачи, в зависимости от развития ситуации. Это наиболее общий вид описания деятельности предприятий, поскольку кейсом может считаться все что угодно, вплоть до уголовного дела или истории болезни. Люди приступают к работе над чем-то, пока неизвестным. Открывают папку (кейс) и начинают действовать, складывая туда все, что появляется во время работы. У папки есть идентификатор, а что там будет храниться, заранее неизвестно. Другими словами, в качестве кейса рассматривается ситуация, разрешение которой требует определенного сопровождения. Методология кейс-менеджмента широко применяется в сферах юстиции, здравоохранении, социальной работы, государственных услуг. Кейс-менеджмент позволяет держать под контролем всю задачу целиком, включая взаимосвязи между документами, внутренними и внешними участниками процесса, а также контролировать ход работы (по кейсу).

 

Вспомним язык ArchiMate (см. предыдущую лекцию). Это язык архитектурных описаний, реализующий стандарт ISO 42010. Согласно его подходу, есть пирамида (иерархия) понятий, в терминах которых рассматривается предприятие.

Он позволяет описывать архитектуру предприятия (часть мира) в 3-уровневой онтологии.

Верхняя часть задает терминологию, в которой нет ничего от предприятия – generic concepts (сущности и отношения). Средняя часть отражает общую терминологию всех предприятий (например, «программа», процесс). Нижняя часть описывает специфику конкретного предприятия – специализацию предметной области и фирмы (например, не просто «процесс», а «процесс сверления дырок в стальных болванках»). Следующая основная диаграмма демонстрирует парадигму данного языка. Есть некоторая информационная архитектура, за которой можно увидеть реальное предприятие. На предприятии осуществляются проекты развития, которые реализуют данную архитектуру, чтобы в качестве конечной цели получить определенные результаты. Все предприятие (его информационная архитектура) рассматривается в виде матрицы, содержащей 3 столбца – объекты работы, собственно работы и исполнители. Соответственно матрице на предприятии можно выделить 3 уровня: один состоит из людей, второй – из (компьютерных) программ, третий – из оборудования. Первый уровень называют архитектурой деятельности, или бизнес-архитектурой. Остальные 2 – архитектурой IT-решения.

При рассмотрении архитектуры предприятия важно учитывать наличие всех 3-х уровней. Существует распространенная ошибка, когда какой-нибудь из этих уровней игнорируется. Программисты неявно склонны рассматривать лишь уровень программ; специалисты поддержки аппаратуры, системные администраторы – уровень оборудования; менеджеры – уровень людей. Парадигма ArchiMate призвана защищать от подобных ошибок. Он специально сконструирован так, чтобы заставить изображать архитектуру деятельности вместе с архитектурой IT-решения, а последнюю – состоящей из взаимодействующих уровней программ и оборудования.

 

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

 

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

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

 

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

 

Рассмотрим относительно небольшой пример использования языка – типичную диаграмму ArchiMate. Она описывает онтологический метод реализации стандарта интеграции данных жизненного цикла. Показано, как одна САПР будет передавать данные в другую САПР. Это часть информационной архитектуры предприятия.

 

 

Желтым цветом изображены работы, выполняемые людьми, инженерные объекты: передаваемая порция проекта, передаваемая часть проекта и весь проект. Эта часть называется архитектурой IT-решения (программы + оборудование, см. выше матрицу). Салатовым цветом изображены данные – часть архитектуры, относящаяся к уровню программ. Чтобы разобраться, зачем все это нужно, достаточно на диаграмме найти сервис (овал, в середине справа) – передача проектных данных из исходного приложения в целевое. Вся диаграмма показывает архитектуру решения этой задачи, включая также сервис настройки преобразования данных. Показано, как и с чем связана функциональность программ, с какими данными они работают, какие есть программные модули. Выделено, какие данные читаются, а какие записываются. Пунктирные стрелки демонстрируют направление передачи информации. Такие схемы позволяют спроектировать программы, затем присоединить их к функциональности других программ. На другой схеме данная диаграмма может быть заменена (представлена) ее основным сервисом – одним овальным блоком. Все изображенное – архитектура программной системы. На основе этой диаграммы программисты, в частности, могут решать, на каких серверах будут расположены какие модули.

Предыдущая статья:Практики определения системы – архитектура Следующая статья:Практики воплощения системы
page speed (0.0104 sec, direct)