Помните этот торжественный момент на старте многих ИТ-проектов? Компания покупает новую платформу, кто-нибудь из топ-менеджмента объявляет о победе над «ИТ-бюрократией» и с горящими глазами выдает аналитикам лицензии:
«Всё, теперь мы независимы! Рисуйте процессы сами, без этих душных программистов и долгих бэклогов!»
Первые три месяца — это эйфория. Процессы собираются мышкой, формочки красятся в корпоративный синий, маршруты согласования летают.
Бизнес в восторге: «Смотрите, мы автоматизировали отдел за неделю! А ИТ-департамент просил на это полгода и бюджет небольшого государства».
Но проходит год. На архитектурный комитет приносят схему процесса, которая больше всего напоминает карту метро Москвы в 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».
Иногда лучший код — это его отсутствие. Но только в том случае, если на его месте работает грамотно спроектированная архитектура.
А какой самый страшный «процессный долг» или визуального Франкенштейна встречали вы на своих проектах? Делитесь болью в комментариях.
