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

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

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

Еще несколько примеров:

• задержка согласования договора с поставщиком,

• конфликт между отделами при возврате товара,

• запуск нового продукта.

А как же тогда удобно и понятно описать контекст? Для этого из мира разработки ПО пришел метод С4 - инструмент, который позволяет разобрать его по уровням. Ценность модели в том, что она помогает понять взаимоотношения контекста с его окружением, его устройство и функционирование.

Модель описывает контекст, деля его на 4 слоя.

• Сам контекст. Здесь описывается ситуация, ее взаимодействие с окружением, причины, цели. Максимально глобальный уровень, отвечающий на вопросы "Зачем?" и "Для чего?".

• Контейнеры. Здесь описывается набор базовых составных частей.

• Компоненты. Здесь контейнеры раскладываются на составляющие части (для каждого контейнера составляется отдельная карта его компонентов, их взаимосвязей).

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

Модель создал в середине 2000-х годов архитектор Саймон Браун, который искал способ преодолеть сложности классических инструментов вроде UML. Первоначально она задумывалась для описания архитектуры программных систем — чтобы разработчики могли быстро объяснять устройство ПО, не путаясь в бесчисленных деталях. Уровни возникли в ответ на необходимость видеть одновременно и всю картину, и погрузится в уточнения и сам функционал. На одном листе это было бы похожа на гигантскую сверхсистему, не подвластную пониманию.

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

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

Первый уровень - контекст

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

Описание первого уровня отвечает на вопросы:

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

Что именно является предметом нашего внимания? Где проходят его границы? Мы четко очерчиваем, что входит в этот контекст прямо сейчас, а что остается за его пределами. Запуск продукта рассматриваем от идеи до первых продаж. Ситуацию с проблемой по регулярной задержке договоров описываем от получения проекта до подписания. Зти границы помогают не распылять внимание до бесконечности.

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

Пример 1. Выдача кредита.
Контекст - это процесс, в рамках которого кредитная организация рассматривает заявку и принимает решение о выдаче кредита.

С чем он взаимодействует?

• Другие отделы компании заявителя (они влияют своими потребностями)

• Другие отделы банка (они заботятся о репутации банка, о его прибыльности и других факторах)

• Законодательство

• Другие банки (они влияют на ситуацию как конкуренты)

Пример 2. Разработка мобильного приложения для бронирования столиков.
Контекст — создание приложения для поиска ресторанов и бронирования столиков онлайн. Не вся компания-разработчик, и даже не отдел разработки. Именно текущая ситуация - разработка мобильного приложения.

С чем взаимодействует?

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

• Клиент и его требования, условия, технические потребности и возможности

• Инфраструктура компании-разработчика (информационные ресурсы, подписки на сервисы и т.д.)

• Сторонние сервисы

Ссылка на диаграмму

Второй уровень - контейнеры

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

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

Рассмотрим пример 1. Выдача кредита. Внутри ранее заданного контекста можно выделить следующие контейнеры:

• Координационный отдел. Этот блок отвечает за прием заявок и консультации заявителей.

• Экспертная группа. Данный контейнер выполняет оценку представленных проектов.

• Финансовый отдел. Здесь происходит проверка финансовой возможности и подготовка документов.

• Цифровая приёмная. Этот контейнер служит точкой входа для заявок, если используется электронная платформа.

Контейнеры примера 2. Разработка приложения.

• Проект как сущность

• Его участники, включая руководителя проекта

• Само приложение в разработке

Система С4 достаточно гибкая и удобна тем, что позволяет настраивать состав уровней "под себя", т.е. так, как удобно команде и руководителям. Контейнеры не всегда должны совпадать с оргструктурой отделов. Это могут быть и роли, и автоматизированные решения (например, чат-бот, если он несет выделенную функцию). В сущности, это набор объектов, выполняющих определенную конечную работу.

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

Ссылка на диаграмму

Третий уровень - компоненты

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

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

В контейнере «Экспертная группа» из примера 1 можно выделить следующие компоненты:

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

• Оценка по критериям. Эксперт, анализирующий проект по установленной шкале и присваивающий баллы.

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

В контейнере «Само приложение» из примера 2 можно выделить такие компоненты:

• Бриф

• Прототип

• Дизайн

• Верстка

• Программирование (как глобальная задача)

• Проверка качества

• Этапы согласования

Каждый компонент имеет конкретную цель, зону ответственности и результат.

Ссылка на диаграмму

Ценность уровня компонентов

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

2. Выявляет узкие места. Позволяет увидеть, где возникают задержки или накапливаются решения.

3. Задает основу для оптимизации. Конкретизирует точки для улучшений: автоматизацию, перераспределение ролей или доработку регламентов.

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

Четвертый уровень - код

После определения компонентов наступает уровень практической реализации. Здесь мы спускаемся с высот абстракции к конкретным инструментам и действиям. Уровень кода отвечает на вопрос "Какими инструментами выполняется работа?". Отличается от уровня Контейнер максимальной детализированностью, пошаговыми инструкциями, детальным набором сервисов, инструментов и пр.

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

Варианты артефактов уровня кода из примера 1. Выдача кредита
Возьмем компонент "Оценка по критериям":

• Регламент оценки с четкой таблицей баллов,

• Шаблон экспертного заключения,

• Маршрут согласования в системе электронного документооборота.

Варианты артефактов уровня кода из примера 2. Разработка приложения.
Возьмем компонент "Программирование":

• Набор готовых шаблонов для типовых элементов

• Инструменты

• Сервисы

Ссылка на диаграмму

Заключение

Вся мощь модели С4 проявляется в операционном решении сложных ситуаций. Представим, что эксперт сталкивается с неочевидной заявкой. Правила уровня (регламенты и чек-листы) не дают ответа. Тогда сотрудник может:

• Обратиться к уровню компонентов, чтобы уточнить ответственного за спорные случаи,

• Подняться к контейнеру, понимая общую логику работы экспертной группы,

• Вернуться к контексту, сопоставив решение с целями компании.

Из примера 2.

Если на уровне кода возникает проблема (непонятно, как реализовать, например, историю заказов), разработчик может не найти ответа в своих шаблонах, и тогда он:

• Обратится к уровню компонентов, чтобы сверится с брифом или прототипом.

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

• Обратиться к уровню контекста, чтобы уточнить технические возможности сервисов, с которыми нужно будет в будущем интегрироваться.

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