Помните этот торжественный момент на старте многих ИТ-проектов? Компания покупает новую платформу, кто-нибудь из топ-менеджмента объявляет о победе над «ИТ-бюрократией» и с горящими глазами выдает аналитикам лицензии:

«Всё, теперь мы независимы! Рисуйте процессы сами, без этих душных программистов и долгих бэклогов!»

Первые три месяца — это эйфория. Процессы собираются мышкой, формочки красятся в корпоративный синий, маршруты согласования летают.

Бизнес в восторге: «Смотрите, мы автоматизировали отдел за неделю! А ИТ-департамент просил на это полгода и бюджет небольшого государства».

Но проходит год. На архитектурный комитет приносят схему процесса, которая больше всего напоминает карту метро Москвы в 2050 году

Изменить в ней хоть один шаг значит сломать всё остальное. Браузер зависает при попытке просто открыть этот холст. Аналитик, который его нарисовал, уволился с нервным тиком, а разработчики крестятся и отказываются брать это в поддержку.

Привет. Я Дмитрий Дунаев. За свою карьеру я успел поработать продактом в нескольких крупных ИТ-компаниях, поучаствовал во внедрениях изнутри, а сейчас занимаюсь развитием платформы Directum. Я видел цикл «от восторга до катастрофы» десятки раз. Сегодня хочу честно поговорить о том, почему No-code в крупном бизнесе — это не волшебная палочка, а мощный инструмент, который без жесткой архитектурной дисциплины превращается в фиаско.

О чем вообще речь и при чем тут крупные компании?

Давайте синхронизируемся в понятиях. Что автоматизируют в крупняке и почему туда пришел No-code?

Крупная компания — это тысячи транзакций ежедневно: согласование договоров на сотни миллионов, онбординг тысяч сотрудников, цепочки поставок. Исторически всё это жило в хардкоде неповоротливых систем, где добавление одного поля в карточку занимало спринт.

Бизнесу нужен был быстрый запуск, и маятник качнулся в сторону визуальной разработки (No-code / Low-code). Но инструменты бывают разными:

• Легковесные платформы (Tilda, Airtable, Notion) — идеальны для малого бизнеса или проверки гипотез. Собрать базу данных для отдела из 10 человек — самое то.

• Тяжелые платформы (BPM, ECM, ERP-системы) — здесь живет ядро. Цена ошибки тут — не поехавшая кнопка на лендинге, а остановленный конвейер, улетевший не туда миллионный платеж или проваленный аудит.

Современные Enterprise-системы дают аналитикам почти полную свободу в визуальных редакторах. И именно эта свобода часто становится проблемой.

Давайте разберем три главные ловушки, в которые попадают команды.

No-code-ловушка №1: «Процессный долг» и миф о том, что можно просто всё нарисовать

В классической разработке есть понятие технического долга: программист пишет костыль ради релиза, обещая всё отрефакторить (спойлер: никогда). В No-code рождается монстр страшнее — процессный долг.

В коде вас ограничивает архитектура, паттерны, линтеры и суровое код-ревью. В визуальном редакторе аналитик предоставлен сам себе.

Как происходит архитектурный крах? На старте всё невинно. Аналитик автоматизирует согласование договора: красивый линейный маршрут из 4 шагов. Но бизнес не статичен. Каждую неделю прилетают новые требования:

• «Если договор больше 1 млн рублей, пусть согласует главбух, а если меньше — просто менеджер».

• «А если контрагент новый — добавь ветку проверки СБ».

• «А если это декабрь, то вообще все договоры идут через финансового директора!».

Аналитик (часто под давлением сроков) не перепроектирует процесс, а начинает лепить новые ромбики Если / ТО. Схема пухнет, обрастает циклами.

Итог: 90+ визуальных блоков на холсте. Читаемость нулевая. Тестируемость — отрицательная.

Как делать правильно: Матрицы принятия решений (DMN-подход)

Мы в Directum, наступив на эти грабли, пришли к жесткому правилу: если логика ветвится из-за бизнес-условий, не выносите её на визуальную схему.

Для этого в здоровой архитектуре используется подход, близкий к DMN (Decision Model and Notation) — матрицы принятия решений или вычисляемые роли. Вы создаете отдельную таблицу (справочник правил). В ней прописано:

Условие А (> 1 млн) + Условие B (Декабрь) = Исполнитель: Финдир.

На самой визуальной схеме BPMN остается один единственный аккуратный блок — «Согласование».

А исполнитель в нем — это переменная, которая стучится в матрицу. Схема остается линейной. А вся сложная бизнес-грязь живет в удобных таблицах, которые может править сам бизнес-заказчик (!) без перерисовки маршрута и риска сломать процесс.

No-code-ловушка №2: Интеграционный Франкенштейн

No-code обещает победу над ручным переносом данных. Но реальность бьет под дых, когда дело доходит до интеграций с зоопарком систем.

Сценарий: при закупке нужно запросить остаток бюджета в ERP. В No-code-редакторе есть блок «HTTP-запрос». Для отправки вебхука в Telegram его хватит. Но когда ответом от 1С приходит многоуровневый JSON на 500 строк с массивами, аналитик начинает страдать.

No-code в сочетании с Low-code

Правильный Enterprise-подход — разделение слоев. Разработчик в своей среде пишет скрипт обработки сложного JSON, настраивает таймауты, идемпотентность и упаковывает всё это в ОДИН визуальный блок.

Блок публикуется в No-code-редакторе. Теперь аналитик просто берет красивый кубик «Получить бюджет из ERP» и ставит на схему. Внутри — надежный «черный ящик», написанный профи. Разделяйте инструменты:

• Аналитику нужна абстракция, визуальный поток и бизнес-смысл.

• Разработчику нужна мощь: IDE, Git, отладчик, изоляция сред (Dev-Test-Prod) и обработка исключений в коде.

No-code-ловушка №3: Синдром «Чистого листа»

Самая большая ошибка при переходе на No-code — начинать автоматизацию с пустого экрана. Кажется, что абсолютная свобода («рисуй как видишь») — это благо. На деле это ловушка.

Когда аналитик собирает маршрут с нуля, он думает об «идеальном пути». Но в Enterprise 80% времени уходит на обработку системных исключений, о которых никто не помнит на старте:

• Что делать, если согласующий уволился прямо в момент, когда ему пришла задача? (Нужен механизм замещений и прав доступа).

• А если он игнорирует задачу 3 дня? (Эскалация).

• А если инициатор решил отозвать документ? (Конечный автомат процесса должен уметь откатывать статус и прерывать задачи).

• А как доказать аудитору через год, кто именно нажал кнопку? (Логирование).

В «голом» конструкторе вы потратите 90% времени на постройку этого инфраструктурного «водопровода», а не на бизнес-ценность.

Как выглядит здоровая реальность: Наследование и лучшие практики

Вместо того чтобы изобретать велосипед, в Enterprise работает подход «от коробки к кастомизации». Вы берете коробку, почти всегда дополнительно есть что-то вроде маркетплейса решений/продуктов и тд (например у нас это Каталог решений Directum), подключаете готовые решения и пользуетесь!

Дальше включается No-code-тюнинг. Вы не льете фундамент — вы занимаетесь отделкой. Система знает, как обрабатывать исключения, потому что ваш кастомный процесс унаследовал эти «гены» от надежного базового класса.

Сухой остаток: правила выживания в no-code

Чтобы ваш No-code-проект не превратился в памятник хаосу, который страшно трогать даже палкой:

• Убивайте Если/ТО. Больше трех условий в процессе? Выносите логику в DMN-таблицы (матрицы правил/вычисляемые роли). Процесс должен быть линейным.

• No-code в сочетании с Low-code. Оставьте бизнес-маршруты аналитикам, а интеграции, парсинг данных и сложные математические расчеты — разработчикам. Упаковывайте код в визуальные блоки.

• Не начинайте с чистого листа. Используйте коробочные решения как фундамент. Оставьте No-code для кастомизации фасадной части, а не для написания ядра.

• Культура документации и нейминга. Блок с названием «Условие_1» — это мина. Процесс должен быть прозрачным

• Код — это нормально. С развитием AI-ассистентов написать пару строк аккуратного кода часто бывает в разы быстрее и надежнее, чем строить Вавилонскую башню из визуальных элементов ради принципа «No-Code only».

Иногда лучший код — это его отсутствие. Но только в том случае, если на его месте работает грамотно спроектированная архитектура.

А какой самый страшный «процессный долг» или визуального Франкенштейна встречали вы на своих проектах? Делитесь болью в комментариях.