7 ошибок руководителей перед автоматизацией бизнеса

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

Это подтверждают и исследования крупных международных организаций. По данным BCG, только 30% крупных технологических программ укладываются одновременно в сроки, бюджет и заявленный объем работ. Еще 35% не достигают ни одной из этих целей. Исследование охватывало более 1 000 руководителей компаний из 59 стран.

Похожую картину показывает исследование Project Management Institute (PMI), опубликованное в декабре 2025 года: только половина проектов сегодня достигает результата, который можно считать успешным с точки зрения созданной ценности; 37% проектов лишь частично дают ожидаемый результат, а 13% терпят неудачу.

В 2026 году PMI отдельно исследовал сложные проекты. Почти треть, 31%, не достигает полного объема запланированных выгод. При этом проекты, в которых команда эффективно управляет сложностью, имеют в пять раз более высокую вероятность успеха.

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

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

1. Начинать с выбора системы, а не с бизнес-проблемы

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

Логика должна быть обратной: сначала бизнес-проблема, затем причина, процесс, данные и только после этого технология.

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

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

Поэтому я начинаю не с вопроса «какую систему будем внедрять?», а с вопроса «какой результат должен измениться после проекта?».

2. Автоматизировать процесс, который еще не определен

Иногда компания хочет автоматизировать процесс, но единого процесса фактически не существует.

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

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

В такой ситуации автоматизация не устраняет проблему. Она просто переносит существующую неопределенность в информационную систему.

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

3. Смотреть на отдельный отдел вместо процесса целиком

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

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

Можно идеально автоматизировать один участок и при этом не улучшить процесс в целом.

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

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

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

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

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

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

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

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

5. Пытаться автоматизировать все одновременно

Когда компания видит большое количество проблем, возникает желание решить их одним масштабным проектом.

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

BCG отдельно отмечает проблемы управления взаимозависимостями, недостаток сквозного планирования и слабое взаимодействие бизнеса и IT среди причин неудач крупных технологических программ.

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

После этого уже можно расширять решение на следующие процессы.

6. Считать запуск системы окончанием проекта

Запуск системы, это не то же самое, что получение бизнес-результата.

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

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

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

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

7. Проектировать систему только под сегодняшний бизнес

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

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

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

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

Хорошая архитектура должна позволять компании развиваться без необходимости каждый раз перестраивать фундамент.

Что объединяет эти ошибки

Во всех семи случаях проблема начинается не с программного обеспечения.

Она начинается с неправильной постановки задачи.

Моя рабочая последовательность выглядит так:

бизнес-проблема → причина → процесс → данные → люди → системы → изменение процесса → измеримый результат.

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

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

Источники

1. Boston Consulting Group (BCG). Most Large-Scale Tech Programs Fail—Here’s How to Succeed. 2024.
2. Project Management Institute (PMI). Step Up: Redefining the Path to Project Success with M.O.R.E. December 2025.
3. Project Management Institute (PMI). Pulse of the Profession® 2026: Driving Success in Complex Projects, From Navigating Tasks to Navigating Systems. May 2026.

Об авторе

Евгений Зубков, IT-консультант и внешний руководитель проектов автоматизации и цифровой трансформации бизнеса, основатель SMSOLUTIONS.

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