Архитектура бизнес-процессов: уровни, элементы и порядок работы

Представьте сервисную телеком-компанию, которая обслуживает корпоративных заказчиков в нескольких регионах. У неё есть регламенты, схемы отдельных работ, CRM, техподдержка, биллинг и система мониторинга сети. Но если руководитель спросит, как построена работа с обращениями клиента – от первой заявки на подключение до восстановления услуги и закрытия акта, каждый покажет только свой участок.

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

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

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

Что такое бизнес-архитектура, архитектура бизнес-процессов и архитектура бизнес-систем

Описание компании адресовано нескольким целевым аудиториям читателей. Руководству оно помогает принимать решения о деньгах и приоритетах. Сотрудникам и аналитикам – договариваться о границах ответственности. Исполнителям – получать однозначные инструкции без пояснений в переписке и разговорах с коллегами.

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

Бизнес-архитектура предприятия: простое определение и место в корпоративной архитектуре

Корпоративная архитектура описывает организацию целиком. В TOGAF она разделена на 4 домена: деятельность, данные, приложения и технологии. Первый домен, по сути, и есть бизнес-архитектура. Он связывает стратегию с тем, как компания создаёт ценность для клиента. Данные – чем она оперирует и кто владеет каждой сущностью. Приложения – в каких системах выполняется работа. Технологии – на какой инфраструктуре эти системы работают. Эти три домена – данные, приложения и технологии – и составляют архитектуру бизнес-систем. Строится этот слой после того, как описана сама деятельность.

Бизнес-архитектура предприятия отвечает на 4 группы вопросов:

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

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

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

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

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

Особенности реестра процессов, в отличие от архитектуры:

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

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

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

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

Основные элементы

В описание входит несколько типов объектов, и у каждого своя типичная ошибка (Табл. 1).

Базового перечня элементов недостаточно. Чтобы архитектурой можно было управлять, нужны ещё пять элементов:

• Границы: вход и выход – чем работа начинается и каким результатом заканчивается. Обеспечивает переход задачи от одного участника к другому.
• Владелец – конкретный человек, отвечающий за итог и изменения. Без него проблема на границе зон ответственности останется нерешённой.
• Показатель – критерий результата или хода выполнения. Делает состояние наблюдаемым.
• Точка контроля – место и правило проверки. Показывает, где обнаруживать отклонение.
• Мастер-система данных – единственный источник достоверных сведений об объекте. Снимает спор между версиями заявки или договора.

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

Как элементы бизнес-архитектуры связаны между собой

Метамодель TOGAF определяет не только типы объектов, но и допустимые отношения между ними. Описание разворачивается сверху вниз – от причины изменения к работе, которую необходимо выполнять.

1. Драйвер инициирует потребность в изменении. Из драйвера, с учётом оценки текущего состояния, формулируется цель – измеримое состояние с единицей измерения и целевым значением.
2. Путь к цели сужают принципы и ограничения: устойчивые правила проектирования и внешние условия, которые нельзя нарушить. Ответственность в процессах распределяется между ролями. Исполнители находятся в организационной структуре. У каждого процесса есть цель и показатели.
3. Достижение цели требует способностей – устойчивого умения организации регулярно доставлять ценность, независимо от структуры. В ходе работы создаются и используются данные, а сама работа выполняется в приложениях.
4. Способности реализуются сочетанием бизнес-функций, процессов, данных и людей. Достижение цели проверяется деревом метрик – иерархией показателей от стратегической цели компании до операционных показателей конкретного процесса.
5. Процесс проходит внутри одной или нескольких функций и услуг. Запускает процесс событие – изменение состояния внутри или снаружи организации.
6. Выход процесса, который предлагается клиенту, становится продуктом или бизнес-услугой; выход, который переходит дальше внутри компании, остаётся промежуточным результатом или внутренней услугой.
7. Продукт или услуга доставляет потребителю ценность. Сквозная последовательность работ, генерирующая эту ценность, и есть поток создания ценности.

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

Пример: как выглядят эти элементы для типичной компании

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

Основные объекты учёта – клиент, договор, заявка, наряд и акт. Уже при расстановке связей становятся видны две проблемы.

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

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

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

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

Фреймворки между собой взаимозаменяемы и в зависимости от потребностей дополняют друг друга.

Какие бывают модели бизнес-архитектуры (TOGAF, ArchiMate, BIZBOK и др.)

TOGAF, редакция 10 – свод для описания предприятия целиком. Ценен методом: цикл ADM (Architecture Development Method) задаёт последовательность фаз – от видения и деятельности к данным, приложениям и технологиям, дальше к дорожной карте и управлению изменениями, после чего цикл повторяется. Нужен, когда требуется организовать саму работу: определить порядок, охват и правила пересмотра.

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

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

Zachman, версия 3.0 – матрица вопросов «что, как, где, кто, когда, почему» по перспективам участников. Как пошаговый метод почти не применяется, зато помогает проверить полноту описания: чьи вопросы остались без ответа.

Существуют также отраслевые и государственные подходы, например FEAF, DoDAF и MODAF. Для компании среднего размера нет необходимости внедрять крупный фреймворк целиком. Полезнее выбрать из него общий словарь, порядок действий и те представления, которые поддерживают конкретное решение.

Модели архитектуры бизнес-процессов: карты, иерархии и референтные модели

Для описания деятельности используют три основных типа представлений:

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

APQC PCF, версия 8.0 – межотраслевой классификатор американского центра производительности и качества. 13 категорий верхнего уровня и 5 уровней детализации: категория, группа процессов, процесс, активность, задача. Сквозная нумерация позволяет сравнивать показатели с рынком.

eTOM, редакция 26.0 – классификатор деятельности оператора связи, его ведёт ассоциация TM Forum. Входит в свод Open Digital Architecture вместе с информационной моделью и открытыми интерфейсами.

SCOR, версия 12.0 – модель для цепочек поставок от ассоциации ASCM: группы работ верхнего уровня, показатели и практики.

РИТМ – открытая российская модель управления ИТ. С 2022 года её создаёт сообщество itSMF России силами больше сотни экспертов из десятков компаний, уже выпущено 16 процессов, часть в бета-версии. Задача проекта – разработать российскую альтернативу ITIL, обучение и сертификация по которому в России сейчас недоступны.

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

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

Как выбрать глубину и детальность описания под задачи компании

Глубина определяется решением, которое будут принимать на основе описания архитектуры бизнес-процессов. Спускаться ниже стоит, когда на текущем уровне уже понятны цель, устройство и способ управления. Если требуется:

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

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

Архитектура бизнес-процессов предприятия: уровни, карты и примеры

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

Пример. Для сервисной компании уровень 1 помещает направления деятельности (основные, управляющие, обеспечивающие и развитие) на один лист. На уровне 2 одно из основных направлений, подключение клиента, раскладывается на группы процессов – от управления обращениями клиента до выставления счёта. На уровне 3 группа «Обработка заказа» разворачивается в процессы: определение выполнимости заказа, проверка кредитоспособности, оформление заказа, контроль исполнения, завершение и закрытие заказа.

На уровне 2 поток раскладывается на 7 крупных шагов, и у некоторых шагов может не оказаться ответственного: приём обращения, пришедшего мимо единой точки входа, и передача заявки бригаде. На уровне 3 раскрывается конкретный шаг «диагностировать обращение» – участок, где накапливается задержка.

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

Цифровая архитектура бизнеса и архитектура бизнес-систем: как связать бизнес и ИТ

Цифровой слой отвечает на три вопроса.

• Где выполняется работа и что происходит с данными. Для каждого шага фиксируется приложение, в котором он проходит, сведения, которые там создаются, и что доступно только для чтения. Это и есть матрица процессов и систем. Сразу становятся видны шаги, которые не поддержаны ни одной системой, дублирующие друг друга приложения и места, где данные переносят руками: из письма в систему учёта или из таблицы в отчёт.
• Где источник правды по каждому объекту. Для клиента, договора и заявки определяют, в какой системе сущность создаётся и чьи данные считаются достоверными. Всё это фиксируют на уровне конфигурации ИТ-ландшафта. Без этого одна и та же сущность может заводиться повторно в разных местах, а отчёты начинают расходиться между собой.
• Где системы обмениваются данными, а где результат проверяет человек. Это точки интеграции и точки контроля.

Пример. Для заявки первым шагом становится единое правило регистрации и владения объектом: пока источник истины не назначен, отчётность по SLA даёт разные результаты.

За последние два года изменились и инструменты, и требования к самому описанию. Системы, которые восстанавливают фактический ход работы по данным информационных систем, известны как процессная аналитика (process mining). В 2026 году этот класс расширили до процессного интеллекта (process intelligence): от таких систем теперь ждут не только восстановленного маршрута, но и контекста для автоматизации и ИИ-агентов. Похожий сдвиг произошёл с цифровым двойником организации – моделью компании, построенной на реальных данных. Она показывает текущее состояние и позволяет проверить последствия изменения до внедрения – методом имитационного моделирования (DES, дискретно-событийная симуляция). Так устроен DES в Stormbpmn: по BPMN-схеме прогоняют поток заявок и смотрят, где растёт очередь и во что обходится одна заявка. Понятие появилось в 2017 году, а сегодня это уже отдельный рынок инструментов. От описания деятельности ждут пригодности для машинной обработки, а не только наглядности для человека.

Требования тоже стали жёстче. Стандарт систем менеджмента для искусственного интеллекта ISO/IEC 42001 требует определить роли и ответственность на всём жизненном цикле системы, а также контроль результата и человеческий надзор при эксплуатации. Требования к данным, пригодным для работы ИИ, звучат подобным образом: у набора сведений должны быть описание, происхождение и владелец. Набор совпадает с атрибутами, которых процессный подход требовал и раньше. Увидеть связи между работами, данными и приложениями помогает граф реестра.

Вывод: описания всё чаще читают исполнители – ИИ-агенты, которым нужны актуальные и достоверные данные, явные границы и точка контроля.

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

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

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

От цели зависит глубина детализации.

Далее проектирование ведётся на двух уровнях: бизнеса и процессов. Сначала нужно определить ценность для клиента, способности компании и собрать карту верхнего уровня. Затем можно переходить к потокам работ, их владельцам, уровням детализации и связям с приложениями. Такой порядок помогает двигаться от общего к частному: прежде чем разбираться, как устроена работа, важно понять, что именно делает компания и ради какого результата.

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

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

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

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

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

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

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

Описание всей компании вплоть до отдельных операций займёт месяцы и может устареть ещё до завершения проекта.

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

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

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

Правило: у каждой схемы должна быть явная пометка состояния, авторства и возможность откатить правки. В Stormbpmn варианты «как есть» и «как будет» хранятся как две отдельные схемы, а версионирование позволяет контролировать изменения.

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

• Заказчик – собственник или директор, который согласовывает работы, утверждает приоритеты и разрешает споры о границах ответственности между подразделениями.
• Руководитель проекта определяет объём и очерёдность работ, собирает участников на интервью и согласования, следит за сроками.
• Владелец процесса отвечает за сквозной результат, а не за отдельный участок работы.
• Участники процессов – руководители участков и исполнители. Они рассказывают, как работа устроена на самом деле, и они же потом пользуются регламентами.
• Процессный методолог следит за единым подходом к построению потоков, правилами именования и детализации.
• Аналитик проводит интервью, собирает информацию и строит схемы.
• ИТ-архитектор описывает приложения, данные и интеграции.
• Владельцы систем подтверждают, где выполняются действия и хранятся сведения.
• Владельцы данных отвечают за конкретную категорию объектов: определение, источник правды и правила изменения.
• Контролёр соответствия – внутренний контроль, комплаенс или служба качества, в зависимости от того, чьи требования проверяются. Подтверждает, что в описании есть нужные точки контроля, разделены несовместимые полномочия и соблюдены требования регулятора или стандарта.
• Архитектурный совет – коллегиальная роль, согласует решения между доменами – деятельностью, данными, приложениями, технологиями – и утверждает отклонения от принятых правил.

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

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

Архитектура бизнеса компании работает на стыке стратегии, инвестиций и операционного уровня. На её основании могут быть приняты решения по:

• Приоритетам инвестиций. Карта показывает, где проблема влияет на клиента и на деньги. Для сервисной компании первым шагом становится единая точка входа для обращений. Здесь же проверяются сами инициативы: если проект нельзя связать с клиентской ценностью, способностью, потоком и измеримым результатом, его приоритет требует дополнительного обоснования.
• Управлению ИТ-портфелем. Показывает, как системы обеспечивают создание ценности, какие дублируют друг друга, а какие являются пережитком прошлого. Решения о консолидации, продлении лицензий и выводе систем принимаются на основании карты.
• Масштабированию. Способ работы тиражируется: новый регион запускается по общей карте и типовым процессам, показатели становятся сопоставимы.
• Изменению структуры и реорганизации. При покупке или слиянии компании видно, какие способности дублируются и что консолидировать в первую очередь. При выведении направления – что уходит вместе с ним: работы, данные, системы, договоры и люди. Оценка влияния делается до сделки, а не после.

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

Архитектура бизнес-процессов и BPMN-модели: связка архитектуры с детальными схемами

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

Стыковку уровней можно проверить по правилам:

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

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

Итоги и первые шаги: с чего начать работу с бизнес-архитектурой и архитектурой бизнес-процессов

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

Начать можно с короткого чек-листа:

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

Как это выглядит на практике

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

Логистическая компания начинает с вопроса, почему растёт доля доставок с нарушением срока. Продукт – перевозка и хранение груза для торговых сетей, ценность – предсказуемость поставки, направление развития – выйти на доставку день в день. Не хватает способности планировать маршруты с учётом фактической загрузки: план строится на нормативах, а не на том, что происходит на складе и в рейсе сегодня.

На старте стоит избегать нескольких ошибок:

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

Хорошее описание не обязано быть максимально подробным: достаточно, чтобы оно в зависимости от задач компании:

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

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