Жил-был аналитик. И отправил его царь-батюшка (генеральный директор) в тридевятое царство — описать бизнес-процессы. А тропинок в том лесу — тьма: тут тебе и BPMN-тропа, и IDEF0-поляна, и EPC-болото с кочками. Чтобы не заблудиться и не быть съеденным злым отделом IT, запоминайте 19.5 богатырских правил.
Часть 1. Сказ о целях: Куда прешь, Иван?
Правило 1. Если вы царь (или Кощей над златом) — берите IDEF0
IDEF0 — это нотация для "взгляда с Олимпа" или с верхушки дуба. Она не про детали, она про архитектуру. Вы рисуете прямоугольники, показываете, куда входят деньги и ресурсы, а что выходит — прибыль или шиш с маслом. Сотрудники там не люди, а безликие "механизмы".
- Для кого: Для собственников, которые хотят ткнуть пальцем в квадратик и сказать: "Вот здесь у нас протечка!".
- Пример: Сеть магазинов "Три богатыря". На схеме IDEF0 видно, что на входе — мужики с телегами (поставщики), на выходе — товар на полке, а управление — указ царя (приказ министра торговли). Но как именно продавец улыбается покупателю — это уже другой нотации дело.
Правило 2. Если нужно регламентировать Вовку из тридевятого царства — берите EPC
EPC (Event-Driven Process Chain) — это нотация для людей, у которых на заставке телефона "Часики". Она строится на простой логике: произошло событие → сделали действие → получили новое событие. Если вы напишете регламент в EPC, его поймет даже Вовка, который "и так сойдет".
- Описание: Главная фишка — чередование событий (ромбики) и функций (прямоугольники). Скучно, но наглядно. Событие всегда запускает функцию, функция всегда заканчивается событием. Как в сказке: "Утро вечера мудренее" — событие, "Лечь спать" — функция.
- Пример: "Процесс приготовления каши из топора". Событие: "Солдат пришел на постой". Функция: "Попросить топор". Событие: "Топор получен". Функция: "Начать варить". EPC идеальна, чтобы повесить регламент на стену в столовой, и никто не придерется.
Правило 3. Если вы строите завод-автомат — берите BPMN 2.0
BPMN — это нотация для перфекционистов и программистов. Она позволяет описать любую, даже самую извращенную логику. Таймеры, исключения, параллельные процессы, шлюзы "И/ИЛИ" — тут есть всё. Но если вы покажете BPMN-схему бабушке на входе, она перекрестится и уйдет в монастырь.
- Для кого: Для системных аналитиков и разработчиков, которые будут этот процесс в код зашивать.
- Пример: Интернет-магазин "Финист — Ясный Сокол". Клиент заказал меч-кладенец. BPMN-схема будет выглядеть как карта метро в час пик:
Проверить наличие на складе у Змея Горыныча.
Если нет — запустить подпроцесс "Ковка у кузнецов".
Если кузнецы заняты — отправить событие-таймер "Ждать 3 дня".
Параллельно: проверить кредитную историю Ивана (вдруг дурак?).
Если скоринг пройден — запустить доставку Соловьем-разбойником (с пометкой: осторожно, свистит).
Правило 4. Если вы пилите свой софт (строите терем из кода) — берите UML
UML Activity — это язык для "синих воротничков" программирования. Тут уже не важно, кто именно выполняет действие (человек или система), важно — как объекты движутся и взаимодействуют.
- Для кого: Для архитекторов ПО, которые любят четкость и ненавидят двусмысленность.
- Пример: Разработка нового мобильного банка для "Лукоморье Банка". UML покажет, как объект "Платеж" переходит из состояния "Создан" в состояние "Исполнен", и какие методы классов при этом вызываются. Бизнес-заказчик уснет на второй минуте, но программисты скажут спасибо.
Правило 5. Золотое правило архитектора: "Сначала репа, потом мышка"
Никогда не лезьте в #BPMN, не нарисовав #IDEF0. Сначала выдерните репку (процесс верхнего уровня) с помощью #IDEF0, покажите, за что дергать, а потом зовите мышку (#BPMN) для детальной проработки. Иначе дед будет держать бабку, бабка — Жучку, а Жучка — непонятно что, и вся схема рассыплется.
Правило 6. Правило "Золотой рыбки"
Всегда спрашивайте: "Кто будет читать эту схему, кроме вас?". Если это будет старик у разбитого корыта (начальник цеха), несите ему EPC. Если это Золотая рыбка (заказчик из IT), которая хочет исполняемую модель — учите BPMN.
Часть 2. Сказ про сложный выбор и развилки
Правило 7. Ветвление: "Налево пойдешь — коня потеряешь"
- EPC: Если у вас развилка "да/нет" — норм. Если условий больше двух, схема в EPC начинает напоминать бороду Черномора — ветвится во все стороны и теряет смысл.
- BPMN: Тут есть шлюзы (gateways). Хочешь — "И", хочешь — "ИЛИ", хочешь — сложное условие с двойным подвывертом. BPMN справится, а EPC ляжет в дрейф.
Правило 8. Документооборот: "Что написано пером..."
EPC обожает документы. Вы можете к каждой функции прицепить конкретный свиток, указ или стрелу. Это визуально и понятно. #BPMN тоже может, но там это делается через потоки данных и артефакты, и неподготовленный пользователь быстро потеряет нить повествования.
Правило 9. Логистика и производство: "Движение — жизнь"
Если ваш процесс — это про то, как деталька едет по конвейеру, или как курьер скачет между адресами, #BPMN вывозит лучше. #EPC, как показали исследования 2025 года, начинает тупить и превращать схему в солянку, где ресурсы перемешиваются с действиями.
Правило 10. Потоки данных: "Клубочек, укажи путь" (DFD)
Если вам плевать на последовательность шагов, но жизненно важно понять, как байты летают между сайтом, #1С и #CRM, берите DFD (Data Flow Diagram). Это не про бизнес-процессы, это про архитектуру систем. DFD покажет, где у вас узкое горлышко и почему данные теряются, как стрела в болоте.
Правило 11. Имитационное моделирование: "Семь раз отмерь"
Хотите не просто нарисовать, а просчитать, сколько Иванов-дураков нужно, чтобы закопать клад за 3 дня? Вам нужна имитация. В России для таких фокусов чаще всего берут #BPMN, потому что инструменты вроде #StormBPMN умеют не только рисовать, но и гонять модели, проверяя их на жизнеспособность.
Правило 12. Матрешка (декомпозиция)
- DEF0: Декомпозиция — это святое. Развернул блок — получил 6 новых блоков. Красота.
- BPMN: Тоже можно, через подпроцессы.
- EPC: Тут беда. Декомпозиция либо отсутствует, либо сделана так, что схема превращается в километровый рулон туалетной бумаги.
Правило 13. Для галочки и СМК (Системы Менеджмента Качества)
Правило 14. Исполняемые процессы: "Чтоб само работало"
Если процесс будет жить в системе (BPM-движке) и сам назначать задачи, слать письма и ругаться с начальством, то выбор один — BPMN 2.0. И плевать, что вы его не любите. Это индустриальный стандарт. Хотите автоматизации — учите матчасть
Правило 15. Для стартапа "Поди туда — не знаю куда" (0.5 литра от правила)
Если вы — маленькая контора с двумя Иванами и одним Коньком-Горбунком, не мучайтесь. Просто нарисуйте блок-схему в Paint или на доске. Это полправила, которые спасут вас от преждевременной бюрократической смерти. Лишь бы все поняли.
Часть 3. Сказ про наше, родное (Софт и реалии 2026-го)
Правило 16. Low-code и молодильные яблоки
Российские платформы вроде #ELMA365, #BPMSoft и #Comindware активно пиарят #low-code. То есть вы рисуете в BPMN, а система сама допиливает код. Звучит как сказка, но на деле все равно нужно знать #BPMN, чтобы не нарисовать велосипед с квадратными колесами.
Правило 17. Для малого бизнеса (СБИС, Pyrus, Битрикс24)
В этих системах вы не найдете чистой b. Там свои упрощенные конструкторы, похожие на лего для самых маленьких. Хорошо для бытовухи, плохо для сложной логики. Как говорится, "каша из топора", а не "кулинарный шедевр".
Правило 18. Для больших и серьезных: StormBPMN (Илья Муромец нашего времени)
Если у вас огромная корпорация с кучей процессов, которые должны быть описаны четко, без воды и без "авось", вам нужен StormBPMN.
- Описание: Это отечественный инструмент, который строго следует стандарту BPMN 2.0. Он не прощает ошибок, он проверяет синтаксис, он заставляет думать. Это как строгий, но справедливый богатырь на службе.
- Пример: Крупный банк "Русский Лес" решил описать процесс выдачи ипотеки. Взяли StormBPMN.
- Нарисовали схему, где учли всё: проверку службой безопасности (отправили запрос в "Базу данных Кощея"), оценку недвижимости (вызвали оценщика), параллельное одобрение на разных уровнях.
- StormBPMN проверил схему на "мертвые петли" и нашел ошибку: процесс уходил в бесконечный цикл при отказе клиента от страховки.
- Без него аналитик бы накосячил, и система автоматизации просто зависла бы. А так — все четко. StormBPMN идеально дружит с Business Studio (где хранятся справочники ролей и документов) и готов к экспорту в любой BPM-движок.
Правило 19. Госсектор и Directum / Docsvision
Там свои тараканы. Процессы в этих системах обычно привязаны к документам. Нотации используют либо упрощенные, либо внутренние графы. Главное — чтобы бумажка доползла до начальника и не сгнила по дороге.
Правило 19.5. Сказ про идеальную команду (Вот и сказочки конец, а кто читает тот ...)
Чтобы аналитика не уволили с треском, а процессы работали как часы, берите на вооружение связку:
- #Business #Studio — для описания архитектуры (#IDEF0, #EPC), хранения данных и печати регламентов. Это ваш "Морозко" — наводит порядок в сундуках.
- #StormBPMN — для детального, выверенного, готового к автоматизации описания процессов в BPMN 2.0. Это ваш "Финист — Ясный Сокол" — красивый, строгий и летит туда, куда надо.
- #ELMA / #Comindware — для того, чтобы запустить этот процесс и заставить людей по нему работать. Это ваша "скатерть-самобранка" — всё само бегает и приносит результат.
Мораль: Не ищите легких путей. Не рисуйте BPMN для бабушек и IDEF0 для программистов. Выбирайте нотацию с умом, а для сложных задач берите StormBPMN — он и петли отлова, и синтаксис проверит, и нервные клетки сбережет.