Процесс цифровизации экономики: почему буксует автоматизация

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

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

«Автоматизация хаоса не устраняет хаос — она его масштабирует и ускоряет».

Ловушка автоматизации хаоса: почему ИТ-инструменты не лечат бизнес-процессы

Самый частый сценарий цифровизации бизнеса начинается с правильного симптома и неправильного рецепта. Руководитель говорит: «У нас теряются сделки, нужна CRM». При разборе выясняется, что проблема устроена сложнее: клиентская база хранится в нескольких версиях, менеджеры используют собственные Excel-файлы, договоры согласуются через почту и мессенджеры, а информация о статусе сделки остаётся в личных заметках.

CRM в такой ситуации действительно может быть нужна. Но сама по себе она не ответит на несколько принципиальных вопросов:

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

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

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

Сначала процесс, потом инструмент

До выбора системы нужно описать хотя бы базовую текущую модель — AS-IS. Не в виде многостраничного регламента, который никто не откроет, а как рабочее описание:

• где возникает заявка или документ;
• кто принимает решение;
• какие данные нужны на каждом этапе;
• где информация хранится сейчас;
• что считается завершением операции;
• на каких шагах чаще всего возникают задержки и возвраты.

Затем формируется целевое состояние — TO-BE. В нём важно не просто добавить электронную форму вместо бумажной, а убрать лишние согласования, дублирование ввода и неясные переходы между подразделениями. Если сотрудник сегодня трижды заносит одни и те же сведения в разные таблицы, автоматизация должна решить именно эту проблему, а не только заменить одну таблицу экраном новой программы.

Минимальный набор подготовки к цифровизации выглядит так:

1. Зафиксировать границы процесса. Нужно понимать, где он начинается и где заканчивается. Например, закупка может стартовать с заявки подразделения, а завершаться не оплатой счёта, а фактической приёмкой товара.

2. Определить владельца процесса. Это не обязательно ИТ-директор. Владелец — руководитель, который может менять порядок работы, согласовывать правила и добиваться их исполнения.

3. Выбрать несколько измеримых признаков результата. Для продаж это может быть скорость обработки лида и доля сделок с заполненными данными. Для склада — точность остатков, время приёмки и число ручных корректировок.

4. Разделить обязательное и желательное. Без этого проект быстро превращается в каталог пожеланий разных подразделений.

5. Согласовать правила данных. Названия товаров, клиентов, подразделений и статусы документов должны иметь единый смысл во всех системах.

Такая подготовка не выглядит технологично. На ней нельзя эффектно показать новый интерфейс или объявить о запуске платформы. Зато именно здесь становится понятно, что предстоит автоматизировать и какой результат бизнес считает полезным.

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

В дискуссиях о цифровой трансформации часто цитируют оценку Boston Consulting Group: около 70% инициатив не достигают заявленных целей. Эту цифру не стоит воспринимать как универсальный прогноз для каждого проекта. Она важна по другой причине: провал цифровизации редко бывает следствием одной технической ошибки. Обычно речь идёт о разрыве между стратегией, операционной работой и фактическим использованием системы.

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

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

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

Здесь важно различать три разных результата:

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

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

Барьеры перехода на отечественное ПО: технологическая незрелость и лоскутная инфраструктура

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

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

Переход на отечественное ПО в такой среде часто начинают с замены самого заметного продукта. Например, выбирают новый корпоративный сервис, но не проверяют, как он будет обмениваться данными с учётной системой, кадровым контуром, телефонией и аналитикой. Формально продукт заменён. Архитектурно компания получает ещё один остров.

Четыре типовые ошибки при перестройке ИТ-контура

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

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

3. Перенос старого процесса без пересмотра. Миграция «один в один» кажется безопасной: сотрудники сохраняют привычные шаги, а подрядчик обещает меньше сопротивления. Но вместе с привычками в новую систему переезжают лишние согласования, ручные проверки и неясные зоны ответственности.

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

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

При выборе отечественного ПО нужно смотреть не только на список функций. Не менее важны:

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

Импортозамещение снимает один класс рисков, но не лечит управленческие проблемы. Можно заменить иностранный продукт на отечественный и сохранить тот же хаос в справочниках, процессах и ответственности.

Кадровый голод и делегирование ответственности: главные управленческие ошибки

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

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

Вторая ошибка — считать, что проект принадлежит только ИТ. Система может быть технически исправной, но её внедрение затрагивает продажи, финансы, закупки, склад, юридическую службу и HR. Если функциональные руководители не участвуют в описании процессов, они закономерно воспринимают изменения как внешнюю нагрузку. А затем возвращают старые таблицы и ручные согласования.

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

Как кадровые ошибки превращаются в проблемы проекта

На практике повторяются одни и те же ситуации:

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

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

Базовую цифровую грамотность сотрудников можно подтянуть недорого, например, на программах бесплатного обучения для жителей Нижневартовска и других городов — такие инициативы дают фундамент, без которого любое внедрение буксует на уровне пользователя. Но общего курса недостаточно, если обучение не связано с конкретной ролью. Менеджеру по продажам нужно показать его воронку и правила работы со сделкой, кладовщику — операции приёмки и списания, руководителю — интерпретацию показателей и ответственность за их качество.

Устойчивая команда цифровизации обычно состоит из нескольких ролей:

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

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

Цена неэффективности: как отсутствие оптимизации процессов ведёт к росту затрат

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

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

Вместо выдуманного показательного кейса здесь полезнее смотреть на типовую экономику неэффективности. Затраты растут по нескольким каналам:

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

Признаки такого сценария достаточно заметны:

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

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

Что происходит с рабочими местами

Разговор об автоматизации часто сводят к сокращению персонала. В отдельных сценариях при автоматизации действительно сокращаются рутинные рабочие места — в том числе может использоваться оценка в диапазоне 15–20%. Но это не означает, что вся высвободившаяся работа исчезает, а тем более что одинаковый эффект будет в каждой отрасли.

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

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

Итерационный подход вместо покупки коробки

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

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

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

После запуска нужно проверить:

1. пользуются ли сотрудники системой в повседневной работе;

2. изменилось ли время прохождения операции;

3. стало ли меньше возвратов и ручных исправлений;

4. совпадают ли данные между подразделениями;

5. какие сценарии пользователи обходят и почему;

6. какие доработки действительно влияют на результат.

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

Для контроля проекта полезно держать небольшой набор показателей:

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

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

Что мешает процессу цифровизации экономики на уровне компании

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

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

Ошибки цифровизации бизнеса повторяются из проекта в проект:

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

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

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