Чому перенесення ERP у хмару не вирішить твоїх проблем із процесами

На кожній нараді про міграцію ERP звучить та сама обіцянка. «Коли ми будемо в хмарі, усе стане простіше.» Не стане. Хмара змінює те, де працює програмне забезпечення, а не те, як працює твоя компанія.

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

Хмара — це місце, а не рішення про процес

Міграція в хмару розв'язує реальні задачі. Ти більше не керуєш залізом. Маєш керовані резервні копії, еластичне масштабування, оновлення без зупинки операцій. Це варте інвестиції. Але це задача інфраструктури.

Твоя ж проблема майже завжди інша. Це продавець, який погоджує кредит на інтуїцію. Це склад, що розходиться із системою, бо ніхто не реєструє повернення вчасно. Це закриття місяця, яке тягнеться два тижні, бо половина проводок живе в окремих таблицях.

Жодна з цих речей не покращиться від зміни сервера. ERP — локальний чи хмарний — це дзеркало твоїх процесів. Якщо процес заплутаний, дзеркало поверне плутанину, тільки з кращим аптаймом.

Помилка лінивого опису «as-is»

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

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

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

За двадцять років до того Hershey пішла протилежним шляхом і завалила все через поспіх. Запустила ERP, CRM і керування ланцюгом постачання у продакшн одночасно, прямо перед Геловіном, без часу на стабілізацію процесів. Не змогла відвантажити замовлення, товар на які вже лежав на складі. Технічно міграцію було зроблено; операція все одно зупинилася.

Що треба зробити, перш ніж торкатися хмари

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

• Мапуй реальні процеси, а не ті, що в інструкції. Реальний процес — це те, що люди роблять о 17:00 у п'ятницю з роздратованим клієнтом на лінії.
• Для кожного кастомного винятку запитай навіщо. У половині випадків відповідь — правило, яке вже нікому не потрібне.
• Вирішуй, що вирівнюєш під стандарт. Дорога кастомізація сьогодні — це технічний борг, що прив'язує тебе до постачальника завтра.
• Очисти дані перед міграцією. Брудні дані в новій системі залишаються брудними даними, крапка.
• Визнач власника кожного процесу. Без власника ніхто не захищає зміну, коли команда чинить опір.

Внутрішній опір — це і є справжній проєкт

Технічна частина міграції — найпередбачуваніша. API, інтеграції, вікна переходу — на все це є інструкції. Чого немає в інструкціях, так це людей, які виконували старий процес п'ятнадцять років і знають його краще за будь-якого консультанта.

Класичні дослідження з управління змінами одностайні в цьому пункті. Більшість програм трансформації провалюються не через технології. Вони провалюються через виконання, узгодженість і залученість людей. HBR добре підсумовує це в роботі Сіркіна, Кінана і Джексона про жорсткі чинники змін.

Уяви типовий сценарій: завідувач складу отримує нову систему, яка змушує реєструвати кожен рух одразу, а не наприкінці зміни. Для нього нова система — це більше роботи, а не менше. Якщо ти не показуєш йому навіщо і не підлаштовуєш процес під реальність цеху, він повертається до паралельної таблиці Excel. І твій ERP у хмарі стає мертвим і дорогим архівом.

То як, хмара того варта?

Варта. Але з правильних причин. Мігруй у хмару, щоб перестати керувати інфраструктурою, мати еластичність і простіше інтегруватися з рештою свого цифрового стека. Не мігруй у надії, що зміна сервера реорганізує твою операцію.

Послідовність, яка працює, легко проговорити й важко виконати. Наведи лад у процесі. Очисти дані. Узгодь людей. І лише потім вмикай хмару. Хто перевертає цей порядок, платить двічі: один раз за міграцію, другий — щоб її переробити.

Хороший софт не лагодить погану операцію. Він лише прискорює її поломку. Правильне питання ніколи не було «хмара чи локально». Воно звучало так: «чи заслуговують наші процеси на автоматизацію в тому стані, в якому вони є?». У більшості випадків чесна відповідь — ні. І саме тут проєкт починається по-справжньому.