Введение

Аннотация.

Современные цепочки поставок представляют собой сложные сети взаимодействующих организаций, где малейший сбой в одном звене может вызвать каскадные задержки по всей системе. Отсутствие единой визуальной нотации приводит к недопониманию между закупщиками, логистами, складскими службами и IT-специалистами, а также к ошибкам при внедрении ERP, WMS и TMS-систем. BPMN-моделирование решает эту проблему, предоставляя стандартизированный язык описания процессов, понятный как бизнесу, так и разработчикам. Курс особенно актуален в условиях глобальных disruptions, требований к устойчивости и цифровой трансформации логистики, когда прозрачность и возможность быстрого перестроения процессов становятся конкурентным преимуществом. Материал ориентирован на практиков, которые хотят превратить разрозненные описания поставок в исполняемые и анализируемые модели.

Цель курса.

После прохождения курса вы сможете самостоятельно создавать, анализировать и оптимизировать исполняемые BPMN-модели ключевых процессов цепочек поставок — от закупок и управления запасами до транспортировки и выполнения заказов — с использованием нотации BPMN 2.0 и современных инструментов моделирования.

Для кого этот курс.

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

Курс не предназначен для тех, кто ищет исключительно теоретический обзор без практики моделирования, а также для специалистов, уже глубоко владеющих BPMN 2.0 и желающих изучать только узкоспециализированные расширения (например, CMMN или DMN в отрыве от supply chain). Базовое понимание бизнес-процессов желательно, но глубоких знаний BPMN заранее не требуется.

Роль BPMN в управлении цепочками поставок

В цепочках поставок процессы редко ограничиваются одной организацией. Закупка сырья, производство, складирование, транспортировка и доставка клиенту образуют сквозной поток, в котором участвуют поставщики, 3PL-операторы, таможенные брокеры и конечные покупатели. BPMN-моделирование позволяет зафиксировать этот поток в единой нотации, понятной всем участникам. В отличие от текстовых регламентов или flowchart-диаграмм в Visio, BPMN 2.0 обладает строгой семантикой и может быть напрямую исполнен в BPMS-движках. Это критично, когда нужно быстро перестроить процесс после срыва поставок или изменения таможенных правил. Практика показывает, что компании, использующие исполняемые BPMN-модели, сокращают время согласования изменений процессов в 2–3 раза по сравнению с теми, кто опирается только на текстовые описания.

Ключевое преимущество BPMN для supply chain — поддержка коллаборации. С помощью пулов и message flows можно явно показать обмен документами (заказ, ASN, invoice) между организациями без раскрытия внутренней логики каждой из них. Это особенно важно при работе с внешними 3PL и поставщиками, где полная прозрачность внутренних процессов нежелательна. Рекомендуется начинать любое моделирование цепочки поставок с определения границ ответственности участников и только потом детализировать внутренние дорожки.

Стандарт BPMN 2.0, поддерживаемый Object Management Group, стал де-факто языком описания процессов в логистике и производстве. Многие ERP-системы (SAP S/4HANA, Microsoft Dynamics 365, 1C:ERP) и специализированные WMS/TMS позволяют импортировать или экспортировать модели в формате BPMN. Это создаёт возможность использовать одну и ту же диаграмму и как документацию, и как спецификацию для автоматизации. При моделировании цепочек поставок особенно востребованы события-сообщения (message events), таймеры для контроля SLA и компенсирующие транзакции для отмены уже выполненных шагов (например, возврат товара на склад при отказе клиента).

Практический совет: перед началом моделирования всегда фиксируйте цель диаграммы. Если цель — согласование с бизнесом, достаточно descriptive-уровня (основные задачи и шлюзы). Если цель — исполнение в Camunda или Flowable, требуется executable-уровень с точными типами задач, формами данных и условиями на шлюзах. Смешение уровней в одной модели — частая ошибка, приводящая к тому, что диаграмма становится слишком сложной для бизнеса и недостаточно точной для IT.

Связь BPMN с моделью SCOR (Supply Chain Operations Reference) даёт мощный каркас для структурирования процессов. SCOR выделяет пять основных областей: Plan, Source, Make, Deliver, Return. Каждую из них можно представить в виде отдельного пула или группы процессов в BPMN. Например, процесс Source (закупки) обычно содержит задачи «Создать заявку на закупку», «Выбрать поставщика», «Оформить заказ», «Получить подтверждение» и события «Товар получен» или «Поставка просрочена». Используя SCOR как верхний уровень, а BPMN — как детальную нотацию, вы получаете иерархию моделей, удобную для навигации и аудита.

Рекомендуемый порядок работы: сначала построить high-level диаграмму по SCOR-областям с использованием collapsed subprocess, затем раскрыть каждый subprocess в детальную BPMN-диаграмму. Такой подход предотвращает «простыни» на одном листе и позволяет разным командам работать параллельно над своими сегментами цепочки поставок.

Измеримость — ещё одно преимущество BPMN-моделей в supply chain. К задачам и событиям можно привязывать KPI: время цикла заказа, процент on-time delivery, стоимость обработки одной отгрузки. Современные BPMS позволяют собирать эти метрики в runtime и визуализировать их на дашбордах. Без формальной модели сбор метрик превращается в ручной труд или в разрозненные отчёты из разных систем. Поэтому даже если компания пока не готова к полной автоматизации, наличие BPMN-модели уже создаёт основу для data-driven управления цепочками поставок.

Антипаттерн: рисовать процессы «как есть» без указания владельца и метрик. Такая модель быстро устаревает и не используется. Правильный подход — сразу назначать process owner и определять 2–3 ключевых показателя для каждого критического процесса.

Базовые элементы BPMN 2.0 для логистики

Любая BPMN-диаграмма строится из четырёх основных групп элементов: Flow Objects (события, задачи, шлюзы), Connecting Objects (sequence flow, message flow, association), Swimlanes (пулы и дорожки) и Artifacts (data objects, groups, annotations). Для цепочек поставок особенно важны message flow и data objects, потому что основная ценность создаётся именно в обмене информацией и материальными потоками между участниками. Sequence flow используется внутри одного пула (одной организации или одного процесса), а message flow — между пулами.

Практический приём: при моделировании всегда сначала размещайте пулы участников (поставщик, склад, транспортная компания, клиент), затем соединяйте их message flow, и только после этого детализируйте внутренние sequence flow. Это гарантирует, что границы ответственности будут чёткими с самого начала. Инструмент bpmn.io и Camunda Modeler поддерживают автовыравнивание пулов и удобное соединение message flow.

Задачи (Tasks) в BPMN имеют несколько типов, которые напрямую соответствуют операциям в цепочках поставок. User Task — ручная работа сотрудника (например, проверка качества на складе). Service Task — автоматический вызов системы (создание документа в WMS). Send Task и Receive Task — отправка и получение сообщений (отправка ASN, получение confirmation). Business Rule Task — применение правил (выбор перевозчика по матрице тарифов). Script Task — выполнение скрипта (расчёт ETA).

Выбор правильного типа задачи критичен для последующей автоматизации. Если аналитик ставит везде абстрактную Task, разработчику потом приходится догадываться, что именно должно происходить. Рекомендация: уже на этапе descriptive-моделирования указывать тип задачи, даже если детали реализации ещё неизвестны. Это сокращает количество итераций между бизнесом и IT.

События в BPMN делятся на Start, Intermediate и End, а также по типу триггера: None, Message, Timer, Error, Compensation, Conditional, Signal, Escalation, Link, Terminate. В логистике наиболее востребованы Message Events (получение заказа, отправка уведомления), Timer Events (контроль срока доставки, напоминание о просрочке) и Error Events (обработка срыва поставки). Compensation Events позволяют моделировать откат уже выполненных действий — например, отмену резервирования товара на складе при отмене заказа клиентом.

Типичная ошибка — использовать только None Events. Это лишает модель семантики и делает её бесполезной для автоматизации. Правило: каждое событие, которое связано с внешним воздействием или временем, должно иметь соответствующий тип. Для контроля SLA в цепочках поставок Timer Intermediate Event, прикреплённый к задаче или boundary, является стандартным решением.

Шлюзы (Gateways) управляют ветвлением и слиянием потоков. Exclusive Gateway (XOR) — выбор одного пути (например, «товар на складе» или «нужна закупка»). Parallel Gateway (AND) — параллельное выполнение нескольких веток (одновременная подготовка документов и резервирование транспорта). Inclusive Gateway (OR) — выполнение одной или нескольких веток в зависимости от условий. Event-Based Gateway — ожидание одного из нескольких событий (например, подтверждение от поставщика A или B).

В цепочках поставок Parallel Gateway часто используется при параллельной обработке нескольких позиций заказа или при одновременной подготовке отгрузки и уведомлении клиента. Event-Based Gateway незаменим при работе с несколькими альтернативными поставщиками. Антипаттерн — ставить Exclusive Gateway там, где реально нужно параллельное выполнение: это искусственно сериализует процесс и увеличивает lead time.

Data Objects и Data Stores позволяют явно показать, какие документы и данные сопровождают процесс. В supply chain это заказы на закупку (PO), накладные, ASN (Advanced Shipping Notice), CMR, инвойсы, складские ордера. Data Object может быть attached к sequence flow или к задаче. Data Store используется для долгоживущих хранилищ (например, база поставщиков или складской остаток).

Рекомендация: не перегружайте диаграмму всеми возможными документами. Отображайте только те data objects, которые влияют на ход процесса или являются входом/выходом ключевых задач. Для детальной спецификации данных лучше использовать отдельную data model или DMN-таблицы. В Camunda Modeler data objects легко связываются с переменными процесса, что упрощает переход к исполнению.

Пулы, дорожки и границы ответственности

Пул (Pool) в BPMN представляет участника процесса — организацию, подразделение или внешнюю систему. В цепочках поставок типичные пулы: «Отдел закупок», «Склад», «Транспортная компания», «Поставщик», «Клиент», «Таможня». Внутри пула размещаются дорожки (Lanes), соответствующие ролям или системам: «Менеджер по закупкам», «Кладовщик», «WMS», «TMS». Правильное разделение на пулы и дорожки сразу делает видимой матрицу ответственности RACI.

Важное правило: sequence flow не может пересекать границы пула. Взаимодействие между пулами осуществляется только через message flow. Это заставляет явно моделировать все точки обмена информацией и предотвращает «размывание» ответственности. При моделировании end-to-end цепочки поставок рекомендуется начинать с 3–5 основных пулов и уточнять их по мере необходимости.

Black-box пулы используются, когда внутренняя логика участника неизвестна или не должна раскрываться. Например, пул «Поставщик» часто рисуется как black-box: мы видим только входящие и исходящие message flow (отправка заказа, получение подтверждения, получение ASN), но не видим, как поставщик обрабатывает заказ внутри. Это соответствует реальности B2B-взаимодействия и защищает коммерческую тайну.

White-box пулы раскрывают внутренние процессы. Их применяют для собственных подразделений компании. Смешанный подход (часть пулов black-box, часть white-box) является стандартным для моделирования цепочек поставок. В инструментах Camunda Modeler и Signavio можно легко переключать отображение пула между collapsed и expanded состоянием.

Message flow должен иметь понятное имя, отражающее суть сообщения: «Заказ на закупку», «Подтверждение заказа», «ASN», «Уведомление о доставке», «Счёт-фактура». Без имени message flow теряет смысл. Дополнительно можно прикреплять data object, чтобы указать конкретный документ. В исполняемых моделях message flow связывается с correlation keys, чтобы BPMS мог сопоставить входящее сообщение с нужным экземпляром процесса.

Практический совет: составьте словарь сообщений для вашей цепочки поставок и используйте его единообразно во всех диаграммах. Это значительно упрощает интеграцию и обучение новых сотрудников. Антипаттерн — рисовать message flow без имени или с общими названиями вроде «сообщение» или «данные».

При большом количестве участников диаграмма может стать перегруженной. В таких случаях применяют иерархию: верхнеуровневая collaboration-диаграмма показывает только пулы и message flow между ними, а детальные процессы каждого участника выносятся в отдельные process-диаграммы, на которые ссылаются через collapsed subprocess или call activity. Этот приём особенно полезен для глобальных цепочек поставок с десятками поставщиков и логистических операторов.

Call Activity позволяет переиспользовать типовые процессы (например, «Проверка качества» или «Оформление таможенной декларации») в разных местах. Это снижает дублирование и упрощает поддержку моделей. В Camunda и Flowable Call Activity может вызывать как локальный subprocess, так и внешний процесс по ключу.

События в процессах цепочек поставок

Message Start Event используется, когда процесс запускается входящим сообщением. Классический пример в supply chain — получение заказа от клиента или получение заявки на закупку от внутреннего подразделения. Message Intermediate Catch Event ожидает сообщение в середине процесса (например, ожидание подтверждения от поставщика). Message Intermediate Throw Event отправляет сообщение (отправка ASN клиенту).

Для корректной работы в BPMS необходимо настроить correlation: по каким данным система поймёт, к какому экземпляру процесса относится входящее сообщение. Обычно используют номер заказа, номер отгрузки или комбинацию идентификаторов. Без корреляции сообщения будут «теряться» или попадать не в те процессы. Это одна из самых частых причин проблем при внедрении исполняемых моделей цепочек поставок.

Timer Events позволяют контролировать сроки. Timer Start Event может запускать процесс по расписанию (ежедневная проверка остатков). Timer Intermediate Catch Event ставит процесс на паузу до наступления момента времени или истечения длительности (ожидание 48 часов на подтверждение заказа). Boundary Timer Event, прикреплённый к задаче, срабатывает, если задача не завершена в срок, и может инициировать эскалацию или альтернативный путь.

В логистике Boundary Timer Event — основной инструмент контроля SLA. Пример: задача «Доставка клиенту» имеет boundary timer на 24 часа; при срабатывании запускается subprocess уведомления менеджера и поиска альтернативного перевозчика. Важно правильно выбирать тип таймера: Date — конкретная дата, Duration — относительное время, Cycle — повторяющийся интервал. Ошибка в типе приводит к некорректному поведению в runtime.

Error Events моделируют обработку исключительных ситуаций. Error Intermediate Throw Event генерирует ошибку, Error Boundary Event её перехватывает. В цепочках поставок типичные ошибки: «Товар отсутствует на складе», «Поставщик отклонил заказ», «Таможенный отказ», «Повреждение груза». Вместо того чтобы размазывать обработку ошибок по всему процессу через шлюзы, Error Events позволяют централизованно описать реакцию на исключения.

Compensation Events используются для отката. Если после резервирования товара на складе заказ отменяется, Compensation Handler возвращает товар в доступный остаток. Compensation особенно важен в длительных процессах с несколькими участниками, где простой «отмены» недостаточно — нужно явно восстановить предыдущее состояние ресурсов.

Signal Events предназначены для широковещательных уведомлений внутри одной организации. В отличие от Message, Signal не имеет конкретного адресата. Пример: сигнал «Склад переполнен» может быть пойман несколькими процессами, которые должны приостановить приёмку или ускорить отгрузки. Conditional Events срабатывают при изменении данных (например, остаток товара упал ниже safety stock).

Рекомендация по выбору: Message — когда есть конкретный отправитель и получатель; Signal — когда нужно оповестить несколько процессов внутри компании; Conditional — когда реакция должна зависеть от состояния данных, а не от явного сообщения. Неправильный выбор типа события — частая причина избыточной сложности моделей.

Шлюзы и маршрутизация в логистических процессах

Exclusive Gateway (XOR) — самый распространённый шлюз. Он направляет поток по одному из исходящих путей в зависимости от условия. В цепочках поставок примеры: «Товар есть на складе?» → да / нет; «Поставщик подтвердил заказ?» → да / нет / таймаут; «Тип доставки?» → стандарт / экспресс / самовывоз. Условия на исходящих sequence flow должны быть взаимоисключающими и покрывать все возможные случаи (иначе процесс «застрянет»).

Хорошая практика — всегда добавлять default flow на Exclusive Gateway. Это путь, который выбирается, если ни одно условие не сработало. Без default flow при неожиданных данных процесс останавливается с ошибкой. В Camunda Modeler default flow отмечается специальной меткой на sequence flow.

Parallel Gateway (AND) разветвляет поток на несколько параллельных веток, которые выполняются одновременно, и затем синхронизирует их. В логистике это используется, когда после получения заказа нужно параллельно: зарезервировать товар на складе, создать транспортную заявку и подготовить сопроводительные документы. Синхронизирующий Parallel Gateway ждёт завершения всех входящих веток перед продолжением.

Важно помнить: если одна из параллельных веток «зависает», весь процесс останавливается на join-шлюзе. Поэтому критические параллельные ветки часто снабжают Boundary Timer Events для принудительного завершения или эскалации. Антипаттерн — использовать Parallel Gateway там, где ветки зависят друг от друга по данным; в таких случаях лучше применять последовательное выполнение или Inclusive Gateway.

Inclusive Gateway (OR) позволяет активировать одну или несколько исходящих веток в зависимости от условий. В отличие от Exclusive, несколько условий могут быть истинными одновременно. Пример: при обработке заказа с несколькими позициями часть позиций может идти со склада, часть — через закупку, часть — через cross-docking. Inclusive Gateway на входе активирует нужные ветки, а на выходе ждёт завершения всех активированных.

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

Event-Based Gateway не оценивает данные, а ожидает наступления одного из нескольких событий. Классический сценарий в цепочках поставок: после отправки запроса нескольким поставщикам процесс ждёт либо подтверждения от поставщика A, либо подтверждения от поставщика B, либо таймера «никто не ответил». Первое наступившее событие определяет дальнейший путь, остальные ожидания отменяются.

Event-Based Gateway идеально подходит для ситуаций конкуренции и таймаутов. Он часто используется вместе с Message Catch Events и Timer Catch Events. В исполняемых моделях это один из самых мощных элементов для реализации resilient-процессов, способных корректно обрабатывать неопределённость внешних участников.

Моделирование процесса закупок

Процесс закупок (Source в терминологии SCOR) — один из самых критичных в цепочках поставок. Типовая BPMN-модель включает: Start Event «Потребность выявлена» (может быть message от MRP-системы или timer), User Task «Создать заявку на закупку», Service Task «Проверить остатки и open PO», Exclusive Gateway «Нужна новая закупка?», затем ветку выбора поставщика, отправки RFQ или PO, ожидания подтверждения и получения товара.

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

Выбор поставщика часто реализуется через Business Rule Task или вызов DMN-таблицы. Критерии: цена, срок поставки, рейтинг поставщика, наличие сертификатов, текущая загрузка. В BPMN это выглядит как Service Task «Определить поставщика» с последующим Exclusive Gateway по результату. Если используется конкурентный запрос (RFQ нескольким поставщикам), применяется Event-Based Gateway для ожидания ответов.

Практика: храните матрицу выбора поставщиков в отдельной DMN-модели, а не «зашивайте» условия в шлюзы. Это позволяет бизнес-пользователям менять правила без изменения процессной диаграммы. Camunda, Flowable и Signavio поддерживают тесную интеграцию BPMN + DMN.

Контроль исполнения заказа на закупку требует комбинации Message и Timer Events. После отправки PO процесс переходит в состояние ожидания: Message Catch «Подтверждение получено» или Boundary Timer «Срок подтверждения истёк». При таймауте запускается эскалация (уведомление менеджера, поиск альтернативного поставщика). Аналогично моделируется ожидание ASN и фактической поставки.

Для многопозиционных заказов часто используют multi-instance subprocess: каждая позиция обрабатывается параллельно или последовательно. Это позволяет отслеживать статус по каждой номенклатуре отдельно и не блокировать весь заказ из-за одной позиции. В Camunda multi-instance настраивается через свойства активности (sequential / parallel, collection, element variable).

Завершение процесса закупок должно фиксировать факт оприходования товара и обновление складских остатков. End Event «Товар оприходован» часто сопровождается Signal Event для уведомления процессов планирования и производства. Если при приёмке обнаружены расхождения, процесс уходит в subprocess «Обработка расхождений» с возможной претензионной работой.

Антипаттерн: завершать процесс закупок в момент отправки PO. Это создаёт «слепую зону» до момента фактической поставки. Правильная модель охватывает весь цикл от потребности до оприходования и закрытия обязательств.

Моделирование складских операций и управления запасами

Складские процессы в BPMN обычно включают приёмку, размещение (put-away), хранение, комплектацию (picking), упаковку и отгрузку. Каждый из этих этапов может быть отдельным subprocess. Start Event приёмки — Message «ASN получено» или «Транспорт прибыл». Далее идут задачи проверки документов, разгрузки, количественной и качественной приёмки, решения о размещении.

Важный элемент — Data Store «Складские остатки». Задачи резервирования и списания должны явно работать с этим хранилищем. В исполняемых моделях это реализуется через Service Task, вызывающие API WMS. Boundary Error Event на задачах приёмки позволяет обрабатывать ситуации «товар повреждён» или «количество не соответствует».

Управление запасами (Inventory Management) часто моделируется как отдельный процесс, запускаемый по Timer (ежедневный/еженедельный расчёт) или по Conditional Event (остаток ниже точки заказа). Процесс рассчитывает потребность, формирует заявки на пополнение и передаёт их в процесс закупок через Message Flow. Использование Conditional Start Event позволяет реагировать на изменение остатков в реальном времени, а не ждать планового запуска.

Для safety stock и reorder point рекомендуется выносить расчёт в DMN или внешний сервис, а в BPMN оставлять только оркестрацию. Это сохраняет процессную модель читаемой и позволяет менять алгоритмы расчёта независимо.

Комплектация заказа (picking) — классический кандидат на multi-instance. Если заказ содержит несколько позиций, каждая позиция может комплектоваться параллельно разными сборщиками или последовательно одним. Parallel multi-instance ускоряет процесс, но требует синхронизации в конце (проверка комплектности). Sequential проще в управлении ресурсами.

В моделях часто добавляют User Task «Подтвердить комплектацию» с формой, где сборщик сканирует штрих-коды. Service Task «Обновить статус в WMS» фиксирует факт. Boundary Timer контролирует соблюдение нормативов времени на комплектацию. При превышении — эскалация бригадиру.

Кросс-докинг моделируется как упрощённый складской процесс без размещения на хранение. Товар принимается и сразу направляется в зону отгрузки. В BPMN это выглядит как короткий subprocess с минимальным количеством задач и обязательной проверкой соответствия входящего и исходящего потоков. Ошибка в кросс-докинге дорого стоит, поэтому Error Events и проверки данных здесь особенно важны.

Рекомендация: создайте отдельную библиотеку типовых складских subprocess (приёмка, put-away, picking, packing, shipping) и переиспользуйте их через Call Activity. Это обеспечивает единообразие и упрощает обучение персонала.

Моделирование транспортировки и доставки

Процесс транспортировки начинается с потребности в перевозке (Message от склада или планирования) и включает выбор перевозчика, создание транспортной заявки, отслеживание рейса и подтверждение доставки. Выбор перевозчика может быть простым Exclusive Gateway (свой транспорт / 3PL) или сложным Business Rule Task с учётом тарифов, сроков, типа груза и доступности.

Отслеживание рейса моделируется через цикл с Message Catch Events «Статус обновлён» и Timer для контроля отклонений от ETA. При значительном отклонении срабатывает Boundary Timer и запускается процесс уведомления клиента и поиска альтернатив. Современные TMS позволяют получать статусы через API, поэтому Service Task «Запросить статус» + Timer образуют типичный polling-паттерн.

Мультимодальные перевозки (море + авто, ж/д + авто) требуют моделирования нескольких последовательных или параллельных транспортных плеч. Каждое плечо — отдельный subprocess с собственными событиями прибытия/убытия. Между плечами — задачи перевалки и обновления документов. Parallel Gateway может использоваться, если часть груза идёт разными маршрутами.

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

Подтверждение доставки (Proof of Delivery) — ключевой End Event транспортного процесса. Оно инициирует закрытие обязательств, выставление счетов и обновление KPI. Message Start Event «POD получен» может запускать последующие финансовые процессы. В B2B-сценариях POD часто приходит как электронный документ (EDIFACT, XML, API), поэтому Service Task «Обработать POD» является стандартным элементом.

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

Управление возвратами (Return в SCOR) — зеркальный процесс к доставке. Start Event — Message «Запрос на возврат» от клиента или «Обнаружен брак». Далее — проверка оснований, организация обратной транспортировки, приёмка на складе, решение о восстановлении/списании/возврате поставщику. Compensation Events здесь особенно полезны: они позволяют «откатить» финансовые и складские проводки основного процесса продажи.

Рекомендуется моделировать возвраты как отдельный процесс, а не как ветку основного order fulfillment. Это упрощает анализ и позволяет иметь разные SLA и ответственных.

Моделирование выполнения заказов клиентов

Order Fulfillment — сквозной процесс от получения заказа клиента до подтверждения доставки и закрытия. Типовая структура: Message Start «Заказ получен» → проверка кредитного лимита и доступности → резервирование → комплектация → отгрузка → транспортировка → POD → End. На каждом этапе возможны отклонения, которые моделируются через Exclusive Gateway и Error Events.

Важный паттерн — «доступность и резервирование». Service Task «Проверить ATP (Available-to-Promise)» обращается к системе планирования. При нехватке товара процесс может уйти в ветку «Предложить альтернативу» или «Создать backorder». Backorder сам по себе может быть отдельным процессом, ожидающим поступления товара.

Для сложных заказов (проектные поставки, сборные грузы) используется иерархия subprocess. Верхний уровень показывает основные этапы, нижние уровни детализируют комплектацию, упаковку, документы. Call Activity позволяет вызывать стандартизированные процедуры (например, «Сформировать пакет документов для экспорта»).

В B2C-сценариях с большим объёмом заказов критична производительность модели. Избегайте избыточных User Task и синхронных вызовов внешних систем внутри горячего пути. Используйте асинхронные Service Task и message-driven взаимодействие, где это возможно.

Уведомления клиента — неотъемлемая часть современного order fulfillment. Message Throw Events «Заказ подтверждён», «Заказ собран», «Заказ передан в доставку», «Заказ доставлен» отправляются в CRM или notification-сервис. В BPMN это моделируется явно, что позволяет контролировать, какие уведомления уходят и при каких условиях.

Рекомендация: вынесите логику уведомлений в отдельный subprocess или даже в отдельный процесс, вызываемый по Signal или Message. Это упрощает изменение каналов коммуникации (email, SMS, push, мессенджеры) без правки основного fulfillment-процесса.