Definicja: System ERP to zintegrowane oprogramowanie, które wspiera przepływ danych i procesów między kluczowymi obszarami firmy, takimi jak finanse, sprzedaż, zakupy, magazyn, produkcja i raportowanie.
Wybór ERP zacznij od procesów, danych i problemów operacyjnych. Dopiero potem porównuj systemy, partnerów wdrożeniowych oraz koszt całkowity.
Zmapuj procesy end-to-end i ustal wymagania krytyczne.
Oceń integracje, skalę działania oraz sposób realizacji luk funkcjonalnych.
Porównaj całkowity koszt posiadania i kompetencje partnera wdrożeniowego.
Przetestuj system na rzeczywistych scenariuszach firmy.
Lista modułów i standardowa prezentacja nie wystarczą do oceny systemu dla średniej lub dużej organizacji. ERP trzeba rozpatrywać jednocześnie jako narzędzie obsługujące procesy, część środowiska informatycznego oraz rozwiązanie, które firma będzie utrzymywać i rozwijać.
O wyniku wyboru nie przesądza więc liczba dostępnych funkcji. Znaczenie mają dopasowanie do przepływów pracy, możliwość wymiany danych, koszty przyszłych zmian, kompetencje partnera oraz gotowość organizacji do przeprowadzenia wdrożenia.
Nie zaczynaj od rankingu ani serii prezentacji handlowych. Najpierw zdefiniuj procesy, problemy i cele, a dopiero potem porównuj systemy.[1][2][3] Dzięki temu każda oferta będzie oceniana wobec tych samych potrzeb, a nie według atrakcyjności pokazu.
Punktem odniesienia powinny być procesy end-to-end, czyli przepływy przechodzące przez kilka działów. Zamiast pytać wyłącznie o moduł sprzedażowy, trzeba ustalić, jak zamówienie wpływa na dostępność towaru, dokumenty, księgowanie i raportowanie. Taka perspektywa ujawnia zależności, których nie pokazuje lista ekranów.
Nazwij problemy operacyjne. Zapisz, gdzie dane są powielane, proces wymaga ręcznego obejścia albo brakuje informacji potrzebnej do podjęcia decyzji.
Określ cel zmiany. Powiąż planowany system z konkretnymi procesami i rezultatami, które organizacja chce osiągnąć.
Wyznacz właścicieli procesów. Zaangażuj osoby odpowiedzialne za przebieg pracy, dane i decyzje w poszczególnych obszarach.
Ustal wymagania i kryteria akceptacji. Każda potrzeba powinna być możliwa do zweryfikowania podczas analizy lub demonstracji.
Porównuj rozwiązania w tym samym zakresie. Dopiero przygotowany materiał pozwala przejść do rozmów z dostawcami.
Zakres tej analizy powinien odpowiadać branży, skali i modelowi operacyjnemu firmy. Nie chodzi o stworzenie możliwie długiej dokumentacji, lecz o przygotowanie wspólnego punktu odniesienia dla zespołu i oferentów.
Zmapuj procesy, dane i integracje przed rozmowami z dostawcami
Wymagania należy opisywać przez pełne przepływy pracy, wykorzystywane dane, role, wyjątki oraz połączenia z innymi systemami. ERP ocenia się na poziomie całego procesu i integracji, a nie pojedynczych ekranów.[1][3]
Jak opisać proces end-to-end
Opis procesu powinien zaczynać się od zdarzenia biznesowego, a kończyć na dokumencie, raporcie lub decyzji. Trzeba uwzględnić nie tylko prawidłowy przebieg, lecz także wyjątki, odpowiedzialne role i dane przekazywane pomiędzy działami.
Przykładowo proces sprzedaży można prześledzić od przyjęcia zamówienia przez sprawdzenie dostępności towaru, wystawienie dokumentu i księgowanie aż do raportowania marży. Taki zapis pokazuje, które elementy mają działać w ERP, a które zależą od wymiany danych z innymi narzędziami.
Przebieg procesu
Jakie zdarzenie uruchamia pracę, kto wykonuje kolejne czynności i jaki wynik kończy proces.
Dane
Skąd pochodzą, kto odpowiada za ich jakość i w których miejscach są używane.
Wyjątki
Jak system ma obsłużyć odstępstwa od typowego przebiegu i kto podejmuje decyzję.
Integracje
Które systemy pozostają poza ERP i jakie informacje muszą być między nimi wymieniane.
Kryterium akceptacji
Po czym zespół rozpozna, że wymaganie zostało rzeczywiście spełnione.
Jak podzielić wymagania według priorytetu
Wymagania można rozdzielić na krytyczne, ważne i opcjonalne. Krytyczne powinny wynikać z procesów, bez których organizacja nie może działać w zakładanym modelu. Pozostałe pomagają różnicować oferty, ale nie powinny przesłaniać podstawowych potrzeb.
Każde wymaganie należy przypisać do konkretnej kategorii i wskazać, kto oraz jakim kosztem je zrealizuje.[1][3] Istotne jest również odnotowanie, czy funkcja znajduje się w standardzie, wymaga konfiguracji, integracji czy modyfikacji.
W wielu organizacjach możliwość bezpiecznej wymiany danych z kluczowymi systemami może być ważniejsza niż sama liczba modułów.[1][2][3] Waga integracji nie jest jednak jednakowa w każdej firmie. Zależy od modelu biznesowego, istniejącego środowiska informatycznego i zakresu projektu.
Oceń skalowalność i dopasowanie systemu w analizie fit-gap
Skalowalność trzeba oceniać w warunkach odpowiadających obecnej i planowanej działalności firmy. Nie wystarczy potwierdzenie, że do systemu można dodać kolejnych użytkowników. Znaczenie mają również wolumen operacji, liczba spółek, magazynów, lokalizacji oraz złożoność raportowania.
Nie istnieje jedna uniwersalna miara skalowalności. Testy trzeba odnieść do profilu organizacji i sprawdzić, jak rozwiązanie zachowuje się przy wzroście skali operacji oraz złożoności struktur.[1]
Standard, konfiguracja, integracja i kastomizacja — czym się różnią
Analiza fit-gap polega na porównaniu potrzeb firmy z możliwościami systemu. Jej wynikiem nie powinna być jedynie lista braków. Każdą lukę należy zaklasyfikować według sposobu realizacji i opisać jej konsekwencje.
Sposób realizacji
Znaczenie w ocenie
Co należy ustalić
Standard
Wymaganie jest obsługiwane przez dostępne możliwości rozwiązania.
Jak przebiega proces i czy da się go potwierdzić w scenariuszu testowym.
KonfiguracjaSposób działania jest ustawiany bez modyfikowania rozwiązania.
Kto wykona ustawienia i czy mieszczą się one w zakresie oferty.
IntegracjaWymaganie zależy od wymiany danych z innym systemem.
Kto odpowiada za połączenie, dane, testy i utrzymanie.
KastomizacjaPotrzebna jest modyfikacja wykraczająca poza standardową konfigurację.
Jaki będzie koszt, wpływ na aktualizacje oraz możliwość zastąpienia zmiany konfiguracją lub integracją.
Przed zaakceptowaniem modyfikacji trzeba sprawdzić jej koszt, wpływ na późniejsze aktualizacje i możliwość zastosowania prostszego rozwiązania.[3] Większy zakres zmian nie powinien być automatycznym celem projektu.
Jakie parametry skalowalności sprawdzić
przewidywaną liczbę użytkowników i ich role;
wolumen operacji i danych;
liczbę spółek, oddziałów, magazynów lub innych jednostek;
złożoność struktur raportowych;
zakres procesów oraz integracji potrzebnych po rozwoju organizacji.
Przy każdej luce warto zapisać sposób realizacji, odpowiedzialny podmiot, koszt, termin i wpływ na utrzymanie systemu. Taka macierz pozwala odróżnić rzeczywiste dopasowanie od ogólnej deklaracji, że dana funkcja może zostać wykonana.
Porównaj całkowity koszt ERP, nie tylko cenę oferty
Oferty należy porównywać według całkowitego kosztu posiadania, określanego jako TCO, a nie wyłącznie według ceny licencji lub abonamentu.[1][2][3] TCO obejmuje wydatki związane z uruchomieniem, utrzymaniem i rozwojem rozwiązania.
Rzetelne porównanie jest możliwe tylko wtedy, gdy każda oferta dotyczy tego samego zakresu. Rzeczywisty koszt zależy od liczby użytkowników, procesów objętych projektem, modelu wdrożenia i warunków umowy z dostawcą.
Element kosztu
Co obejmuje
Pytanie do dostawcy
Licencje lub abonament
Prawo do korzystania z rozwiązania w uzgodnionym zakresie.
Co wpływa na wysokość opłat i które elementy są objęte ofertą.
WdrożenieAnalizę, przygotowanie rozwiązania i jego uruchomienie.
Jakie założenia zakresowe przyjęto w wycenie.
Migracja danychPrzeniesienie danych potrzebnych do rozpoczęcia pracy.
Kto odpowiada za przygotowanie, jakość i weryfikację danych.
IntegracjeWymianę danych z systemami pozostającymi poza ERP.
Kto tworzy, testuje i później utrzymuje połączenia.
SzkoleniaPrzygotowanie użytkowników i zespołu odpowiedzialnego za system.
Jakie grupy użytkowników i materiały obejmuje zakres.
Utrzymanie i wsparcieObsługę systemu po jego uruchomieniu.
Jak działa wsparcie i jakie warunki określa SLA.
AktualizacjeZmiany rozwiązania potrzebne w trakcie jego użytkowania.
Które aktualizacje są objęte opłatą, a które wymagają osobnej wyceny.
Rozwój i zmianyDalszą konfigurację, integracje lub modyfikacje.
Jak wyceniane są prace wykraczające poza pierwotny zakres.
Każdego oferenta należy poprosić o rozdzielenie kosztów jednorazowych i cyklicznych oraz o wskazanie założeń przyjętych w wycenie. Pozwala to dostrzec sytuację, w której oferta tańsza na początku przestaje być tańsza podczas utrzymania i rozwoju systemu.
Wybierz partnera wdrożeniowego i sprawdź gotowość organizacji
Produkt, partner wdrożeniowy i gotowość własnej organizacji to trzy odrębne elementy decyzji. Ocena marki lub funkcji systemu nie zastępuje sprawdzenia zespołu, który będzie prowadził analizę, konfigurację, migrację, integracje i wsparcie.
Partnera należy oceniać osobno, biorąc pod uwagę doświadczenie w podobnej skali i branży, kompetencje konsultantów, model wsparcia, SLA oraz zasady wyceny zmian.[1][2][4][5] Nie istnieje jednak jeden obowiązujący model takiej oceny. Kryteria trzeba dostosować do zakresu i ryzyka konkretnego projektu.
Co sprawdzić u partnera wdrożeniowego
Referencje: czy dotyczą organizacji o podobnej skali i procesach.
Zespół: kto faktycznie będzie prowadził analizę i realizował prace.
Podział odpowiedzialności: które zadania należą do partnera, producenta i firmy zamawiającej.
Wsparcie: jak wygląda obsługa po uruchomieniu i jakie warunki określa SLA.
Zmiany zakresu: w jaki sposób są zatwierdzane i wyceniane dodatkowe prace.
Rozwój rozwiązania: kto odpowiada za aktualizacje, integracje i dalszą konfigurację.
Czy firma ma zasoby do podjęcia projektu
Dobry produkt nie kompensuje braku właściciela projektu, zespołu decyzyjnego i planu zarządzania zmianą.[4][5] Wsparcie kierownictwa, jasne cele, kompetentny zespół, komunikacja i przygotowanie zmian organizacyjnych są częścią wdrożenia, a nie dodatkiem do prac technicznych.
Czy projekt ma sponsora zdolnego podejmować decyzje międzydziałowe.
Czy każdy ważny proces ma właściciela.
Czy zespół ma czas na analizę, testy i odbiory.
Czy określono odpowiedzialność za przygotowanie danych.
Czy zaplanowano komunikację, szkolenia i pracę z użytkownikami.
Czy zasady podejmowania decyzji oraz akceptowania zmian są jednoznaczne.
Źródła przeglądowe opisują czynniki wpływające na wdrożenia, ale nie pozwalają przewidzieć wyniku konkretnego projektu. Lista kontrolna służy więc do rozpoznania ryzyka, a nie do zagwarantowania powodzenia.
Zweryfikuj ERP na scenariuszach firmy i potwierdź wymagania lokalne
Każdy dostawca powinien otrzymać te same scenariusze biznesowe oraz kryteria oceny. Standardowa prezentacja pokazuje możliwości rozwiązania, ale test firmowego procesu pozwala sprawdzić przepływ danych, wyjątki, integracje i wynik końcowy.
Jak przygotować scenariusz do demo ERP
Scenariusz powinien prowadzić od rzeczywistego zdarzenia biznesowego do dokumentu, raportu albo decyzji.[2][3] Jest to rekomendacja procesowa, a nie wynik jednego badania porównawczego.
Opisz zdarzenie rozpoczynające proces i oczekiwany wynik.
Wskaż role, dane wejściowe oraz systemy uczestniczące w przepływie.
Dodaj wyjątek, który występuje w codziennej pracy.
Ustal kryteria akceptacji wymagania.
Zapisz, czy dostawca wykorzystał standard, konfigurację, integrację czy planowaną modyfikację.
Odpowiedzi i ograniczenia trzeba dokumentować, zwłaszcza gdy realizacja wymagania zależy od przyszłych prac. Dzięki temu końcowa decyzja opiera się na porównywalnych wynikach, a nie wyłącznie na deklaracjach handlowych.
KSeF i inne lokalne wymagania: co potwierdzić
W polskiej organizacji należy zweryfikować aktualne wymogi lokalne, w tym zakres obsługi Krajowego Systemu e-Faktur. Trzeba sprawdzić oficjalną dokumentację KSeF oraz potwierdzić z dostawcą zakres obsługi, terminy aktualizacji i odpowiedzialność za integrację.[6]
Także wtedy, gdy analizowanym rozwiązaniem jest comarch erp, sama nazwa produktu nie zastępuje potwierdzenia zakresu integracji, odpowiedzialności i warunków aktualizacji.
Terminy i wymagania KSeF mogą się zmieniać, dlatego nie należy opierać decyzji na nieaktualnej prezentacji lub ogólnej deklaracji zgodności. Stan techniczny i formalny wymaga ponownej weryfikacji przed publikacją materiału, podpisaniem umowy oraz uruchomieniem integracji.
