Почему перенос ERP в облако не решит вашу проблему с процессами

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

Если заявка на закупку сегодня проходит через три согласования по почте, отдельную таблицу Excel и звонок по телефону, то же самое будет и после миграции. Только теперь всё это крутится на серверах во Франкфурте, а не на машине в подвале.

Облако — это место, а не решение по процессу

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

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

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

Ошибка ленивого обследования «как есть»

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

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

Случай Lidl — самый цитируемый публичный пример. Ритейлер годами строил новую систему управления запасами на базе SAP. Проект свернули в 2018 году, потратив сотни миллионов. Одна из названных причин: Lidl настаивала на том, чтобы подогнать софт под свою модель учёта запасов по цене закупки, вместо того чтобы адаптировать процесс под стандарт. Софт гнули, пока он не сломался.

За двадцать лет до этого Hershey пошла обратным путём и провалилась из-за спешки. Она запустила ERP, CRM и управление цепочкой поставок одновременно, прямо перед Хэллоуином, не оставив времени на стабилизацию процессов. Компания не смогла отгрузить заказы, которые лежали на складе. Технически миграция была сделана; операционная работа всё равно встала.

Что нужно сделать до того, как трогать облако

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

• Опишите реальные процессы, а не те, что в инструкции. Реальный процесс — это то, что люди делают в пятницу в 17:00 с разъярённым клиентом на линии.
• Для каждого кастомного исключения спросите «почему». В половине случаев ответ — правило, которое уже никому не нужно.
• Решите, что вы выравниваете под стандарт. Дорогая кастомизация сегодня — это технический долг, который завтра привяжет вас к поставщику.
• Очистите данные до миграции. Грязные данные в новой системе — это грязные данные, и точка.
• Назначьте владельца каждого процесса. Без владельца никто не отстоит изменение, когда команда начнёт сопротивляться.

Внутреннее сопротивление и есть настоящий проект

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

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

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

Так что, облако того стоит?

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

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

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