1 октября 2025 г.

Александр Домницкий

По данным НИУ ВШЭ на 2024 год, 21,6% российских компаний используют low-code- или no-code- платформы. Еще 42,3% планируют внедрить их в ближайшее время. По оценкам отраслевых экспертов, в 2025 году доля организаций, применяющих LCNC-инструменты для автоматизации процессов, превысит 70%. Причина такой востребованности — в возможности внедрять решения гораздо быстрее, снижая при этом нагрузку на ИТ. Однако с ростом популярности приходят и риски: сложности с архитектурой, неуправляемое развитие, дублирование решений, хаос в поддержке. О том, почему компании нередко останавливаются на этапе пилотных проектов, не переходя к промышленному масштабу, рассказывает начальник отдела развития платформ и клиентских сервисов IBS Александр Домницкий.

Особый подход к low-code

Зрелое использование low-code начинается с целенаправленного подхода. В некоторых компаниях пилотные проекты на low-code-платформах запускаются в тестовом режиме: без четко сформулированной цели, проработанного ТЗ и оценки ожидаемого эффекта. Такой подход не дает системного результата: даже успешные кейсы не всегда масштабируются и становятся частью устойчивой цифровой архитектуры. Ценность low-code раскрывается, когда решение выходит за рамки одной задачи и интегрируется в общую систему автоматизации большинства процессов компании.

Как выстроить единое цифровое пространство

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

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

Способность адаптироваться имеет важное значение в бизнесе. Low-code-инструменты дают возможность бизнесу оперативно реагировать на изменения рынка. Простой пример: гибкая адаптация процессов в ритейле в праздничные дни, когда выручка за 8 марта, 23 февраля и в новогодний период критична для выполнения финансовых планов — сокращение сроков SLA по обращениям и заявкам, укорачивание процессов согласований и учет прочих «экстренных» мер, которые помогут бизнесу справиться с временным, но многократным увеличением нагрузки, а затем вернуть процесс в стандартное размеренное состояние. С low-code это может сделать даже руководитель подразделения за пару минут. Те компании, которые могут гибко адаптироваться — сохраняют лидирующие позиции.

Переход к единому цифровому пространству на базе low-code строится поэтапно:

  1. Описание ролей, задач, процессов
  2. Создание технического задания и проектирование архитектуры единой системы. Здесь нужно понимать функциональные возможности и ограничения решений, поскольку не все имеет смысл переносить на low-code. Например, бухгалтерию лучше оставить в 1С, так как платформа уже содержит все необходимые механизмы и интеграции, а перенос потребует значительных ресурсов и не всегда будет оправдан коммерчески. Также важно не дублировать системы, а выстроить архитектурно целостную среду
  3. Адаптация платформы под ТЗ, тестирование и реализация

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

Ошибки на старте

Основных ошибок несколько. Бывает, что бизнес, получив преднастроенный демостенд, проводит краткое тестирование и затем предпочитает реализовать проект на 1С, Битрикс24, самописных решениях. Обычно это связано с желанием сиюминутной экономии, но не несет экономической выгоды в долгосрочной перспективе. Недостаток платформенной гибкости и функциональных возможностей за один-три года приведет к отставанию бизнеса от уровня конкурентов, использующих продвинутые программные инструменты, оптимизирующие работу и даже проведя перевнедрение ИТ-ландшафта на новые технологии. Плюс, как правило, в компании есть штат сотрудников, имеющих компетенции в работе с 1С, Битрикс, настаивающих оставить все как есть и подтверждающих, что все пожелания бизнеса реализуемы на имеющихся legacy-системах.

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

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

Управление и роли

Эффективное использование low-code-платформы невозможно без выстроенной системы ролей и зон ответственности. Даже при минимальном масштабе требуется базовая команда:

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

По мере роста числа решений и вовлеченных подразделений структура управления дополняется. Появляются:

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

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

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

Что такое «фабрика приложений»?

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

Так называемая «фабрика» может реализовываться в нескольких форматах:

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

Контроль за «гражданскими» разработчиками

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

  • Обучение и методология. Все участники «фабрики приложений» должны пройти обучение, чтобы понимать архитектуру решений и работать в рамках утвержденных методологических подходов.
  • Инструменты контроля, предпросмотра, тестирования. Современные платформы включают встроенные механизмы тестирования и валидации. Прежде чем приложение будет опубликовано, оно проходит техническую проверку: для внутренних решений ее выполняет администратор или центр компетенций; для публичных модулей в маркетплейсе контроль качества и сертификацию осуществляет сам вендор.

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

Безопасность

Можно выделить несколько ключевых принципов обеспечения безопасности при работе с low-code-решениями:

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

Поддержка и сопровождение

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

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

Выбор платформы

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

Основные рекомендации:

  1. Оцените опыт. Если речь идет о типовых сценариях, при выборе платформы важно учитывать наличие готовых решений с релевантной функциональностью или успешных кейсов по аналогичным задачам. Не менее важно оценить технологические ограничения. Выбор платформы — стратегическое решение, влияющее на скорость масштабирования, управляемость и затраты в будущем, поэтому стоит привлекать хороших экспертов. Ключевой участник этого процесса — квалифицированный консультант, обладающий экспертизой реализации нескольких проектов на разных платформах и понимающий, какие технологии работают эффективно в рамках конкретных задач.
  2. Сравните методологическую зрелость. Обучение, сертификации, наличие партнерской сети и методической поддержки — все это индикаторы того, что платформа готова к масштабному использованию.
  3. Проверьте соответствие платформы требованиям по ИБ, регуляторике и защите КИИ. Это особенно важно для банков, госсектора, а также организаций, подпадающих под действие 187-ФЗ «О безопасности критической информационной инфраструктуры». Обратите внимание на наличие у платформы сертификаций ФСТЭК и ФСБ, а также уровня доверия. Например, четвертый уровень доверия допускает использование ПО в критически важных и защищенных информационных системах.
  4. Тестируйте на практике. Пилотный проект на реальном кейсе покажет удобство интерфейсов, скорость разработки и готовность платформы к ключевым процессам.
  5. Смотрите на экосистему. Чем шире сообщество, маркетплейс и партнерская сеть, тем быстрее можно запускать и масштабировать решения.

Источник: Александр Домницкий, начальник отдела развития платформ и клиентских сервисов IBS