Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. Глава 1. Процессы или функции?

Дмитрий Пинаев

Генеральный директор ГК «Современные технологии управления»

Введение

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

В статье рассматриваются темы:

1. Деятельность организации: это процессы или функции? Что на самом деле мы моделируем в модели «процессов верхнего уровня»?
   Возможность использования нотации IDEF0 для модели верхнего уровня.
2. На какие части можно поделить деятельность организации?
   Принцип «модульности» при проектировании архитектуры системы.
   Принцип «автономности» при проектировании архитектуры организационной системы.
3. Особенности создания модели «верхнего уровня» в нотации IDEF0.

В качестве основных теорий для рассуждения и обоснования предлагаемых решений используются:

1. Понятие «Онтология» и теория множеств для конструирования классов онтологии.
2. 4D-экстенсионализм.
3. Нотация для экземпляров и классов (Matthew West «Developing high quality data models», ISO 15926–2 «Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data model»).
4. Понятия и методы системной инженерии.

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

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

Например, если мы говорим «стол» и показываем на него пальцем, то 99% аналитиков согласятся с нами. Если мы говорим, что это «мебель» — более высокий класс, то с нами согласятся 98% аналитиков. Но если мы возьмем понятие «сквозной процесс», то дать четкое определение и, согласно этому определению, однозначно выделить сквозной процесс в реальности аналитики вряд ли смогут. У всех будут разные ответы.

Постановка задачи

Давайте рассмотрим задачу, когда аналитику требуется создать модель существующей компании.

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

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

Другой пример: один и тот же объект мы можем называть и системой, когда рассматриваем его отдельно, и компонентом, когда мы рассматриваем его в контексте надсистемы. В хороших онтологиях объект может быть и тем, и другим.

Мы не хотим иметь дело с таким количеством объектов и делаем первый, вполне естественный шаг: объединяем операции в классы по принципу подобия. Первый шаг классификации дается нам достаточно легко: мы видим в окружающей нас реальности похожие друг на друга операции и относим их к одному классу. Например, «Сборка стула» или «Оформление накладной». И здесь можно констатировать первый очевидный факт: в нашей модели деятельности мы моделируем классы операций, а не конкретные операции.

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

Замечания:

1. Далее, в тексте вместо более общего класса операций будет использоваться более привычное понятие «класс процессов».
2. Хотя совсем привычным для читателя будет использование понятий из ООП: «процесс» и «экземпляр процесса» вместо «класс процессов» и «процесс» соответственно. В рамках данной статьи эти понятия тождественны.

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

Количество получившихся классов процессов — поменьше, но тоже очень велико — сотни и тысячи. Что делать дальше? Дальше, по логике, нужно включать классы процессов во все более абстрактные классы и подниматься по уровням модели все выше и выше. Зачем? Чтобы на самом верхнем уровне (bird’s-eye view) получить компактную модель, удовлетворяющую следующим требованиям:

1. Модель может поместиться в голову человека «целиком».
2. Модель должна быть понятна неподготовленному человеку. (А, в идеале, подходить на роль учебного материала для новичков.)
3. Модель должна давать четкий ответ на вопрос: что именно делает компания. А для этого очень желательно, чтобы выполнялось требование 4.
4. Модель должна отражать связи операций по входам и выходам.

Какие проблемы возникают при создании модели верхнего уровня? Те, кто пытались это сделать для существующего бизнеса (а с этого начинают почти все знакомые мне аналитики), уже знают, что:

1. Включение классов процессов в более абстрактные классы — не очень то простая задача. Всегда найдутся те классы процессов, которые никуда «не лезут» или те, которые непонятно куда относить, т. к. вроде бы они подходят и туда, и туда.
2. Может получиться слишком большое количество классов процессов на верхнем уровне.
3. И, главное, возникают большие вопросы к понятности модели.

Давайте в качестве примера рассмотрим труд не начинающих аналитиков, а ряд давно используемых на практике моделей.

APQC Process Classification Framework (PCF) — Cross Industry — Version 7.2.1 September 26, 2019

APQC PCF- это одна из самых известных «классификаций процессов».

Характеристики:

• Создавалась для бенчмаркинга компаний (сравнения между собой);
• 13 верхнеуровневых категорий процессов: 6 операционных и 7 управления и поддержки;
• Глубина: местами до 5 уровня. Всего 1264 элемента (Activity) на 4 уровне.

Критика:

• Переусложненная онтология: 2 сущности для группировки процессов (Category, Process Goup, 3 сущности для декомпозиции процессов (Process, Activity, Task):
  

  

• Строго заданное фиксированное количество уровней.
  На практике попытка выдержать классификацию по жестко заданному количеству уровней часто терпит фиаско. Представьте, если бы вам сказали, что абсолютно любую систему (например, стол или атомную станцию) вы можете декомпозировать не более, чем на 5 уровней;
• Понятность модели вызывает вопросы. Например, операционные процессы включают почему-то такую группу как «1.0 Разработка видения и стратегии». И в ней в рамках «1.2 Develop business strategy» выделяется деятельность по организационному проектированию, как маленький кусочек:

  OPERATING PROCESSES
  1.0	Develop Vision and Strategy
  1.2	Develop business strategy
  1.2.5	Create organizational design
  1.2.5.1	Evaluate breadth and depth of organizational structure
  1.2.5.2	Perform job-specific roles mapping and value-added analyses
  1.2.5.3	Develop role activity diagrams to assess hand-off activity
  1.2.5.4	Perform organization redesign workshops
  1.2.5.5	Design the relationships between organizational units
  1.2.5.6	Develop role analysis and activity diagrams for key processes
  1.2.5.7	Assess organizational implication of feasible alternatives
  1.2.5.8	Migrate to new organization

• Нет связи по входам и выходам.

Типовые модели экосистемы Business Studio

Нормативных моделей, которые используются, большое количество. Среди них лично я выделяю следующие, получившие распространение в экосистеме Business Studio, модели:

8-процессная модель Тимура Кадыева

Выполнена в нотации IDEF0, операции сгруппированы по жизненному циклу элементов предприятия и внешних объектов.

Удовлетворяет всем выдвинутым в начале статьи критериям для модели деятельности верхнего уровня. Но на мой взгляд модель имеет ряд недостатков, среди которых главные:

• Модель содержит временной парадокс: деятельность по проектированию системы и результат проектирования (модель системы) показаны на одной схеме;
• Также на схеме присутствует деятельность по сборке системы (через связь механизмы), что допустимо с т.з. IDEF0, но также, как в случае с проектированием, вызывает экзистенциальные вопросы (как система работает и как мы ее собираем — показано на одой схеме и происходит как бы одновременно) и перегружает схему в случае реальных моделей с бОльшим количеством блоков.

Типовые структуры процессов СТУ

Это переработка модели процессов Тимура Кадыева в реестр процессов и локализация его на следующие виды деятельности:

• Оказание услуг (PDF);
• Проектная деятельность (PDF);
• Производство (PDF);
• Управляющая компания (PDF).

Можно сказать, что это аналог классификатора «APQС». И, кстати, он тоже используется для бенчмаркинга, причем автоматизированного, на портале www.bizdiag.com.

Модель Игоря Лозовицкого

Модель является примером использования деления деятельности на Основную, Управления и Поддерживающую. На мой взгляд, это является плюсом модели, т. к. это позволяет сфокусироваться на определенном аспекте функционирования компании. Так, например, легко выделяется цепочка создания ценности в Сфере основной деятельности. 

В модели выделено 18 групп процессов, разбитых по трем сферам. Модель выполнена в IDFE0, но для верхнеуровневого «презентационного» представления используется нотация VAD.

Процессы или функции?

Теперь самое время точно определиться с понятиями, с которыми мы имеем дело в верхнеуровневой модели деятельности компании. И начнем мы по традиции с критических высказываний в сторону классификатора APQC:

Независимо от Брюса Силвера я также пришел к выводу о том, что понятия, которыми мы оперируем в модели деятельности верхнего уровня, носят вневременной характер. То есть, мы не можем указать на временные границы, например, таких видов деятельности «Разработка видения и стратегии» или «Разработка и управление продуктами и услугами» (примеры из APQC). Зато мы можем сказать, что мы точно знаем, что такая деятельность есть и время от времени она дает свои конкретные результаты!

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

• Композиция;
• Агрегация;
• Классификация (включение члена в класс).

Давайте разберем их подробнее. В результате Композиции и Агрегации получается целый объект. Главное здесь в том, что мы получаем именно объект, имеющий свои 4D-границы, и на который, при желании, можно показать пальцем. Например, когда мы говорим о том, что процесс делится на части, мы имеем ввиду именно отношение композиции, т. к. и части, и целое являются объектом-операцией. Здесь можно зафиксировать промежуточный результат. Мы установили, что, когда мы двигаемся ниже по уровням иерархии от уровня процессов, мы имеем дело с отношением композиции.

Подходят ли эти отношения для описания того феномена, который мы наблюдаем в верхнеуровневых моделях деятельности? Нет, потому что, как отмечалось выше, понятия, которые возникают в модели деятельности верхнего уровня не являются объектами.

Давайте попробуем подумать про понятие «Класс».

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

Класс носит вневременной характер, он существует всегда. По классу нельзя «постучать пальцем», это не объект.

Понятие «Класс» и операция «Классификация» как нельзя лучше описывает то, что мы делаем в модели деятельности верхнего уровня с классами процессов. Например, включение классов процессов из APQC «1.1.1.6 Анализ демографии» или «1.2.6.1 Идентификация организационных целей» (если мы, конечно, считаем, что члены этих классов — это процессы, имеющие начало и конец) в качестве членов в класс «1.0 Разработка видения и стратегии» означает, что все конкретные процессы в рамках определенной компании: которые уже были выполнены, которые выполняются в данный момент, которые будут выполняться в будущем, — имеют отношение к деятельности по разработке стратегии. А процессы всех классов, которые, как мы решили, относятся к разработке стратегии, собственно, и являются этой деятельностью.

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

Мы можем аналогичным образом получить и промежуточные уровни нашей модели. Для этого мы можем ввести в модели подклассы класса «1.0 Разработка видения и стратегии». Но отношение здесь будет уже другое — специализация (класс-подкласс). Членами этих подклассов по-прежнему будут классы процессов.

Давайте отразим это уже в более формализованной нотации «экземпляров и классов».

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

Можно было бы обойтись только одним понятием «Операция». Но понятие «Процесс» привычно, и исключение его из языка будет затруднительно.

Прочитать данную онтологию можно следующим образом:

• Некоторые операции являются процессами;
• #Процесс1 состоит из операций #Операция1 и #Операция2;
• Процессы собираются в классы процессов;
• Классы процессов собираются в классы классов процессов.

Использование нотации IDEF0 для создания моделей деятельности верхнего уровня

Давайте сделаем паузу в наших умственных упражнениях и рассмотрим старую добрую нотацию IDEF0. Как известно, это нотация для функционального моделирования, которая используется для создания моделей верхнего уровня. Она базируется на методологии структурного анализа и проектирования (SADT), описанной в книге Дэвид А. Марка и Клемент МакГоуэн «Методология структурного анализа и проектирования (SADT)».

Эта методология знаменита, в частности, тем, что подарила нам понятие «Декомпозиция функции». Удивительно, но в книге не дается определение функции! Что-то похожее на определение появляется в базирующимся на нем стандарте IDEF0:

К данному определению у меня всегда было много вопросов. Например, если функция — это и есть процесс, то зачем придумывать новое понятие? Что нового оно дает?

Давайте разбираться. В описании нотации IDEF0 подчеркивается вневременной характер модели:

А семантика входов и выходов функции включает в себя принципы:

• Появление объекта на входе функции не обязательно означает ее активацию. В каких-то случаях достаточно появление одного объекта на входе, в каких-то — несколько;
• Не обязательно на всех входах функции должны появиться объекты.

Таким образом, модели IDEF0 сосредоточены на описании того, ЧТО должно делаться — функциях и на интерфейсах между функциями.

Я думаю, уже стало понятно, к чему я клоню. Тот объект, который у нас появился раньше, и подходит на определение понятия «Функция»:

Функция — это класс классов процессов.
(Или, с т.з. понятий ООП, если процесс — это класс, то:
Функция — это класс процессов).

Следствия из такого определения:

1. Функцию мы можем собрать из любых классов процессов, как нам заблагорассудится.
   Можно выбрать любой критерий включения в класс. Например, как в примере выше, мы можем считать, что определенные классы процессов имеют отношение к разработке стратегии.
   Или мы теперь можем легко решить очередную философскую проблему — что такое бухгалтерский учет — процесс или не процесс? Бухгалтерский учет — это, конечно, не процесс. Это функция, включающая все классы процессов, относящихся к предметам бухгалтерского учета.
2. Один класс процессов может входить в несколько функций (и это не грех, как принято считать сейчас. Мир слишком многогранен, чтобы его можно было описать одной таксономией).
3. Мы можем обобщать функции до бесконечности вверх. Между родительской и дочерней функцией существует отношение класс-подкласс. На нижнем уровне, когда в функцию оказывается включен только один класс процессов, обычно осуществляют смену типа модели и переходят к созданию типовой модели процессов класса (описывающей все процессы класса). При этом дальнейшее разбиение на части происходит с использованием связи композиция.
   Подобный подход давно поддерживала система Business Studio. Теперь мы знаем, что это означает с точки зрения теории.
4. Стрелки между функциями моделируют объекты, перемещающиеся между функциями. Это значит, что в реальности найдутся два конкретных процесса между которыми будут перемещаться конкретные объекты. Но как в любой модели классов (с указанием соответствующей кратности на конце связи) не все связи будут существовать между каждыми двумя процессами. При объединении стрелок, моделирующих интерфейсы функций, в более крупные стрелки, имеет место аналогичный функциям подход.

Замечания об онтологии

Почему такое, на первый взгляд, большое внимание уделено рассмотрению объектов и классов нашей онтологии и связей между ними? В хороших онтологиях вы должны уметь пройти от верхнероувневых абстрактных классов до конечных объектов, лежащих в основе онтологии, и смочь «показать на них пальцем». Если вам это не удается, то скорее всего ваша онтология не так прозрачна и используема на практике, как хотелось бы.

Также очень хорошо, если ваша онтология синхронизирована с другими. В описанном случае, мне кажется, это удалось. Онтология не противоречит IDEF0, а также языкам BPMN и Archimate.

Июнь 2021 г.

Рекомендуемые материалы по тематике

Построение верхнеуровневой модели деятельности компании на основе принципов системной инженерии. Глава 2. Делим организацию на части

Построение верхнеуровневой модели деятельности компании на основе принципов системной инженерии. Глава 3. Фреймворк деятельности компании