Etapy wdrożenia ERP: trzy podejścia i jak wybrać właściwe

Kiedy ktoś pyta mnie o etapy wdrożenia ERP, najpierw chcę zrozumieć, jak jego firma wyobraża sobie dojście do uruchomienia. Czy potrzebuje systemu zbudowanego na podstawie szczegółowych wymagań, który dopiero później odbiorą użytkownicy? Czy ludzie mogą próbować całych procesów w miarę powstawania rozwiązania? A może są gotowi zacząć od standardowych funkcji i trochę zmienić własny sposób pracy?

Z tych rozmów zwykle wyłaniają się trzy podejścia: klasyczne wdrożenie sekwencyjne, rozwój iteracyjny z jednym wspólnym uruchomieniem oraz start od standardu i późniejsze usprawnienia. Wybieram między nimi, patrząc na ryzyko dla codziennej działalności, elastyczność firmy i gotowość ludzi do zmian.

Migracja danych, szkolenia i dokumentacja są potrzebne w każdym z tych wariantów. Zmienia się kolejność pracy, moment, w którym użytkownicy przekazują uwagi, oraz to, ile dostosowań robimy przed startem, a ile już po nim.

Trzy sposoby na zorganizowanie wdrożenia

Najpierw zestawię je obok siebie, żeby było jasne, czym się różnią. Za chwilę przejdę przez każdy z nich dokładniej.

Rozwijać system częściami i uruchamiać go częściami to dwie różne decyzje. Możemy pracować iteracyjnie, a mimo to przełączyć firmę na nowy ERP w jednym wspólnym momencie.

Etapy wdrożenia ERP: co ma powstać, kto odpowiada i kiedy idziemy dalej

Podejście do wdrożenia mówi nam, jak organizujemy pracę. Etap opisuje zadania i rezultat, którego potrzebujemy, zanim podejmiemy kolejną decyzję. W każdym z trzech podejść pojawiają się podobne obowiązki, choć nie muszą układać się w jeden nieprzerwany ciąg.

Poniższą mapę potraktowałbym jako punkt wyjścia do rozmowy. Z klientem uzgadniamy konkretne rezultaty, odpowiedzialność i kryteria odbioru. To proponowany sposób kontrolowania projektu, a nie twierdzenie, że każde wdrożenie ERP przebiega według identycznej metodyki.

Rozpoznanie potrzeb i wymagania

Na początek potrzebujemy wspólnie ustalonych celów biznesowych, zakresu procesów, najważniejszych wymagań, ograniczeń i wstępnej listy ryzyk.

Tę pracę koordynuje analityk biznesowy lub konsultant funkcjonalny. Właściciele procesów po stronie firmy zatwierdzają wymagania, a sponsor projektu — osoba umocowana do podejmowania decyzji biznesowych — rozstrzyga priorytety.

Kiedy możemy iść dalej? Gdy wiadomo, kto odpowiada za krytyczne procesy, niezbędne potrzeby są opisane, a firma zgadza się co do tego, co projekt ma osiągnąć.

Wybór platformy i zaplanowanie rozwiązania

Tutaj sprawdzamy dopasowanie platformy, wskazujemy braki, wybieramy podejście do realizacji i ustalamy wstępny zakres, zależności oraz plan odbioru.

Osoba odpowiedzialna za całość rozwiązania ocenia, czy system pasuje do potrzeb. Właściciele procesów sprawdzają scenariusze biznesowe, a sponsor zatwierdza wybór i zakres.

Chcę na tym etapie widzieć wiarygodny sposób obsługi najważniejszych potrzeb. Jeśli pozostają luki, musimy wiedzieć, co z nimi zrobimy. Firma powinna rozumieć i zaakceptować proponowane podejście.

Konfiguracja, rozwój i integracje

Zespół przygotowuje uzgodnione procesy i rozszerzenia, wykonuje sprawdzenia techniczne oraz aktualizuje dokumentację rozwiązania. Osoba prowadząca rozwiązanie pilnuje zależności między obszarami, a właściciele procesów oglądają, jak będzie wyglądała ich praca.

Warunek przejścia do testów użytkowników jest dla mnie konkretny: uzgodniony zakres można pokazać od początku do końca. Ograniczenia, które jeszcze pozostają, są zapisane i zrozumiałe dla obu stron.

Przygotowanie migracji i próbne przeniesienie danych

Potrzebujemy mapowania danych, uporządkowanych źródeł, próbnej migracji i wyników porównania danych przed przeniesieniem oraz po nim.

Za wykonanie transferu odpowiada osoba prowadząca migrację. Ale to biznesowi właściciele danych potwierdzają, czy są one kompletne i poprawne. Sam komunikat „import zakończony” jeszcze nam tego nie mówi.

Dalej przechodzimy, gdy uzgodnione kontrole dały prawidłowy wynik, rozbieżności wpływające na podstawową pracę są rozwiązane i wiadomo, kto odpowiada za końcową migrację.

Testy akceptacyjne i szkolenia

Efektem powinny być wykonane scenariusze biznesowe, rejestr uwag, instrukcje dla użytkowników i przygotowani użytkownicy kluczowi.

Właściciele procesów akceptują sposób pracy. Użytkownicy kluczowi wykonują testy, a zespół wdrożeniowy poprawia błędy i prowadzi szkolenia.

Przed następnym krokiem muszą przejść krytyczne scenariusze. Błędy blokujące uruchomienie powinny być zamknięte. Jeżeli świadomie zostawiamy inne problemy na później, każdy z nich potrzebuje właściciela i — tam, gdzie to konieczne — uzgodnionego sposobu pracy zastępczej.

Plan przełączenia i decyzja o starcie

To moment, w którym składamy przygotowania w jeden plan: końcowa migracja, przełączenie systemów, komunikacja, dostępność wsparcia oraz plan awaryjny.

Kierownik projektu koordynuje działania. Osoby odpowiedzialne za biznes i technologię potwierdzają gotowość, a sponsor lub wyznaczony decydent biznesowy zezwala na uruchomienie.

Nie wystarczy, że „wszyscy mniej więcej są gotowi”. Potrzebujemy potwierdzeń od konkretnych osób, uzgodnionego okna przełączenia i punktów, w których podejmiemy decyzję o kontynuacji albo skorzystaniu z planu awaryjnego. Nie może też pozostawać nierozwiązana przeszkoda uniemożliwiająca podstawową działalność.

Uruchomienie i intensywne wsparcie po starcie

Firma zaczyna pracować w systemie. Sprawdzamy dane po końcowej migracji, zapewniamy uzgodnione wsparcie i na bieżąco prowadzimy rejestr problemów. Ten okres często nazywa się hypercare.

Za codzienną pracę odpowiada firma, zespół wdrożeniowy i wsparcie rozwiązują problemy, a kierownik projektu koordynuje eskalacje.

Kiedy ten etap można uznać za zakończony? Gdy podstawowe operacje działają stabilnie przez uzgodniony okres obserwacji, krytyczne problemy startowe zostały rozwiązane, a dla pozostałych prac ustaliliśmy dalszą ścieżkę.

Przekazanie do utrzymania i kolejne usprawnienia

Na koniec potrzebujemy zaakceptowanej dokumentacji operacyjnej, jasnego podziału obowiązków wsparcia, listy znanych problemów i uporządkowanego backlogu usprawnień.

Osoba odpowiedzialna za wsparcie przyjmuje system do utrzymania. Właściciele procesów ustalają priorytety zmian, a sponsor lub upoważniona osoba zatwierdza zamknięcie projektu.

Chodzi o to, żeby rutynowa obsługa nie wymagała ciągłego angażowania zespołu projektowego, a firma przejęła odpowiedzialność za pracę w systemie i zaakceptowała pozostałe zobowiązania.

Te etapy będą się na siebie nakładać

Celowo rozdzieliłem odpowiedzialność i decyzje. Nie chciałbym jednak, żeby ktoś przeczytał ten opis i uznał, że danymi lub szkoleniami zajmiemy się dopiero pod koniec.

Przygotowanie migracji powinno ruszyć już wtedy, gdy projektujemy procesy. A szkolenia warto prowadzić na tych sposobach pracy, z których ludzie rzeczywiście będą korzystać.

Tak samo rozumiem punkt decyzyjny między etapami: ktoś ma prawo powiedzieć „idziemy dalej”, ale potrzebuje do tego dowodów. Musimy też wiedzieć, co zatrzyma przejście. Hasło „programowanie skończone” niewiele wyjaśnia, jeśli nikt nie pokazał całego procesu biznesowego i nie sprawdził danych, na których ten proces się opiera.

Jak ta mapa zmienia się w zależności od podejścia?

W projekcie klasycznym wymagania i plan rozwiązania tworzą główną podstawę dalszej realizacji. Formalna akceptacja użytkowników następuje po zasadniczej części prac, a poprawki muszą doprowadzić system do uzgodnionej gotowości. Wcześniejsze demonstracje nadal mają sens: pozwalają zauważyć nieporozumienia, zanim zamienią się w kosztowny spór przy odbiorze.

W projekcie iteracyjnym planowanie, realizacja i uwagi użytkowników powtarzają się dla kolejnych fragmentów procesów. Każda iteracja potrzebuje własnej definicji ukończenia: co użytkownik potrafi zrobić, jakie testy przeszły i jakie ograniczenia pozostały. Ukończenie iteracji nie daje jeszcze zgody na pracę produkcyjną. Całość nadal wymaga wspólnego odbioru, próby migracji i skoordynowanej decyzji o jednym uruchomieniu.

W podejściu opartym na standardzie sprawdzamy najważniejsze potrzeby na standardowych procesach i ograniczamy zmiany przed startem. Migracja, szkolenia, akceptacja i plan przełączenia pozostają potrzebne. Więcej adaptacji i opcjonalnych usprawnień następuje już podczas pracy. Ale krytycznej luki nie można po prostu przenieść na listę przyszłych zmian tylko po to, żeby zgadzała się data startu.

Jeszcze przed próbą migracji właściciele biznesowi powinni sprawdzić dane podstawowe, od których zależą transakcje: między innymi kartoteki klientów, dostawców i produktów.

Od czego zależą czas i budżet wdrożenia?

Zanim oszacuję pracę, chcę zobaczyć zakres procesów, integracje, jakość danych i dostępność ludzi, którzy będą podejmować decyzje oraz akceptować wyniki. Nawet duży zespół programistów nie zastąpi odpowiedzi na otwarte pytanie biznesowe ani brakujących danych źródłowych.

W projekcie klasycznym uzgodnione wymagania pomagają przypisywać pracę do etapów i kontrolować zmiany zakresu. Jeżeli jednak podczas odbioru pojawią się nowe potrzeby, nadal trzeba zdecydować, jaki mają wpływ na koszty i harmonogram.

Przy podejściu iteracyjnym szczegółowo planujemy najbliższe fragmenty, a prognozę całości aktualizujemy wraz ze zdobytą wiedzą. Pilnowałbym tutaj minimalnego zakresu potrzebnego do startu i rozróżniał rzeczywiście odkryte potrzeby od opcjonalnych usprawnień. Inaczej bardzo przydatna rozmowa z użytkownikami może zamienić się w projekt, który bez końca się powiększa.

Start od standardu może ograniczyć ilość pracy przed uruchomieniem, bo robimy mniej indywidualnych modyfikacji. Nadal jednak trzeba uwzględnić migrację, szkolenia, wsparcie i dostosowania po starcie. Wcześniejsze uruchomienie zmienia moment wykonania części prac; nie sprawia, że przestają być potrzebne.

Ustalenia dotyczące celu i odpowiedzialności warto zebrać w karcie projektu, a budżet projektu powiązać z zakresem.

W każdym wariancie pokazałbym najważniejsze zależności: kiedy będą gotowe dane, kiedy można sprawdzić integracje, kiedy użytkownicy mają czas na udział i kto zatwierdza decyzje. Taka rozmowa zwykle mówi o harmonogramie znacznie więcej niż ogólna obietnica, ile miesięcy trwa wdrożenie ERP.

1. Podejście klasyczne: opisać, zbudować, odebrać i uruchomić

W klasycznym wdrożeniu zaczynamy od wymagań biznesowych. Firma opisuje problemy, które chce rozwiązać, potrzebne moduły i najważniejsze funkcje, których oczekuje już w standardzie.

Na tej podstawie wybieramy platformę. W projekcie Odoo pomaga w tym analiza dopasowania standardu i braków, często nazywana fit-gap. Zanim ruszymy z właściwą realizacją, powinniśmy więc mieć zarówno wybrany system, jak i wspólnie uzgodnioną podstawę wymagań.

Wymagania i wybór platformy

Przedstawiciele firmy opowiadają, jak działają procesy i co nowy system musi obsługiwać. Lista modułów to dopiero początek. To, że potrzebujecie zakupów, magazynu i księgowości, nie wyjaśnia jeszcze, jak mają ze sobą współpracować w Waszej firmie.

Przed realizacją uzgodniłbym zakres, krytyczne wymagania i kryteria odbioru. W przeciwnym razie przy odbiorze łatwo wpaść w rozmowę: „ale my przecież od początku mieliśmy na myśli coś innego”. O samym wyborze platformy opowiadam szerzej w artykule jak wybrać system ERP na podstawie doświadczeń z dużych firm i przetargów.

Konfiguracja, programowanie i połączenia z innymi systemami

Zespół przygotowuje ERP według tych wymagań. Może to obejmować konfigurację i dostosowanie Odoo, integracje, nowe dokumenty biznesowe, dodatkowe formularze i programowanie funkcji, których platforma nie ma w standardzie.

Zakres tych prac zależy od firmy. Ich wynikiem jest system gotowy do oceny przez biznes. Ukończenie programowania nie oznacza jeszcze, że ludzie mogą bezpiecznie zacząć prowadzić w nim codzienną działalność.

Eksploatacja próbna i odbiór

Teraz użytkownicy potrzebują popracować na swoich zadaniach. Sprawdzają system i zbierają uwagi.

Rozdzielałbym tutaj błędy od brakujących lub zmienionych wymagań. Jeśli funkcja nie spełnia uzgodnionego wymagania, trzeba ją poprawić. Jeśli dopiero teraz odkryliśmy nową potrzebę, potrzebna jest decyzja o zakresie. Kiedy wrzucimy wszystko do jednego worka, trudniej będzie zapanować nad kosztami i odpowiedzialnością.

Poprawki i uruchomienie produkcyjne

Zespół rozwiązuje zgłoszone problemy i przygotowuje końcową migrację, szkolenia, dokumentację oraz przejście do pracy produkcyjnej. Firma decyduje wtedy, czy system jest gotowy, żeby stać się jej narzędziem operacyjnym.

Po starcie powinien nastąpić uzgodniony okres intensywnego wsparcia, czyli hypercare. Ustaliłbym wcześniej, kto zajmuje się pilnymi problemami i co musi się ustabilizować, zanim przejdziemy do zwykłego wsparcia.

Kiedy wybrałbym ten wariant?

Skłaniam się ku niemu, gdy firma jest złożona, a zakłócenie jej ustalonych procesów oznacza poważne ryzyko operacyjne. Wyraźne etapy i przekazania odpowiedzialności dają podstawę do zarządzania zakresem oraz budżetem.

Słabszą stroną jest odległość między opisaniem wymagań a odbiorem. Możecie otrzymać system, który bardzo dobrze odpowiada temu, co zapisaliście, i jednocześnie odkryć, że nie tego ludzie się spodziewali.

Dlatego także podczas realizacji warto wracać do prawdziwych procesów i pokazywać ich obsługę. Sekwencyjny plan sam w sobie nie uzupełnia brakujących wymagań i nie gwarantuje niezmiennego budżetu.

Z mojego doświadczenia: wymagania zostały, ale firma zdążyła się zmienić

Brałem udział w wyborze ERP dla holdingu z branży FMCG, czyli dóbr szybko zbywalnych. Zbieranie wymagań było długim, wielomiesięcznym przedsięwzięciem. Każdy dział zgłaszał swoje potrzeby, potem je porządkowaliśmy i łączyliśmy. Powstał z tego naprawdę obszerny dokument.

Wybraliśmy ERP, który — jak wynikało z porównania — pokrywał więcej wymagań niż pozostali kandydaci. Po zawarciu umowy dostawca przygotował własną dokumentację techniczną do zatwierdzenia i zaczął dostosowywać system.

Gdy po długim okresie realizacji przekazał gotowe rozwiązanie, dołączył listę wykonanych zmian. Tyle że w tym czasie biznes poszedł dalej. Zmieniły się procesy zarządzania produktami i zakupów, a raportowanie stało się bardziej uporządkowane.

I nagle okazało się, że dostarczony ERP znacznie lepiej pasuje do zapisanych wymagań niż do aktualnych oczekiwań firmy. Trzeba było ponieść dodatkowe nakłady na zmianę systemu, który właśnie przygotowano dla wcześniejszej wersji tego biznesu.

Dla mnie lekcja z tego projektu jest prosta: zatwierdzenie wymagań nie zatrzymuje organizacji w miejscu. Przy długim projekcie sekwencyjnym wracałbym do ważnych założeń biznesowych jeszcze podczas realizacji i otwarcie oceniał skutki zmian. Inaczej na odbiorze możemy dowieść, że dostawca zbudował to, co uzgodniono, ale nadal nie wiedzieć, czy firma dostała to, czego teraz potrzebuje.

2. Podejście iteracyjne: rozwijamy całe procesy, uruchamiamy raz

Drugi sposób polega na rozwijaniu ERP w mniejszych iteracjach. Można organizować tę pracę z wykorzystaniem Scruma, choć sam rozwój iteracyjny jeszcze nie oznacza, że zespół rzeczywiście pracuje według Scruma.

Najbardziej podoba mi się tutaj zasada: zbudujmy cały proces biznesowy, dajmy ludziom go wypróbować i na podstawie ich uwag zdecydujmy, co robimy dalej.

Pokażmy proces od początku do końca

Weźmy umowny przykład: zakup towaru, przyjęcie do magazynu, doliczenie właściwych dodatkowych kosztów nabycia i składowanie. Użytkownicy powinni móc prześledzić drogę towaru od dostawcy do własnego zapasu i zobaczyć w systemie końcową ilość oraz wycenę zapasów.

W jednej demonstracji end-to-end spotyka się wtedy kilka działów. Zakupy sprawdzają zamówienie, magazyn przyjęcie i przechowywanie, a finanse sposób ujęcia kosztów. Wszyscy oglądają jeden powiązany przebieg, zamiast osobno oceniać poszczególne ekrany. Praktykę rozliczania kosztów opisuję też w artykule o Landed Costs w Odoo.

Drugi przydatny scenariusz to sprzedaż klientowi, wydanie z magazynu i ujęcie przychodu zgodnie z uzgodnionym sposobem księgowania. Możemy przejść przez dokumenty, zatwierdzenia i zależności potrzebne do zakończenia transakcji.

To przykłady tego, co pokazałbym podczas takiej pracy, a nie opis iteracji u konkretnego klienta ani założenie, że każdy ERP identycznie obsługuje wszystkie kroki.

Chodzi o to, żeby przebieg dało się zrozumieć i sprawdzić. Niektóre nietypowe przypadki, specjalistyczne raporty i dodatkowe udogodnienia można dołożyć później. Nadal trzeba jednak rozpoznać krytyczne kontrole i zależności. Uproszczony pokaz nie powinien ukrywać braku, który później zatrzyma uruchomienie.

Sprawdzamy, poprawiamy i dokładamy następne elementy

Teraz ludzie odnoszą się już do czegoś, co widzą. Mogą powiedzieć, co działa, co jest niejasne i o czym wcześniej nie pomyśleli.

Następna iteracja poprawia ten proces albo wprowadza kolejny. Z czasem powstaje połączone rozwiązanie, a użytkownicy coraz lepiej je znają. Nie muszą wyobrażać sobie każdego szczegółu, zanim jeszcze zobaczą system w działaniu.

Przygotowujemy całość do jednego startu

W wariancie, o którym tutaj mówię, firma nie przenosi bieżącej działalności do każdej ukończonej iteracji. Rozwijamy i testujemy częściami, a potem uruchamiamy ERP jako całość.

Przed startem musimy sprawdzić, czy procesy działają również razem. Osobne demonstracje nie wystarczą. Gotowe muszą być dane, integracje, podział zadań między użytkowników i przejście ze starego systemu.

Otrzymujemy więc działający system oraz ludzi, którzy uczestniczyli w jego tworzeniu i sprawdzaniu. Po wspólnym uruchomieniu następuje uzgodniony hypercare i wsparcie po wdrożeniu.

Kiedy wybrałbym podejście iteracyjne?

Polecam je elastycznej firmie, która może podejmować decyzje i przekazywać uwagi przez cały okres realizacji, ale nie może przechodzić na nowy ERP po jednym procesie.

Największa korzyść to nauka jeszcze przed uruchomieniem. Trudniejsza jest prognoza całości: kiedy po drodze odkrywamy i zmieniamy pracę, ciężej utrzymać bardzo szczegółowy końcowy budżet i harmonogram.

Planowanie nadal jest potrzebne. Określiłbym niezbędny zakres startowy, wskazał zależności i regularnie wracał do tego, ile pracy pozostało. Musimy rozumieć, bez czego nie uruchomimy systemu, a co może poczekać.

3. Najpierw standard: zaczynamy pracować, potem udoskonalamy

Trzecie podejście wychodzi z innego założenia. Firma jest gotowa przyjąć standardowe procesy ERP, zamiast na początku prosić zespół o odtworzenie dotychczasowego sposobu działania.

To może pasować do biznesu, który ma niewiele wymagań niepodlegających negocjacji i chce najpierw nauczyć się, jak pracuje się w wybranym systemie.

Najpierw sprawdźmy, czy standard obsłuży to, co niezbędne

Zacząłbym od oddzielenia przyzwyczajeń od rzeczywistych wymagań. Znany układ ekranu być może da się zmienić. Ale procesu potrzebnego do wysyłania zamówień, prowadzenia prawidłowej ewidencji czy wykonania obowiązku firmy zwykle nie można po prostu pominąć.

Podejście oparte na standardzie ma sens, gdy standard rzeczywiście pozwala wykonywać podstawową pracę. Nie powinno służyć odkładaniu problemu, który uniemożliwi działalność po starcie.

Przygotowujemy dane i użytkowników

Migracja dość szybko staje się tutaj bardzo praktycznym tematem. Ludzie potrzebują przecież swoich informacji w nowym systemie. Przygotowujemy i sprawdzamy dane, konfigurujemy standard, szkolimy użytkowników i opisujemy sposób pracy.

Przygotowania mogą być mniejsze niż w projekcie z dużą liczbą indywidualnych rozszerzeń. Nadal jednak trzeba świadomie zdecydować, czy firma jest gotowa do uruchomienia.

Zaczynamy pracę i sprawdzamy, co naprawdę warto zmienić

Firma zaczyna korzystać z systemu i zapisuje to, co jej nie odpowiada. Wsparcie i nauka stają się ważną częścią wdrożenia.

Część wcześniejszych próśb może zniknąć. Proces w nowym ERP działa inaczej, więc dawne wymaganie przestaje być potrzebne. Ludzie odkrywają, że standard rozwiązuje ich problem, choć nie odtwarza każdego znanego kroku.

Inne braki pozostają rzeczywiste. Wtedy planujemy dalszą konfigurację, programowanie lub integracje.

Co zmieniło się, kiedy ludzie spróbowali pracować w systemie?

Mam z praktyki niewielki, ale bardzo wymowny przykład dotyczący nazw. Klient upierał się, żeby rekordy klientów nazywać „leadami”, bo jego zespół używał właśnie tego określenia. Po pewnym czasie codziennej pracy temat przestał być problemem. Ludzie oswoili się ze słownictwem systemu.

Oczywiście lead i klient nie oznaczają tego samego. Ten przykład pokazuje, dlaczego przed zamówieniem zmiany warto sprawdzić, czy chodzi o potrzebę procesu, czy o znajomą etykietę na ekranie.

Podobne rozmowy pojawiają się przy dokumentach. Zespół mówi: „Chcemy od razu wysłać fakturę i czekać na płatność”, podczas gdy w danym przebiegu system wykorzystuje na tym etapie ofertę albo dokument pro forma.

Zanim zaczniemy to zmieniać, porozmawiałbym o tym, jakie zdarzenie biznesowe ma reprezentować dokument i kiedy powinna powstać właściwa faktura. Pokazałbym i sprawdził tę kolejność z użytkownikami. Sposób ujęcia księgowego i podatkowego musi przy tym pasować do przepisów obowiązujących daną firmę oraz jej konfiguracji.

Widziałem też zespoły finansowe, które chciały automatycznego księgowania wszystkich faktur, a po zdobyciu praktycznego doświadczenia wracały do tej decyzji. Księgowi potrzebowali sprawdzać błędy, przypisania w księgowości analitycznej i dane kontrahentów. W tych przypadkach pozostawienie kontroli księgowego okazało się bardziej przydatne niż pierwotna prośba o automatyzację wszystkiego.

Nie wyciągałbym z tego wniosku, że automatyzacja jest zła. Chodzi o ustalenie, jakie kontrole muszą się odbyć, kto za nie odpowiada i które transakcje mogą bezpiecznie przechodzić automatycznie. Dopiero praca na procesie potrafi pokazać, jakie wymaganie rzeczywiście ma sens.

Kiedy proponuję start od standardu?

Kiedy firma jest gotowa dostosować sposób pracy i chce uczciwie sprawdzić standardowe procesy ERP. Można wtedy wcześniej uzyskać działającą podstawę, a usprawnienia planować na podstawie faktycznego użytkowania.

Byłbym ostrożny, gdyby zarząd oczekiwał takiej adaptacji, ale nie dawał pracownikom czasu, szkolenia i możliwości zmiany codziennych nawyków. Przed uruchomieniem nadal trzeba też rozwiązać wszystkie krytyczne wymagania.

Wcześniejszy start produkcyjny nie oznacza końca całego wdrożenia. Po prostu większa część nauki i usprawnień odbywa się już po nim.

Jak wybieram między tymi podejściami?

Najpierw pytam, czego firma nie może sobie pozwolić zakłócić. Potem — jak bardzo jest gotowa się zmienić.

Jeśli ustalone procesy są złożone, a ryzyko operacyjne wysokie, skłaniam się ku projektowi klasycznemu z wyraźnymi wymaganiami i etapami odbioru. Jeśli firma jest elastyczna, może uczestniczyć w całej realizacji i potrzebuje jednego wspólnego startu, wybieram rozwój iteracyjny. Gdy wystarcza standard i zespół chce go przyjąć, rozważam trzecie podejście.

Sama wielkość przedsiębiorstwa nie rozstrzyga tej decyzji. Więcej mówią ograniczenia procesów, gotowość danych, integracje i dostępność osób, które podejmują decyzje.

Przed rekomendacją zadałbym pięć konkretnych pytań:

1. Które procesy muszą pozostać bez zmian ze względów operacyjnych lub wymogów zgodności, a które można dostosować do standardu ERP?
2. Czy właściciele procesów i użytkownicy kluczowi mogą regularnie brać udział w pokazach, testach i decyzjach o zakresie?
3. Czy na starcie wystarczą funkcje standardowe, czy wcześniej muszą powstać niezbędne integracje i rozszerzenia?
4. Czy dane źródłowe nadają się do wykorzystania i kto odpowiada za ich poprawienie oraz zatwierdzenie?
5. Czy działalność można przełączać stopniowo, czy powiązane procesy wymagają jednego skoordynowanego uruchomienia?

Odpowiedzi powinny wpływać na plan. Sama otwartość na eksperymentowanie sprzyja iteracjom, ale jeszcze nie oznacza gotowości do produkcyjnego startu na standardzie.

Niezależnie od podejścia jasno podzieliłbym obowiązki. Właściciele procesów akceptują sposób pracy. Zespół wdrożeniowy dostarcza uzgodnione rozwiązanie. Osoba prowadząca projekt zarządza zakresem i otwartymi decyzjami. A konkretny decydent biznesowy zezwala na uruchomienie.

Uzgodniłbym również, co kończy hypercare. Ludzie muszą umieć wykonywać podstawowe zadania, ważne dane i integracje powinny działać stabilnie, a nierozwiązane problemy potrzebują odpowiedzialnych osób i dalszej ścieżki wsparcia. Samo udostępnienie programu jest tylko częścią wdrożenia.

Drobiazgi, które potrafią zatrzymać start

Z mojego doświadczenia przeszkody bywają zaskakująco zwyczajne: zabrakło danych historycznych, ktoś nie uwzględnił kroku zatwierdzania, nie ma sposobu na anulowanie lub odwrócenie operacji albo nadal nie wiadomo, jak wprowadzić potrzebną transakcję z wcześniejszą datą.

Bardzo często chodzi tutaj o historię i to, co firma musi z nią robić po migracji. Sam import rekordów nie wystarczy, jeśli użytkownik nie może później wykonać operacji, która od tych rekordów zależy.

Dlatego przed zgodą na start poprosiłbym właścicieli procesów o pokazanie niezbędnych scenariuszy związanych z historią i odpowiednich wyjątków. Ustalamy, jakie operacje muszą być możliwe, na co pozwala system i jakie kontrole obowiązują. Potrzeba poprawienia dawnej transakcji nie oznacza zgody na pomijanie zasad księgowych czy ograniczeń wynikających z zamknięcia okresu.

Jeśli niezbędnej operacji nie da się wykonać i nie ma akceptowalnej alternatywy, traktowałbym to jako temat do decyzji „uruchamiamy czy wstrzymujemy start?”.

Jeśli interesuje Was konkretnie kontekst metodyki Odoo, na anglojęzycznej stronie mamy też omówienie oficjalnego przewodnika wdrożeniowego Odoo. Tutaj patrzę szerzej: na wybór sposobu realizacji ERP z perspektywy firmy, która będzie na nim pracować.

Porozmawiajmy o podejściu, zanim ruszymy z projektem

W ERPixel dobieramy sposób wdrożenia do ograniczeń klienta i jego gotowości do zmiany. Nie potrzebujemy, żeby każdy projekt przechodził przez identyczną sekwencję.

Jeśli rozważacie Odoo, możemy pomóc uporządkować wymagania i zaplanować dalszą drogę. W ramach wdrożenia Odoo przechodzimy do praktycznej pracy w systemie, uwzględniając potrzebną migrację i integracje. Szerszy zakres takich projektów opisujemy też na stronie wdrożeń systemów ERP.

Opowiedzcie nam o swoim projekcie albo napiszcie przez formularz poniżej. Możemy zacząć od procesów, które musicie ochronić, zmian, na które Wasz zespół jest gotowy, i sposobu, w jaki chcecie dojść do uruchomienia.