## **1. Процессная архитектура** Процессная архитектура — это **наглядное представление того, как на самом деле работает ваша компания**: кто что делает и как всё между собой связано. Это не коллекция схем, а **структурированная модель деятельности**, в которой каждый процесс имеет: границы, владельца, входы, выходы, измеримые результаты. **Главные свойства процессной архитектуры:** * **Прозрачность** — все видят, какие процессы существуют и кто за них отвечает. * **Наглядность** — связи и потоки отображаются визуально, а не в виде таблиц или текстов. * **Созависимость** — каждый процесс явно связан с другими, с ресурсами, документами, системами и стратегическими целями. * Эти три качества вместе создают **управляемость** — возможность принимать обоснованные решения на основе полной картины. **Процессы — это не «воздух», который есть «просто так». Это активы компании.** Такие же, как оборудование, люди или ИТ-системы. Их можно и нужно визуализировать, измерять и улучшать. --- ## **2. Зачем нужна процессная архитектура** **Процессная архитектура решает конкретные бизнес-задачи:** * **Формирует сквозное видение компании** — от стратегических целей до операционных задач. Старший менеджмент видит, как KPI верхнего уровня достигаются через конкретные процессы. * **Обеспечивает прозрачность ответственности** — исчезают «функциональные колодцы», когда каждый подразделение гонится за своим KPI, но сквозной поток не работает. * **Позволяет руководителям видеть всё в одном окне** — без перехода между Excel, Confluence и BPM-моделерами. Есть функция проваливания (drill-down): от общей карты — к конкретной операции. * **Поддерживает принятие решений на данных, а не на интуиции** — вы видите, как изменение в одном процессе повлияет на всю архитектуру. * **Позволяет быстро масштабироваться** — запуск нового филиала или направления строится на уже отлаженной модели. * **Сокращает управленческие риски** — вы заранее видите, сколько «плеч» у процесса, какие команды будут затронуты, какие данные потребуются. * **Даёт возможность моделировать сценарии** — что если заменить людей на роботов? Что если внедрить новую систему? Ответ можно получить на цифрах, а не на гипотезах. --- ## **3. Архитектурный подход как методология** Процессная архитектура строится не хаотично, а на основе **архитектурного подхода** — системного проектирования, как при создании здания, холодильника или программного продукта. Ключевые принципы: * **Проект разбивается на этапы** — не нужно описывать все процессы сразу. Выделяются приоритетные домены и сквозные цепочки. * **Согласованность решений** — любое изменение в одном процессе автоматически влияет на смежные. Вся архитектура остаётся целостной. * **Эмерджентность** — при взаимодействии элементов возникают новые свойства, которых нет у частей по отдельности. Это синергетический эффект, который можно планировать и усиливать. * **Процессы никогда не существуют в изоляции** — если вы нашли «белое пятно» (процесс без связей), это ошибка моделирования. --- ## **4. Процесс как объект управления** **(а не BPMN-схема)** В StormBPMN **процесс ≠ BPMN-модель**. Модель — это лишь одна часть. На самом деле процесс — это **структура данных**, включающая: * **Идентификацию**: название, код, владелец. * **Цели и показатели**: KPI, план/факт/дельта, целевые значения. * **Модели**: BPMN, IDEF0 или другие нотации. * **Входы и выходы**: поставщики, потребители, продукты. * **Ресурсы**: роли, ИТ-системы, документы. * **Регламенты**: инструкции, политики, стандарты. * **Риски и контроли**: точки управления качеством. * **Планы развития**: дата актуализации, проекты оптимизации. * **История изменений**: кто, когда и что менял. Управление процессом — это управление его **жизненным циклом**: от создания и согласования до моделирования, внедрения, мониторинга и оптимизации. ## **5. Структура архитектуры:** **Уровни группировки** Архитектура строится иерархически. Рекомендуем использовать **не более чем 3–4 уровня**: * **Уровень 1** — это **группировка** (домен, направление, сквозная цепочка). Не процесс, а контейнер. * **Уровень 2** — вторая **группировка**, например, подгруппы внутри домена. * **Уровень 3** — **операционный процесс** с владельцем, KPI, моделью BPMN и документацией. * **Уровень 4** — опционально, только если критически необходимо. Ниже — уже не процессы, а отдельные операции. **Принципы группировки** Выбор принципа зависит от бизнеса и зрелости компании. Рекомендуется придерживаться **одного подхода**: * **По продуктам** — у каждого продукта или услуги своя ветка процессов. * **По направлениям** — маркетинг, логистика, финансы и т.д. (часто приводит к «функциональным колодцам»). * **По сквозным процессам** — «от заявки до оплаты», «от найма до увольнения». Наиболее зрелый подход. * **По способностям компании (APQC)** — подходит для крупных корпораций с высокой стандартизацией. * **По модели Портера** — core-процессы, поддерживающие, управления и **развития** (процессы развития часто забывают, но без них невозможно внедрение BPM). --- ## **6. Настройка структуры архитектуры** Архитектор настраивает архитектуру один раз - в разделе [**Реестр бизнес-процессов → Структура**](https://helpdesk.stormbpmn.com/hc/docs/articles/1766959121-) Это обеспечивает единообразие - единые правила для всех кто работает с процессами и архитектурой. При настройке архитектор: 1. определяет уровни архитектуры: их количество, названия, префиксы 2. настраивает поля карточек процессов для каждого уровня --- ## **7. Формы архитектуры** StormBPMN поддерживает **четыре формы визуализации одной и той же архитектуры** — каждая под разные задачи и роли: ### [**Реестр процессов**](https://helpdesk.stormbpmn.com/hc/docs/articles/1754918003-) [**Дерево**](https://helpdesk.stormbpmn.com/hc/docs/articles/1754918003-) - иерархическая группировка процессов. Привычное и простое представление: родитель и дети. Хорошо для структурирования, но плохо показывает горизонтальные связи между процессами. Подходит для аналитиков на этапе построения реестра. [**Каталог**](https://helpdesk.stormbpmn.com/hc/docs/articles/1767992964-) - группировка не по иерархии, а по другим критериям: по продуктам, системам, владельцам. ### [**Таблица**](https://helpdesk.stormbpmn.com/hc/docs/articles/1766958823-) Идеальна для сбора KPI, паспортизации и фильтрации. Можно настроить множество колонок: владелец, статус, тип процесса, дата актуализации и т.д. Минус — нет наглядности связей. Подходит для аудита и отчётности. ### [**Карта**](https://helpdesk.stormbpmn.com/hc/docs/articles/1766958303-) «Матрешка» — вложенные блоки, где каждый процесс содержит подпроцессы и KPI. Поддерживает интерактив: можно фильтровать по системам, статусам, метрикам. Позволяет сфокусироваться на одной цепочке и сразу увидеть, где «красные» зоны. Требует высокого качества данных, но даёт наибольшую управляемость. ### **Граф** Показывает все связи: процессы → документы, процессы → системы, процессы → роли. Идеален для анализа входов/выходов и автоматизации. Требует качественных данных и хорошего UX, иначе превращается в «клубок» при большом объёме. Особенно полезен топ-менеджменту для быстрого принятия решений. --- ## **8. Показатели и параметры** StormBPMN разделяет: * **Показатели** — метрики с планом, фактом и дельтой (например, «доля этапов в срок»). * **Параметры** — атрибуты без измерений (например, «тип процесса», «продукт», «дата актуализации»). Показатели и параметры можно задавать: * **Сквозные** — для всего уровня (в настройках структуры). * **Локальные** — только для конкретного процесса. Ключевые показатели можно пометить как **приоритетные** — они будут отображаться на карте процессов. --- ## **10. Единое информационное окно** StormBPMN реализует принцип **«единого окна»** для всех типов пользователей: * **Собственник** видит карту процессов, KPI и может провалиться в проблемную зону. * **Архитектор** настраивает структуру, справочники, права. * **Аналитик** заполняет карточки, привязывает модели, документы, показатели. * **Исполнитель** видит свою роль, документы и регламенты. Все работают **в одном интерфейсе**, без перехода между системами. Это устраняет «зоопарк из 1000+ приложений», о котором говорят в Global BPM Survey. --- ## **11. Подготовка к запуску** Перед началом работы необходимо ответить на 8 ключевых вопросов: 1. Сколько уровней будет в архитектуре? 2. Какие параметры будет иметь каждый уровень? 3. Какие процессы создают основную ценность? 4. Какие процессы её поддерживают? 5. Где начинаются и заканчиваются процессы? 6. Кто владелец? Кто потребитель результата? 7. Как измеряется эффективность? 8. Где собираются данные? StormBPMN предоставляет чек-лист из 38–40 вопросов для детальной подготовки - [скачать](https://disk.yandex.ru/i/ZhO79l65LJ82IA). --- ## **Заключение** StormBPMN — это не просто BPMN-редактор. Это **платформа для управления процессной архитектурой как активом**, где процессы — не схемы, а **живые объекты с контекстом, связями и жизненным циклом**. Система обеспечивает: * Дисциплину через настройку структуры, * Гибкость через каталог и фантомы, * Прозрачность через карты и графы, * Управляемость через полный скоп данных. Это решение для компаний, которые готовы перейти от хаотичного моделирования к **системной, стратегической работе с процессами**.