Почему проекты цифровой трансформации проваливаются и как это исправить

Неудобная правда

Большинство инициатив цифровой трансформации не приносит обещанной пользы: 70% цифровых трансформаций не достигают своих целей — BCG, 2020. В наших проектах модернизации успешные от остальных отличают одни и те же закономерности.

Ошибка 1: считать это технологической задачей

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

Ошибка 2: пытаться охватить всё сразу

Амбиция преобразовать всё одновременно — частая причина провала. Многолетняя программа, пытающаяся заменить все системы разом, не даёт ранних побед, вытягивает организационную энергию и оставляет вас беззащитными перед меняющимися требованиями.

Ошибка 3: измерять активность вместо результата

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

Что действительно работает

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

Паттерн Strangler Fig для унаследованных систем. Не переписывайте старые системы разом. Стройте новую рядом со старой, постепенно переводя трафик, пока унаследованную не станет безопасно отключить.

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

Роль руководства

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

Как выбрать первый срез

Первый срез решает, поверит ли организация в программу. У хорошего кандидата четыре свойства:

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

Пять вопросов перед началом

1. Какой процесс мы меняем первым и во что он обходится нам сегодня?
2. Кто владеет этим процессом и будет ли он пользоваться новой версией?
3. Что мы будем измерять и кто фиксирует исходное значение?
4. Какую унаследованную систему мы отключим и когда это будет решено?
5. Кто спонсор, который сохранит финансирование, если первый срез пойдёт медленнее плана?

Если какой-то ответ звучит как «решим потом», это и есть первая задача. Технический аудит часто быстрее всего отвечает на вопросы 1 и 4 фактами, а не мнениями.