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