Role i odpowiedzialności w projekcie wdrożeniowym ERP

Dlaczego podział ról i odpowiedzialności zaczyna się na etapie planowania

Planowanie wdrożenia ERP wymaga przypisania właścicieli do czterech zadań: analizy procesów biznesowych i identyfikacji obszarów, które mogą skorzystać na wdrożeniu, określenia celów i oczekiwań projektu, przeglądu dostępnych na rynku technologii oraz wyboru platformy ERP.

Projekt powstaje pod indywidualne potrzeby i specyfikę organizacji, więc decyzji o zakresie nie można w całości delegować na zewnątrz.

W projekcie występują trzy strony: organizacja zamawiająca, dostawca systemu ERP oraz niezależny doradca, którego rola jest wspierająca, a nie zastępująca decyzje organizacji. Po stronie organizacji pracują właściciele procesów, przyszli użytkownicy i kierownik projektu.

Podział obowiązków opiera się na sekwencji faz wdrożenia: analiza, projektowanie, implementacja (instalacja oprogramowania, konfiguracja funkcji, migracja danych, szkolenie użytkowników), testowanie oraz wsparcie po wdrożeniu.

Dla każdej fazy trzeba wskazać, kto wykonuje pracę, kto zatwierdza wynik, kto jest konsultowany, a kto tylko informowany. Taki zapis zastępuje ogólne formuły o „zaangażowaniu zespołu”, których nie da się później wyegzekwować.

Najwięcej luk odpowiedzialności powstaje nie po stronie dostawcy, lecz w organizacji: w dostępności użytkowników, jakości danych do migracji, tempie decyzji o konfiguracji i zatwierdzaniu odstępstw od standardu. Wskazanie tych punktów już w planie zapobiega przestojowi, gdy nikt nie ma mandatu do rozstrzygnięcia sporu o zakres.

Kto odpowiada za cele, wymagania i zakres wdrożenia

Za zdefiniowanie wymagań i celów odpowiada organizacja, nie dostawca. Lista kontrolna obejmuje pytania: jakie kluczowe cele chcemy osiągnąć i jak zamierzamy je mierzyć, jaki będzie punkt odniesienia dla prawidłowego pomiaru tych celów.

Kolejne pytania dotyczą tego, jakie procesy powinny znaleźć się w zakresie wdrożenia i dlaczego oraz jakie istotne nieefektywności obecnych procesów lub systemów powinny zostać wyeliminowane. Odpowiedzi są materiałem do późniejszego odbioru projektu.

Drugi zestaw decyzji dotyczy granicy między wymaganiami krytycznymi i niekrytycznymi. Dla każdego procesu trzeba ustalić, które wymagania muszą być ujęte w nowym systemie nawet kosztem zmian w standardowych funkcjonalnościach, a które są niekrytyczne.

Trzeba też określić, jaki będzie wpływ na organizację, jeśli wymaganie nie zostanie wdrożone, oraz czy da się je zrealizować inaczej — w ramach obecnych systemów lub narzędzi dedykowanych.

Rozwiązanie powinno spełniać dodatkowe wymagania interesariuszy, dlatego trzeba wyznaczyć osobę zbierającą i priorytetyzującą te postulaty.

W analizie potrzeb i wyborze optymalnego rozwiązania może pomóc niezależny doradca; jego rola jest wspierająca, a nie zastępująca decyzje organizacji. Gdy technologia jest wybrana, definiowanie wymagań zaczyna się od znalezienia luk między obecnymi procesami a standardowymi funkcjonalnościami systemu, a nie od ponownego opisu stanu obecnego.

Za cele i wymagania odpowiada organizacja, a niezależny doradca jedynie wspiera analizę potrzeb i wybór rozwiązania. Osoba zbierająca i priorytetyzująca postulaty interesariuszy oraz osoba odpowiedzialna za zebranie i weryfikację referencji muszą być wskazane z imienia i nazwiska.

Właścicielem listy wymagań krytycznych i niekrytycznych jest organizacja. To ona rozstrzyga, które wymagania wejdą do systemu nawet kosztem zmian w standardzie, a które da się obsłużyć poza nim.

Odpowiedzialność za budżet, TCO i analizę luk

Całkowity koszt posiadania systemu ERP (TCO) obejmuje nie tylko wdrożenie, ale też licencje, szkolenia, utrzymanie i aktualizacje. Firmy, które budżetują wyłącznie koszt implementacji, zaniżają realny wydatek średnio o 40–60%.

Właścicielem budżetu powinna więc być osoba odpowiedzialna za cały cykl życia systemu, a szkolenia, utrzymanie i aktualizacje muszą mieć swoje miejsce w planie finansowym projektu od pierwszego dnia.

Analiza luk (gap analysis) między istniejącymi procesami a standardowymi funkcjonalnościami systemu ERP pozwala oszacować skalę modyfikacji i koszt wdrożenia jeszcze przed podpisaniem umowy z dostawcą.

Dokument ma dwóch odbiorców: organizację, która decyduje, czy akceptuje modyfikacje i ich konsekwencje, oraz dostawcę, który na tej podstawie wycenia zakres.

Ktoś po stronie zamawiającego musi mieć prawo zatwierdzania lub odrzucania każdej modyfikacji standardu i odpowiadać za terminowość tych decyzji.

Weryfikacja dopasowania rozwiązania nie kończy się na prezentacji sprzedażowej: referencje od użytkowników działających w tej samej branży i o zbliżonej wielkości firmy są bardziej wiarygodnym wskaźnikiem dopasowania systemu ERP niż prezentacje dostawcy. Zebranie referencji, sprawdzenie ich i udokumentowanie wniosków trzeba przypisać konkretnej osobie, a wynik powinien współdecydować o wyborze platformy.

Z tej fazy wynikają trzy role po stronie zamawiającego: właściciel budżetu odpowiedzialny za cały cykl życia systemu, właściciel analizy luk oraz osoba odpowiedzialna za referencje. Każda z nich podejmuje decyzje w swoim zakresie i odpowiada za ich termin.

Role w analizie procesów i projektowaniu rozwiązania

Faza analizy należy do organizacji: to ona przeprowadza szczegółową analizę procesów biznesowych i określa oczekiwania oraz cele związane z wdrożeniem systemu. W praktyce oznacza to wyznaczenie właścicieli poszczególnych procesów, którzy opisują stan obecny, a następnie zatwierdzają stan docelowy w zakresie swojej odpowiedzialności.

Faza projektowania polega na opracowaniu konkretnego rozwiązania spełniającego wymagania organizacji.

Praca przebiega zwykle w podziale: dostawca przekłada wymagania na możliwości standardu i przygotowuje projekt konfiguracji, użytkownicy biznesowi weryfikują, czy proponowany proces docelowy odpowiada realnej pracy, a kierownik projektu rozstrzyga spory o zakres i odstępstwa od standardu.

Projekt rozwiązania bez akceptacji przyszłych użytkowników jest tylko hipotezą, którą weryfikują dopiero testy.

Do fazy projektowania trzeba włączyć przyszłych użytkowników, a nie tylko kadrę zarządzającą i informatyków. Ich udział ma charakter zadaniowy: przegląd projektu procesu, wskazanie wyjątków, które muszą być obsłużone, oraz potwierdzenie, że przyjęte uproszczenia nie blokują codziennej pracy.

Ustalenia z tej fazy stanowią podstawę scenariuszy testowych w kolejnym etapie.

Role tej fazy są cztery: właściciel procesu opisuje stan obecny i zatwierdza stan docelowy, dostawca przekłada wymagania na standard, użytkownik biznesowy weryfikuje projekt procesu, a kierownik projektu rozstrzyga spory o zakres i odstępstwa.

Kto odpowiada za implementację: instalację, konfigurację, migrację i szkolenia

Implementacja obejmuje cztery zadania: instalację oprogramowania, konfigurację funkcji, migrację danych oraz szkolenie użytkowników. To najczęstsze źródło nieporozumień — domyślnie zakłada się, że wszystkie cztery wykona dostawca, tymczasem migracja i szkolenia wymagają zasobów organizacji, których nie zastąpi praca zewnętrzna.

Migrację danych trzeba rozdzielić na dwie odrębne odpowiedzialności: przygotowanie i oczyszczenie danych po stronie organizacji oraz techniczny import po stronie dostawcy. Właściciele danych decydują o zakresie pól, regułach mapowania i sposobie postępowania z rekordami niekompletnymi; bez tej decyzji import zatrzymuje się na pytaniach, na które zespół wdrożeniowy nie może odpowiedzieć samodzielnie.

Przy instalacji i konfiguracji funkcji organizacja zapewnia dostęp do środowisk, akceptuje parametry konfiguracyjne i potwierdza, że ustawienia odpowiadają przyjętym procesom. Szkolenia prowadzi zwykle dostawca, ale organizacja wyznacza uczestników, zapewnia ich dostępność w terminie szkolenia i wskazuje osobę pierwszego kontaktu dla pytań pojawiających się po szkoleniu.

Cztery zadania implementacji mają czterech wykonawców: instalację i konfigurację funkcji prowadzi dostawca, dane przygotowuje i oczyszcza organizacja, import wykonuje dostawca, a szkolenie prowadzi dostawca dla uczestników wskazanych przez organizację. Każdy z tych czterech obszarów potrzebuje właściciela po stronie zamawiającego.

Rola użytkowników i zespołu projektowego w testowaniu

Przed oddaniem systemu do użytku trzeba przeprowadzić serię testów sprawdzających jego funkcjonalność oraz wydajność. Testy funkcjonalne weryfikują, czy scenariusze procesowe przebiegają zgodnie z projektem zatwierdzonym na etapie projektowania; testy wydajnościowe odpowiadają na pytanie, czy system utrzymuje obciążenie wynikające z realnej skali działania organizacji.

Podział zadań w testach wynika z kompetencji: użytkownicy kluczowi wykonują scenariusze odzwierciedlające codzienną pracę i zgłaszają rozbieżności, dostawca przygotowuje środowisko testowe oraz prowadzi testy techniczne i wydajnościowe. Warunkiem sensownego przebiegu jest ustalenie kryteriów akceptacji przed rozpoczęciem testów i prowadzenie rejestru błędów z właścicielem każdego zgłoszenia oraz terminem zamknięcia.

Testy zużywają czas użytkowników, który trzeba zaplanować w harmonogramie projektu jako realne obciążenie, a nie czynność dodatkową. Bez formalnego odbioru testów zespół nie ma podstawy do przekazania systemu do pracy produkcyjnej, dlatego osobę zatwierdzającą wynik testów należy wskazać w planie wdrożenia z imienia i nazwiska.

Role w testach są rozdzielone: użytkownik kluczowy reprezentuje codzienną pracę, dostawca odpowiada za warstwę techniczną i wydajność, właściciel zgłoszenia pilnuje zamknięcia błędu, a zatwierdzenie wyniku etapu należy do organizacji. Bez wskazania tych czterech ról rejestr błędów zamienia się w listę życzeń.

Odpowiedzialności po wdrożeniu: wsparcie techniczne i aktualizacje

Wsparcie po wdrożeniu obejmuje dwa nurty: wsparcie techniczne dla użytkowników oraz bieżącą aktualizację systemu. Oba są stałymi elementami funkcjonowania systemu, a nie działaniami incydentalnymi, i oba wymagają przypisania właściciela oraz środków w budżecie na utrzymanie.

Wsparcie organizuje się kaskadowo: pierwsza linia działa wewnątrz organizacji i przyjmuje zgłoszenia, druga obejmuje dostawcę lub dział IT i rozwiązuje problemy wymagające zmian w systemie, trzecia sięga do producenta oprogramowania. W planie trzeba ustalić kanał zgłaszania, godziny dostępności, sposób klasyfikacji priorytetów oraz to, kto ma prawo eskalować sprawę do kolejnej linii.

Aktualizacje są składnikiem całkowitego kosztu posiadania systemu, obok licencji, szkoleń i utrzymania, więc nie mogą być odkładane na moment, gdy pojawi się wolny czas. Każda wymaga testów regresji sprawdzających, czy nie naruszyła wcześniej działających funkcji, oraz ustalonego okna serwisowego — decyzję o terminie i zakresie wdrożenia aktualizacji na środowisko produkcyjne podejmuje właściciel systemu.

Trzy linie wsparcia to kolejno: pierwsza linia wewnątrz organizacji, druga u dostawcy lub w dziale IT, trzecia u producenta oprogramowania. Właściciel systemu po stronie organizacji odpowiada za budżet utrzymania i decyzje o aktualizacjach.

Jak uzgodnić role i uniknąć luk odpowiedzialności

Role najłatwiej uzgodnić, zestawiając je w jednym dokumencie przyporządkowanym do etapów wdrożenia: analiza, projektowanie, implementacja (instalacja, konfiguracja, migracja, szkolenia), testowanie i wsparcie po wdrożeniu. Dla każdego etapu zapisuje się, kto wykonuje pracę, kto zatwierdza wynik, kto jest konsultowany i kto otrzymuje informację. Dokument jest częścią planu wdrożenia i obowiązuje wszystkie strony — organizację, doradcę, dostawcę i użytkowników.

Katalog ról obejmuje zamawiającego, dostawcę systemu, niezależnego doradcę, kierownika projektu, właścicieli procesów, właścicieli danych, użytkowników kluczowych oraz właściciela systemu. Każda rola musi mieć przypisane zadanie w co najmniej jednym etapie wdrożenia — inaczej zostaje wyłącznie na papierze.

Lista wymagań krytycznych i niekrytycznych wraz z odpowiedzią, jaki będzie wpływ na organizację, jeśli dane wymaganie nie zostanie wdrożone, jest narzędziem rozstrzygania sporów o zakres w trakcie projektu.

Podobnie zdanie z etapu wyboru: referencje od użytkowników z tej samej branży i o zbliżonej wielkości firmy są bardziej wiarygodnym wskaźnikiem dopasowania niż prezentacje sprzedażowe.

Te ustalenia powinny być zamknięte przed startem projektu, a nie weryfikowane w trakcie jego trwania.

Luki odpowiedzialności powstają najczęściej w obszarach zależnych od organizacji: dostępność użytkowników do testów i szkoleń, przekazanie i oczyszczenie danych do migracji, decyzje o parametrach konfiguracji, zatwierdzanie modyfikacji standardu wynikających z analizy luk.

Dla każdego z tych punktów trzeba wskazać osobę i termin.

Osobno należy rozstrzygnąć, kto jest właścicielem budżetu — skoro całkowity koszt posiadania obejmuje licencje, szkolenia, utrzymanie i aktualizacje, a pominięcie tych pozycji zaniża wydatek średnio o 40–60%, odpowiedzialność finansowa nie kończy się na dacie odbioru wdrożenia.