Первая волна low-code дала компаниям скорость — и породила «зоопарки» приложений без четко определенных зон ответственности и моделей сопровождения. Теперь ажиотаж в этой сфере угасает, а вопрос управляемости становится все более критичным. О том, как крупный бизнес переосмысляет low-code и почему этот подход превращается в эффективный инструмент только с хорошо проработанной системой правил, рассказал Михаил Миронов, директор отделения Low-code решений IBS.
Эволюция подхода к low-code
Раньше для применения low-code хватало единственного обоснования: бизнесу нужна скорость, а значит требуются инструменты для ускоренного создания приложений. Сейчас этот аргумент по-прежнему важен, но крупным организациям его недостаточно. Для них скорость сама по себе не результат. Главное, чтобы новые приложения можно было встраивать в ИТ-ландшафт, безопасно эксплуатировать, сопровождать, обновлять, масштабировать и связывать с экономикой процессов. Если этого нет, быстрая разработка становится не преимуществом, а новым источником неопределенности.
На этом фоне рынок low-code закономерно выходит из фазы ажиотажа. Это не значит, что компании отказываются от технологии. Просто они начинают относиться к ней более рационально и возвращают low-code в привычные для крупного бизнеса управленческие рамки, которые охватывают контроль, ответственность, безопасность, архитектуру, эксплуатацию и экономику проектов. Компании больше не задаются вопросом, позволит ли low-code быстрее создавать приложения. Практика уже показала, что это возможно. Теперь в центре внимания другой вопрос: как сделать так, чтобы быстрые изменения не нарушали управляемость корпоративной ИТ-среды.
Почему одной скорости мало
Во время первой волны интереса к low-code эту технологию часто воспринимали как способ обойти узкие места классической разработки. Компаниям нужно было быстро менять процессы, запускать новые сервисы, автоматизировать согласования, собирать личные кабинеты и прототипы, но ИТ-команды были перегружены, списки задач в проектах росли, а сроки классической разработки не всегда соответствовали темпам развития бизнеса. На этом фоне low-code выглядел естественным решением, способным снизить порог входа. С этой технологией минимально жизнеспособный продукт можно собрать за недели, а не месяцы, благодаря более быстрой визуальной разработке и доступности готовых типовых компонентов.
Однако у крупного бизнеса есть особенность: он покупает не просто скорость, а предсказуемость. Это хорошо видно на примере корпоративных платформ, в которых компании ценят не только основную функциональность. ERP (система планирования ресурсов предприятия), CRM (система управления взаимоотношениями с клиентами), BPM (система управления бизнес-процессами), ECM (система управления корпоративным контентом) и решения других классов исторически выполняли еще одну важную роль: они задавали рамки процессов. Такие системы предотвращали отклонения от правил, фиксировали роли, определяли права, поддерживали аудит действий, обеспечивали обновление, сопровождение и единые источники данных. Конечно, эти платформы часто казались «тяжелыми» и их было сложно быстро менять, но они обеспечивали порядок.
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. Эти правила должны учитывать критичность процесса, тип данных, интеграции, нагрузку, требования информационной безопасности, срок эксплуатации решения и ожидаемый экономический эффект. Также нужна ролевая модель. Low-code снижает технический порог входа, но не отменяет профессиональные роли. Бизнес-владелец приложения отвечает за цель и эффект, аналитик — за требования и процесс, разработчик — за качество реализации, архитектор — за место решения в ИТ-ландшафте, служба информационной безопасности — за распределение доступа и защиту данных, команда сопровождения — за эксплуатацию.
Не менее важно учитывать архитектурные ограничения. Low-code не должен развиваться отдельно от корпоративной архитектуры, поэтому надо опираться на правила интеграции, шаблоны компонентов, ограничения по данным, подходы к API (программному интерфейсу приложений), требования к журналированию, тестированию и промышленному запуску. Однако запуск приложения еще не конец проекта, поэтому следует продумать модель сопровождения. Бизнесу нужно понимать, кто получает обращения пользователей, кто исправляет ошибки, кто проверяет влияние обновлений платформы, кто отвечает за развитие функциональности и кто принимает решение о выводе приложения из эксплуатации.
Наконец, необходимо рассчитать экономику проекта, ведь low-code нельзя оценивать только по скорости запуска. Важно смотреть на стоимость составляющих полного жизненного цикла: создания, сопровождения, владения платформой, интеграций, обновлений, обучения команды, снижения ручного труда и влияния на процесс.
Какова роль искусственного интеллекта
Развитие ассистентов и агентов на базе искусственного интеллекта — отдельный фактор эволюции low-code. Они усиливают эффект от применения этой технологии, потому что снижают порог создания сценариев и помогают быстрее реализовывать интерфейсы, процессы, документы, задачи и действия в корпоративных системах, но вместе со скоростью растет риск. Если ИИ-агент может не только подсказывать, но и выполнять действия, компании нужны более четкие ответы на вопросы: какие права у агента, какие данные ему доступны, какие действия он может выполнять сам, а какие должен подтверждать человек, где хранится цифровой след и кто отвечает за результат.
Логика здесь такая же, как с назначением прав сотрудникам. Руководитель не дает новому ассистенту полный доступ ко всем договорам, финансовым операциям, почте, CRM-системе и календарю. Сначала определяются роль, полномочия, ограничения и ответственность специалиста. С ИИ-агентами должно быть так же. Low-code и искусственный интеллект нельзя рассматривать только как ускорители, ведь это новые механизмы реализации изменений в корпоративной среде. Это значит, что им нужны роли, правила, ограничения и контроль.
С чего начать оптимизацию
Если компания уже использует low-code или планирует масштабирование, начинать стоит не с очередного пилотного проекта, а с короткой диагностики. В ее рамках минимальный набор вопросов может выглядеть так:
- Какие low-code-решения уже существуют в компании?
- У каждого ли есть бизнес-владелец и ответственный в технической сфере?
- Какие данные и интеграции используют приложения?
- Какие решения стали критичными для процессов?
- Есть ли правила отбора задач для low-code?
- Кто утверждает запуск таких решений в промышленную эксплуатацию?
- Кто отвечает за сопровождение и обновление приложений?
- Как оценивается их экономический эффект?
- Какие решения нужно развивать, объединять или выводить из эксплуатации?
- Где low-code может дать быстрый эффект без роста архитектурного риска?
Ответы на такие вопросы быстро показывают реальную зрелость контура low-code. Иногда в этой сфере компании нужен новый пилотный проект, но зачастую она сначала нуждается в инвентаризации, карте применимости и правилах управления портфелем.
Low-code дает бизнесу ускорение процессов, но крупной компании нужна не просто скорость, а управляемая скорость: с понятными правилами, архитектурой, ответственностью, безопасностью, сопровождением и экономикой проекта. Поэтому главный вопрос сегодня не в том, использовать low-code или нет. Вопрос в том, сможет ли бизнес превратить low-code из набора быстрых инициатив в управляемую производственную систему изменений. Именно в этой точке low-code превращается из технологического эксперимента в инструмент корпоративного развития.
Источник: Михаил Миронов, директор отделения Low-code решений IBS
