=Paper=
{{Paper
|id=Vol-2064/paper44
|storemode=property
|title=
Роль декомпозиции при моделировании организационных систем
(The role of decomposition in organizational system modeling)
|pdfUrl=https://ceur-ws.org/Vol-2064/paper44.pdf
|volume=Vol-2064
|authors=George Kalyanov,Boris Kuprianov,Igor Fiodorov
}}
==
Роль декомпозиции при моделировании организационных систем
(The role of decomposition in organizational system modeling)
==
https://ceur-ws.org/Vol-2064/paper44.pdf
УДК 330.132
Калянов Г.Н.,1 Куприянов Б.В.,1 Фёдоров И.Г.2
1 Институт проблем управления им. В.А. Трапезникова РАН, г. Москва, Россия
2 Российский экономический университет им Г.В. Плеханова, г. Москва, Россия
РОЛЬ ДЕКОМПОЗИЦИИ ПРИ МОДЕЛИРОВАНИИ ОРГАНИЗАЦИОННЫХ СИСТЕМ*
Аннотация
В статье показано, как выбор стратегии декомпозиции определяет тип полученной модели
организационной системы. Предложено разделять модели, описывающие работу
организационной системы, на модели состава, структуры и поведения. Модель состава
показывает номенклатуру функций организационной системы, она получается путем
многократной функциональной декомпозиции, так что информационные и процедурные
связи между функциями теряются. Модель структуры показывает взаимосвязь между
функциями по данным и по потокам управления, второй тип диаграмм принято называть
моделью потоков работ. Модель поведения отображает историю изменения состояний
системы. Таким образом, модель потоков работ не описывает поведение системы.
Выделены три базовых стратегии декомпозиции: функциональная, по стабильным
подсистемам и темпоральная (временная), причем выбор стратегии однозначно
определяет тип результирующей модели. В результате функциональной декомпозиции
будет получена модель состава, структурной – модель потоков данных или работ,
процессной – модель поведения.
Описан набор принципов декомпозиции, выполнение которых защищает аналитика от
ошибок деления целого на части. Важнейший практический вывод заключается в том, что
для перехода на процессное управление аналитики должны создавать модели поведения, а
модель потоков работ, не обеспечивает получения требуемого результата.
Ключевые слова
Модель бизнес-процесса; декомпозиция; справочная модель; SCOR; eTOM.
Kalyanov G.N.,1 Kuprianov B.V., 1 Fiodorov I.G.2
1 Trapeznikov Institute of Control Sciences of Russian Academy of Sciences, Moscow, Russia
2 Plekhanov Russian University of Economics, Moscow, Russia
THE ROLE OF DECOMPOSITION IN ORGANIZATIONAL SYSTEM MODELING
Abstract
The article shows how the choice of the decomposition strategy determines a type of organizational
system model. It is proposed to distinguish three types of models, describing a work of organizational
system: model of composition, structure and behavior. A model of composition shows the
nomenclature of functions of the organizational system, it is obtained by multiple functional
decomposition, so that informational and procedural links between functions are lost. The model of
structure shows the relationship between the functions by data or by control flows, the second type of
diagram is commonly referred to as workflow models. The behavior model presents a history of the
state change of an object that is selected for observation. We conclude that a workflow does not
describe a behavior of a system.
Three basic strategies of decomposition have been singled out: functional, by stable subsystems and
temporal. The choice of strategies uniquely determines the type of the resulting model. A functional
decomposition issue a composition model, a structural one – a workflow or a data flow model, a
behavioral decomposition – a process model.
* Труды II Международной научной конференции «Конвергентные когнитивно-
информационные технологии» (Convergent’2017), Москва, 24-26 ноября, 2017
Proceedings of the II International scientific conference "Convergent cognitive information
technologies" (Convergent’2017), Moscow, Russia, November 24-26, 2017
380
A set of decomposition principles is described, their implementation protects the analyst from the
errors of dividing the whole into parts. The main important practical conclusion is that for the
transition to process management it is necessary to create a model of behavior, while a workflow
model is not ensuring the obtaining of a desired result.
Keywords
Business process model; decomposition; reference model; SCOR; eTOM.
Введение
Из работ Хаммера и Чампи очевидно различие функционального и процессного подхода к управлению
предприятием [1]. В качестве первого шага при решении проблемы перехода к процессному управлению
они предлагают радикальное переосмысление и кардинальную переработку бизнес-процессов и
рекомендуют провести моделирование бизнес-процессов предприятия. Однако многие популярные
сегодня техники моделирования приводят к созданию функциональных моделей. Возникает законный
вопрос: можно ли переходить к процессному управлению через функциональное моделирование, нет ли
тут противоречия. Поскольку не нотация, а методология определяет полученный результат, выбор
стратегии декомпозиции обусловливает тип полученной модели. Выделим глобальную проблему
моделирования бизнес-процессов – аналитики неохотно пользуются известными формальными
методами [2].
Предметом данного анализа являются организационной системы, а объектом исследования – модели,
описывающие работы, выполняемые организационной системой. Главный вопрос исследования: какую
модель следует называть процессной? Вспомогательный вопрос: в чем заключается методика построения
функциональной и процессной моделей? Целью исследования является исследование влияния стратегии
декомпозиции на тип результирующей модели. Не может ли оказаться, что некоторые модели, которые
мы используем для описания бизнес-процессов в отрыве от методологии, по сути, являются
функциональными?
Декомпозиция
Декомпозиция – это метод научного познания, который, с целью упрощения, предлагает заменить
рассмотрение сложного, составного понятия – объекта или явления на изучение его частей меньшего
размера. Будем рассматривать только непосредственное влияние этих частей друг на друга,
осуществляемое через их вход и выход, будем пренебрегать их косвенным влиянием, осуществляемым
через разделяемые ресурсы [3]. Ограничим наше рассмотрение системами, между которыми существуют
взаимно детерминированные отношения, так что состояние одной системы полностью определяет
состояние другой, и наоборот [4]. Рассмотрим стратегии декомпозиции и типы получающихся в
результате моделей, перечислим принципы, исключающие ошибки декомпозиции.
1 Стратегии декомпозиции
Целое можно разделить на части разными способами, называемыми стратегиями декомпозиции. М.
Тода и Э. Шуфорд выделяют три стратегии декомпозиции системы: (а) функциональную, которую они
связывают с расчленением системы, состояние которой есть функция нескольких переменных, на
подсистемы таким образом, что каждая является функций только одной переменной; (б)
пространственную, в которой отдельные компоненты характеризуются положением относительно друг
друга; (в) темпоральную (временную) предполагающую исследование истории состояний этой системы
[4]. Технология структурного анализа SADT предполагает четыре вида декомпозиции: (а)
функциональную, перечисляющую все действия, выполняемые системой; (б) в соответствии с
известными стабильными подсистемами, показывающую действия, выполняемые выбранными
подсистемами; (в) по физическому процессу, которая показывает детальную историю этой системы; (д)
по этапам жизненного цикла, показывающую только существенные изменения состояния системы [5].
Сравнивая эти подходы можно видеть, что оба предлагают функциональную декомпозицию.
Пространственная декомпозиция и декомпозиция по известными стабильными подсистемами суть одна
стратегия, если предположить, что под пространством понимается положение относительно известных
подсистем. Можно видеть, что две декомпозиции SADT – по этапам жизненного цикла и по физическому
процессу, относятся к одной стратегии темпоральной декомпозиции. Таким образом, будем считать, что
существует всего три базовых стратегии декомпозиции системы.
1.1 Типы моделей
Принято разделять модели состава, структуры и поведения системы [6]. Первые изображают
381
номенклатуру частей, из которых состоит система, пренебрегая их связями, вторые выявляют
существенные связи между этими частями, последние изображают динамику изменения системы во
времени. Нам необходимо уточнить понятия: функция, структура, поведение.
По мнению Ю.Г. Маркова, «функцией системы можно назвать все то, что можно узнать о системе, не
касаясь её внутреннего содержания, абстрагируясь от него» [5]. Функцией можно назвать то, что можно
узнать о системе, абстрагируясь от ее внутреннего содержания и от ее взаимодействия с окружением. В
рамках функционального подхода система рассматривается исключительно с позиции ее внешнего
аспекта, она взаимодействует с окружением через свои входы и выходы, другие типы взаимодействия не
рассматриваются, таким образом, функция подсистемы отражает ее роль в системе. В результате
декомпозиции функция разделяется на подфункции, с которыми ее связывает отношение «Часть ↔
Целое».
Согласно М. Тода и Э. Шуфорду структура определяется как совокупность отношений между
подсистемами, образованными в результате применения определённого способа декомпозиции к
исходной системе [4]. Будем выделять два типа отношений между функциями. Первые, называемые
потоками управления, определяют очередность выполнения, так что между последовательно
выполняемыми функциями существует отношение «Причина ↔ Следствие». Полученные в результате
модели принято называть диаграммами потоков работ (workflow). Вторые, называемые
информационными потоками, показывают взаимосвязь функций по входам / выходам, между функциями
существует отношение «Объект действия ↔ Действие». Полученные в результате модели принято
называть диаграммами потоков данных (DFD). Таким образом, части, на которые разделена система,
взаимодействуют только посредством потоков управления и данных.
Под поведением системы принято понимать последовательность принимаемых ею состояний. Хотя
изменение состояния происходит в результате выполнения какой-либо функции, неверно говорить, что
последовательность функций описывает поведение. Дело в том, что факт выполнения функции ничего не
говорит о достигнутом в результате состоянии системы. Таким образом, функция есть инструмент, через
который реализуется поведение. Поведение в технических системах его принято изображать траекторией
фазовой точки в пространстве переменных этой системы [3]. Поэтому диаграмма поведения должна
показывать историю состояний системы во времени.
1.2 Базовые принципы декомпозиции
В ходе декомпозиции легко нарушить целостность системы, поэтому следует придерживаться
следующих базовых принципов, выполнение которых защищает аналитика от ошибок [8]:
Непрерывность – при разбиении необходимо последовательно переходить от уровня
декомпозиции, раскрытого последним, к последующему, не перескакивая через уровни, относящиеся к
другому порядку;
Выбора основания – до начала декомпозиции необходимо выбрать стратегию декомпозиции;
Одного основания – недопустимо менять стратегию декомпозиции при переходе на нижележащий
уровень. В случае декомпозиции по времени, недопустимо бесконтрольно менять объекта, «вокруг
которого» строится процесс.
Взаимоисключения – части, находящиеся на одном уровне декомпозиции не должны находиться в
отношениях пересечения друг с другом.
Полнота – нижележащий уровень должен полностью раскрывать верхний;
Избыточность – в результате декомпозиции не должно возникнуть то, чего нет в исходном целом.
Обратим внимание, хотя технология SADT не упоминает данные принципы, но предлагает проверить
качество декомпозиции, складывая полученные фрагменты [6]. Если в результате будет восстановлено
исходное целое, то декомпозиция выполнена корректно.
2 Примеры декомпозиции моделей организационных систем
Декомпозиция может применяться к системе целиком или к ее отдельным составляющим: людям – в
результате будет получена организационная структура; объектам (физическими и информационными),
которые подвергаются обработке – информационная модель, работам, которые преобразуют объекты
системы, в результате будет получена модель работ. В рамках данной работы нас интересует только
декомпозиция работ, мы не будем рассматривать декомпозицию людей или декомпозицию объектов.
Рассмотрим влияние стратегии декомпозиции на результирующие модели организационных систем
на нескольких примерах типовых моделей организационных систем, взятых из альбомов фирмы SAP [9],
SCOR [10] и eTOM [12]. Будем обращать внимание: что является объектом моделирования, какая стратегия
декомпозиции использована?
2.1 Справочная модель бизнес-процессов фирмы SAP
382
Библиотека справочных моделей бизнес-процессов фирмы SAP содержит более 600 не тривиальных
процессов, описанных с помощью нотации ARIS EPC [9]. Она включает так называемые модели лучших
практик, изображающие последовательность работ, которые необходимо выполнить для достижения
запланированного результата. Рассмотрим одну из моделей, имеющую название «обработка заказа на
поставку изделия» (см. Рисунок 1). Легко видеть, что для создания этой модели использовалась
темпоральная стратегия декомпозиции – автор выбрал некоторый объект, изобразил
последовательность работ, изменяющих этот объект, отобразил последовательность состояний объекта,
изменяющихся в результате обработки. Вместе с тем, он не обратил внимание на смену объекта – вначале
процесс стоится вокруг объекта «заказ», в средней части процесса в качестве объекта рассматриваются
товары, которые формируют заказ, а в конце рассматривается инвойс, по которому происходит оплата
заказа. Таким образом, автор строит модель, используя последовательно три разных объекта, не замечает
их смены. В рассматриваемом примере одному заказу на входе соответствует один инвойс на выходе,
поэтому смена объекта проходит «безболезненно», однако в случае, если соотношение окажется один ко
многим, придется разделить монолитный процесс на цепочку из нескольких взаимодействующих
процессов, у каждого свой объект.
Рисунок 1. Процесс «обработка заказа на поставку изделия»
2.2 Модель SCOR
Рассмотрим справочную модель логистической деятельности SCOR [10]. Модель делится на три уровня,
именуемые: Process Types, Process Categories, Process Elements. Документация упоминает четвертый
уровень Implementation Level, который не входит в состав модели, но, как считают авторы SCOR, может
быть «легко» получен из справочной модели. Если проанализировать, какие стратегии использовались
при создании модели SCOR (см. Рисунок 2), выяснится, что она построена путем функциональной
декомпозиции.
Чтобы построить верхний уровень модели авторы задают вопрос: «что делает логистическая
компания?». Ответом является перечень видов деятельности: Plan, Source, Make, Deliver, Return. Возможно,
некоторым покажется, что это декомпозиция по жизненному циклу, но, в таком случае, следовало бы явно
выделить объект, этапы жизненного цикла которого мы анализируем. Поскольку объект не выделен,
декомпозицию следует рассматривать как функциональную. Этот уровень называется «типы процессов».
Второй уровень описывает «конфигурацию процессов». Каждый из элементов первого уровня
подвергается функциональной декомпозиции, например, деятельность Plan разделяется на: Plan Source,
Plan Make, Plan Deliver, Plan Return. Аналогично производится декомпозиция остальных видов
деятельности.
Последний, третий уровень модели показывает процессные элементы, те самые кирпичики, из
которых планируется строить сквозные процессы. Процессный элемент представляет собой цепочку
операций, выстроенную в порядке, определяемым последовательностью жизненного цикла продукта * .
Например, Source Stocked Products выстраивается в следующую цепочку:
Schedule Product Deliveries (S1.1) Receive Product (S1.2) Verify Product (S1.3) Transfer Product (S1.4)
Authorize Supplier Payments (S1.5)
В данной цепочке выделен общий для всех элементов объект, под названием Product, поэтому имеет
место декомпозиция по этапам жизненного цикла. Обратим внимание, тем самым нарушен принцип,
запрещающий смену стратегии по ходу декомпозиции.
* Мы специально опускаем метрики и KPI модели SCOR, поскольку они не входят в круг нашего рассмотрения
383
Рисунок 2. Уровни модели SCOR
Авторы модели утверждают, что собственно процессы м.б. составлены из процессных элементов
третьего уровня [10]. Это действительно так, однако они умалчивают немаловажную деталь, что бы найти
нужный фрагмент, придется перебрать десятки процессных элементов, полученные трехкратной
функциональной декомпозицией. Процедура напоминает сборку паззла, с числом фрагментов
превышающим сотню. Рисунок 3 иллюстрирует сложности, которые возникают при выборе процессных
элементов, составляющих сквозной процесс.
4
5
3
6
2
1
Рисунок 3. Сборка процесса из элементов в модели SCOR
Модель SCOR скромно умалчивает о возникающих трудностях, однако аналогичные проблемы,
возникающие при работе с моделью eTOM, нашли отражение в официальной документации Tele
Management Forum.
384
2.3 Модель eTOM
Карта операций оператора связи eTOM, разрабатываемая Tele Management Forum, представляет собой
справочную модель для классификации и описания всех работ оператора телекоммуникационных услуг
связи [11]. Цель описания – определить основные понятия и компоненты из которых, как из кирпичиков,
строится система управления. Карту ошибочно называют моделью процессов. Анализ показывает, что она
построена методом функциональной декомпозиции. Руководящие документы по eTOM регулярно
упоминают термин бизнес-процесс, в том числе сквозные процессы, например, «Выполнение»,
«Обеспечение» и «Биллинг» (Fulfillment, Assurance and Billing). Однако эти «процессы» не соответствуют
нашему представлению о бизнес-процессе, поскольку объект не выделен.
Для правильного понимания трактовки процессов в модели eTOM необходимо рассмотреть документ
«GB921F – Representative process Flows» (примеры построения цепочек потоков работ) [12]. Документ
призывает различать иерархию процессных элементов (описанных в eTOM) и цепочку потоков работ
(workflow). Документ следует воспринимать как иллюстрацию, демонстрирующую, что переход к
потокам работ возможен, но не как практическое руководство. Описывается только общий подход,
сценарии показывают лишь некоторые из возможных взаимосвязей. Рисунок 4 демонстрирует переход от
модели eTOM к цепочке процесса. Как и в случае SCOR, процедура объединения процессных элементов в
цепочку потоков работ не алгоритмизирована.
Рисунок 4. Переход от модели eTOM к цепочке процесса
Проблема перехода от функциональной к процессной модели
Функциональная модель представляет собой «идеальный» взгляд на деятельность организации. Две
компании, работающие в одной сфере бизнеса, имеют одинаковые наборы функций, однако очередность
операций в них может отличаться, поскольку предприятия обладают различной организационной
структурой, производственной культурой и т.д. Эту модель следует трактовать как каталог функций,
иерархически организованный справочник работ, в котором перечислены все действия, выполняемые
субъектами. Считается, что, имея «полный» набор функций, можно скомпоновать систему, применяя
повторно используемые компоненты. Функциональная модель строится сверху вниз поскольку этот
способ является наиболее естественным для анализа системы. Сила и преимущество справочной модели
заключается в том, что она содержит набор функций, необходимый и достаточный для работы системы,
модель является полной, в ней отсутствуют как избыточность, она позволяет выявить дублирование
функций. Благодаря многоуровнему устройству она позволяет выбирать подходящий для конкретного
рассмотрения уровень детализации.
385
Хотя модели SCOR и eTOM говорят, что переход моделям потоков работ не представляет сложности, на
практике такой переход затруднен. Проблема перехода от функциональной моделей SCOR и eTOM к
процессным моделям заключается в том, что в результате многократной, повторной функциональной
декомпозиции теряется логическая связь, описывающая очередность выполнения процессных элементов.
Восстановить потерянную связь трудоемко, что затрудняет практическое применение справочных
моделей.
Выводы
Модели, описывающие работу организационных систем, предлагается разделять на модели состава,
структуры и поведения. Модели состава показывают номенклатуру функций организационной системы.
Они получаются путем многократной функциональной декомпозиции, так что информационные и
процедурные связи между функциями теряются. Функцию и ее подфункции связывает отношение «Часть
↔ Целое». Модели структуры показывают взаимосвязь между функциями по данным, при этом функции
связывает отношение «Объект действия ↔ Действие» и по потокам управления, отношение «Причина ↔
Следствие». Последний тип диаграмм принято называть моделями потоков работ, их нельзя смешивать с
моделью поведения, поскольку последняя должна отображать историю изменения состояний объекта,
который выбран для наблюдения.
Выделены три базовых стратегии декомпозиции: функциональная, по стабильным подсистемам и
темпоральная (временная), причем выбор стратегии однозначно определяет тип результирующей
модели. В результате функциональной декомпозиции будет получена модель состава, структурной –
модель потоков данных или работ, процессной – модель поведения.
Описан набор принципов декомпозиции, выполнение которых защищает аналитика от ошибок
деления целого на части. Их знание поможет аналитику локализовать ошибку, если в ходе проверки,
соединив вместе полученные части он не получит исходное целое.
Важнейший практический вывод заключается в том, что для перехода на процессное управление
аналитики должны создавать модели поведения, а модели потоков работ, не обеспечивают получение
требуемого результата.
Литература
1. Hammer M. Champy J. Reengineering the corporation: a manifesto for business revolution. NY: HarperBusiness, 1993
2. Калянов Г.Н. Теория бизнес-процессов: формальные модели и методы // Экономика, статистика и информатика, No. 4, 2016.
pp. 19-21
3. Эшби Р. Общая теория систем, как научная дисциплина // In: Исследования по общей теории систем. 1969. pp. 125-142
4. Тода М., Шуфорд Э. Логика систем: введение в формальную теорию структуры // In: Исследования по общей теории систем.
М. 1969
5. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования SADT. М.: Метатехнология, 1993. 240 pp
6. Перегудов Ф.И., Тарасенко Ф.П. Введение в системный анализ. М.: Высшая школа, 1989. c 375
7. Марков Ю.Г. Функциональный подход в современном научном познании. Новосибирск: Наука, 1982. 255 с
8. Parnas D. On the Criteria To Be Used in Decomposing Systems into Modules // Communications of the ACM , Vol. 15, No. 12,
December 1972. pp. 1053-1058
9. Curran T., Keller G., Ladd A. SAP R/3 Business Blueprint: Understanding the Business Process Reference Model. Prentice Hall, 1997.
391 pp
10. Supply-Chain Council Inc. Supply-Chain Operations Reference-model, Pittsburgh
11. TeleManagement Forum. Enhanced Telecom Operations Map® (eTOM) The Business Process Framework, USA, November 2005. c.
81
12. eTOM – Representative process flows. TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU;, 2005. 35 pp
Reference
1. Hammer M. Champy J. Reengineering the corporation: a manifesto for business revolution. NY: HarperBusiness, 1993
2. Kaljanov G.N. Teorija biznes-processov: formal'nye modeli i metody // Jekonomika, statistika i informatika, No. 4, 2016. pp. 19-21
3. Jeshbi R. Obshhaja teorija sistem, kak nauchnaja disciplina // In: Issledovanija po obshhej teorii sistem. 1969. pp. 125-142
4. Toda M., Shuford Je. Logika sistem: vvedenie v formal'nuju teoriju struktury // In: Issledovanija po obshhej teorii sistem. M. 1969
5. Marka D., MakGoujen K. Metodologija strukturnogo analiza i proektirovanija SADT. M.: Metatehnologija, 1993. 240 pp
6. Peregudov F.I., Tarasenko F.P. Vvedenie v sistemnyj analiz. M.: Vysshaja shkola, 1989. c 375
7. Markov Ju.G. Funkcional'nyj podhod v sovremennom nauchnom poznanii. Novosibirsk: Nauka, 1982. 255 s
8. Parnas D. On the Criteria To Be Used in Decomposing Systems into Modules // Communications of the ACM , Vol. 15, No. 12,
December 1972. pp. 1053-1058
9. Curran T., Keller G., Ladd A. SAP R/3 Business Blueprint: Understanding the Business Process Reference Model. Prentice Hall, 1997.
391 pp
10. Supply-Chain Council Inc. Supply-Chain Operations Reference-model, Pittsburgh
11. TeleManagement Forum. Enhanced Telecom Operations Map® (eTOM) The Business Process Framework, USA, November 2005. c.
81
12. eTOM – Representative process flows. TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU;, 2005. 35 pp
386
Об авторах:
Калянов Георгий Николаевич, доктор технических наук, профессор, главный научный сотрудник,
Институт проблем управления им. В.А. Трапезникова РАН, kalyanov@mail.ru
Куприянов Борис Васильевич, кандидат технических наук, старший научный сотрудник, Институт
проблем управления им. В.А. Трапезникова РАН, kuprianovb@mail.ru
Фёдоров Игорь Григорьевич, доктор экономических наук, доцент кафедры прикладной информатики,
Российский экономический университет им Г.В. Плеханова, Igor.Fiodorov@mail.ru
Note on the authors:
Kalyanov George N., doctor of technical sciences, professor, Research fellow, Trapeznikov Institute of Control
Sciences of Russian Academy of Sciences, kalyanov@mail.ru
Kuprianov Boris V., Candidate of technical sciences, Senior Researcher, Trapeznikov Institute of Control Sciences
of Russian Academy of Sciences, kuprianovb@mail.ru
Fiodorov Igor G., Doctor of Economics, Associate Professor of Applied Informatics Department, Plekhanov
Russian University of Economics, Igor.Fiodorov@mail.ru
387