Есть один любопытный нюанс, который не осветил автор.
Написать в одиночку с нуля конфигу для связи внутреннего учета с весовой платформой (если я правильно понял суть разработки) - задача в общем не рокет сайенс, но и не на день-два.
Юристы компании не заявляли встречных претензий на тему того, что человек в рабочее время занимался задачей, которую никто не ставил, но результат которой теперь пытается продать?
Если брать это решение за прецедент, следующему истцу по похожей теме могут и задать этот вопрос.
Если я правильно прочитал, в момент разработки и установки конфиги автор был уже не разработчиком, а начальником ОИТ и на эту должность не было ДИ, даже типовой.
Яндекс в прошлом году запустил возвраты через курьеров Лавки
Доставистовские курьеры так еще лет 5 назад, если не больше, таскали возвраты.
У СДЭКа вроде бы и сейчас есть вывоз курьером с адреса
Правда, мало кому из ритейла это нужно как сервис.
Ключевая сложность возврата "от дверей" – это попасть к дверям. Сложно сейчас найти МКД со свободным доступом в подъезд. А значит курьера нужно заказать на четкое время (это дороже), или ждать сидя дома.
А из СНТ, ИЖС и прочих поселений возврат выйдет дороже доставки, ибо поездка почти гарантированно будет 1 - 1, а не N - N. Просто нет такого количества одновременных возвратов.
Ну и про ПВЗ маркетплейсов выше написали. Они сейчас в шаговой доступности просто везде
Да, бывало, на пресейл приезжают старые знакомые, с которыми уже не раз пересекался на проектах "не только здесь", обсуждается общий концепт, играется тендер, и выходит наполовину другая команда.
Бывали и замены "на ходу", особенно если сроки уезжали сильно вправо
Причин масса на самом деле и каждый случай по-своему особый
Да, приходилось, и нередко, включать в договора конкретных исполнителей и следить за этим
Точно помню, что мы начали менять кассовые аппараты на базе Fujitsu на 486х процессорах в 2006-м году. И не сильно торопились. По тем временам их за глаза хватало. Просто поднадоели матричные принтеры.
Вероятно, есть ещё немало таких же "ниш", в которых просто не нужно больше
Не очень круто :))) Я тут немного наколхозил для возможности продолжения беседы :)))
Эта схема неплохо подошла бы для какой-нибудь презентации на 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 и начертить простую блочную.
Юрий, давайте сразу оговорюсь, что 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С Бухгалтерии.
ОФД: обрабатывать кассовый чек аванса, обрабатывать кассовый чек полного расчета.
Вы правы, схемы должны решать конкретные задачи и мысль о том, что «Система - полноценный участник процесса», абсолютно верная. Однако также нужно всегда помнить то том, что схемы должны быть понятными целевой аудитории.
Позволю себе добавить несколько ремарок с точки зрения работы со стандартами, не в порядке критики, а как повод для дискуссии.
BPMN уже содержит многое из того, что вы описываете. Выделение «Системы» в отдельную дорожку - штатный механизм. Пулы и дорожки как раз предназначены для разделения ответственности между ролями, системами и подразделениями. Отправка сообщений между ними моделируется стандартными элементами (Message Flow), без необходимости вводить авторские «якоря».
Визуальный стиль - не семантика. Красить дорожки, менять толщину линий, добавлять иконки или подписи - можно и нужно, если это улучшает читаемость. Но важно, чтобы смысл элементов оставался в рамках спецификации. Иначе схема перестаёт быть языком и становится авторской иллюстрацией, которая требует отдельной легенды и пояснений, устных или письменных.
Адаптация может привести к непониманию. Когда мы отступаем от стандарта осознанно и всей командой – это нормально. Мне на практике доводилось встречать минимум 3 кастомных версии BPMN. Но каждое такое отступление крайне желательно документировать, а дальше строго соблюдать, иначе через полгода-год даже автор схемы не вспомнит, чем «указание Системы» отличается от обычного потока управления. А недавно нанятый сотрудник - тем более, ему придётся проводить отдельный мини-курс по правилам чтения документов. Если команда регулярно решает одну и ту же задачу (например, документирует работу 1С в различных процессах), можно оформить набор допустимых расширений как внутренний профиль BPMN: зафиксировать цвета, шаблоны, правила. Можно даже частично «экспортировать» профиль из других нотаций, например из архимейта: «Бизнес» - желтый «Апликуха» - голубой «Системы» - зеленый Это сохранит преимущества стандарта, но даст гибкость.
До своей команды я обычно доношу это так: «Если нотация не подходит под задачу - не используй её. Если используешь - не ломай семантику». Иначе каждая схема требует собственной легенды, и смысл использования стандарта теряется. Это становится «простой блочной схемой, которую начертили в Bizagi»
Ещё раз спасибо за материал. Такие статьи полезны тем, что можно немного подискутировать на тему «как балансировать между строгостью стандарта и практической пользой».
P.S.
В качестве наглядной иллюстрации тезиса про адаптацию, я перевёл ключевую фразу этого комментария на болгарский:
«Нотацията е език за общуване... Адаптацията на езика... може да доведе до пълно неразбиране»
Для НЕ носителя языка текст выглядит почти как русский за счёт 100% совпадения алфавита и частичного совпадения словаря, но смысл считывается с трудом.
Это пример предельной «адаптации» - другой язык в рамках одного алфавита. Работает так же, как кастомизация нотации: вроде бы «всё те же квадратики, кружочки и стрелочки», но без знания легенды нет уверенности в понимании. А если легенда у каждого своя, то начинаются чудеса.
Иван, это как раз знакомо, пройдено, вспоминается как страшный сон.
К счатью, я уже чуток постраше, у моей семьи в выборе между “здоровый муж/отец" и “муж/папа на должности и ЗП +50“ однозначный преоритет отдаётся первому. Могу себе позволить говорить “нет"
Не буду менторствовать. Терпения Вам, удачи в борьбе с работодателем и надёжного тыла в части понимающей и принимающей семьи.
Разумеется могу. Давайте начнём с простого. Где Вы увидели слово "эксперт" в моём ответе ? Его там нет. Потому что речь не об экспертах.
Как ни странно, проблема "незаменимости" характерна не только для экспертов и звёзд. Те самые "80% ходящих за зарплатой", упомянутые автором, также иногда становятся бас-фактором.
Механика очень проста. Пишется сервис. Любой, не важно что он делает, важно что сервис в целом нужный, но регулярно изменяемый. На время запуска там работает полноценная команда, но после отладки он уходит на поддержку. Редкие инциденты, редкие доработки. Команда не нужна. Сервис отходит в руки одному, максимум двум сотрудникам, которые "что-то делают". Через пару-тройку лет, если руководитель забил и не озаботился ротацией знаний, мы получаем "уникального незаменимого специалиста", который единственный знает "как это работает".
Дальше уже от человека зависит. Есть ребята, которые стремятся вырваться и просят дать им ещё какие-то задачи, а они "своим поделятся". Есть те, кто реально спокойно продолжает поддерживать этот сервис "за зарплату". Таких кстати довольно много и им так комфортно. Но периодически встречаются те, кто решает, что им в руки попала "золотая акция" и начинают заявлять требования выше стандартного трудового договора. Там какие только варианты не встречались. И улучшенный ДМС, и компенсация "не съеденных в офисе печенек", и отпуск 20+ дней в августе. Ключевое. Все эти требования обычно подкрепляются, явно или неявно, посылом "вы ж меня не уволите, я же уникальный".
Повторю, случай не частый. Но и не редкий. Встречается регулярно. И характерно как раз для крупных компаний типа Яндекса (автор критикуемой статьи как раз оттуда вроде).
Ну допустим. Согласен, КМ нужно проверить, не сегодня, так в июле.
Но есть менее болезненный с точки зрения закона вариант – скинуть полный расчёт на свою же облачную кассу по статусу “выдан“. Да, там место расчёта не то и сентябрьские правки ФФД нужно пересмотреть. Но не завершать же расчёт без передачи
... Я то грешным делом подумал, что пропустил очередное Письмо. Нет, мнение ТП ЧЗ тут не устроит, оно с точки зрения НПД не стоит ничего.
Пойду поковыряю тему. У меня сейчас ЧЗ нет, на запуске товарная группа
По первой части – не могу ничего сказать. Даже если и видел Письма на эту тему, просто пропустил их потому, что не занимаюсь автоматизацией ИП.
Уверен, что Вы правы, но речь в статье о юрике.
По второй же части – ссылку дайте пожалуйста. Заинтриговали.
ЧЗ этого точно не требует. Писем ФНС и Минфина на эту тему точно не видел. И сдаётся мне, что под “требует“ Вы имеете в виду свою кастомную реализацию.
Тут сразу вопрос – а что Вы делаете при отказе клиента? Ввод в оборот возвратом? Он не во всех товарных группах допускается
Всё, я понял о чём Вы. Да, возврат разумеется возможен. Я же говорил не о возврате, а о техническом сторно в течении открытого банковского дня. Для ситуаций "я дура не туда нажала"
В приложении магазина на своем телефоне Вы не можете сами себе сделать “полный расчет". Только внести аванс/предоплату.
Полный расчет может сделать только продавец/курьер в своём приложении.
Особенности кассового законодательства РФ.
...
По теме топика. Ваши опасения разумеется понятны и очевидны в текущей непростой жизни
Но в данном кокретном случае переживать не стоит. Это реально существующая технология. Просто крайне редкая и не популярная, я в реальности видел эту встройку всего пару раз и сам не интегрировал. А мобильный интернет реально глушат, так что без Вашего вайфая у курьера вероятно не было возможности закрыть продажу.
СБП в качестве вида оплаты в рознице очень неприятен. Его крайне сложно сторнировать. Вернее даже так. Нельзя сторнировать нигде кроме Сбера на данный момент.
Есть один любопытный нюанс, который не осветил автор.
Написать в одиночку с нуля конфигу для связи внутреннего учета с весовой платформой (если я правильно понял суть разработки) - задача в общем не рокет сайенс, но и не на день-два.
Юристы компании не заявляли встречных претензий на тему того, что человек в рабочее время занимался задачей, которую никто не ставил, но результат которой теперь пытается продать?
Если брать это решение за прецедент, следующему истцу по похожей теме могут и задать этот вопрос.
Если я правильно прочитал, в момент разработки и установки конфиги автор был уже не разработчиком, а начальником ОИТ и на эту должность не было ДИ, даже типовой.
Дойдёт, простите, куда именно?
Яндекс в прошлом году запустил возвраты через курьеров Лавки
Доставистовские курьеры так еще лет 5 назад, если не больше, таскали возвраты.
У СДЭКа вроде бы и сейчас есть вывоз курьером с адреса
Правда, мало кому из ритейла это нужно как сервис.
Ключевая сложность возврата "от дверей" – это попасть к дверям. Сложно сейчас найти МКД со свободным доступом в подъезд. А значит курьера нужно заказать на четкое время (это дороже), или ждать сидя дома.
А из СНТ, ИЖС и прочих поселений возврат выйдет дороже доставки, ибо поездка почти гарантированно будет 1 - 1, а не N - N. Просто нет такого количества одновременных возвратов.
Ну и про ПВЗ маркетплейсов выше написали. Они сейчас в шаговой доступности просто везде
Это достаточно распространённая практика.
Да, бывало, на пресейл приезжают старые знакомые, с которыми уже не раз пересекался на проектах "не только здесь", обсуждается общий концепт, играется тендер, и выходит наполовину другая команда.
Бывали и замены "на ходу", особенно если сроки уезжали сильно вправо
Причин масса на самом деле и каждый случай по-своему особый
Да, приходилось, и нередко, включать в договора конкретных исполнителей и следить за этим
Точно помню, что мы начали менять кассовые аппараты на базе Fujitsu на 486х процессорах в 2006-м году. И не сильно торопились. По тем временам их за глаза хватало. Просто поднадоели матричные принтеры.
Вероятно, есть ещё немало таких же "ниш", в которых просто не нужно больше
Не очень круто :)))
Я тут немного наколхозил для возможности продолжения беседы :)))
Эта схема неплохо подошла бы для какой-нибудь презентации на 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 и начертить простую блочную.
:))) Выдохнул, ушел на выходные.
Удачи Вам :)
Юрий, давайте сразу оговорюсь, что 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С Бухгалтерии.
ОФД: обрабатывать кассовый чек аванса, обрабатывать кассовый чек полного расчета.
Спасибо за статью, Юрий.
Вы правы, схемы должны решать конкретные задачи и мысль о том, что «Система - полноценный участник процесса», абсолютно верная.
Однако также нужно всегда помнить то том, что схемы должны быть понятными целевой аудитории.
Позволю себе добавить несколько ремарок с точки зрения работы со стандартами, не в порядке критики, а как повод для дискуссии.
BPMN уже содержит многое из того, что вы описываете.
Выделение «Системы» в отдельную дорожку - штатный механизм. Пулы и дорожки как раз предназначены для разделения ответственности между ролями, системами и подразделениями. Отправка сообщений между ними моделируется стандартными элементами (Message Flow), без необходимости вводить авторские «якоря».
Визуальный стиль - не семантика.
Красить дорожки, менять толщину линий, добавлять иконки или подписи - можно и нужно, если это улучшает читаемость. Но важно, чтобы смысл элементов оставался в рамках спецификации. Иначе схема перестаёт быть языком и становится авторской иллюстрацией, которая требует отдельной легенды и пояснений, устных или письменных.
Адаптация может привести к непониманию.
Когда мы отступаем от стандарта осознанно и всей командой – это нормально. Мне на практике доводилось встречать минимум 3 кастомных версии BPMN.
Но каждое такое отступление крайне желательно документировать, а дальше строго соблюдать, иначе через полгода-год даже автор схемы не вспомнит, чем «указание Системы» отличается от обычного потока управления. А недавно нанятый сотрудник - тем более, ему придётся проводить отдельный мини-курс по правилам чтения документов.
Если команда регулярно решает одну и ту же задачу (например, документирует работу 1С в различных процессах), можно оформить набор допустимых расширений как внутренний профиль BPMN: зафиксировать цвета, шаблоны, правила. Можно даже частично «экспортировать» профиль из других нотаций, например из архимейта:
«Бизнес» - желтый
«Апликуха» - голубой
«Системы» - зеленый
Это сохранит преимущества стандарта, но даст гибкость.
До своей команды я обычно доношу это так: «Если нотация не подходит под задачу - не используй её. Если используешь - не ломай семантику». Иначе каждая схема требует собственной легенды, и смысл использования стандарта теряется. Это становится «простой блочной схемой, которую начертили в Bizagi»
Ещё раз спасибо за материал. Такие статьи полезны тем, что можно немного подискутировать на тему «как балансировать между строгостью стандарта и практической пользой».
P.S.
В качестве наглядной иллюстрации тезиса про адаптацию, я перевёл ключевую фразу этого комментария на болгарский:
«Нотацията е език за общуване... Адаптацията на езика... може да доведе до пълно неразбиране»
Для НЕ носителя языка текст выглядит почти как русский за счёт 100% совпадения алфавита и частичного совпадения словаря, но смысл считывается с трудом.
Это пример предельной «адаптации» - другой язык в рамках одного алфавита. Работает так же, как кастомизация нотации: вроде бы «всё те же квадратики, кружочки и стрелочки», но без знания легенды нет уверенности в понимании. А если легенда у каждого своя, то начинаются чудеса.
Иван, это как раз знакомо, пройдено, вспоминается как страшный сон.
К счатью, я уже чуток постраше, у моей семьи в выборе между “здоровый муж/отец" и “муж/папа на должности и ЗП +50“ однозначный преоритет отдаётся первому. Могу себе позволить говорить “нет"
Не буду менторствовать. Терпения Вам, удачи в борьбе с работодателем и надёжного тыла в части понимающей и принимающей семьи.
...
И да.
Я писал о другой крайности
Разумеется могу.
Давайте начнём с простого. Где Вы увидели слово "эксперт" в моём ответе ?
Его там нет. Потому что речь не об экспертах.
Как ни странно, проблема "незаменимости" характерна не только для экспертов и звёзд.
Те самые "80% ходящих за зарплатой", упомянутые автором, также иногда становятся бас-фактором.
Механика очень проста.
Пишется сервис. Любой, не важно что он делает, важно что сервис в целом нужный, но регулярно изменяемый. На время запуска там работает полноценная команда, но после отладки он уходит на поддержку.
Редкие инциденты, редкие доработки. Команда не нужна. Сервис отходит в руки одному, максимум двум сотрудникам, которые "что-то делают". Через пару-тройку лет, если руководитель забил и не озаботился ротацией знаний, мы получаем "уникального незаменимого специалиста", который единственный знает "как это работает".
Дальше уже от человека зависит.
Есть ребята, которые стремятся вырваться и просят дать им ещё какие-то задачи, а они "своим поделятся".
Есть те, кто реально спокойно продолжает поддерживать этот сервис "за зарплату". Таких кстати довольно много и им так комфортно.
Но периодически встречаются те, кто решает, что им в руки попала "золотая акция" и начинают заявлять требования выше стандартного трудового договора. Там какие только варианты не встречались. И улучшенный ДМС, и компенсация "не съеденных в офисе печенек", и отпуск 20+ дней в августе. Ключевое. Все эти требования обычно подкрепляются, явно или неявно, посылом "вы ж меня не уволите, я же уникальный".
Повторю, случай не частый. Но и не редкий. Встречается регулярно. И характерно как раз для крупных компаний типа Яндекса (автор критикуемой статьи как раз оттуда вроде).
Вы пропустили один любопытный краевой случай.
Шантаж своей незаменимостью.
Такие случаи нередки. И это обычно становится проблемой :))
Это врядли.
Двигатели по сути решают одну и ту же неизменную задачу в неизменной среде.
Процессы усложяются и переплетаются не потому что их исполнители вдруг заскучали, а в ответ на изменения целей и внешней среды
ТСПИоТ чуток отложен.
Ну допустим. Согласен, КМ нужно проверить, не сегодня, так в июле.
Но есть менее болезненный с точки зрения закона вариант – скинуть полный расчёт на свою же облачную кассу по статусу “выдан“. Да, там место расчёта не то и сентябрьские правки ФФД нужно пересмотреть. Но не завершать же расчёт без передачи
... Я то грешным делом подумал, что пропустил очередное Письмо. Нет, мнение ТП ЧЗ тут не устроит, оно с точки зрения НПД не стоит ничего.
Пойду поковыряю тему. У меня сейчас ЧЗ нет, на запуске товарная группа
Благодарю ещё раз за подсказку
Благодарю :))
По первой части – не могу ничего сказать. Даже если и видел Письма на эту тему, просто пропустил их потому, что не занимаюсь автоматизацией ИП.
Уверен, что Вы правы, но речь в статье о юрике.
По второй же части – ссылку дайте пожалуйста. Заинтриговали.
ЧЗ этого точно не требует. Писем ФНС и Минфина на эту тему точно не видел. И сдаётся мне, что под “требует“ Вы имеете в виду свою кастомную реализацию.
Тут сразу вопрос – а что Вы делаете при отказе клиента? Ввод в оборот возвратом? Он не во всех товарных группах допускается
Всё, я понял о чём Вы.
Да, возврат разумеется возможен.
Я же говорил не о возврате, а о техническом сторно в течении открытого банковского дня. Для ситуаций "я дура не туда нажала"
У Вас есть способ отката СБП транзакции не в Сбере после подтверждения перевода?
Поделитесь пожалуйста ссылкой, докой, чем угодно.
Реально интересно
В приложении магазина на своем телефоне Вы не можете сами себе сделать “полный расчет". Только внести аванс/предоплату.
Полный расчет может сделать только продавец/курьер в своём приложении.
Особенности кассового законодательства РФ.
...
По теме топика. Ваши опасения разумеется понятны и очевидны в текущей непростой жизни
Но в данном кокретном случае переживать не стоит. Это реально существующая технология. Просто крайне редкая и не популярная, я в реальности видел эту встройку всего пару раз и сам не интегрировал. А мобильный интернет реально глушат, так что без Вашего вайфая у курьера вероятно не было возможности закрыть продажу.
...
Нет, я не из DNS
СБП в качестве вида оплаты в рознице очень неприятен. Его крайне сложно сторнировать. Вернее даже так. Нельзя сторнировать нигде кроме Сбера на данный момент.
Не любим мы его
Превед.
Песать истчо олбанской мовою - зачод и наше фсё, щетаю
Хотя это разумеется не гарантия. Распознать и подделать паттерн сознательного искажения языка - по сути "родная" задача для LLM
Вероятно, авторы не предполагали, что те, кто не использует инструмент, начнут отвечать на вопросы об использовании.