Генерация моделей BPMN — инструмент нейросети Аливия на базе ИИ. Разложит ваш процесс на участников, задачи, шлюзы и события по нотации BPMN 2.0 и вернёт модель текстом, в XML для Camunda и bpmn.io или схемой для регламента. Пришлите текстовый порядок работы или должностную инструкцию — найдёт лишние согласования, незакрытые ветки и места, где процесс встаёт.
Работает онлайнРусский и другие языкиТест бесплатно, без регистрацииБез VPNДоступ 24/7Голосовой ввод и файлы
АливияИИ-ассистент2 000 символов бесплатно2 000 символов доступны сразу — без карты и без регистрации.
Зарегистрируйтесь и подтвердите почту — начислим ещё 10 000 символов на 7 дней.ЗарегистрироватьсяОнлайн
Зарегистрируйтесь и подтвердите почту — начислим ещё 10 000 символов на 7 дней.ЗарегистрироватьсяОнлайн
Примеры запросов — нажмите, и текст подставится в чат:
Поиск инструментов
Весь каталог →Отдельной страницы под это нет, но Аливия справится в чате на этой странице.
Популярные инструменты для бизнеса
ТаблицаIDEF0ТЗБизнес-планРаспознавание текстаКоммерческое предложениеПрезентацияПроектыОтчетыБюджетРезюмеВакансииЦАДеловой стиль текстаИдеи стартаповАктыКак сделать в Excel и WordАнализ таблицы ExcelДоверенностьSWOT-анализБизнес-модельРасчёт НМЦКАкт скрытых работМотивацияСлужебная запискаСмета на ремонт оборудованияСравнение поставщиковУТПKPIПрогнозированиеПротокол совещанияЗаявка на участие в закупкеНаценка и маржаОбоснование закупкиПрайс-лист услугСчёт на оплатуШаблон учёта в Google ТаблицахСтратегияАнализ конкурентов
Бизнес · ИИ-инструмент нейросети Аливия
Конструктор схемы BPMN
Опишите процесс словами — бот разложит его на дорожки, задачи, шлюзы и события BPMN 2.0.
Что делаем
Формат ответа
Детализация
Ещё настройки
Исключения
Язык подписей
Список вопросов
Ваш запрос
Запрос подставится в поле чата — его можно поправить перед отправкой.
ЗапросПострой модель процесса «Возврат товара в магазин» в нотации BPMN 2.0. Участники (дорожки): клиент, продавец, товаровед, бухгалтерия. Начало и итог: клиент принёс товар → деньги вернули или отказ. Детализация: рабочая — каждый шаг и решение. Добавь ветки отказа и ошибок; где в описании не сказано, что делать, — ставь [уточнить]. Таймеров не добавляй. Подписи — на русском. Задачи — глагол с объектом («Проверить чек»). Шлюз только разводит ветки, решение принимает задача перед ним; подпиши условие каждой ветки. Параллельные ветки своди параллельным шлюзом. Одно стартовое событие, у каждой ветки — завершающее; между пулами — поток сообщений. Не добавляй участников, шагов и сроков, которых нет в моих данных; где без них не обойтись — [ЗАПОЛНИТЬ: что именно]. В конце списком — неясные места описания. Перед ответом проверь: у каждой задачи есть вход и выход, у каждого шлюза подписаны ветки, нет шагов не из моих данных. Формат ответа: таблица шагов: №, участник, элемент BPMN, название, откуда, куда, условие ветки.Как идёт процесс:
Клиент приносит товар и чек.
Продавец проверяет чек.
Товаровед осматривает товар.
Если брак или срок возврата не прошёл — бухгалтерия возвращает деньги.
Иначе продавец отказывает клиенту с объяснением.
Ответ Аливии
Вот модель процесса «Возврат товара в магазин» в нотации BPMN 2.0:
| № | Участник | Элемент BPMN | Название | Откуда | Куда | Условие ветки |
|---|---|---|---|---|---|---|
| 1 | Клиент | Стартовое событие | Клиент принёс товар и чек | Продавец | ||
| 2 | Продавец | Задача | Проверить чек | Продавец | Товаровед | |
| 3 | Товаровед | Задача | Осмотреть товар | Товаровед | Шлюз | |
| 4 | Товаровед | Шлюз | Проверка состояния товара | Осмотреть товар | Шлюз | Брак или срок возврата не прошёл? |
| 5 | Бухгалтерия | Задача | Вернуть деньги | Шлюз | Завершение процесса | Да |
| 6 | Продавец | Задача | Отказать клиенту | Шлюз | Завершение процесса | Нет |
| 7 | Продавец | Завершение | Завершение процесса | Вернуть деньги / Отказать |
Неясные места:
- Что делать в случае, если чек недействителен.
- Действия, если товар не соответствует условиям возврата (например, неупакован или повреждён).
Что проверить. Порядок шагов и условие ветки взяты из описания верно. Но шлюз ведёт сам в «Шлюз», у обеих веток одно завершающее событие вместо своего, ветки «чек недействителен» в схеме нет — только в списке неясностей. Потоков сообщений между участниками тоже нет. Переходы проверьте вручную.
ЗапросПострой модель процесса «Согласование отпуска» в нотации BPMN 2.0. Участники (дорожки): сотрудник, руководитель, кадровик. Начало и итог: заявление подано → приказ подписан или отказ. Детализация: для Camunda — с типами задач (пользовательская, сервисная) и условиями на ветках; это каркас, без скриптов и форм. Добавь ветки отказа и ошибок; где в описании не сказано, что делать, — ставь [уточнить]. Сроки: руководитель отвечает за 3 рабочих дня — таймерные события только на эти сроки. Системы: кадровая система, почта — автоматические шаги в них отметь сервисными задачами. Подписи — на английском. Задачи — глагол с объектом («Проверить чек»). Шлюз только разводит ветки, решение принимает задача перед ним; подпиши условие каждой ветки. Параллельные ветки своди параллельным шлюзом. Одно стартовое событие, у каждой ветки — завершающее; между пулами — поток сообщений. Не добавляй участников, шагов и сроков, которых нет в моих данных; где без них не обойтись — [ЗАПОЛНИТЬ: что именно]. Перед ответом проверь: каждый sourceRef и targetRef ссылается на существующий id, у каждой задачи есть вход и выход. Формат ответа: BPMN 2.0 XML одним блоком кода — с разделом диаграммы (bpmndi), фигурой и координатами у каждого элемента, уникальными id; перед кодом — 2–3 фразы о схеме.Как идёт процесс:
Сотрудник подаёт заявление в кадровой системе.
Руководитель согласует или отклоняет.
При согласовании кадровик готовит приказ, сотрудник подписывает его.
При отказе сотрудник получает уведомление с причиной.
Ответ Аливии
Вот BPMN 2.0 XML для процесса «Согласование отпуска». В процессе участвуют три дорожки: сотрудник, руководитель и кадровик. Включены автоматические сервисные задачи, таймерные события и условия на ветках.
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
targetNamespace="http://www.example.org/bpmn"
xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
xmlns:camunda="http://camunda.org/schema/1.0/bpmn">
<process id="VacationApprovalProcess" isExecutable="true">
<lane id="EmployeeLane" name="Сотрудник" />
<lane id="ManagerLane" name="Руководитель" />
<lane id="HRLane" name="Кадровик" />
<startEvent id="StartEvent" name="Заявление подано" />
<task id="SubmitApplication" name="Подать заявление" />
<serviceTask id="SendEmail" name="Отправить уведомление" camunda:delegateExpression="${emailService}" />
<task id="ReviewApplication" name="Проверить заявление" />
<exclusiveGateway id="DecisionGateway" name="Согласовать?" />
<task id="PrepareOrder" name="Подготовить приказ" />
<task id="SignOrder" name="Подписать приказ" />
<endEvent id="OrderSigned" name="Приказ подписан" />
<endEvent id="ApplicationRejected" name="Отказ" />
<intermediateCatchEvent id="TimerEvent" name="Таймер 3 рабочих дня">
<timerEventDefinition>
<timeDuration xsi:type="tFormalExpression">P3D</timeDuration>
</timerEventDefinition>
</intermediateCatchEvent>
<!-- Потоки -->
<sequenceFlow id="flow1" sourceRef="StartEvent" targetRef="SubmitApplication" />
<sequenceFlow id="flow2" sourceRef="SubmitApplication" targetRef="ReviewApplication" />
<sequenceFlow id="flow3" sourceRef="ReviewApplication" targetRef="DecisionGateway" />
<sequenceFlow id="flow4" sourceRef="DecisionGateway" targetRef="OrderSigned" id="flow4a" />
<sequenceFlow id="flow5" sourceRef="DecisionGateway" targetRef="ApplicationRejected" id="flow5a" />
<sequenceFlow id="flow6" sourceRef="DecisionGateway" targetRef="TimerEvent" id="flow6a" />
<sequenceFlow id="flow7" sourceRef="TimerEvent" targetRef="ApplicationRejected" />
<sequenceFlow id="flow8" sourceRef="DecisionGateway" targetRef="PrepareOrder" id="flow8a" />
<sequenceFlow id="flow9" sourceRef="PrepareOrder" targetRef="SignOrder" />
<sequenceFlow id="flow10" sourceRef="SignOrder" targetRef="OrderSigned" />
<sequenceFlow id="flow11" sourceRef="ApplicationRejected" targetRef="SendEmail" />
</process>
<bpmndi:BPMNDiagram>
<bpmndi:BPMNPlane bpmnElement="VacationApprovalProcess">
<bpmndi:BPMNShape bpmnElement="StartEvent" id="StartEvent_di" isThrowing="false">
<dc:Bounds x="100" y="150" width="36" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="SubmitApplication" id="SubmitApplication_di">
<dc:Bounds x="180" y="150" width="100" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="ReviewApplication" id="ReviewApplication_di">
<dc:Bounds x="300" y="150" width="100" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="DecisionGateway" id="DecisionGateway_di">
<dc:Bounds x="420" y="150" width="50" height="50" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="PrepareOrder" id="PrepareOrder_di">
<dc:Bounds x="500" y="100" width="100" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="SignOrder" id="SignOrder_di">
<dc:Bounds x="500" y="150" width="100" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="OrderSigned" id="OrderSigned_di">
<dc:Bounds x="620" y="150" width="36" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="ApplicationRejected" id="ApplicationRejected_di">
<dc:Bounds x="620" y="250" width="36" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="SendEmail" id="SendEmail_di">
<dc:Bounds x="300" y="250" width="100" height="36" />
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="TimerEvent" id="TimerEvent_di">
<dc:Bounds x="420" y="250" width="50" height="50" />
</bpmndi:BPMNShape>
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
</definitions>Эта модель описывает процесс согласования отпуска с учетом всех указанных требований и условий.
Что проверить. XML не откроется: у четырёх потоков атрибут id повторён дважды. Кроме того, подписи русские, а просили английские; P3D — три календарных дня, а не рабочих; таймер висит на шлюзе, а не на задаче руководителя; из завершающего события выходит поток; условий на ветках и линий нет. Соберите заново.
ЗапросПроверь мою схему процесса «Обработка заявки на кредит» в нотации BPMN 2.0: перечисли ошибки нотации и логики (где и как исправить), затем дай исправленную версию. Участники (дорожки): клиент, менеджер, служба безопасности, кредитный комитет. Детализация: рабочая — каждый шаг и решение. Таймеров не добавляй. Подписи — на русском. Задачи — глагол с объектом («Проверить чек»). Шлюз только разводит ветки, решение принимает задача перед ним; подпиши условие каждой ветки. Параллельные ветки своди параллельным шлюзом. Одно стартовое событие, у каждой ветки — завершающее; между пулами — поток сообщений. Не добавляй участников, шагов и сроков, которых нет в моих данных; где без них не обойтись — [ЗАПОЛНИТЬ: что именно]. В конце списком — неясные места описания. Перед ответом проверь: у каждой задачи есть вход и выход, у каждого шлюза подписаны ветки, нет шагов не из моих данных. Формат ответа: таблица шагов: №, участник, элемент BPMN, название, откуда, куда, условие ветки.Моя схема:
1. Клиент — заполнить заявку
2. Менеджер — проверить документы
3. Шлюз «Документы полные?»: да → 4, нет → вернуть клиенту
4. Служба безопасности — проверить клиента
5. Кредитный комитет — принять решение
6. Менеджер — сообщить клиенту
Ответ Аливии
Ошибки нотации и логики:
- Отсутствие стартового события: Схема должна начинаться со стартового события, которое инициирует процесс.
- Не указаны условия для шлюзов: Условия для ветвей шлюза должны быть четко обозначены.
- Отсутствие завершения процесса: Каждая ветка должна иметь завершающее событие.
- Отсутствие потоков сообщений: Не указано, как информация передается между разными участниками.
- Недостаточная детализация: Некоторые задачи не имеют четкого входа и выхода.
Исправленная версия схемы:
| № | Участник | Элемент BPMN | Название | Откуда | Куда | Условие ветки |
|---|---|---|---|---|---|---|
| 1 | Клиент | Стартовое событие | Начало обработки заявки | Менеджер | ||
| 2 | Клиент | Задача | Заполнить заявку | Начало обработки заявки | Менеджер | |
| 3 | Менеджер | Задача | Проверить документы | Заполнить заявку | Шлюз «Документы полные?» | |
| 4 | Менеджер | Шлюз | Документы полные? | Проверить документы | [4, 5] | Да (4) / Нет (5) |
| 5 | Клиент | Задача | Вернуть документы клиенту | Документы полные? (Нет) | Завершение процесса | |
| 6 | Служба безопасности | Задача | Проверить клиента | Документы полные? (Да) | Кредитный комитет | |
| 7 | Кредитный комитет | Задача | Принять решение | Проверить клиента | Менеджер | |
| 8 | Менеджер | Задача | Сообщить клиенту | Принять решение | Завершение процесса | |
| 9 | Менеджер | Завершающее событие | Завершение обработки заявки | [6, 7] |
Неясные места описания:
- [ЗАПОЛНИТЬ: что именно] - отсутствует информация о том, что происходит, если документы не полные, или как сообщается клиенту.
Что проверить. Стартовое и завершающее события добавлены верно. Но «не указаны условия шлюза» — неправда: да/нет у вас есть. Главное пропущено: у решения кредитного комитета нет веток «одобрить / отказать». Ссылки на строки в таблице перепутаны ([4, 5], [6, 7]), у всех веток одно завершение.
ЗапросРазбери процесс «Закупка канцелярии для офиса» в нотации BPMN 2.0: сначала схема «как есть» по моему описанию, затем «как надо» и список изменений с причиной каждого. Участники (дорожки): сотрудник, офис-менеджер, финансовый директор, поставщик. Начало и итог: нужна канцелярия → сотрудник получил. Детализация: обзорная — 5–7 крупных шагов. Таймеров не добавляй. Подписи — на русском. Задачи — глагол с объектом («Проверить чек»). Шлюз только разводит ветки, решение принимает задача перед ним; подпиши условие каждой ветки. Параллельные ветки своди параллельным шлюзом. Одно стартовое событие, у каждой ветки — завершающее; между пулами — поток сообщений. Не добавляй участников, шагов и сроков, которых нет в моих данных; где без них не обойтись — [ЗАПОЛНИТЬ: что именно]. В конце списком — неясные места описания. Перед ответом проверь: у каждой задачи есть вход и выход, у каждого шлюза подписаны ветки, нет шагов не из моих данных. Формат ответа: таблица шагов: №, участник, элемент BPMN, название, откуда, куда, условие ветки.Как идёт процесс:
Сотрудник пишет офис-менеджеру в мессенджер, что нужно.
Офис-менеджер раз в неделю собирает список.
Список согласует финансовый директор.
Офис-менеджер заказывает у поставщика и раздаёт.
Проблема: просьбы теряются, согласование занимает до недели.
Ответ Аливии
Процесс «Закупка канцелярии для офиса» в нотации BPMN 2.0
1. Схема «как есть»
| № | Участник | Элемент BPMN | Название | Откуда | Куда | Условие ветки |
|---|---|---|---|---|---|---|
| 1 | Сотрудник | Сообщение | Написать заявку | - | Офис-менеджер | - |
| 2 | Офис-менеджер | Задача | Собрать список | Сообщение | Согласование | - |
| 3 | Финансовый директор | Задача | Согласовать список | Список | Заказ | - |
| 4 | Офис-менеджер | Задача | Заказать канцелярии | Согласование | Поставщик | - |
| 5 | Поставщик | Задача | Доставить канцелярии | Заказ | Офис-менеджер | - |
| 6 | Офис-менеджер | Задача | Раздать канцелярии | Доставка | Сотрудник | - |
2. Схема «как надо»
| № | Участник | Элемент BPMN | Название | Откуда | Куда | Условие ветки |
|---|---|---|---|---|---|---|
| 1 | Сотрудник | Сообщение | Написать заявку | - | Офис-менеджер | - |
| 2 | Офис-менеджер | Задача | Собрать список | Сообщение | Согласование | - |
| 3 | Финансовый директор | Задача | Согласовать список | Список | Заказ | - |
| 4 | Офис-менеджер | Задача | Заказать канцелярии | Согласование | Поставщик | - |
| 5 | Поставщик | Задача | Доставить канцелярии | Заказ | Офис-менеджер | - |
| 6 | Офис-менеджер | Задача | Раздать канцелярии | Доставка | Сотрудник | - |
3. Список изменений и причины
- Добавить автоматизированную систему для сбора заявок от сотрудников:
- Причина: Устранить потерю заявок.
- Сократить сроки согласования списка путем внедрения регулярных встреч:
- Причина: Ускорить процесс согласования.
Неясные места описания
- Как часто и в каком формате финансовый директор должен согласовывать список?
- Как происходит взаимодействие с поставщиком (например, предпочитаемый способ заказа)?
- Что делать, если поставщик не может выполнить заказ?
Что проверить. Таблица «как надо» дословно повторяет «как есть» — изменения из списка (система заявок, встречи) в схему не внесены. Нет стартового и завершающего событий, «Сообщение» стоит как шаг, «Заказать канцелярии» — с ошибкой. Список неясных мест полезен. Схему «как надо» придётся строить самим.
ЗапросПострой модель процесса «Приём заказа в кафе с доставкой» в нотации BPMN 2.0. Участники (дорожки): гость, администратор, кухня, курьер. Начало и итог: заказ оплачен → заказ доставлен или деньги возвращены. Детализация: рабочая — каждый шаг и решение. Добавь ветки отказа и ошибок; где в описании не сказано, что делать, — ставь [уточнить]. Сроки: доставка не дольше 60 минут — таймерные события только на эти сроки. Системы: сайт, касса — автоматические шаги в них отметь сервисными задачами. Подписи — на русском. Задачи — глагол с объектом («Проверить чек»). Шлюз только разводит ветки, решение принимает задача перед ним; подпиши условие каждой ветки. Параллельные ветки своди параллельным шлюзом. Одно стартовое событие, у каждой ветки — завершающее; между пулами — поток сообщений. Не добавляй участников, шагов и сроков, которых нет в моих данных; где без них не обойтись — [ЗАПОЛНИТЬ: что именно]. В конце списком — неясные места описания. Перед ответом проверь: у каждой задачи есть вход и выход, у каждого шлюза подписаны ветки, нет шагов не из моих данных. Формат ответа: блок-схема Mermaid (flowchart) одним блоком кода с пометкой, что это упрощение, а не нотация BPMN.Как идёт процесс:
Гость оформляет заказ на сайте и оплачивает.
Администратор подтверждает заказ.
Повар готовит, упаковщик собирает пакет.
Курьер забирает и доставляет.
Если блюда нет в наличии — администратор звонит гостю и предлагает замену или возврат денег.
Ответ Аливии
Вот упрощённая блок-схема процесса «Приём заказа в кафе с доставкой» в формате Mermaid. Она не является точной нотацией BPMN 2.0, но иллюстрирует основные этапы процесса.
flowchart TD
A[Гость оформляет заказ на сайте и оплачивает] --> B[Администратор подтверждает заказ]
B -->|Заказ подтверждён| C[Повар готовит блюда]
B -->|Блюда нет в наличии| D[Администратор звонит гостю]
D -->|Предлагает замену| E[Гость согласен на замену]
D -->|Предлагает возврат| F[Гость согласен на возврат]
C --> G[Упаковщик собирает пакет]
G --> H[Курьер забирает заказ]
H --> I[Курьер доставляет заказ]
I --> J[Заказ доставлен]
F --> K[Деньги возвращены]
style A fill:#f9f,stroke:#333,stroke-width:2px
style J fill:#0f0,stroke:#333,stroke-width:2px
style K fill:#ff0,stroke:#333,stroke-width:2px
classDef decision fill:#f96,stroke:#333,stroke-width:2px;
class D decision;Неясные места описания:
- [уточнить]: Что делать, если гость не отвечает на звонок?
- [уточнить]: Процесс обработки возврата денег.
- [уточнить]: Условия замены блюда (например, аналогичное или другое).
Что проверить. Код Mermaid рабочий, пометка об упрощении есть, развилка «блюда нет» учтена. Но ветка замены обрывается: после согласия гостя заказ никуда не идёт. Нет таймера на 60 минут доставки и шагов в сайте и кассе. Допишите ветку замены и проверьте, что у каждой ветки есть финал.
ЗапросПроверь мою схему процесса «Согласование договора» в нотации BPMN 2.0: перечисли ошибки нотации и логики (где и как исправить), затем дай исправленную версию. Детализация: рабочая — каждый шаг и решение. Таймеров не добавляй. Подписи — на русском. Задачи — глагол с объектом («Проверить чек»). Шлюз только разводит ветки, решение принимает задача перед ним; подпиши условие каждой ветки. Параллельные ветки своди параллельным шлюзом. Одно стартовое событие, у каждой ветки — завершающее; между пулами — поток сообщений. Не добавляй участников, шагов и сроков, которых нет в моих данных; где без них не обойтись — [ЗАПОЛНИТЬ: что именно]. Перед ответом проверь: каждый sourceRef и targetRef ссылается на существующий id, у каждой задачи есть вход и выход. Формат ответа: BPMN 2.0 XML одним блоком кода — с разделом диаграммы (bpmndi), фигурой и координатами у каждого элемента, уникальными id; перед кодом — 2–3 фразы о схеме.Моя схема:
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" id="d1" targetNamespace="t">
<process id="p1">
<startEvent id="s1"/>
<task id="t1" name="Подготовить договор"/>
<task id="t2" name="Согласовать с юристом"/>
<sequenceFlow id="f1" sourceRef="s1" targetRef="t1"/>
<sequenceFlow id="f2" sourceRef="t1" targetRef="t3"/>
</process>
</definitions>
Ответ Аливии
Ваш процесс «Согласование договора» требует исправлений по нотации и логике. Вот основные ошибки:
- Отсутствие завершающих событий: Каждый шаг процесса должен завершаться хотя бы одним событием.
- Неопределенная задача: Ваша схема ссылается на
t3, но эта задача отсутствует. - Отсутствие шлюза: Для разделения потоков требуется добавить шлюз перед условиями.
- Не хватает стрелок между задачами: Необходимо добавить все последовательные потоки.
- Нет параллельных или условных веток: Если есть несколько путей, они должны быть обозначены.
Вот исправленная версия вашей схемы «Согласование договора»:
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" id="d1" targetNamespace="t">
<process id="p1">
<startEvent id="s1"/>
<task id="t1" name="Подготовить договор"/>
<task id="t2" name="Согласовать с юристом"/>
<task id="t3" name="Внести правки"/>
<endEvent id="e1"/>
<endEvent id="e2"/>
<exclusiveGateway id="g1" name="Договор согласован?"/>
<sequenceFlow id="f1" sourceRef="s1" targetRef="t1"/>
<sequenceFlow id="f2" sourceRef="t1" targetRef="t2"/>
<sequenceFlow id="f3" sourceRef="t2" targetRef="g1"/>
<sequenceFlow id="f4" sourceRef="g1" targetRef="e1" name="Да"/>
<sequenceFlow id="f5" sourceRef="g1" targetRef="t3" name="Нет"/>
<sequenceFlow id="f6" sourceRef="t3" targetRef="g1"/>
</process>
<bpmndi:BPMNDiagram id="BPMNDiagram_p1">
<bpmndi:BPMNPlane bpmnElement="p1">
<bpmndi:BPMNShape bpmnElement="s1" id="BPMNShape_s1">
<dc:Bounds x="100" y="100" width="36" height="36"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="t1" id="BPMNShape_t1">
<dc:Bounds x="200" y="90" width="100" height="40"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="t2" id="BPMNShape_t2">
<dc:Bounds x="350" y="90" width="130" height="40"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="g1" id="BPMNShape_g1">
<dc:Bounds x="500" y="90" width="50" height="50"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="t3" id="BPMNShape_t3">
<dc:Bounds x="600" y="90" width="100" height="40"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="e1" id="BPMNShape_e1">
<dc:Bounds x="750" y="100" width="36" height="36"/>
</bpmndi:BPMNShape>
<bpmndi:BPMNShape bpmnElement="e2" id="BPMNShape_e2">
<dc:Bounds x="750" y="200" width="36" height="36"/>
</bpmndi:BPMNShape>
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
</definitions>Объяснение исправлений:
- Добавлены завершающие события
e1иe2для разных веток. - Добавлен шлюз
g1для проверки условия "Договор согласован?". - Исправлена ссылка на задачу
t3, которая теперь присутствует. - Упрощены потоки с указанием условий между шлюзом и задачами.
Эта версия соответствует требованиям BPMN 2.0 и логике процесса «Согласование договора».
Что проверить. Ссылку на несуществующий t3 нашёл верно. Но XML не откроется: префиксы bpmndi и dc не объявлены. Шаг «Внести правки» и шлюз «Договор согласован?» бот придумал. Событие e2 ни с чем не связано, линий нет. Что t2 висел без входа и выхода, не сказано. Сверьте шаги со своим процессом.
Ответы получены 29.09.2026 в этом чате и приведены без правок. Выделено то, чего не было в запросе.
Содержание
Что умеет генератор BPMN и когда он пригодится
BPMN показывает процесс как последовательность шагов с участниками, развилками и событиями — так, чтобы схему одинаково понимали руководитель, исполнитель и разработчик. Аливия превращает описание словами в модель по нотации BPMN 2.0: пулы и дорожки по ролям, задачи, шлюзы, события начала и конца, а по запросу — XML-файл, который открывается в Camunda Modeler, bpmn.io или Bizagi. Она же проверяет готовые схемы на типичные ошибки и ищет, где процесс теряет время.
- Описание процесса «как есть» перед оптимизацией или автоматизацией.
- Проектирование «как должно быть» — новая схема согласований, обработки заказа, найма.
- Регламенты — схема плюс пошаговый текст с ответственными.
- Учебные работы по бизнес-процессам и информационным системам.
- Подготовка к внедрению BPM-системы — модель, которую можно загрузить в движок.
Как получить схему, которую примут и люди, и Camunda
- Опишите процесс как историю: с чего начинается, кто что делает, где принимаются решения, чем заканчивается.
- Перечислите роли и системы — они станут дорожками и пулами.
- Назовите исключения: что происходит при отказе, просрочке, ошибке — без них схема «счастливого пути» бесполезна.
- Попросите модель текстом с элементами BPMN и проверкой: закрыты ли шлюзы, у всех ли задач есть исполнитель.
- Запросите BPMN 2.0 XML и откройте его в редакторе, чтобы увидеть диаграмму.
- Попросите анализ узких мест и регламент — таблицу шагов с ответственными и сроками.
Готовая формула запроса: «Опиши процесс обработки заказа в интернет-магазине в BPMN 2.0: роли — клиент, менеджер, склад, курьер, 1С. Шаги от оформления до доставки, развилки: нет на складе, отказ от оплаты, возврат. Дай текстовую модель с проверкой и BPMN XML для Camunda Modeler».
Схема без исключений — это иллюстрация, а не модель. Если на диаграмме нет ни одного шлюза «что, если», процесс описан для брошюры, а не для работы. Попросите нейросеть отдельно перечислить, где процесс может пойти не по плану.
Сравнение: способы построить модель BPMN
| Критерий | Аливия | Редактор (Camunda Modeler, bpmn.io) вручную | Бизнес-аналитик |
|---|---|---|---|
| От описания к схеме | По тексту за минуты, с XML | Рисуете сами | Интервью и моделирование |
| Проверка на ошибки нотации | По запросу | Частично | Да |
| Регламент и таблица ролей | Да | Нет | Да |
| Знание вашего процесса | Только из вашего описания | Ваше | Собирает на интервью |
| Стоимость | Бесплатный пробный объём | Бесплатно | От 60 000 ₽ за процесс |
Схема процесса по текстовому описанию
Основной сценарий: вы рассказываете, как работа устроена сейчас, ИИ превращает рассказ в структуру. На выходе — пулы и дорожки по участникам, цепочка задач, точки принятия решений, стартовое и конечное события. Каждый элемент подписан так, как принято в нотации: задача глаголом, событие состоянием.
Выгрузка в BPMN 2.0 XML
Если схему нужно открыть в Camunda Modeler, bpmn.io, Bizagi или Visio, попросите результат в формате BPMN 2.0 XML. Файл сохраняется как обычный текст с расширением .bpmn и открывается в редакторе, где схему можно двигать и дорабатывать мышью.
Разбор и проверка готовых моделей
Аливия читает описание существующей схемы и указывает на классические ошибки: шлюз, который открыли и не закрыли, ветка без завершения, задача без исполнителя, смешение событий и задач в одном элементе.
Поиск узких мест
Отдельный запрос — анализ: какие шаги можно выполнять параллельно, где процесс ждёт согласования дольше всего, какие проверки дублируются. Это не заменяет интервью с сотрудниками, но даёт список гипотез для обсуждения.
Регламент и описание ролей
К схеме можно попросить текстовую расшифровку: пошаговое описание, таблицу ответственных, критерии перехода между этапами. Такой документ уже годится как черновик регламента.
Бизнес-аналитикам
Первый черновик схемы за минуты вместо часа рисования — дальше остаётся уточнить детали на встрече с заказчиком.
Руководителям и владельцам процессов
Возможность увидеть процесс целиком, найти лишние согласования и понять, где теряется время.
Тем, кто внедряет автоматизацию
Модель в BPMN 2.0 XML — это то, что можно передать разработчикам или загрузить в движок процессов. Рядом полезны генератор моделей IDEF0, генератор технических заданий и построитель роадмапа.
Чего ИИ не сделает за вас при моделировании BPMN?
Нейросеть строит модель по тому описанию, которое получила: если в рассказе пропущен шаг, его не будет и в схеме. Поэтому готовую диаграмму обязательно показывают участникам процесса — именно они замечают недостающие проверки и неформальные договорённости. И ещё: красивая схема не улучшает процесс сама по себе, она лишь делает видимым то, что есть.
Цифры и факты
- Нотация BPMN 2.0 принята консорциумом OMG в январе 2011 года и закреплена как международный стандарт ISO/IEC 19510 в 2013 году.
- BPMN 2.0 включает формат обмена XML, поэтому модель, построенная в одном редакторе, открывается в других — Camunda Modeler, bpmn.io, Bizagi, Visio.
- Базовый набор элементов нотации: события, задачи, шлюзы, потоки и артефакты; для большинства процессов достаточно десяти элементов, полный стандарт описывает более ста.
- За последние 30 дней генератором BPMN воспользовались 44 раза — 105 сообщений; чаще всего моделируют обработку заказов, согласования и найм.
Комментарий эксперта
«Самые полезные схемы BPMN в чате получались у тех, кто описывал процесс с конца: «клиент получил заказ и подтвердил» — и шёл назад к началу. Так всплывают шаги, о которых при рассказе с начала забывают: возвраты, повторные звонки, ожидание оплаты. Попробуйте описать процесс в обе стороны и попросите нейросеть сверить две версии — разница и есть ваши слепые зоны».
— Аливия Кирсанова, основатель и руководитель Аливии
Какие ошибки допускают в схемах BPMN и как их избежать?
Готовые схемы присылают в чат на проверку регулярно, и нейросеть находит в них повторяющиеся нарушения.
- Шлюз открыт и не закрыт. Параллельные ветки должны сойтись в парном шлюзе, иначе процесс «зависает».
- Задача без исполнителя. Если элемент не лежит в дорожке роли, непонятно, кто делает работу.
- Только счастливый путь. Нет веток для отказа, просрочки, ошибки — схема не описывает реальность.
- Стрелки сообщений внутри одного пула. Внутри участника — поток управления, между участниками — поток сообщений.
- Двадцать задач на одной диаграмме. Разбейте на подпроцессы, иначе схему не прочтёт даже автор.
Опишите свою схему или пришлите XML — Аливия проверит её по этим правилам и укажет, что исправить.
Кейсы
С какими процессами приходят чаще всего.
Реальные кейсы
AI-эксперт в области искусственного интеллекта и нейросетей.
Кейс 1: Подбор персонала
Тема: HR-процесс
Запрос: «Построй BPMN: заявка, скрининг, интервью, оффер, выход на работу»
Запрос: «Построй BPMN: заявка, скрининг, интервью, оффер, выход на работу»
Результат: Модель с дорожками по участникам и шлюзами на отказах. Стало видно, что заявка согласуется дважды у одного человека.
Кейс 2: Возврат товара
Тема: Электронная коммерция
Запрос: «Опиши процесс возврата с проверкой сроков и решением по деньгам»
Запрос: «Опиши процесс возврата с проверкой сроков и решением по деньгам»
Результат: Схема с ветвлениями по срокам и состоянию товара. Два тупика в текущем процессе нашлись прямо при построении.
Кейс 3: Шлюзы и ветвления
Тема: Нотация
Запрос: «Объясни разницу между AND, OR и XOR на моём примере»
Запрос: «Объясни разницу между AND, OR и XOR на моём примере»
Результат: Разбор на одном и том же участке процесса с тремя вариантами шлюза. Разница в поведении стала очевидной.
Кейс 4: Ошибки и таймеры
Тема: Исключения
Запрос: «Как показать, что заявка висит больше двух дней и уходит руководителю?»
Запрос: «Как показать, что заявка висит больше двух дней и уходит руководителю?»
Результат: Модель с граничным событием-таймером и эскалацией. Именно этой части обычно не хватает в схемах, нарисованных «на глаз».
Кейс 5: Узкие места
Тема: Оптимизация
Запрос: «Разбери мой процесс: где лишние согласования?»
Запрос: «Разбери мой процесс: где лишние согласования?»
Результат: Нашлись два согласования подряд у смежных руководителей и одно, которое ничего не меняло. После пересборки цикл сократился на день.
Опрос
Для чего вам нужна модель BPMN?
Описать текущий процесс
66.67%
Спроектировать новый процесс
33.33%
Для учёбы или диплома
0%
Для внедрения в BPM-систему
0%
Генерация моделей BPMN: частые вопросы
В каком виде приходит готовая диаграмма?
Аливия возвращает модель текстом: список участников и дорожек, последовательность задач, шлюзы с условиями и события. По запросу тот же процесс выдаётся в формате BPMN 2.0 XML, который открывается в Camunda Modeler, bpmn.io или Bizagi, либо в виде кода для Mermaid, если схему нужно быстро показать в документации.
Нужно ли знать нотацию BPMN, чтобы получить схему?
Нет. Опишите процесс так, как рассказали бы коллеге: кто участвует, с чего всё начинается, где принимается решение, чем заканчивается. ИИ сам разложит это на пулы, дорожки, задачи и шлюзы и объяснит, почему выбрал именно такие элементы.
Чем шлюз «исключающее ИЛИ» отличается от «И»?
Исключающий шлюз (XOR) отправляет процесс ровно по одной ветке — например, заявка либо одобрена, либо отклонена. Параллельный шлюз (AND) запускает все ветки одновременно: бухгалтерия готовит счёт, а склад параллельно резервирует товар. Если перепутать их, схема будет описывать процесс, которого нет.
Можно ли проверить уже готовую схему?
Да. Опишите свою диаграмму текстом или вставьте BPMN XML — ИИ найдёт типовые ошибки: незакрытые шлюзы, задачи без исполнителя, отсутствующее конечное событие, ветки, которые никуда не ведут.
BPMN или IDEF0 — что выбрать?
BPMN описывает последовательность: что происходит, в каком порядке и кто это делает. IDEF0 отвечает на вопрос, из чего функция состоит и что ею управляет. Для регламентов и автоматизации берут BPMN, для описания системы функций верхнего уровня — IDEF0. Подробнее — на странице генератора моделей IDEF0.
Подойдёт ли результат для регламента или ТЗ?
Да, это одна из частых задач: попросите к схеме текстовое описание каждого шага с ответственными и сроками — получится основа регламента. Для технического задания пригодится генератор ТЗ, он оформит требования по разделам.
Кто отвечает за корректность модели?
Нейросеть строит схему по вашему описанию и не знает, как процесс устроен на самом деле. Готовую модель нужно сверить с участниками процесса: именно они замечают шаги, которые в описании были пропущены.
Как описать процесс, чтобы схема получилась точной?
Расскажите последовательно: с какого события всё начинается, кто выполняет каждый шаг, где принимается решение и чем процесс заканчивается. Отдельно назовите документы и системы, которые участвуют. Чем больше в описании глаголов действия и названий ролей, тем меньше нейросети приходится домысливать.
Что делать, если в процессе участвует несколько отделов?
В BPMN для этого есть пулы и дорожки: каждый участник получает свою полосу, а передача работы между ними становится видимой. Достаточно перечислить отделы и указать, кто за что отвечает, — Аливия разложит задачи по дорожкам и покажет точки передачи, где чаще всего теряется время.
Можно ли доработать уже полученную схему?
Да, диалог сохраняет контекст: попросите добавить ветку отказа, вынести подпроцесс на отдельную диаграмму или заменить шлюз. Переписывать описание с нуля не нужно — правки применяются к текущей модели, и вместе с ними обновляется BPMN XML для импорта в редактор.
Итог
Генератор BPMN даёт схему по нотации, XML для редактора и регламент к ней — за один разговор вместо дня рисования. Первую модель можно построить бесплатно; для регулярной работы с процессами посмотрите тарифы. Рядом: модель IDEF0 для общей картины, техническое задание, KPI процесса.
