Один процесс — несколько BPMN-схем внутри 1С

Один процесс — несколько BPMN-схем: когда это действительно нужно

В процессном моделировании часто используется простая логика: один процесс — одна BPMN-схема. Для небольшого процесса этого обычно достаточно.

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

Попытка собрать всё на одной диаграмме постепенно делает её перегруженной. Если же создавать отдельный файл под каждую задачу, появляется другая проблема: схемы начинают жить независимо друг от друга. Возникают файлы вроде Заказ_финал.bpmn, Заказ_для_ИТ.bpmn и Заказ_финал_2.bpmn, а определить актуальный вариант становится сложно.

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

Три подхода к описанию одного процесса

Одна универсальная схема

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

Несколько независимых файлов

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

Один процесс и несколько связанных схем

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

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

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

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

Практический пример: выполнение заказа клиента

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

1. Предварительная схема

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

Предварительная схема помогает уточнить фактический порядок работы.

2. Основная схема

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

Основная схема

3. Расширенная схема для ИТ

Раскрывает то, что скрыто за крупными этапами основной схемы: документы и справочники 1С, другие системы, источники данных, ручной перенос и проверки.

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

Техническая детализация остаётся связанной с тем же процессом

4. Схема будущих улучшений

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

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

Как поддерживать несколько схем одного процесса

У процесса нужна одна основная схема — понятная точка входа, а не обязательно самая подробная диаграмма. Названия остальных должны объяснять их назначение: «предварительная», «для ИТ», «будущие улучшения».

Важно различать представления и редакции. Основная и техническая схемы решают разные задачи. Схема «до правки» и «после правки» — две редакции одного представления; их лучше вести через контроль изменений.

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

Как подход реализован в Схемопоинте

Для практической проверки этого подхода в Схемопоинте процесс и BPMN-схема рассматриваются как отдельные сущности.

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

К процессу можно отнести основную и дополнительные BPMN-схемы. Это позволяет сохранить несколько представлений одного процесса внутри 1С и открывать нужную схему в зависимости от задачи.

BPMN-элементы, связи с объектами 1С и используемыми ИТ-системами относятся к конкретной схеме. Поэтому техническая детализация дополнительного представления не смешивается с элементами основной схемы.

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

Вывод

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

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