Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 5
Спасибо за статью, Юрий.
Вы правы, схемы должны решать конкретные задачи и мысль о том, что «Система - полноценный участник процесса», абсолютно верная.
Однако также нужно всегда помнить то том, что схемы должны быть понятными целевой аудитории.
Позволю себе добавить несколько ремарок с точки зрения работы со стандартами, не в порядке критики, а как повод для дискуссии.
BPMN уже содержит многое из того, что вы описываете.
Выделение «Системы» в отдельную дорожку - штатный механизм. Пулы и дорожки как раз предназначены для разделения ответственности между ролями, системами и подразделениями. Отправка сообщений между ними моделируется стандартными элементами (Message Flow), без необходимости вводить авторские «якоря».Визуальный стиль - не семантика.
Красить дорожки, менять толщину линий, добавлять иконки или подписи - можно и нужно, если это улучшает читаемость. Но важно, чтобы смысл элементов оставался в рамках спецификации. Иначе схема перестаёт быть языком и становится авторской иллюстрацией, которая требует отдельной легенды и пояснений, устных или письменных.Адаптация может привести к непониманию.
Когда мы отступаем от стандарта осознанно и всей командой – это нормально. Мне на практике доводилось встречать минимум 3 кастомных версии BPMN.
Но каждое такое отступление крайне желательно документировать, а дальше строго соблюдать, иначе через полгода-год даже автор схемы не вспомнит, чем «указание Системы» отличается от обычного потока управления. А недавно нанятый сотрудник - тем более, ему придётся проводить отдельный мини-курс по правилам чтения документов.
Если команда регулярно решает одну и ту же задачу (например, документирует работу 1С в различных процессах), можно оформить набор допустимых расширений как внутренний профиль BPMN: зафиксировать цвета, шаблоны, правила. Можно даже частично «экспортировать» профиль из других нотаций, например из архимейта:
«Бизнес» - желтый
«Апликуха» - голубой
«Системы» - зеленый
Это сохранит преимущества стандарта, но даст гибкость.
До своей команды я обычно доношу это так: «Если нотация не подходит под задачу - не используй её. Если используешь - не ломай семантику». Иначе каждая схема требует собственной легенды, и смысл использования стандарта теряется. Это становится «простой блочной схемой, которую начертили в Bizagi»
Ещё раз спасибо за материал. Такие статьи полезны тем, что можно немного подискутировать на тему «как балансировать между строгостью стандарта и практической пользой».
P.S.
В качестве наглядной иллюстрации тезиса про адаптацию, я перевёл ключевую фразу этого комментария на болгарский:
«Нотацията е език за общуване... Адаптацията на езика... може да доведе до пълно неразбиране»
Для НЕ носителя языка текст выглядит почти как русский за счёт 100% совпадения алфавита и частичного совпадения словаря, но смысл считывается с трудом.
Это пример предельной «адаптации» - другой язык в рамках одного алфавита. Работает так же, как кастомизация нотации: вроде бы «всё те же квадратики, кружочки и стрелочки», но без знания легенды нет уверенности в понимании. А если легенда у каждого своя, то начинаются чудеса.
Во-первых, Андрей, большое спасибо за такой развернутый и содержательный комментарий.
По поводу стандартов полностью согласен: BPMN действительно содержит все необходимые механизмы для моделирования взаимодействия систем, ролей и подразделений.
Вопрос в другом: знает ли их тот, кто будет читать схему? Уровень подготовки у людей в части BPMN сильно различается. Я, например, далеко не всё помню 🙂.
Отсюда и мой подход: рисовать так, чтобы схему мог прочитать человек, вообще не знакомый с BPMN.
Это достигается за счет следующего:
минимальный набор элементов;
отсутствие избыточной детализации в одной схеме;
усиление наглядности за счет визуала и точных формулировок.
В этом случае соглашение об используемых элементах и обозначениях сводится к нескольким предложениям. Такое пояснение можно прикладывать к каждой схеме — и этого, как правило, достаточно для ее понимания.
А еще у меня просьба: если у вас есть примеры схем, где хорошо показано участие системы в рамках стандартного BPMN — буду очень благодарен за ссылки или скриншоты. Всегда интересно посмотреть, как это решают другие.
Юрий, давайте сразу оговорюсь, что BPMN я для таких задач не использую.
То есть "готовых под рукой" диаграмм такого плана у меня нет
Если мне нужно отразить слои бизнес-логики и приложения, я использую archimate или в ряде случаев UML Sequence.
Ок. Перевербовывать Вас не буду, просто покажу как я бы решал конкретно Вашу задачу.
Итак, у меня входные условия:
1. Создать диаграмму happy path end-to-end процесса
2. Аудитория: от CEO-1 до тимлидов разработки отдельных модулей корпоративной системы.
3. Диаграмма должна включать в себя бизнес-уровень (действия пользователей) и уровень приложения (действия системы). Системный уровень (базы, протоколы API etc) - исключить.
4. Диаграмма должна быть создана в BPMN-инструменте.
5. Диаграмма может нарушать "библейские" нормы BPMN в части стиля оформления если это необходимо для повышения читаемости.
6. Допускается дополнить диаграмму стилевыми приёмами, не нарушающими нотацию BPMN, если это необходимо для повышения читаемости
7. Диаграмма не должна содержать элементов, требующих знания нотации BPMN для свободного чтения (редких модификаторов, краевых событий)
8. Диаграмма не должна явно нарушать семантику нотации BPMN чтобы не вводить в ступор людей, знающих нотацию.
Сразу оговорюсь, что господа Белайчук или Репин разумеется закидают меня тряпками вот за этот шедевр, но ... Вашу задачу я вроде бы выполнил
Самопроверка в QWEN 3.6
Промпт
#Твоя роль Опытный фулстек аналитик (бизнес + системный). Розница. РФ. #Входные данные XML диаграммы BPMN Camunda, содержащий описание happy path end-to-end процесса заказа в интернет-магазине с курьерской доставки. #Точка зрения CEO-1 торговой сети #Задача. Разработать драфт документа Концепта по данной диаграмме. Включить разделы: Глоссарий. Бизнес-требования Функциональные требования #Важное условие обработки Использовать только материал диаграммы. Не включать собственных знаний и не предлагать решений по данному процессу
Генерация документа по схеме через LLM
ДРАФТ КОНЦЕПТА
Сквозной процесс оформления заказа в интернет-магазине с курьерской доставкой
1. Глоссарий
Термин
Определение (согласно диаграмме)
Покупатель
Инициатор процесса, взаимодействующий с Интернет-магазином и получающий товар, уведомления и чеки.
Торговая сеть «N»
Владелец процесса. Включает подсистемы и роли: Интернет-магазин, ERP-система, WMS система, Кладовщик, Бухгалтер, 1С Бухгалтерия.
Интернет-магазин
Фронтальная система взаимодействия с Покупателем: каталог, корзина, оформление, оплата, уведомления, формирование чеков.
ERP-система
Ядро управления заказом: проверка остатков, резервирование, распределение на сборку/доставку, управление статусами, фиксация выбытия, передача данных в бухгалтерию.
WMS система
Система управления складом: создание заданий на сборку, формирование документов на передачу, закрытие отгрузки.
Кладовщик
Роль, выполняющая физическую сборку, проверку QR-кода курьера, подписание документов и передачу заказа.
Служба доставки
Внешний/внутренний логистический участник. Включает роли: Курьер и ПО Курьера.
ПО Курьера
Прикладная система курьера: отображение заказа, генерация QR-кода на отгрузку, закрытие доставки.
Курьер
Роль, выполняющая транспортировку и передачу заказа Покупателю.
Банк
Финансовый участник: прием платежа, обработка финансовой сверки.
ОФД
Оператор фискальных данных: получение и обработка кассовых чеков (аванса и полного расчета).
Чек аванса / Чек полного расчета
Фискальные документы, формируемые на этапах подтверждения оплаты и подтверждения доставки соответственно.
2. Бизнес-требования (видение CEO-1)
Сквозная прослеживаемость заказа. Процесс должен обеспечивать автоматическую фиксацию и передачу данных о заказе на всех этапах: от оформления в Интернет-магазине до закрытия финансовых операций в 1С Бухгалтерии.
Контроль товарных остатков до подтверждения заказа. Покупатель должен видеть актуальные остатки и сроки доставки до момента выбора способа оплаты. Резервирование товара должно происходить строго после подтверждения оплаты Банком.
Соблюдение фискальных процедур. На этапе подтверждения оплаты формируется и передается чек аванса. На этапе подтверждения доставки формируется и передается чек полного расчета. Оба чека направляются Покупателю и в ОФД.
Управление статусами и информирование клиента. Покупатель должен получать уведомления о ключевых вехах: «Заказ собран», «Заказ у курьера». Статусная модель должна синхронизироваться между ERP, WMS и службой доставки.
Минимизация ручных операций на стыках участников. Передача заказа между Интернет-магазином, ERP, WMS, Кладовщиком и Курьером должна выполняться системно. Взаимодействие Кладовщика и Курьера контролируется через проверку QR-кода и автоматическое формирование передаточных документов.
Финансовая дисциплина и закрытие цикла. Процесс должен завершаться только после: фиксации доставки, формирования чека полного расчета, проведения выручки, запуска сверки с Банком по эквайрингу и оплаты услуг Службы доставки. Заказ закрывается в учетной системе после завершения всех указанных операций.
3. Функциональные требования
Требования сформулированы строго по узлам и потокам BPMN-модели, сгруппированы по участникам.
3.1. Интернет-магазин
Отображать каталог и корзину, принимать от Покупателя выбор товаров и переход к оформлению.
Запрашивать у ERP-системы актуальные остатки и сроки доставки, отображать варианты доставки и оплаты.
Передавать платежные данные в Банк, получать подтверждение и переводить заказ в статус «Подтвержден».
Параллельно после подтверждения:
Формировать чек аванса, отправлять его Покупателю и в ОФД.
Сохранять заказ и передавать данные в ERP для запуска сборки.
После получения сигнала от ERP менять статус заказа на «Собран» и отправлять уведомление Покупателю.
После получения сигнала от ERP менять статус заказа на «Отгружен» и отправлять уведомление Покупателю «Заказ у курьера».
После получения сигнала о доставке формировать чек полного расчета, отправлять его Покупателю и в ОФД.
Закрывать заказ в системе после формирования чека полного расчета.
3.2. ERP-система
Обрабатывать запросы от Интернет-магазина по остаткам и срокам доставки, возвращать маршруты и цены.
Параллельно с формированием чека аванса резервировать товар под заказ.
Распределять подтвержденный заказ на склад для сборки.
Получать сигнал о закрытии сборки из WMS, параллельно:
Менять статус на «Собран» (сигнал в Интернет-магазин).
Распределять заказ в Службу доставки.
После получения сигнала о закрытии отгрузки параллельно:
Менять статус на «Отгружен» (сигнал в Интернет-магазин).
Перемещать товар в статус «в путь».
Фиксировать доставку по сигналу от ПО Курьера.
Менять статус на «Доставлен», инициировать формирование чека полного расчета.
Параллельно после доставки:
Передавать данные в 1С Бухгалтерию для проведения выручки и закрытия заказа.
Фиксировать выбытие товара при продаже.
Получать данные о результатах сверки по эквайрингу от Банка.
3.3. WMS система
Создавать задание на сборку на основе данных из ERP.
Получать сигнал о закрытии сборки от Кладовщика, закрывать сборку и передавать сигнал в ERP.
После проверки QR-кода Кладовщиком формировать документы на передачу заказа.
Получать сигнал о подписании и передаче заказа от Кладовщика, закрывать отгрузку и передавать сигнал в ERP.
3.4. Кладовщик
Получать задание на сборку.
Выполнять физическую сборку и закрывать сборку в системе.
Получать заказ от Курьера, сканировать/проверять QR-код для поиска заказа.
Подписывать документы на передачу и физически передавать заказ Курьеру.
3.5. Служба доставки (ПО Курьера / Курьер)
Отображать новый заказ, отражать его в Торговой сети «N».
Показывать QR-код на отгрузку Кладовщику.
Получать заказ, доставлять и передавать его Покупателю.
Закрывать доставку в системе после передачи заказа.
3.6. 1С Бухгалтерия / Бухгалтер
Проводить выручку после фиксации выбытия товара.
Запускать сверку с Банком.
Обрабатывать результаты сверки по эквайрингу.
Закрывать заказ в учетной системе.
Выполнять оплату услуг Службы доставки.
3.7. Внешние участники (Банк, ОФД)
Банк: принимать платеж от Интернет-магазина, обрабатывать финансовую сверку от 1С Бухгалтерии.
ОФД: обрабатывать кассовый чек аванса, обрабатывать кассовый чек полного расчета.
Огромное спасибо за такой подробный ответ и схему - изучил, очень круто.
Не очень круто :)))
Я тут немного наколхозил для возможности продолжения беседы :)))
Эта схема неплохо подошла бы для какой-нибудь презентации на KickOff, в которой нужно отразить овервью сквозного процесса и рассказать большой аудитории "как это должно работать"
1. Она выполнена на базовых знакомых всем артефактах. Пул, дорожка, прямоугольник (задача), ромб (решение), круг (начало/конец) — это универсальный язык, понятный даже без знания BPMN
2. Она содержит все ключевые точки end-to-end этого процесса. Ничего существенного не пропущено.
Однако...
Я не рекомендую Вам использовать эту схему в качестве мануала по BPMN, потому что это неправильный BPMN :)))
Ошибки, абсолютно критичные с точки зрения исполняемого BPMN:
1. Техническая.
Message Flow, направленные напрямую на пустой Task. Так нельзя. Message Flow может приходить либо на границу другого пула, либо на message event или receive task.
2. Смысловая.
Сквозной процесс собран из пяти по факту независимых:
- выбор товаров и оплата
- резерв и распределение на сборку
- сборка и вызов логистов
- отгрузка и доставка
- учёт и отчётность
В исполняемом BPMN токен пройдёт про процессу ровно 1 раз. По факту же бухгалтер запускает сверку не по каждому заказу, а раз в месяц по всем.
3. Разметка развилок.
"Повисшие" ветки на параллельных гейтах. Токены, ушедшие с гейта, должны или вернуться на гейт "И", или убиться на end event. Это я уже не специально так сделал, накидал схему и выложил без проверки.
Какую мысль пытаюсь донести:
1. Повторю, что Вы абсолютно правы в том, что действия Системы могут и должны быть отражены на диаграммах. BPMN. EPC и много чего ещё Вам в помощь
2. Добавление стилей на схему также допустимо, но оно должно помогать, а не мешать. Тут очень сложно поймать грань
2. Будьте аккуратны с "адаптацией" стандартов. Это палка о двух концах. Да, в моменте Вы повышаете читаемость. В долгую - закладываете своеобразный технический долг в документацию. Когда вы добавляете маленькую неточность (например, стрелку сообщения в пустую задачу), 99.99% людей не заметят проблему и запомнят неправильный паттерн. А потом начертят такой же в реальном проекте, где BPMN - исполняемый, и разработка встанет.
Резюмируя.
Чистейшее IMHO
Если собираетесь "адаптировать" конкретно BPMN определите для себя границу допустимых изменений исполняемостью модели. Если она потеряна - лучше открыть DrawIO и начертить простую блочную.
:))) Выдохнул, ушел на выходные.
Удачи Вам :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как рисовать для 1С бизнес-процессы, не забывая их главного участника