Конструктор сценариев решает большую часть задач автоматизации дешевле и быстрее кода, и мы сами собираем в нём основную массу того, что делаем. Но есть шесть ситуаций, в которых он гарантированно окажется дороже и хуже, и распознать их можно до первого узла — по свойствам процесса, а не по ощущению сложности.
Цена ошибки конкретна. Процесс, собранный в конструкторе и через год переписанный в собственный сервис, обходится в 642 000 ₽ по разработке против 408 000 ₽, если бы его написали сразу. Переплата — 234 000 ₽, то есть 57 %, и это без учёта года, прожитого на решении, которое не подходило.
Эта статья — про категорические случаи. Числовая граница между конструктором и кодом на обычных задачах проходит иначе, и мы разбирали её отдельно, с восемью измеримыми порогами и расчётом на три архитектуры, — где заканчивается low-code и начинается разработка. Здесь речь о том, где считать уже не надо.
Шесть признаков и порог по каждому
Каждый признак сформулирован так, чтобы на него можно было ответить «да» или «нет», глядя на процесс, а не на техническое задание. Одного «да» достаточно, чтобы остановиться.
| Признак | Порог | Что происходит в конструкторе | Чем закрывать |
|---|---|---|---|
| Жёсткий SLA по времени ответа | Гарантированный ответ быстрее 30 секунд или доступность выше 99,5 % | Прогон встаёт в общую очередь площадки; гарантии времени выполнения площадка не даёт и в договоре не фиксирует | Собственный сервис с измеримым временем ответа и своим мониторингом |
| Объём данных за один прогон | Больше 500 записей за прогон или файл больше 15 МБ | Прогон упирается в ограничение по времени и памяти, ломается на середине и оставляет половину работы сделанной | Пакетная обработка в коде или выгрузка через промежуточную базу |
| Требования к аудиту | Нужно доказать через год, как система поступила в конкретный день | Журналы прогонов на массовых тарифах хранятся 7–30 дней, версий узлов нет, воспроизвести прогон нечем | Свой журнал с телом запроса и ответа, версионируемый код, хранение по вашему сроку |
| Операция «всё или ничего» | Один шаг меняет данные в двух и более системах и не должен пройти наполовину | Конструктор выполняет узлы последовательно и не умеет откатывать уже сделанное | Транзакция внутри учётной системы или собственный сервис с компенсирующими действиями |
| Отраслевое регулирование с блокировкой | Маркировка, ЕГАИС, ветеринарные документы, медицинские сведения | Сбой означает не потерянную заявку, а остановленную продажу или непринятый документ | Штатные механизмы учётной системы и специализированное ПО, конструктор — только вокруг них |
| Критичность процесса | Остановка процесса останавливает выручку, а починить его умеет один человек | Носитель знания и точка отказа совпадают; в отпуск процесс уходит вместе с ним | Код в репозитории, документация и подрядчик с временем реакции в договоре |
Третий признак — самый недооценённый, и именно он чаще всего оказывается решающим. Процесс, прогон которого нельзя повторить, нельзя и починить с гарантией. Через месяц после инцидента вы не докажете ни клиенту, ни проверяющему, ни себе, что система поступила именно так, а не иначе: журнала уже нет, а сценарий с тех пор трижды правили и предыдущих версий узлов не сохранилось. В процессах, где такой вопрос может возникнуть, это блокер, который не обходится настройками.
Вертикальный список из шести блоков-карточек, каждая разделена на три поля. Карточка 1 «Жёсткий SLA» — порог «ответ быстрее 30 секунд, доступность выше 99,5 %» — вместо «собственный сервис». Карточка 2 «Объём за прогон» — «больше 500 записей или файл больше 15 МБ» — «пакетная обработка в коде». Карточка 3 «Аудит» — «доказать поведение системы год спустя» — «свой журнал и версионируемый код». Карточка 4 «Всё или ничего» — «одна операция в двух и более системах» — «транзакция в учёте». Карточка 5 «Регулирование» — «маркировка, ЕГАИС, ветеринарные документы, медицина» — «штатные механизмы учётной системы». Карточка 6 «Критичность» — «остановка процесса останавливает выручку» — «код в репозитории и подрядчик с SLA». Слева от списка сплошная вертикальная линия с подписью «одно совпадение — стоп». Чертёжный стиль, подписи по-русски.
Что предлагать вместо конструктора
Вариантов замены не один, а три, и выбирают между ними не по бюджету, а по тому, где должна жить логика процесса.
- 1Собственный сервис — когда важны время ответа, объём и воспроизводимость
Код в вашем репозитории, тесты, версии, свои журналы. Дороже на старте — 136 часов против 46 на модельном процессе, — но это единственный вариант, в котором можно доказать поведение системы задним числом и гарантировать время ответа. Полное сравнение двух путей на горизонте 36 месяцев мы считали в материале про low-code или код.
- 2Доработка учётной системы — когда операция должна быть транзакцией
Если шаг меняет документы, остатки и деньги, ему место внутри учёта, а не снаружи: там есть транзакция, проведение и штатный откат. Внешний контур не заменяет эти механизмы и не воспроизводит их. Развилку «дорабатывать 1С или строить обмен» мы разбирали отдельно — доработка 1С или внешняя интеграция.
- 3Отказ от автоматизации этого шага — когда цена ошибки выше цены ручной работы
Самый недооценённый вариант. Шаг, который делает человек десять минут в день, при цене ошибки в остановленную отгрузку не окупается никакой автоматизацией. Иногда правильный ответ — не система, а регламент на полстраницы: что именно проверяет человек и в каком порядке. Мы собрали такие случаи в материале про то, что решается регламентом без денег.
Этот план звучит разумно и почти никогда не выполняется вовремя. Проблема в том, что через год вокруг сценария вырастают другие сценарии: кто-то повесил на него уведомление, кто-то читает его таблицу, отчёт собирается из его результата. К моменту переписывания вы двигаете не один процесс, а куст из пяти-восьми, и половина связей обнаруживается только после отключения. Если решение всё-таки такое — назначайте дату выключения в тот же день, когда собираете сценарий, и запрещайте строить поверх него что-либо ещё.
Три вопроса к процессу, которые дают ответ до сборки
Эти три вопроса задаются владельцу процесса, а не подрядчику, и занимают минут пятнадцать. Они закрывают все шесть признаков и не требуют технических знаний.
- 1Что произойдёт, если этот шаг сегодня не выполнится до конца дня. Если ответ — «ничего, догоним завтра», конструктор подходит. Если ответ — «встанет отгрузка», «касса не пробьёт товар», «пациента не примут», — процесс критичный, и он требует гарантий, которых конструктор не даёт.
- 2Понадобится ли когда-нибудь доказать, как именно система поступила в конкретный день год назад. Если да — сразу считайте свой журнал и версионируемый код; журналы площадки на массовых тарифах живут 7–30 дней, и продлить их до года обычно нельзя ни за какие деньги.
- 3Сколько записей проходит за один прогон и что должно случиться, если связь оборвётся на середине. Больше 500 записей — упрётесь в ограничения прогона. Требование «либо всё, либо ничего» — конструктор так не умеет: он выполнит первые триста и остановится, а откатывать их придётся руками.
Обратите внимание, чего в этих вопросах нет: сложности логики, числа систем, наличия ветвлений. Всё это конструктор переваривает нормально, и именно поэтому решение «подходит или нет» нельзя принять, глядя на схему процесса. Оно принимается по свойствам последствий, а не по свойствам схемы.
Цена ошибки: перенос процесса через год
Считаем на модельном процессе — приём и разбор входящих заявок с записью в учёт. Ставка инженера 3 000 ₽/час. Сборка в конструкторе занимает 46 часов, написание того же процесса кодом с нуля — 136 часов. Через год выясняется, что процесс подпадает под один из шести признаков, и его переносят в собственный сервис.
Год в конструкторе не пропал зря: логика отлажена, требования уточнились, и разработка идёт 120 часов вместо 136. Но эти сэкономленные 16 часов (48 000 ₽) не покрывают ни 138 000 ₽ сборки, ни 144 000 ₽ на перенос состояния, сверку и отключение. Сам переход через год — шаги со второго по пятый — обходится в 504 000 ₽, и это больше, чем стоила бы разработка с нуля в самом начале. Арифметика остаётся отрицательной при любом раскладе, в котором признак был виден заранее.
И это ещё оптимистичный расчёт. В нём не учтён год эксплуатации на решении, которое не подходило: разбор сбоев, ручные догоны, объяснения клиентам. Не учтены и связи, наросшие вокруг сценария за год, — на реальных проектах их разбор добавляет к переносу от 20 до 60 часов, потому что находятся они только после отключения.
Диаграмма из двух столбцов в рублях. Левый столбец «Путь А: сразу код» — сплошной, 408 000 ₽, подпись «136 часов». Правый столбец «Путь Б: конструктор, через год код» — 642 000 ₽, разбит на пять сегментов снизу вверх с подписями: «сборка в конструкторе 138 000 ₽», «разработка 360 000 ₽», «перенос состояния 48 000 ₽», «параллельный прогон 72 000 ₽», «отключение и зачистка 24 000 ₽». Справа от правого столбца вертикальная скобка на верхней части высотой 234 000 ₽ с подписью «переплата, +57 %». Внизу строка: «не учтён год эксплуатации на неподходящем решении и 20–60 часов на разбор наросших связей». Ось — рубли. Чертёжный стиль, подписи по-русски.
Пограничные случаи: конструктор на квартал
Есть ситуации, в которых признак сработал, а конструктор всё равно правильный выбор — потому что решение заведомо временное. Таких случаев три, и у всех одно общее условие.
- Проверка гипотезы. Непонятно, нужен ли процесс вообще и в каком виде. Собрать за 46 часов, посмотреть три месяца на реальном потоке и принять решение — дешевле, чем спроектировать сервис под требования, которых ещё нет. Здесь конструктор работает как макет, и выбросить его не жалко.
- Сезон или разовая кампания. Процесс живёт квартал: приём заявок на сезонную акцию, обработка анкет с мероприятия, разовая миграция данных. Писать под это код бессмысленно — он не успеет окупиться даже теоретически.
- Заглушка на время разработки. Нормальное решение уже в работе и выйдет через два месяца, а процесс нужен сейчас. Конструктор закрывает разрыв, и это его честная роль.
Общее условие у всех трёх одно: дата выключения назначается в тот же день, когда сценарий собирается, и записывается туда же, где живёт паспорт сценария. Без этой даты «временное решение» превращается в постоянное примерно за квартал, а через год вы оказываетесь в расчёте из предыдущего раздела. Второе правило: поверх временного сценария не строят другие сценарии и не завязывают на него отчёты — иначе выключить его в назначенный день станет невозможно.
Когда останавливаться не надо
Эта статья легко читается как «конструкторы опасны», а это неверный вывод. Ни один из шести признаков не срабатывает на большинстве задач, ради которых конструкторы и покупают. Четыре ситуации, в которых сомневаться не нужно.
- Перекладывание данных между системами. Заявка с сайта в CRM, контакт из формы в рассылку, документ из почты в папку. Объёмы небольшие, откат не нужен, задержка в минуту никого не волнует — это ровно та работа, для которой конструктор и создан.
- Уведомления и напоминания. Сообщение менеджеру о новой заявке, напоминание о неоплаченном счёте, сигнал о просроченной задаче. Сбой означает несостоявшееся уведомление, а не остановленный процесс, и цена его невелика.
- Регулярные сверки и отчёты. Ежедневное сравнение остатков в двух системах, сводка по заявкам за сутки, выгрузка в таблицу. Здесь конструктор выигрывает у кода не только ценой, но и скоростью правки: отчёт меняется чаще, чем что-либо другое.
- Процесс, который вы ещё не понимаете. Если требования меняются каждые две недели, писать код — значит переписывать его каждые две недели. Конструктор здесь дешевле именно из-за скорости изменений, и это его главное преимущество перед кодом, а не цена лицензии.
Практический вывод из всего вышенаписанного простой. Шесть признаков проверяются один раз, до сборки, за пятнадцать минут разговора. Если ни один не сработал — собирайте в конструкторе и не оглядывайтесь: на этих задачах он дешевле кода и остаётся дешевле годами. Если сработал хотя бы один — считайте разработку сразу, потому что через год тот же результат обойдётся на 234 000 ₽ дороже.
Конструктор выбирают по свойствам последствий, а не по сложности схемы. Схему он переварит любую.
