Матричная архитектура процессов

Тема статьи

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

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

В конце статьи есть пример конкретной МАП.

Терминология

Что такое процессный ландшафт

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

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

Графический вид:

• VAD диаграммы;
• IDEF диаграммы;
• Или без использования какой-то нотации, а виде квадратиков.

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

• Сколько процессов вообще?
• Кто за них отвечает?
• Как они взаимосвязаны между собой?
• Кто или что на них влияет и управляет?
• Что является их результатом?
• Как они измеряются?
• Как контролируются?
• Какие ошибки и разрывы присутствуют?
• Что определить, как приоритет для дальнейшей работы?

Пример: IDEF диаграммы
Источник: trinion.org

Пример: VAD диаграммы
Источник: eor.dgu.ru

Как разрабатывают процессные ландшафты

Процедура разработки в каждой компании индивидуальна и зависит от:

• Этапа внедрения процессного подхода – первый раз или новая итерация существующей.
• Уровня развитости компании – никто ничего не знает или менеджеры обучены принципам процессного управления.
• Уровня развития процессов – хаос или есть какая-то структура, например используются стандарты, внедрено СМК или применяются бережливые технологии.
• Стратегической осведомленности – стратегия не определена или есть стратегия развития на несколько лет вперед с понятными и оцифрованными целями.
• Уровня зрелости менеджмента – каждый живет в своем “Царстве-королевстве” и достигает личные KPI или все менеджеры понимают, что каждое их действие влияет на итоговый результат всей компании.

Процесс разработки двигается обычно по похожей процедуре:

1. Определили миссию и верхнеуровневые цели компании.
2. Определили основные продукты / способности / направления развития.
3. Определили, с помощью каких групп процессов они достигаются.
4. Определили ответственных по каждой группе.
5. Визуализировали и утвердили данные договоренности.

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

Пример: Дерево процессов
Источник: reglament.net

Древовидная структура

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

Пример: Дерево процессов

Как появились древовидные представления процессного ландшафта

Построение древовидных структур – очень “древний” подход, и своими корнями уходит во времена до нашей эры, например, Аристотель в своих трудах уже применял такие структуры, а огромную популярность они получили в конце 19 века после концепции “Древа жизни” Чарльза Дарвина.

В менеджменте этот формат структуризации информации стал популярен при формировании организационных структур в рамках функциональной модели управления.

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

Например, CBOK до сих пор рекомендует начинать формирование процессного ландшафта отталкиваясь от функциональной модели:

4.7. Уровни процессных моделей

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

Источник: CBOK. Раздел 4.7.

Что не так с древовидной структурой

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

Неудобства древовидной структуры 

1. Абстрактность группировок

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

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

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

Я для себя разделяю эти группировки по следующему принципу:

Полезные группы

Процессное поле,  область определяющее одну из границ плоскости анализируемого контекста. 

Например:

• Модель Портера - основные и поддерживающие.
• Классическая модель управления - управляющие, основные, поддержка, развитие.
• PDCA - Plan, Do, Check, Act - Планирования, Реализация, Контроль и Стандартизация.
• Способности или навыки – термин относительно новый. Что это – процесс, компетенция, ресурсы, средства? Если коротко – все перечисленное. Способность – это то, что вы, как организация, можете и готовы делать. Например, логистическая компания способна осуществлять доставку грузов, в том числе мультимодальную (несколькими видами транспорта), в том числе сборные грузы, в том числе импортную и экспортную (беря на себя взаимодействие с таможней) (официальное определение CBOK).
• Встречаются случаи, когда формат процессного поля формируют под себя, без привязки к историческим моделям.

Следующая важная и нужная плоскость – сквозные процессы, которые соединяют отдельные процессы в группы. Группы распределены где-то по организационным функциям, по продуктам или по командам, которые их исполняют.

Бесполезные группы

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

На практике возникали следующие сложности:

2. Определение ответственности

Очень сложно выявить,  кто является владельцем того или иного уровня процессов,

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

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

1. Большая часть процессов – это внутрифункциональные процессы с отсутствующими кроссфункциональными связями, т.е. процесс превращается в инструкцию для работников конкретного подразделения и не учитывает включенность в общую процессную модель.
2. Руководители подразделений становятся равны Владельцам процессов без оценки реальной способности управления новой сущности, просто потому что он и так управляет этим подразделением.
3. Цели, метрики и показатели (далее ЦМП) также остаются внутрифункциональные, разрабатываются по тем же принципам, как и для организационной функции. Это приводит к их локализации и разрывает связь между ЦМП других процессов, а главное ЦМП компании.
4. Определение KPI - непонятно, как разбросанные по всему дереву показатели соотносятся между собой, как их определять и корректно декомпозировать даже в рамках одной ветки дерева.
5. Определение продуктов – что получается на уровне каждого отдельного листа / звена дерева, определить несложно, но, как они друг на друга влияют или зависят, становится непонятно. Или, например, разделить то, что получается на уровнях от Процессной категории до Операционного процесса несложно, но как они потом связаны с другими ветвями либо непонятно, либо усложняет визуализацию самих деревьев и этот важный объект управления исключают из схем. 
6. Иерархичность древовидной модели, т.е. сложность в отображении пересекающихся процессов. В дереве каждый процесс или операция связаны с единственным родительским процессом, что делает трудным представление процессов, которые пересекаются и могут быть частью нескольких потоков. Это ограничивает гибкость модели и может привести к трудностям при анализе кросс-функциональных процессов.
7. Жёсткость структуры. Древовидная модель, как правило, ограничена линейной иерархией, что затрудняет отображение сложных, многоуровневых и взаимосвязанных бизнес-процессов. В реальной жизни многие процессы могут быть более сложными и не соответствуют строгой иерархической структуре. Это становится проблемой, особенно в динамичных и изменяющихся организациях, где процессы могут пересекаться и изменяться в реальном времени.

Таким образом, древовидная структура является бесперспективным и неудобным способом организации процессов, а современные контексты вокруг процессов требуют поиск новых подходов или инструментов.

В качестве альтернативы мы предлагаем использовать Матричную архитектуру процессов (МАП).

Матричная архитектура процессов

МАП формируется следующим образом:

1. Определяется тип процессного поля, например, модель Портера, классическая модель управления, PDCA и т.д.
2. Согласовывается перечень сквозных и кросс-функциональных процессов.
3. На пересечении строк и столбцов образуется - процессная ячейка, в которой мы можем отразить весь перечень процессов, которые к ней относятся. Переиспользуемые процессы могут отражаться в разных ячейках, их дублирование не является ошибкой. Дерево, например, не позволяет отразить один и тот же процесс в разных ветках, потому что это нарушит логику иерархической принадлежности.
   Также в матрице явно видны “Белые пятна”, крупная область в рамках какого-то сквозного процесса без отраженных процессов, что позволяет просигнализировать аналитику о возможной ошибке, которую нужно проанализировать и понять, действительно ли не должно быть процессов или они упущены.
   

   Т.е. у нас формируется пересечение двух плоскостей:

   • Первая - процессное поле;
   • Вторая - сквозной процесс. 

   Ценность такой структуры заключается в четкой принадлежности процесса к определенному анализируемому контексту без необходимости дополнительной декомпозиции или избыточной связанности.

4. Определяется владелец процесса, который отвечает за весь перечень ячеек. Количество групп резко сокращается, у нас больше нет первого, второго, пятого или шестого уровней.
5. Далее прорабатывается дополнительный контекст вокруг сквозного процесса – определяются продукты, цели и метрики (BSC, OKR или иное, это не важно или это могут быть вообще не связанные с этими концепциями показатели, какие-нибудь операционные, финансовые и так далее. Сквозной процесс нельзя просто вставить в дерево, он и его контекст никогда не найдёт себе места в иерархии так, чтобы из этого места было понятно всё.

Определение KPI, определение продуктов становится более логичным, потому что они непосредственно связаны со сквозными процессами. Сами же KPI, которые мы определяем, декомпозируются, не на огромный перечень стволов, веток и листиков, а только на сквозную ветку и её процессы. Операционные метрики или конкретными процессными KPI определяются при работе с самим процессом и на уровне матрицы не отображаются, но формируются с точки зрения KPI основного процесса.

Возможности использования процессных матриц

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

Основные принципы формирования матричной архитектуры процессов

При анализе и разработке данной концепции сформировалось несколько тезисов, которые по сути являются постулатами:

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

Пример: Двумерная матрица процессов

Пример: Четырехмерная матрица процессов

Сравнительная таблица визуальных форм

Принцип распределения баллов:
1 балл — трудно / тяжело / неудобно / плохо
5 баллов — просто / легко / удобно / хорошо

 Пример Матричной архитектуры процессов и сравнительную таблицу можно найти по ССЫЛКЕ

Заключение

Как считаете, поможет ли МАП решить вопросы сложность организации и внедрения процессного подхода в компаниях? Поделитесь своим мнением в нашем сообществе.