Low-code на честном слове: что первое сломается на масштабе

Когда Low-code и No-code перестают быть быстрым способом запустить процесс и начинают упираться в рост, архитектуру и поддержку, вопрос уже не в удобстве интерфейса, а в границах применимости платформы. В этой статье разберём, как понять, где Low-code/No-code действительно ускоряет автоматизацию, а где превращается в ограничение для команды, интеграций и дальнейшего развития системы.

На примере бизнес-приложения IDM (Identity Management) мы покажем, как меняется подход к разработке, если использовать No-code, Low-code или Pro-code инструменты. Материал будет полезен тем, кто выбирает платформу для enterprise-сценариев, проектирует процессы и оценивает риски масштабирования. 

Дальше слово экспертам: Илье Радченко, директору по платформенным продуктам SimpleOne, и Евгению Котухову, ITSM/ITAM эксперту и технологическому партнеру SimpleOne.

Почему крупному бизнесу нужна универсальность

В небольших командах платформа автоматизации часто решает узкую задачу: собрать заявки, настроить пару маршрутов согласования, наладить уведомления. Для крупного бизнеса планка другая. Здесь автоматизация — не разовая инициатива, а долгосрочная программа изменений: процессы эволюционируют, оргструктура перестраивается, появляются новые системы и требования безопасности, растет нагрузка, меняются правила отчетности. И платформа должна выдерживать этот рост без пересборки на другой технологии.

Типичная проблема внедрений: компанию устраивает скорость старта, но через 1–2 года выясняется, что критичную часть нельзя реализовать средствами платформы. Причины повторяются из проекта в проект:

• Специфичные процессы и регламенты. В Enterprise почти всегда есть правила, от которых нельзя отказаться ради коробочного сценария: внутренние политики, требования ИБ, отраслевые нормы, формат обязательной отчетности.

• Интеграции и сквозные сценарии. Пока процесс живет внутри платформы, его легко собрать визуально. Но как только он должен управлять внешними системами (каталоги пользователей, учетные системы, почтовые сервисы, инфраструктура), нужны расширения, обработка ошибок, очереди, аудит.

• Нагрузка и масштабирование. Решение, которое отлично работает в одном отделе, начинает буксовать при тиражировании на всю компанию: больше ролей, больше справочников, больше исключений, больше параллельных процессов.

• Необходимость менять и дорабатывать без остановки бизнеса. Крупные организации не могут позволить себе заморозить процесс на полгода ради переписывания систем. Нужна модель, где изменения — от мелких правок до новых модулей — вносятся регулярно, быстро и недорого.

Если платформа не поддерживает путь от простых изменений к сложной разработке, компания оказывается перед неприятным выбором: либо ограничивать требования («делаем как умеет инструмент»), либо строить отдельную разработку рядом (и получать зоопарк решений), либо менять платформу целиком. Для Enterprise это дорого не только по бюджету, но и по рискам: миграция данных, переобучение пользователей, повторная настройка интеграций, пересогласование процессов с ИБ и бизнесом.

В крупном бизнесе универсальность решения значит не «много функций», а отсутствие тупиков». Современная Enterprise‑платформа должна позволять стартовать быстро, но не ограничивать развитие. Универсальность здесь — это три уровня разработки:

1. No-code для скорости и управляемых изменений — когда аналитик или владелец процесса может самостоятельно адаптировать формы, статусы, маршруты, правила, не превращая каждую правку в мини‑проект.

2. Low-code для кастомизации и защиты от ограничений — когда типовых настроек уже недостаточно, но до «тяжелой разработки» можно закрыть задачу небольшими скриптами, правилами, виджетами и расширением логики.

3. Pro-code для полноценной разработки бизнес‑приложений и промышленных решений — когда нужна сквозная автоматизация, сложная логика согласований, нестандартный UI, интеграции с внешними системами и надежная обработка исключений.

Уровни разработки на SimpleOne и их возможности

Такая лестница зрелости снижает риски при внедрении внедрения: компания понимает, что платформа не закончится на первом успешном пилоте — на ней можно строить решения уровня бизнес‑приложений, упаковывать их в пакеты и масштабировать на другие подразделения или контуры.

No-code — простая автоматизация с использованием конструктора рабочих процессов (Workflow)

В крупной компании ценность No-code не только в том, что можно сделать быстро. Важнее другое: No-code снижает стоимость изменений. Когда процесс живет, его неизбежно придется донастраивать — добавлять поля, менять маршруты согласования, уточнять правила назначения, перестраивать статусы и уведомления. Если для каждого такого шага нужно подключать разработчиков или вендора, скорость улучшений падает, а пользователи перестают верить в автоматизацию.

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

Какие задачи закрывает No-code

1. Быстрый запуск типовых процессов.

Запросы сотрудников, согласования, маршрутизация заявок, уведомления, контроль сроков — все то, что составляет основу сервисных и внутренних процессов (ИТ, HR, АХО, безопасность, закупки). Важно, чтобы это настраивалось без кода: бизнесу нужен быстрый результат и понятный цикл изменений.

2. Прозрачность и управляемость через workflow.

Даже простая автоматизация ценна, когда она делает процесс измеримым: видно, где заявка находится, кто ответственный, какие сроки (SLA/SLO), где узкие места, какие этапы застревают. Это превращает разрозненные коммуникации в управляемый поток работ.

3. Адаптация форм и данных под компанию.

На уровне No-code платформа должна позволять создавать и менять структуру данных: справочники, карточки, формы, поля, отображение в интерфейсе. Это важно не только для удобства пользователей, но и для качества данных — без него не будет нормальной аналитики и контроля.

Пример Workflow конструктора SimpleOne

На примере бизнес-приложения IDM: автоматизация подачи заявки на доступ без разработки

Хороший показатель возможностей No-code — сценарии, где компания начинает с минимально жизнеспособной автоматизации, а затем наращивает глубину.

Например, процесс управления доступами сотрудников в базовом виде может выглядеть так:

1. сотрудник или руководитель создает запрос на выдачу доступа;

2. платформа автоматически регистрирует заявку, назначает ответственных по правилам, выставляет целевые сроки;

3. запускается маршрут согласования (по роли/группе/категории запроса);

4. после согласования заявка уходит в исполнение — зачастую пока еще в ручной режим, когда ответственная группа выдает доступ в целевой системе и фиксирует результат.

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

Это еще не сквозная автоматизация, но уже рабочая и полезная стадия: появляется единый поток заявок, дисциплина исполнения, контроль сроков, история действий и измеримость процесса. И что критично для Enterprise — такой контур можно запустить быстро и без тяжелой разработки, а дальше развивать: добавлять проверки, интеграции, новые ветки согласований, исключения и обработку ошибок.

Low-code — страховка от ограничений вендора и кастомизация без «тяжелой разработки»

No-code хорошо работает, пока процесс укладывается в типовую логику: статусы, маршруты, роли, уведомления, SLA. Но в крупной компании почти сразу появляются нюансы, которые сложно закрыть чистым конструктором: условные проверки, нестандартные зависимости между полями, особая логика согласования, специфичные уведомления, дополнительные элементы интерфейса. 

Если платформа на этом этапе требует  внесения изменения только через вендора или предлагает единственный путь — полноценную разработку, скорость изменений резко падает. Когда простая доработка превращается в очередной цикл согласований, релизов и зависимости от внешнего подрядчика, организация сталкивается с эффектом «паралича изменений» — когда улучшения откладываются, потому что слишком дороги и медленны.

При этом Low-code — не только прослойка между конструктором и разработкой. На этом уровне можно создавать и самостоятельные прикладные решения без сложной разветвленной логики — например, внутренние реестры, сервисные интерфейсы, формы и небольшие рабочие кабинеты для конкретных функций. 

Пример клиентского скрипта: при создании инцидентов и запросов система автоматически указывает в заявке текущего пользователя и его основную группу

Low-code закрывает зону, когда бизнесу недостаточно типового конструктора и нужно больше гибкости, но задача еще не тянет на отдельный проект разработки. И здесь появляется важная для Enterprise «страховка» — компания не упирается в ограничения платформы на уровне повседневных улучшений.

Что обычно относится к Low-code на современных платформах

1. Условия и проверки в данных и интерфейсе.

Классическая история: поле становится обязательным только при определенном значении в другом поле; меняется доступность секции формы в зависимости от роли; система проверяет корректность набора параметров перед переводом заявки в следующий статус. Как правило, это небольшая логика — но она критична для качества данных и соблюдения регламентов.

2. Усложнение workflow без переписывания процесса.

Например, согласование зависит не просто от «группы», а от комбинации условий: типа доступа, подразделения, роли заявителя, критичности сервиса. Или появляются дополнительные ветки: «если запрос создал руководитель — он не должен повторно согласовывать свою же заявку». Такие правила часто реализуются небольшими скриптами/правилами — и это типичный слой Low-code.

3. Кастомные уведомления и точечные элементы UX.

Enterprise-процессы живут на коммуникациях: кому, когда и что именно отправлять; что показывать на портале; как подсвечивать риски просрочки. Здесь появляются кастомные виджеты, небольшие расширения интерфейса, дополнительные подсказки и сценарии.

Важно, чтобы этот уровень изменений был доступен не глубокой разработке, а команде внедрения: аналитику, системному администратору платформы, разработчику, который решает точечные задачи быстро и безопасно.

На примере бизнес-приложения IDM: как развивается сценарий управления доступами на Low-code

Если продолжить пример с заявками на доступ, то следующий шаг после базового No-code процесса обычно выглядит так:

• появляются проверки на этапе создания заявки: корректность параметров, обязательность определенных полей, подсказки пользователю;

• усложняются правила согласования (в зависимости от типа доступа, подразделения, роли, критичности);

• добавляются уведомления и контрольные точки — чтобы процесс был предсказуемым и не зависел от ручных напоминаний;

• формируется учетная логика: например, фиксация факта выдачи доступа в отдельном регистре/таблице для последующего контроля.

Это еще не уровень полной сквозной автоматизации с изменениями во внешних системах, но уже заметный рост зрелости: процесс становится точнее, надежнее и ближе к требованиям ИБ и аудита.

Pro-code — следующий уровень разработки корпоративных решений

Где заканчивается Low-code и начинается Pro-code? Обычно не в одной конкретной точке, а в момент, когда решение, созданное на платформе, перерастает возможности стандартных инструментов — workflow, бизнес-правил, форменных настроек и точечных скриптов. По мере развития процесса бизнесу становится недостаточно внутренней автоматизации: появляются требования к сквозной логике, интеграциям с корпоративными системами, автоматическому выполнению действий во внешнем контуре, обработке ошибок, аудиту и нестандартным интерфейсам. 

В SimpleOne Pro-code — это возможность построить полноценное бизнес‑приложение на базе платформы, не ограничиваясь стандартными сценариями. Важно, что речь не о доработках вокруг системы, а о разработке внутри единого стека: с управлением данными, интерфейсом, процессами и интеграциями. Так, например, SimpleMES создала на базе SimpleOne промышленную MES-систему для управления производством.

Ниже — пример того, как этот переход выглядит на сценарии автоматизации управления доступами сотрудников, чтобы снизить ручную нагрузку.

На примере бизнес-приложения IDM: как выглядит решение на Pro-code

1. Подача заявки на портале и сбор параметров.

Пользователь выбирает тип доступа, систему/ресурс, получателя (себя или группу сотрудников), параметры. Уже на этом этапе может работать логика Pro-code: динамические элементы формы, предзаполнение, сложные проверки и подсказки.

2. Умное согласование с множественными зависимостями.

На уровне Pro-code согласование становится многомерным: система анализирует не только роль и тип запроса, но и историю предыдущих одобрений, нагрузку на согласующих, сроки, бюджетные лимиты. Например, заявка на закупку может автоматически маршрутизироваться через разные цепочки в зависимости от суммы, категории товара, остатка бюджета подразделения и загруженности финансового контролера. Если основной согласующий в отпуске или перегружен — запрос автоматически перенаправляется заместителю с уведомлением и эскалацией. Такая логика требует обработки множества переменных, интеграции с HR-системой (отпуска), бюджетной системой и календарями — это уже полноценная разработка.

3. Автоматическое выполнение во внешнем контуре (интеграции).

Ключевой шаг — платформа не просто передает заявку исполнителям, а сама вносит изменения во внешние системы (например, в каталог учетных записей/групп). Для этого используется интеграционный слой и агент (например, MID‑agent), через который запускаются скрипты и выполняются операции в целевой инфраструктуре.

Здесь проявляется разница между «автоматизацией процесса» и «автоматизацией результата». Во втором случае бизнес получает реальную экономию времени: доступ выдается не потому, что кто-то увидел заявку, а потому что платформа выполнила действие сама.

4. Обработка исключений и отказоустойчивость.

Enterprise‑автоматизация всегда должна учитывать, что внешние системы могут быть недоступны или ответить ошибкой: агент не в сети, неверные параметры, конфликт в каталоге, ограничение прав. На уровне Pro-code строится «страховочная» логика:

• если автоматическое выполнение невозможно — заявка переводится в ручной режим;

• назначается ответственная группа на выполнение вручную;

• автоматически создается инцидент/уведомление о сбое интеграции (например, «агент недоступен»);

• фиксируются попытки выполнения и причины ошибок для аудита и последующего улучшения процесса.

Такой сценарий позволяет автоматизации стать надежным промышленным механизмом, а не скриптом, который работает, когда повезет.

5. Контроль факта выдачи доступа и сверка данных.

Дополнительно решение может вести реестры выданных доступов и поддерживать обратную сверку: периодически получать актуальные данные из внешних систем (какие учетные записи активны, в каких группах состоит сотрудник) и сравнивать их с тем, что прошло через заявки. Это закрывает реальную боль крупных организаций: изменения могут происходить «в обход процесса», и их важно обнаруживать.

Почему это именно разработка бизнес‑приложения, а не доработка процесса

Для сложных корпоративных сценариев – платформа становится средой разработки, где можно создавать:

• кастомные виджеты, которые показывают нагрузку, риски SLA, приоритеты и динамику по заявкам;

• массовые операции и расширенные представления списков;

• интеграционные интерфейсы;

• действия рабочих процессов;

• замена стандартных UI‑компонентов, если бизнесу нужна другая логика взаимодействия.

Когда логика оформлена как приложение на платформе, ее можно упаковывать и переносить (например, в виде пакетов) между инстансами и контурами: разворачивать в других подразделениях, адаптировать под другую оргструктуру и справочники, использовать как основу для новых решений. Это делает разработку экономически оправданной: одна команда создает зрелый процесс, а затем организация масштабирует его на весь периметр — без переписывания с нуля.

Выводы

Крупному бизнесу недостаточно платформы, которая помогает быстро стартовать и закрыть типовые сценарии. На практике процессы усложняются, появляются интеграции, требования ИБ и аудита, нагрузка и необходимость регулярных изменений. Если в этот момент платформа упирается в ограничения, компания получает высокий риск: заморозку развития, рост ручного труда или повторное внедрение другой системы.

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