Классификация бизнес-процессов организации

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

Материал написан для руководителей и владельцев бизнеса, операционных директоров, бизнес-аналитиков и всех, кто занимается описанием, оптимизацией или автоматизацией деятельности компании. Здесь вы найдёте рабочие оси классификации, примеры для разных отраслей, минимальный стандарт реестра и чек-лист для внедрения за две недели.

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

Понятие бизнес-процесса и зачем нужна классификация

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

• вход — то, что его запускает: заявка клиента, счёт поставщика, заявление сотрудника;
• выход — результат, который получает клиент: отгруженный товар, закрытая вакансия, оплаченный счёт;
• владелец — ответственный за то, чтобы он правильно работал;
• границы — чётко очерченные точки начала и завершения.

Зачем классифицировать. Без классификации возникают три типичные проблемы.

1. Дублирование и путаница. Отделы описывают сценарии, не подозревая, что половина из них — один и тот же сквозной алгоритм, просто с разных точек зрения.
2. Споры о приоритетах. Когда всё кажется одинаково важным, ресурсы уходят на то, что громче звучит, а не на то, что реально влияет на прибыль и клиента.
3. Размытая ответственность. «Процесс = отдел» — самая частая ошибка. Отдел — это элемент структуры, а поток работы, как правило, пересекает несколько отделов.

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

Распространённые ошибки при идентификации

Классификация бизнес-процессов по роли в создании ценности

Есть несколько способов построить модель операционной структуры компании. На практике используют разные референтные схемы: цепочку создания ценности Майкла Портера, 13-процессную и 21-процессную модели, отраслевые BAAN, eTOM и другие. Они по-разному группируют деятельность организации и выделяют разные её уровни.

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

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

• В производстве: разработка продукта → закупка → производство → логистика → продажа.
• В банке: привлечение клиента → открытие счёта → кредитование → обслуживание.
• В ИТ-компании: маркетинг → продажи → внедрение → поддержка.

Именно здесь сосредоточено основное внимание при оптимизации и автоматизации, так как улучшения дают максимальный эффект.

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

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

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

Управленческие. Эти потоки работы задают направление и контролируют результат. Их выходы — решения, планы, стандарты, приоритеты.

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

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

Процессы развития. Это потоки, которые меняют саму компанию: создают новые продукты, совершенствуют то, как она работает, внедряют инновации.

• Примеры: разработка новых продуктов и услуг, проектная деятельность, практики непрерывного улучшения (Lean, Kaizen), внедрение новых систем.

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

Дополнительные оси классификации

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

По границам: внутренние и внешние

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

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

По охвату: внутрифункциональные, кросс-функциональные и сквозные

• Внутрифункциональные — выполняются в рамках одного подразделения. Например, подготовка ежемесячного финансового отчёта внутри бухгалтерии.
• Кросс-функциональные — пересекают несколько подразделений организации. Например, согласование договора может требовать участия отдела продаж, юридического отдела и финансовой службы.
• Сквозные — проходят через несколько подразделений и охватывают полную цепочку создания ценности, выходя за границы организации. Например, выполнение заказа клиента начинается с оформления заявки, проходит через продажи, производство, склад и логистику, а завершается получением товара заказчиком.

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

По степени автоматизации: ручные, автоматизированные, гибридные

• Ручные — все действия выполняются людьми без автоматического управления. Например, ручная комплектация заказов по бумажным накладным или инвентаризация склада с заполнением ведомостей вручную.
• Автоматизированные — основные операции выполняются системой без участия человека. Например, автоматическая сортировка посылок на логистическом терминале или автоматическое пополнение запасов при достижении минимального остатка.
• Гибридные — часть операций выполняется автоматически, а часть требует участия человека. Например, складская система автоматически формирует задание на комплектацию, после чего сотрудник собирает заказ и подтверждает выполнение операции.

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

По влиянию на добавленную стоимость

Этот срез используют при оптимизации. Каждый шаг можно отнести к одной из трёх категорий:

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

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

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

Один из распространённых вариантов выглядит так:

Один из вариантов иерархии бизнес-процессов

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

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

Реестр — минимальный стандарт. Это структурированный перечень всех объектов деятельности организации с их основными атрибутами и связями. Он служит навигатором по архитектуре: прежде чем описывать, анализировать или автоматизировать работу, нужно понимать, какие сценарии существуют и как они связаны между собой.

В зависимости от инструмента и задач перечень можно представить в разных форматах:

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

Независимо от формы представления обычно фиксируется один и тот же набор данных:

Пример атрибутов в реестре

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

❗Для сквозных сценариев назначают специального владельца, иначе никто не несёт ответственности за стыки между отделами.

Как выбрать глубину описания. Уровни архитектуры (L0, L1, L2 и далее) показывают место потока в общей структуре организации. При этом глубина моделирования определяется не архитектурным уровнем, а задачей, ради которой создаётся описание.

Одну и ту же работу можно представить по-разному:

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

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

Классификация основных бизнес-процессов предприятия: материнский процесс и цепочка создания ценности

Как найти главную цепочку создания ценности. В каждой компании есть один или несколько ключевых (core) потоков, которые непосредственно генерируют выручку и создают ценность для клиента. Чтобы их найти, задайте вопрос: «За что заказчик платит деньги и как этот результат попадает к нему?»

Такой сценарий называют цепочкой создания ценности (Value Stream). Он, как правило, начинается с запроса клиента и заканчивается получением клиентом результата (и оплатой).

Как разложить основной поток на подпроцессы. Единого стандарта декомпозиции нет, но есть принцип, согласно которому подпроцессы должны быть логически завершёнными: у каждого свой вход, выход и ответственный.

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

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

Примеры разбивки по отраслям

Классификация моделей бизнес-процессов: какие модели нужны и чем они отличаются

Описание работы предполагает создание моделей — схем того, как всё устроено. Но «модель» — понятие широкое. Чтобы не путаться, разберём основные классификации.

AS-IS и TO-BE: две точки отсчёта

AS-IS («как есть») — описание текущего состояния. Цель: зафиксировать реальность, найти потери, узкие места, дублирования и неэффективности. AS-IS строится на основе интервью, наблюдений и данных из систем.

TO-BE («как должно быть») — описание целевого состояния. Цель: спроектировать улучшенный или новый сценарий с учётом найденных проблем, новых технологий или стратегических целей.

Правило: нельзя пропускать AS-IS и сразу рисовать TO-BE. Без понимания текущего состояния TO-BE будет оторван от реальности.

Уровни представления и детализации моделей

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

Возможные уровни представления и детализации потоков

Описательные, аналитические и исполняемые модели

Это одна из ключевых классификаций — особенно для тех, кто планирует автоматизацию.

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

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

Исполняемые — это BPMN-схемы, которые напрямую запускаются в BPM-системе (например, в Jmix). Они должны быть формально корректными и содержать все технические атрибуты: условия переходов, таймеры, обработчики ошибок, интеграции. Это уже не документация, а работающий код.

Как это работает на практике в проекте описания / оптимизации / автоматизации:

1. Проект описания: строятся описательные AS-IS модели L2 → формируется реестр → создаётся карта L0.
2. Проект оптимизации: строятся аналитические AS-IS модели → проводится анализ потерь → проектируются TO-BE модели → утверждаются и внедряются изменения.
3. Проект автоматизации: на основе TO-BE создаются исполняемые модели → настраиваются интеграции, роли, правила → сценарий запускается в BPM-системе.

Часто встречается ошибка: команда рисует описательные схемы, а потом пытается загрузить их в BPM-систему. Это не работает — исполняемая модель требует другого уровня проработки.

Как провести классификацию деятельности компании и зафиксировать её в Stormbpmn

Шаг 1. Определите границы и цель. Прежде чем собирать операционную архитектуру, ответьте на вопрос: зачем она нужна? От цели зависит глубина проработки и способ представления информации. Например:

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

Шаг 2. Сформируйте верхнеуровневую архитектуру. Определите основные направления деятельности, домены или группы работ. В зависимости от выбранного подхода можно двигаться как сверху вниз — от архитектуры к отдельным сценариям, так и снизу вверх — от продуктов, услуг или существующих потоков к формированию общей структуры.

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

Шаг 3. Заполните реестр. Соберите перечень объектов и заполните их основные атрибуты: владельца, категорию, участников, входы, выходы и статус описания. На этом этапе важнее обеспечить полноту охвата, чем детально моделировать каждый объект.

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

Шаг 4. Расставьте приоритеты. Используйте два критерия:

• влияние на клиента и выручку — насколько сценарий влияет на ценность для заказчика, выручку, сроки или качество;
• готовность к изменениям — есть ли ресурсы и заинтересованность в улучшениях.

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

Шаг 5. Опишите приоритетные потоки. Начните с фиксации текущего состояния (AS-IS), а затем переходите к проектированию целевого состояния (TO-BE). Глубина моделирования должна определяться задачей: для анализа достаточно верхнеуровневой схемы, для автоматизации может потребоваться детальная проработка бизнес-правил, ролей и исключений.

Stormbpmn поддерживает моделирование в нотации BPMN 2.0 и позволяет последовательно развивать модели от обзорных до высокодетализированных схем.

Шаг 6. Назначьте владельцев и запустите цикл улучшений. Без владельца работа остаётся только объектом описания. Владелец отвечает за актуальность модели, метрики выполнения и инициативы по развитию.

FAQ по классификации бизнес-процессов

Сколько потоков должно быть в реестре?

Универсального числа не существует. Размер реестра зависит от отрасли, бизнес-модели, сложности организации и выбранного уровня детализации.

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

Если реестр становится слишком большим, это не обязательно ошибка. Однако стоит проверить, не смешаны ли в нём объекты из разных уровней детализации, подпроцессы, операции и отдельные рабочие задачи. В таких случаях полезно пересмотреть структуру и правила декомпозиции.

Чем процесс отличается от проекта?

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

Нужно ли описывать вспомогательную деятельность?

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

Чем реестр отличается от карты?

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

Можно ли использовать несколько классификаций одновременно?

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

Что такое «процессная архитектура»?

Это системное описание всей деятельности компании: их иерархия (L0–L3), взаимосвязи, владельцы и ключевые характеристики. Архитектура — это результат полноценно выполненной классификации.

Заключение: с чего начать и чек-лист внедрения

Классификация бизнес-процессов организации — это не разовый проект, а инструмент управления компанией. Не существует единственно верной операционной архитектуры или универсального способа её построить. Важно выбрать подход, который соответствует целям бизнеса и позволяет поддерживать описание процессов в актуальном состоянии.

С чего начать?

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

Дальнейшая детализация зависит от задач организации: анализа, регламентации, автоматизации или процессной трансформации.

Чек-лист запуска процессной архитектуры за 1–2 недели

Неделя 1 — Формирование основы

• ☐ Определить цель проекта: анализ, регламентация, автоматизация, BPM-трансформация и др.
• ☐ Собрать рабочую группу с участием представителей ключевых направлений бизнеса
• ☐ Выделить ключевые направления деятельности, продукты или услуги компании
• ☐ Сформировать верхнеуровневую архитектуру в виде карты, дерева, реестра или матрицы
• ☐ Определить структуру реестра и набор атрибутов объектов
• ☐ Зафиксировать общий перечень потоков и их основные характеристики

Неделя 2 — Приоритизация и моделирование

• ☐ Назначить ответственных
• ☐ Определить самые важные направления для бизнеса и области для улучшений
• ☐ Расставить приоритеты по влиянию на бизнес и готовности к изменениям
• ☐ Зафиксировать статус описания и план дальнейшей проработки
• ☐ Построить первые модели AS-IS для приоритетных потоков
• ☐ Определить порядок актуализации архитектуры и реестра

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