Low-code снижает нагрузку на ИТ-команды и ускоряет решение задач. Однако без правильного управления изменениями с этой платформой бизнес получает «зоопарк» приложений и постепенно теряет контроль над собственным цифровым контуром. Рассмотрим, почему портфель low-code может превратиться в технический долг и как этого избежать.

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

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

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

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

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

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

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

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

Можно выделить пять основных признаков неуправляемого «зоопарка» low-code-решений:

• Дублирование функций. Например, оно возникает, если разные подразделения создают похожие приложения для заявок, отчетности, согласований или контроля задач. Каждое из них решает локальную проблему, но вместе они усложняют архитектуру, размывают стандарты и мешают масштабировать эксплуатацию компонентов.
• Неизвестные владельцы. Бывает так, что приложение используется, но непонятно, кто отвечает за его развитие, поддержку, данные и принятие решений при изменении процесса. В результате ИТ-команда становится заложником уже работающего решения: бизнес требует стабильности, но формальной ответственности и ресурсов на сопровождение нет.
• Неописанные интеграции. Low-code-решения могут быть связаны с CRM (системой управления взаимоотношениями с клиентами), ERP (системой планирования ресурсов предприятия), документооборотом, хранилищем данных, почтой, календарями или внешними сервисами. Если эти связи не зафиксированы, любое изменение в смежной системе может привести к сбою, который сложно быстро диагностировать.
• Разная зрелость доступа и безопасности. Например, такая проблема возникает, если в одном приложении права настраивают оптимально, в другом их выдают слишком широко, а в третьем используют временные учетные записи, которые становятся постоянными. Пока решений мало, можно вручную обеспечивать безопасность в подобных ситуациях. Когда приложений становится много, ручной контроль перестает работать.
• Отсутствие правил вывода из эксплуатации. В компаниях часто описывают процедуры запуска новых решений, но гораздо реже — регламенты их закрытия. В результате старые приложения продолжают работать, хранить данные, применять права доступа и зависеть от платформы — даже после изменения бизнес-потребности.

Зрелый подход к low-code начинается не с запретов и попыток вернуть все изменения в зону классической разработки. Это было бы неправильно: компаниям действительно нужна скорость, просто ее необходимо встроить в управляемый контур. Он формируется из пяти основных составляющих:

• Единый реестр low-code-приложений. Бизнес должен владеть информацией не только о крупных системах, но и обо всех прикладных решениях, которые создаются на платформах low-code. Должны быть доступны сведения о назначении, владельцах, пользователях, подключенных данных, интеграциях, критичности, статусе, версиях и правилах поддержки приложений.
• Модель владельцев. У каждого решения должен быть бизнес-владелец, отвечающий за цель, процесс и эффект. Также необходимо описывать технический контур ответственности для всех low-code-приложений: кто их сопровождает, обновляет, проверяет безопасность и принимает решения при изменениях.
• Архитектурные ограничения. Не все задачи подходят для исполнения на базе low-code. В одних случаях эта платформа дает быстрый и качественный результат, а в других решения лучше реализовывать иначе. Провести такую границу помогут заранее разработанные критерии применимости. Они должны отвечать на вопросы, какие процессы можно автоматизировать в контуре low-code, какие данные допустимо обрабатывать, какие интеграции разрешены и какие сценарии требуют участия архитектора или службы безопасности.
• Правила сопровождения. Работа над приложением не заканчивается в момент запуска. Его нужно обновлять, тестировать, поддерживать, контролировать доступ, отслеживать инциденты и стоимость владения. Без этих составляющих можно оценить только скорость разработки без учета всех факторов, влияющих на цену решения.
• Управление портфелем. Low-code-приложения нужно рассматривать не как набор разрозненных инициатив, а как портфель изменений. В нем видны повторяющиеся сценарии, потенциальные типовые компоненты, решения с высоким риском, устаревшие приложения и зоны, в которых нужен не локальный инструмент, а системная автоматизация.

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

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

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