Галузева статистика каже, що 50-75% ERP-проектiв не досягають своїх цiлей. Ця цифра звучить драматично, але наш досвiд її пiдтверджує - не тому, що ERP-ПЗ погане, а тому, що однi й тi самi помилки повторюються в кожному проектi. Пiсля впровадження Odoo для 50+ компанiй у виробництвi, роздрiбнiй торгiвлi, освiтi та послугах ми можемо з неприємною точнiстю передбачити, якi проекти матимуть труднощi, виходячи з того, як проходять першi два тижнi.
Причина перша: погане збирання вимог. Це найпоширенiша точка збою, i вона стається до того, як буде зроблено хоч один рядок конфiгурацiї. Типовий сценарiй: компанiя знає, що потребує ERP, але не задокументувала свої реальнi процеси. Вони кажуть 'нам потрiбне управлiння складом', не уточнюючи, що використовують три склади з рiзними стратегiями пiдбору, мають консигнацiйний товар вiд двох постачальникiв i потребують вiдстеження партiй для регуляторного комплаєнсу. Партнер iз впровадження бере розмиту вимогу, налаштовує базовий склад, а через три мiсяцi клiєнт каже 'це нам не пiдходить'.
Виправлення жорстко просте, але потребує дисциплiни: витратьте 2-4 тижнi на картографування процесiв, перш нiж торкатися Odoo. Пройдiть кожен вiддiл, задокументуйте кожен робочий процес, iдентифiкуйте кожне виключення. Не те, яким вони хочуть процес, а те, яким вiн насправдi є сьогоднi, включно з обхiдними шляхами та кроками на кшталт 'з цим ми працюємо в Excel'. Ми використовуємо структуровану анкету дослiдження для кожного модуля, яка змушує давати конкретнi вiдповiдi. Коли клiєнт каже 'стандартне виставлення рахункiв', ми ставимо 15 уточнюючих запитань про умови оплати, кредитнi лiмiти, повторюванi рахунки, мультивалютнiсть, податковi сценарiї та робочi процеси затвердження. Фаза дослiдження повинна створити документ, який обидвi сторони пiдписують.
Причина друга: вiдсутнiсть пiдтримки з боку керiвництва або вiдсутнiй чемпiон проекту. Впровадження ERP потребує рiшень, що перетинають вiддiльнi межi. Коли змiна процесу команди продажiв впливає на робочий процес складської команди, хтось iз повноваженнями повинен прийняти рiшення. Якщо проектом володiє IT або менеджер середньої ланки, який не може переважити керiвникiв вiддiлiв, рiшення застрягають у комiтетi. У нас був проект, який зупинився на шiсть тижнiв, бо два керiвники вiддiлiв не могли домовитися щодо робочого процесу затвердження замовлень на закупiвлю, а нiхто не мав повноважень прийняти остаточне рiшення.
Рiшення: iдентифiкуйте виконавчого спонсора до початку проекту. Цiй людинi не потрiбно бути на кожнiй нарадi, але вона повинна бути доступною для рiшень протягом 48 годин i готовою забезпечувати дотримання дедлайнiв. Найкращi проекти, якi ми вели, мали COO або CFO, який вiдвiдував щотижневу статусну нараду, приймав рiшення на мiсцi та тримав свої команди вiдповiдальними за вчасне виконання завдань.
Причина третя: недооцiнка мiграцiї даних. Кожна компанiя думає, що її данi чистi. Вони нiколи такими не є. Записи про клiєнтiв iз дубльованими записами, каталоги товарiв iз непослiдовним iменуванням, бухгалтерськi данi з необґрунтованими коригуваннями, записи про спiвробiтникiв iз вiдсутнiми полями. Ми бачили, як мiграцiя даних поглинала 30-40% загальних зусиль проекту, коли спочатку закладали 10%.
Пiдхiд, який працює: почнiть мiграцiю даних на першому тижнi, а не в кiнцi. Експортуйте зразок iз кожного модуля, очистiть його, iмпортуйте в тестовий iнстанс Odoo i валiдуйте з користувачами. Робiть це iтеративно - перший iмпорт виявить проблеми якостi даних, про якi ви не знали. Закладiть щонайменше 3 повних цикли очищення-валiдацiї перед iмпортом на go-live. I призначте власника даних у кожному вiддiлi, вiдповiдального за валiдацiю мiгрованих даних його вiддiлу.
Причина четверта: недостатнє навчання та управлiння змiнами. Це те мiсце, де технiчно успiшнi проекти зазнають невдачi на практицi. Система налаштована правильно, данi мiгрованi, усе працює в тестуваннi - а потiм реальнi користувачi вiдхиляють її, бо їх не пiдготували належним чином. Навчання, що складається з 2-годинної сесiї за тиждень до go-live, - це не навчання. Це формальнiсть.
Ефективне навчання починається пiд час впровадження, а не пiсля. Ключовi користувачi з кожного вiддiлу повиннi бути залученi до процесу конфiгурацiї, тестувати з реальними сценарiями та надавати зворотний зв'язок протягом усього проекту. Перед go-live ми проводимо щонайменше двi повноциклiчнi симуляцiї, де користувачi обробляють реалiстичнi транзакцiї вiд початку до кiнця. Ми також створюємо короткi вiдеогайди (2-3 хвилини кожен) для поширених завдань, бо нiхто не читає 50-сторiнкових iнструкцiй. Перший мiсяць пiсля go-live повинен мати присвячену пiдтримку - або вiд партнера впровадження, або вiд внутрiшнiх суперкористувачiв, якi можуть допомагати колегам у реальному часi.
Причина п'ята: вибiр не того партнера з впровадження. Це мета-причина - це причина, чому всi iншi причини не отримують вирiшення. Партнер, який не наполягає на належному зборi вимог, не спонукає до пiдтримки керiвництва, недооцiнює мiграцiю даних, щоб виграти тендер, i трактує навчання як другорядне, програмує проект на невдачу.
Червонi прапорцi при оцiнцi партнерiв: вони дають вам фiксовану цiну до розумiння ваших вимог. Вони обiцяють нереалiстично коротку часову лiнiю. Вони не можуть надати референси вiд компанiй схожого розмiру у вашiй галузi. У них немає структурованої методологiї, i вони iмпровiзують. Вони погоджуються з усiм, що ви говорите, замiсть того, щоб пiдштовхнути вас до перегляду поганих iдей.
Зеленi прапорцi: вони витрачають значний час на дослiдження до цiнової пропозицiї. У них є задокументована методологiя впровадження. Вони чеснi щодо того, що Odoo не робить добре. Вони пiдштовхують вас, коли ви хочете пропустити кроки. У них є кейси з конкретними метриками, а не просто логотипами. Вони говорять про управлiння змiнами та навчання як про основнi компоненти проекту, а не як про додатки.
Незручна правда в тому, що бiльшiсть невдач ERP-проектiв можна запобiгти. Патерни вiдомi, рiшення не секретнi, i все ж компанiї продовжують робити тi самi помилки, бо прiоритизують швидкiсть i вартiсть над процесом. Витратити додатковий мiсяць на початку на належне дослiдження, забезпечення пiдтримки керiвництва, ранiй старт мiграцiї даних i належне планування навчання заощадить вам 6-12 мiсяцiв болю, переробок i змарнованого бюджету в кiнцi.