CIO против CPO: кто должен владеть low-code в компании

Сергей Лебедев, коммерческий директор компании GreenData

Спрос на low-code платформы стремительно растет. В 2024 году мировой рынок таких решений оценивался в $28,75 млрд и, по прогнозам, к 2032 году вырастет до $264,4 млрд, что соответствует среднегодовому темпу роста 32,2%. В России в 2024 году расходы на автоматизацию процессов с использованием low-code/no-code технологий достигли 5,9 млрд руб.

Low-code — альтернатива традиционному кодированию для создания приложений. Основную работу здесь выполняют с помощью визуальных конструкторов и готовых компонентов. Бизнесу это дает скорость и экономию ресурсов: повторное использование готовых модулей и коробочных решений снижает совокупную стоимость владения до 25%, сокращает сроки внедрения до 30% и разгружает поддержку — показатели SLA (соглашения об уровне обслуживания, определяющего качество и скорость предоставления услуг) повышаются до 50%. Эти показатели подтверждаются практикой внедрений GreenData в крупных российских организациях.Международный конгресс по anti-age и эстетической медицине — ENTERESTET 2026

На практике это означает возможность быстро запускать новые функции для фронтенд-сервисов, CRM и клиентских порталов, улучшать пользовательский опыт и сразу видеть эффект через показатели вроде time-to-value, NPS, конверсии и вовлеченности. Системы управления бизнес-процессами (BPM) также выигрывают от low-code: платформы позволяют поддерживать нужный ритм работы, оперативно обновляя процессы без риска для SLA. Кроме того, low-code помогает стандартизировать работу ITSM и ESM, контролировать нагрузку и ускорять выпуск обновлений. Даже решения для коллекторских процессов, ЭДО и КЭДО можно быстро масштабировать.

CIO vs CPO: разделение ответственности

Но при внедрении low-code возникает вопрос: кто отвечает за технологию и ее использование в компании — директор по ИТ (CIO) или директор по продукту (CPO/CDTO)? С одной стороны, low-code дает бизнесу возможность обходиться без участия ИТ-департамента: ведь теперь приложения можно собирать буквально «из кубиков», без программистов. С другой, это все-таки ИТ-проект, поэтому по профилю за него должен отвечать CIO.

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

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

Ключ CIO

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

Ключ CPO

CPO (или CDTO) отвечает за бизнес-ценность и скорость вывода готовых решений. Его зона — это продуктовое наполнение платформы. Он управляет списком задач и идей для развития (бэклог), определяет приоритеты бизнес-кейсов в зависимости от их влияния на результаты компании, а также решает, использовать ли готовые («коробочные») возможности платформы или разрабатывать кастомные решения под конкретные потребности. Он контролирует продуктовые метрики и доказуемые бизнес-эффекты: time-to-value (время до получения ценности), удержание пользователей, NPS внутренних клиентов (индекс лояльности) и долю автоматизации процессов.

Совместная ответственность

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

Операционная модель: как работать вместе

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

1. Коробка или кастом: как найти баланс между скоростью и гибкостью. Совместная работа CIO и CPO начинается с договоренности о приоритетах: использовать готовые решения или разрабатывать кастомные. Основное правило — не изобретать велосипед. Если задачу можно решить с помощью готового модуля или шаблона за 3 месяца, выбирают «коробочное» решение. CPO оценивает его с точки зрения бизнес-метрик и скорости достижения ценности, а CIO проверяет совместимость, безопасность и масштабируемость. Приоритетные направления для «коробочных» решений: управление ресурсами, операционная эффективность, ЭДО и КЭДО, дистанционный мониторинг, CRM и ITSM, где сейчас наблюдается наибольшее число внедрений и проектов импортозамещения. Для уникальных задач допускается ограниченная кастомизация, но с обязательным планом возврата к стандарту.

2. Два владельца результата. В этой модели нет «главного» — есть два владельца. Любой релиз проходит по принципу двойного согласования: технологического и продуктового. Только после этого он запускается в работу.

3. SLA как внутренний контракт. Все стороны работают на основании прозрачных SLA. Это сервисный уровень обслуживания, то есть договор, который четко определяет, как быстро и качественно должна работать система. Обычно SLA заключают с внешними поставщиками, но внутри компании тоже нужны свои правила, называемые OLA — внутренние соглашения о том, как ИТ и бизнес будут работать вместе, чтобы выполнять SLA. На практике то, что зафиксировано в договорах с вендором, должно стать основной для OLA между ИТ и продуктовым направлением. В компании должен действовать принцип «ноль багов». Это значит, что любая ошибка рассматривается не как естественное явление, а как сбой процесса. Если что-то ломается или работает неправильно, это сигнал, что взаимодействие ИТ и бизнеса можно улучшить.

4. Выбор платформы. Рынок насыщен «псевдо low-code». Незрелые инструменты, которые не могут обеспечить должную безопасность и интеграцию с корпоративной архитектурой, создают иллюзию простоты, но в долгосрочной перспективе лишь порождают «зоопарк» разрозненных сервисов. Поэтому CIO и CPO должны вместе определять выбор платформы.

5. Вендорский надзор как страховка. Вендор может понадобиться не только на этапе внедрения платформы — особенно когда речь идет о комплаенсе или защите критически важных информационных систем (КИИ). Возможность привлечь внешнего специалиста для методической и экспертной поддержки становится своего рода страховкой качества продукта и управляемости изменений и помогает CIO и CPO работать согласованно.

6. Обучение — часть стратегии. Low-code платформы раскрывают всю свою силу только тогда, когда команды владеют инструментом. ИТ и продуктовое направление делят между собой задачи по развитию внутренних компетенций, при необходимости обращаясь к вендору за методологической поддержкой. CIO обеспечивает технологическую основу и стандарты, а CPO отвечает за развитие продуктовых компетенций и использование платформы для реальных бизнес-задач. ИТ-команды осваивают администрирование, безопасность и архитектуру решений, а продуктовые — логику построения процессов и UX. Сотрудники проходят треки от уровня junior до senior, осваивая весь функционал платформы и лучшие практики работы.

7. Принцип «анти-пилот». Low-code не для эксперимента ради эксперимента. Каждый пилотный проект должен иметь четкие метрики успешного запуска и дату выхода в промышленную эксплуатацию. Если даты нет, пилота быть не может. Такой подход дисциплинирует и CIO, и CPO: для CIO важно, чтобы решения не застревали в «песочнице» и проходили все этапы внедрения в продуктивный контур, а для CPO — чтобы пилоты приносили измеряемую бизнес-ценность.

8. Реинжиниринг вместо копирования. Миграция на новую платформу — это не повод просто повторить старые процессы. Синдром «как было — но на новом» приводит к тем же узким местам. Low-code дает шанс переосмыслить работу. Здесь тоже важно участие обеих сторон: CIO отвечает за корректную интеграцию с существующей архитектурой, а CPO — за то, чтобы сам процесс стал проще и создавал ценность.

9. Реалистичные ожидания от ИИ. Генеративный и предиктивный ИИ ускоряет моделирование процессов и тестирование гипотез, а low-code позволяет быстро внедрять эти модели в реальные процессы, что очень полезно CPO. Но ИИ не заменяет бизнес-логику, экспертизу и требования безопасности, за которые отвечает CIO. Нужно строить реалистичные сценарии его использования, а не ждать магии.

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