Что такое архитектура бизнес-процессов и как она используется

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

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

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

Когда речь заходит об архитектуре бизнес-процессов, сразу становится понятно, что это весьма субъективная сущность. Дело в том, что границы бизнес-процессов определяются людьми в рамках выполнения конкретных задач: трансформации бизнеса, внедрения систем управления (например, СМК), автоматизации кросс-функциональных процессов и т.д. 

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

Часть общей архитектуры компании

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

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

Видение архитектуры бизнес-процессов

Рабочее определение архитектуры бизнес-процессов следующее:

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

На рис. 4 показана условная модель ролей управления архитектурной деятельностью в зависимости от уровней архитектуры организации. 

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

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

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

1. функциональная модель;

2. структурно-функциональная модель;

3. модель на основе бизнес-компетенций;

4. модель на основе цепочек (сети) создания ценности;

5. модель на основе жизненного цикла продукции;

6. модель на основе структуры продуктов компании;

7. модель на основе  цикла PDCA ;

8. линейный перечень кросс-функциональных процессов;

9. прочие экзотические модели. 

При выборе метода формирования уровня архитектуры процессов для целей снижения субъективности мнения архитектора важно учитывать следующие аспекты:

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

• должна быть определена заинтересованная сторона(ы)/пользователь проекции(модели) уровня архитектуры процессов;

• при формировании модели на уровне должен существовать, как минимум, один основной сценарий использования заинтересованной стороной (не архитектором) – прикладная задача менеджмента с ценным для бизнеса результатом;

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

Выбрав конкретный метод, процессный архитектор строит некоторую базовую иерархическую архитектуру бизнес-процессов. Она является основой для создания любых необходимых проекций (view). Например, руководству компании может потребоваться:

• спроектировать кросс-функциональный бизнес-процесс разработки нового изделия «от идеи до постановки на производство»;

• сформировать модель сквозного бизнес-процесса управления цепочкой поставок в группе компании;

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

• создать процесс сквозного интегрированного планирования;

• выявить все процессы, связанные с планированием и отчетностью;

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

• создать архитектуру процессов управления для руководителя, если не получается создать модель управления в рамках логики построения базовой архитектуры, например, для директора завода или руководителя подразделения управляющей компании Холдинга;

• прочее.

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

Нотации и инструменты

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

Какие нотации можно использовать для построения архитектуры? На верхнем (0-3 уровни) это, как правило, нотации VAD и IDEF0. Можно использовать также разновидности нотаций DFD, но без детализации информационных потоков. Сравнение нотаций VAD и IDEF0 можно посмотреть в моей статье «Внедрение Business Studio 6: создание системных справочников. Часть I». 

На нижнем, операционном уровне можно использовать нотации eEPC и BPMN. Я всегда отдаю предпочтение нотации BPMN, так как eEPC давно и безнадежно устарела и не является уже выразительным языком моделирования, подходящим для проектирования исполняемых процессов в современных Low-code системах. 

Если говорить об инструментах, то процессный архитектор может выбрать следующие продукты:

• MS Visio;

• Draw io;

• Camunda;

• Bizagi Modeler;

• STORMBPMN;

• Business Studio;

• iGrafx;

• OSAWl.

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

Не советую использовать для построения процессной архитектуры редакторы, «заточенные» только под Archimate (например, Archi – отличный редактор, но для своих задач). В целом, в стандарте Archimate процессы описываются довольно грубо, невыразительно (особенно в части Work Flow). Кроме того, сложно строить иерархические процессные модели. 

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

Практическое использование архитектуры бизнес-процессов

Кто в компании заинтересован в использовании архитектуры бизнес-процессов. По степени значимости для бизнеса это:

1. Собственники компании.

2. Топ-менеджмент.

3. Владельцы бизнес-процессов.

4. Процессный офис и департамент ИТ.

5. Прочие.

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

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

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

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

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

4. системное планирование, выполнение и контроль работы по регламентации, автоматизации и цифровизации бизнес-процессов компании;

5. проведение бенчмаркинга – сравнение компании с конкурентами, выявление потенциала повышения эффективности бизнес-процессов.

Выводы 

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

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

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