Процесс управления цифровизацией: как исправить главную ошибку

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

Консалтинговые оценки здесь неприятно стабильны: McKinsey говорит о 70% проектов трансформации, не достигших целей, BCG — о 75% инициатив, не создающих ценности, Bain & Company — о 88% проектов, не оправдывающих ожиданий. Методологии у этих оценок различаются, но паттерн один: технология редко оказывается главным источником провала. Обычно проблема появилась раньше — на этапе постановки задачи и описания процесса.

Автоматизация хаоса: как ошибка масштабируется вместе с системой

«Автоматизация хаоса» — не просто удачная формулировка для презентации. Это вполне измеримый эффект: компания переносит в новую систему неэффективные правила, лишние согласования, неясные зоны ответственности и плохие данные. После запуска каждый дефект начинает воспроизводиться быстрее, в большем объёме и с более высокой стоимостью исправления.

Типовой сценарий выглядит так. Отдел продаж ведёт клиентов в таблицах, бухгалтерия — в учётной системе, сервисная команда — в мессенджерах. Руководство покупает CRM, чтобы «собрать всё в одном окне». Но перед внедрением никто не договорился:

• что считать лидом, сделкой и активным клиентом;
• кто имеет право менять карточку контрагента;
• на каком этапе сделка передаётся из продаж в производство или поддержку;
• какие поля обязательны, а какие существуют «на всякий случай»;
• какой отчёт нужен руководителю и какое действие должно следовать за его цифрами.

В новой CRM появляются 18 статусов сделки, пять вариантов названия одного и того же продукта и тысячи карточек без владельца. Формально цифровизация состоялась: лицензии куплены, интеграция подключена, дашборд работает. Фактически компания получила дорогой интерфейс к прежней неразберихе.

Автоматизация не лечит процесс. Она увеличивает скорость, с которой процесс производит результат — хороший или плохой.

В этом месте часто возникает опасное заблуждение: «Настроим потом, когда пользователи привыкнут». На практике потом наступает период адаптации, затем появляются исключения, ручные обходы, новые поля и локальные таблицы. Через несколько кварталов система обрастает слоем компромиссов, а любое изменение требует длинной цепочки согласований с ИТ, интеграторами и владельцами смежных систем.

Управление процессами цифровизации предприятия начинается не с интерфейсов. Оно начинается с разборки текущей работы до уровня операций, решений, данных и ролей.

Что именно нужно искать в процессе до выбора платформы

Аудит не обязан длиться полгода и превращаться в академическое исследование. Для большинства процессов достаточно быстро ответить на несколько прикладных вопросов:

1. Какой результат получает клиент или внутренний заказчик?

Не «заявка прошла согласование», а, например, «клиент получил коммерческое предложение с корректной ценой в течение одного рабочего дня».

2. Где возникает ожидание, а не работа?

В процессах редко всё тормозит из-за низкой скорости сотрудников. Обычно время съедают очереди: документ ждёт подписи, менеджер ждёт расчёта, бухгалтер ждёт уточнения реквизитов.

3. Какие решения принимаются по правилам, а какие — по опыту конкретного человека?

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

4. Какие данные создаются, где они становятся эталонными и кто отвечает за качество?

Без этого интеграция не связывает системы, а синхронизирует ошибки между ними.

5. Какой ручной шаг действительно нужен?

Ручная операция не всегда дефект. Иногда она удерживает риск: подтверждает нестандартную скидку, проверяет контрагента, разрешает конфликт в заказе. Убирать её только потому, что «так будет цифровее», — плохая итерация.

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

Почему цифровизация всё чаще упирается не в бюджет, а в качество решений

В 2026 году настроение рынка стало прагматичнее. По данным исследований, 36% крупных российских компаний оптимизируют или сокращают ИТ-бюджеты, ещё 30% удерживают финансирование на прежнем уровне. Увеличивать вложения планируют только 12%.

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

Здесь полезно разделить два разных типа проектов.

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

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

Данные — скрытый лимит для ИИ и автоматизации

Около 58% крупных компаний в России уже внедряют или пилотируют ИИ-решения. Но примерно 35% из них называют барьером низкое качество и разрозненность данных. Это ожидаемый результат: нейросеть не отменяет проблемы справочников, версий документов и неполных карточек. Она делает их заметнее.

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

Поэтому ИИ-пилот нельзя строить по логике «подключим все данные, а дальше модель разберётся». Рабочая последовательность другая:

1. Выбрать один узкий сценарий с понятной ценой ошибки.

Например, поиск ответа в актуальных регламентах для первой линии поддержки, а не универсального «ИИ-помощника для всей компании».

2. Ограничить контекстное окно проверенным набором источников.

Не давать модели всё файловое хранилище. Для первого контура лучше 30 актуальных документов с владельцами и датами пересмотра, чем 30 тысяч файлов без структуры.

3. Настроить права доступа до подключения модели.

Ассистент не должен превращаться в обходную точку доступа к коммерческим условиям, персональным данным или внутренней переписке.

4. Заранее определить, где ответ ИИ допустим, а где нужен человек.

Для черновика письма, классификации обращения или поиска по базе знаний порог риска один. Для решения по кредитному лимиту, цене контракта или кадровому вопросу — совсем другой.

5. Собирать не только положительные отзывы, но и ошибки.

Каждая неверная генерация должна попадать в набор для следующей итерации: уточнения промпта, чистки источника, настройки поиска или изменения бизнес-правила.

Качество ИИ-ответа редко выше качества корпоративного контура данных, на котором он построен.

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

Почему low-code перестал быть универсальным ответом

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

По данным BPMSoft, в 2026 году только 34% крупных компаний рассматривают low-code как инструмент быстрой цифровизации — годом ранее таких было 66%. Это не отказ от подхода, а охлаждение после первых внедрений. Рынок увидел лимиты: быстро собранное приложение может стать новым изолированным контуром, если не продуманы интеграции, модель данных, жизненный цикл доработок и поддержка.

Low-code хорошо работает в трёх типах задач:

• автоматизация локального процесса с устойчивыми правилами: заявки, согласования, внутренние сервисы;
• прототипирование, когда нужно за несколько итераций проверить гипотезу до полноценной разработки;
• оркестрация между уже существующими системами, если платформа умеет работать с API и не дублирует мастер-данные.

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

Проблема интеграции особенно остра: 38% компаний, недовольных отечественным ПО, указывают именно на сложности соединения систем и закрытый API. В целом качеством российских ИТ-решений недовольны около 82% опрошенных компаний; среди причин называют незрелость продуктов и высокую стоимость. Это не повод отказаться от локального стека. Это повод перестать оценивать систему по одной демо-форме.

При выборе платформы нужно проверять не «есть ли в ней ИИ» и не «можно ли собрать процесс без кода», а более приземлённые параметры:

• как система отдаёт и принимает данные;
• есть ли документированный API и насколько он покрывает реальные сценарии;
• как ведутся версии процессов и кто может откатить неудачную настройку;
• можно ли выгрузить данные без ручной археологии;
• как разграничиваются роли и журналируются действия;
• сколько доработок компания сможет поддерживать собственными силами через два года.

Стратегия цифровой трансформации: четыре слоя вместо списка закупок

Стратегия цифровой трансформации часто выглядит как дорожная карта из названий систем: CRM в первом квартале, BI во втором, ЭДО в третьем, ИИ-помощник в четвёртом. Такой план удобен для статуса, но почти ничего не говорит о бизнес-эффекте.

Рабочая стратегия строится сверху вниз — от цели к процессу, затем к данным и только после этого к технологиям.

1. Целевой результат

Формулировка должна быть операционной. Не «повысить клиентский опыт», а «сократить время первого ответа в B2B-поддержке с текущего уровня до согласованного SLA». Не «внедрить сквозную аналитику», а «видеть маржинальность по каналу и кампании до закрытия месяца».

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

2. Процесс и правила

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

Здесь же фиксируют правила, которые нельзя оставлять «в голове у опытного менеджера». Иначе после автоматизации они превратятся в поток ручных исключений.

3. Данные и интеграции

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

Это скучный слой, поэтому его любят переносить на потом. Но именно он определяет, будет ли BI показывать одну правду, а ИИ — отвечать из корректного контекста.

4. Технологический контур

Только теперь выбираются SaaS, ERP-модули, low-code, шина интеграции, BI-инструменты и ИИ-компоненты. Технология становится не центром истории, а исполнителем требований процесса.

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

Люди и роли: дефицит не там, где его обычно ищут

Ещё одна причина, по которой управление цифровизацией буксует, — неверная кадровая модель. В 2026 году 44% компаний отмечают дефицит квалифицированных ИТ-специалистов: архитекторов, экспертов по интеграции, импортозамещению и сложным корпоративным контурам. При этом 22% говорят о перегреве массового сегмента, то есть о переизбытке начинающих специалистов.

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

Для устойчивого проекта нужны как минимум четыре роли:

• владелец процесса — отвечает за бизнес-результат и принимает изменения правил;
• архитектор или сильный интеграционный лидер — удерживает целостность систем, данных и API;
• аналитик процесса — переводит реальную работу подразделений в проверяемые требования, а не в набор пожеланий;
• команда реализации — настраивает, разрабатывает, тестирует и поддерживает контур.

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

Как перезапустить проект, который уже автоматизировал хаос

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

Практический порядок действий такой:

1. Заморозить новые функции, не связанные с измеримым эффектом.

Иначе команда продолжит строить надстройки над неустойчивым основанием.

2. Собрать список ручных обходов.

Таблицы «для себя», согласования в мессенджере, выгрузки по пятницам, правки задним числом — это не вина пользователей, а диагностика дыр в процессе или системе.

3. Выбрать один показатель, который действительно болит.

Например, срок обработки обращения, долю возвратов из-за ошибки, количество дублей клиентов, время подготовки договора.

4. Проверить цепочку от источника данных до финального действия.

Где рождается значение? Кто его меняет? В какие системы оно попадает? Кто на его основе принимает решение?

5. Убрать одну причину, а не десять симптомов.

Иногда эффект даёт не новый модуль, а единый справочник, сокращение числа статусов или отмена лишнего согласования.

6. Запустить пилот на ограниченном контуре.

У пилота должен быть лимит по времени, аудитории и данным. И обязательно — критерий остановки: что считается неудачей, после которой масштабирование не происходит.

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

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

Граница здесь простая. Если команда сначала обсуждает вендоров — она покупает надежду. Если сначала разбирает процесс, считает потери и формулирует результат — она строит управляемую систему.