Где low-code экономит недели, а где потом забирает месяцы

Согласно исследованию BPMSoft, доля крупных российских компаний, которые используют low-code-платформы или рассматривают такой подход, снизилась с 66% в 2025 году до 34% в 2026 году. Опрос проводился среди 50 крупных российских компаний с выручкой более 10 млрд рублей.

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

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

На этих этапах постепенно выясняется, что low-code — не волшебный способ обойтись без ИТ. Это возможность быстрее создать цифровой объект, за который все равно кто-то должен отвечать.

Почему компании охладели к low-code

Low-code обещал бизнесу понятную вещь: меньше ждать.

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

Для многих задач это действительно сработало. Но затем бизнес столкнулся с другой стороной скорости.

Быстро собрать приложение — не то же самое, что встроить его в компанию.

У приложения появляются владельцы данных, права доступа, интеграции, поддержка, резервирование, аудит действий, изменения регламентов. Пользователи начинают относиться к нему не как к эксперименту, а как к рабочему инструменту. Руководители ждут отчетности. ИТ спрашивает, где это размещено, кто имеет доступ и что будет при сбое.

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

Здесь многих и поджидает разочарование — не в самой технологии, а в ожидании, что она снизит сложность. Да, low-code снижает порог входа в разработку. Но не снижает ответственность за результат.

Где low-code действительно дает эффект

Low-code полезен там, где компания теряет время не на сложной логике, а на организационных препонах. 

Например, сотрудник запрашивает доступ к системе. Заявка уходит в почту. Потом ее пересылают руководителю. Потом в ИТ. Потом выясняется, что не хватает согласования службы безопасности. Через неделю никто не знает, где застрял запрос.

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

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

Еще один сценарий — замена Excel-процессов, которые уже стали слишком дорогими.

Многим знакомо: в какой-то момент таблица превращается в неофициальную систему управления. У нее есть владелец, версии, сверки, ошибки копирования, зависимость от одного сотрудника и регулярные совещания по ней.

Если процесс уже живет, но держится на ручном труде, low-code также может стать промежуточным шагом между хаосом и полноценной системой.

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

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

Где low-code начинает стоить дороже, чем казалось

Проблемы начинаются, когда low-code берут не для подходящей задачи, а для обхода сложного разговора.

Например, бизнес хочет быстро автоматизировать процесс, но сам процесс не описан. У каждого подразделения своя версия правил, а исключений больше, чем стандартных сценариев. В таком случае платформа не наведет порядок. Она просто зафиксирует беспорядок в интерфейсе.

Второй сложный случай — глубокие интеграции.

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

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

Третий риск — теневое ИТ.

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

Так компания получает не цифровую гибкость, а новый слой зависимости. Только менее заметный, чем в классических ИТ-системах.

Отдельная ловушка — временные решения.

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

И вот уже экономия первого месяца превращается в риск для операционного спокойствия.

Карта применимости: куда low-code пускать, а куда — нет

Полезнее говорить не «low-code работает» или «low-code не работает». Работает или не работает не технология, а связка: задача, процесс, данные, команда сопровождения и уровень риска.

Зеленая зона: можно запускать быстро

Low-code хорошо подходит для процессов, где ошибка неприятна, но не разрушительна.

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

Здесь главный выигрыш — время. Вполне конкретные часы сотрудников и руководителей, которые перестают уходить на поиск писем, сверку версий и ручное напоминание.

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

Желтая зона: можно, но только под присмотром

Сюда попадают процессы, которые уже выходят за пределы одного отдела.

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

Здесь нельзя оставлять low-code только в руках энтузиастов. Нужны архитектурные правила: какие данные можно использовать, кто дает доступы, кто тестирует изменения, кто отвечает за поддержку, когда прототип становится промышленным решением.

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

Красная зона: лучше не начинать с low-code

Есть задачи, где скорость первого запуска не должна быть главным аргументом.

Это ядро ERP, CRM или производственного контура. Высоконагруженные системы. Сложные расчеты. Критичные клиентские сервисы. Процессы, где сбой останавливает деньги, поставки, производство или обязательства перед клиентами.

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

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

Что делать компании, которая уже использует low-code

Самое практичное действие — не покупать новую платформу и не запрещать старую. Начать стоит с инвентаризации.

Нужно посмотреть, какие low-code-решения уже живут в компании. Кто ими пользуется. Какие данные в них проходят. Какие процессы от них зависят. Кто может внести изменения. Что произойдет, если решение остановится на день.

Обычно после такой ревизии становится видно три группы.

Первая — полезные локальные инструменты. Их не нужно усложнять. Достаточно минимальных правил и понятной поддержки.

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

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

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

Технология не обязана быть универсальной, чтобы быть полезной. Ей достаточно быть примененной в правильном месте.