Dlaczego klasyczne demo ERP nie wystarcza do podjęcia decyzji
Jak wygląda typowe demo systemu ERP
Standardowe demo systemu ERP to prezentacja sprzedażowa. Dostawca pokazuje kilka ładnie przygotowanych ekranów, kilka „flagowych” funkcji i gładko przechodzi po scenariuszu, który zna na pamięć. Wszystko jest już wstępnie skonfigurowane, dane są idealnie dopasowane, a użytkownik nie może praktycznie nic zepsuć.
W takim pokazie nie ma miejsca na realne potknięcia: błędne dane od klienta, korekty zamówień, opóźnione dostawy czy pomyłki magazynu. System wygląda na prosty, szybki i logiczny. Problem w tym, że codzienna praca w firmie tak nie wygląda. Codzienność to wyjątki, zmiany decyzji w trakcie procesu, presja czasu i użytkownicy o różnym poziomie umiejętności.
W klasycznym demo ERP dostawca wybiera obszary, w których jego produkt jest najmocniejszy. Jeśli system słabiej radzi sobie np. z produkcją jednostkową czy specyficznym raportowaniem, to te wątki są pomijane albo zbywane obietnicą „to się skonfiguruje na etapie wdrożenia”. Dla zespołu po stronie klienta to złudny obraz – piękny, ale niepełny.
Prezentacja sprzedażowa a realny dzień pracy w systemie
Między demo a realnym dniem pracy w systemie ERP jest przepaść. W prezentacji handlowiec pokazuje 10–15 kliknięć, które prowadzą od zamówienia do faktury. W rzeczywistości proces obejmuje:
wprowadzanie niekompletnych lub niejasnych danych od klienta,
weryfikację stanów magazynowych i rezerwacji,
uzgadnianie cen i rabatów z działem handlowym,
zmiany terminu dostawy w ostatniej chwili,
kontakt z produkcją lub planistą, gdy brakuje materiału,
korekty dokumentów, zwroty i reklamacje.
Demo bardzo rzadko pokazuje, jak system zachowuje się pod presją, kiedy użytkownik musi szybko znaleźć informację, przełączyć się między kilkoma oknami, poprawić błąd lub wycofać się z operacji. Nie widać też, ile kroków faktycznie zajmuje wykonanie zadania, gdy posiada się tylko realne dane, a nie podręcznikowy przykład.
W efekcie zarząd otrzymuje pozytywny obraz: „System jest prosty, wszystko działa, konsultant żongluje modułami bez problemu”. Po wdrożeniu okazuje się, że zwykła faktura korekcyjna wymaga przejścia przez pięć ekranów, a dział zakupów musi utrzymywać własne arkusze Excel, bo raport w systemie jest nieczytelny lub niedostępny.
Efekt „wow” i jego krótkotrwałość
Demo ERP jest projektowane tak, aby wywołać efekt „wow”. Jest to zrozumiałe – dostawca chce sprzedać produkt. Problem rodzi się wtedy, gdy ten efekt staje się główną podstawą decyzji. Zespół decyzyjny zachwyca się nowoczesnym interfejsem, dashboardami, widokami 3D magazynu, a w tle nikt nie sprawdza, czy system poradzi sobie z codzienną robotą.
Efekt „wow” jest z natury krótkotrwały. Po kilku dniach pamięta się głównie ogólne wrażenie: „było ładnie, system A wyglądał nowocześniej niż system B”. W tym czasie umykają konkretne pytania:
czy w systemie da się zrealizować nasz nietypowy schemat rabatów,
jak wygląda proces korekty zamówienia już w trakcie realizacji,
czy planer produkcji rzeczywiście widzi wszystko, czego potrzebuje, w jednym widoku,
ile kliknięć wymaga wykonanie najczęściej powtarzającej się czynności.
Bez realnego sprawdzenia tych elementów na własnych danych wybór ERP przypomina zakup auta po obejrzeniu reklamy – ładne ujęcia, efektowne przyspieszenie na pustej drodze i hasło „technologia przyszłości”, ale nikt nie zmierzył faktycznego spalania w mieście w godzinach szczytu.
Ryzyka decyzji opartej tylko na demo
Decyzja o wyborze systemu ERP oparta wyłącznie na demo generuje kilka poważnych ryzyk:
Ukryte koszty – funkcje pokazane na demo okazują się wymagać dodatkowych modułów, konfiguracji lub modyfikacji. Cennik rośnie po podpisaniu umowy.
Niedoszacowany czas wdrożenia – skoro „na demo wszystko działało”, zakłada się krótki harmonogram, który później rozsypuje się przy pierwszych customizacjach.
Rozjazd z realnymi procesami – system wymusza zmianę pracy firmy w sposób, który jest trudny lub kosztowny do zaakceptowania. Zespół obchodząc ograniczenia, wraca do Excela i maili.
Rozczarowanie użytkowników – pracownicy, którzy nie uczestniczyli w demo, dostają narzędzie nieprzetestowane w ich konkretnych zadaniach. Narasta frustracja i opór.
Lock-in technologiczny – po inwestycji w licencje i wdrożenie trudno się wycofać, nawet jeśli po roku widać, że system był złym wyborem.
Te ryzyka można znacząco ograniczyć, przechodząc od „cukierkowego” demo do warsztatu wyboru ERP na własnych danych i realnych scenariuszach procesowych.
Krótki przykład źle wybranego systemu po efektownym demo
Średnia firma produkcyjno-handlowa szukała nowego ERP. Na etapie wyboru zdecydowała się na system, który miał imponujący moduł raportowy i nowoczesny interfejs. Demo wyglądało znakomicie: prowadzący w kilka minut przechodził przez proces od zamówienia po fakturę, pokazując wykresy i zestawienia w czasie rzeczywistym.
Po wdrożeniu okazało się, że system słabo wspiera produkcję z częstymi zmianami zleceń i krótkimi seriami. Planowanie wymagało żmudnej konfiguracji i wielu dodatkowych tabel. Firma zaczęła zlecać modyfikacje, które mocno podniosły koszt projektu. Ostatecznie po dwóch latach budżet całkowity przekroczył pierwotny plan o kilkadziesiąt procent, a część kluczowych procesów nadal była obsługiwana poza systemem.
Przy realnym warsztacie na własnych danych problem z produkcją wyszedłby na wierzch w ciągu kilku godzin. Decyzja o wyborze systemu mogłaby być zupełnie inna albo przynajmniej firma negocjowałaby inne warunki budżetowe i zakresowe.
Cel warsztatu wyboru ERP na własnych danych
Weryfikacja dopasowania do procesów, danych, zespołu i budżetu
Warsztat wyboru ERP na własnych danych ma jeden główny sens: pokazać, jak dany system zachowa się w realnym środowisku firmy. Nie w idealnym, laboratoryjnym scenariuszu dostawcy, tylko w prawdziwych procesach, na prawdziwych (choć czasem zanonimizowanych) danych i z udziałem ludzi, którzy będą z systemu korzystać.
Podczas dobrze zaprojektowanego warsztatu można ocenić:
Dopasowanie procesowe – czy kluczowe procesy da się obsłużyć bez karkołomnych obejść.
Pracę na waszych danych – czy system poradzi sobie z typowymi błędami, brakami, wyjątkami, które występują w firmie.
Komfort pracy użytkowników – czy interfejs jest zrozumiały dla handlowca, magazyniera czy księgowego po krótkim wprowadzeniu.
Szacunkowy wysiłek wdrożeniowy – ile customizacji i konfiguracji będzie potrzebne, aby obsłużyć krytyczne przypadki.
Ryzyka kosztowe – czy już na etapie warsztatu widać elementy, które mogą generować dodatkowe nakłady finansowe.
Warsztat pełni rolę testu rzeczywistości. Zamiast „wierzyć na słowo” w obietnice dostawcy, zespół decyzyjny obserwuje system w akcji, na swoich scenariuszach. To oszczędza późniejsze rozczarowania i pozwala lepiej zaplanować budżet.
Różnica między warsztatem, proof of concept a pilotem
Warsztat na własnych danych bywa mylony z proof of concept (POC) albo pełnym pilotem. Te formy mają jednak inną skalę i koszty:
Warsztat wyboru ERP – 1–2 dni pracy z każdym dostawcą, ograniczony zakres (np. 3–7 procesów), uproszczona konfiguracja, przykładowe dane. Celem jest porównanie rozwiązań i odsiew systemów, które ewidentnie nie pasują.
Proof of concept – zwykle większy zakres niż warsztat, bardziej zaawansowana konfiguracja, czasem integracja z jednym zewnętrznym systemem. Często płatny, z wyraźnym harmonogramem. Służy sprawdzeniu jednego lub kilku kluczowych obszarów w praktyce.
Pilot – fragment faktycznego wdrożenia. System działa w ograniczonym obszarze firmy lub na części danych, czasem równolegle z dotychczasowym rozwiązaniem. Wymaga znacznie większego zaangażowania i zwykle jest już częścią płatnego projektu.
Warsztat to najmniej kosztowna i najszybsza forma przetestowania kilku systemów na równych zasadach. Nie zastąpi on pełnego POC ani pilota, ale pozwala uniknąć wydawania pieniędzy na te etapy w przypadku rozwiązań, które i tak nie przejdą podstawowego testu dopasowania do procesów.
Porównywanie kilku systemów na równych zasadach
Jedną z głównych zalet warsztatu jest możliwość obiektywnego porównania 2–4 systemów ERP na tych samych danych i w tych samych scenariuszach. Zamiast kilkunastu rozproszonych prezentacji, gdzie każdy dostawca pokazuje co innego, zespół decyzyjny ogląda konkretny proces X w systemie A, B i C – w identycznych warunkach.
To podejście umożliwia stworzenie prostej, ale bardzo skutecznej macierzy oceny ERP, w której dla każdego scenariusza zaznacza się:
czy proces dało się zrealizować w całości,
ile wymagał obejść lub manualnych kroków,
jak użytkownicy ocenili intuicyjność obsługi,
jakie modyfikacje dostawca musiałby wprowadzić, aby proces działał komfortowo.
Taka macierz pozwala porównać systemy w sposób znacznie bardziej konkretny niż subiektywne „ten podobał nam się bardziej”. Gdy zestawia się wyniki dla 3–7 kluczowych procesów, różnice między rozwiązaniami stają się bardzo wyraźne.
Warsztat jako jazda próbna przed podpisaniem umowy
Zakup systemu ERP to wydatek i zobowiązanie na lata. Podpisanie umowy wdrożeniowej bez wcześniejszej „jazdy próbnej” na własnych danych jest ryzykowne. Warsztat pełni rolę takiej jazdy próbnej – pokazuje, jak system „prowadzi się” w realnych warunkach.
Podczas warsztatu:
użytkownicy widzą, czy system naprawdę przyspiesza ich pracę, czy tylko „ładnie wygląda”,
zespół projektowy potrafi lepiej oszacować skalę zmian organizacyjnych,
dostawca poznaje specyfikę firmy i może lepiej skalkulować ofertę wdrożeniową.
To także pierwszy test współpracy z dostawcą. Po sposobie prowadzenia warsztatu można wnioskować, jak będzie wyglądała komunikacja w trakcie wdrożenia: czy konsultanci słuchają, czy tłumaczą, czy próbują zrozumieć, a może wpychają standard „za wszelką cenę”.
Jakie decyzje podejmować na podstawie warsztatu
Aby warsztat miał sens, trzeba wcześniej ustalić, do jakich decyzji posłuży. Przykładowe cele:
zawężenie listy dostawców do 1–2 rozwiązań (shortlista),
wybór jednego systemu do dalszych negocjacji umowy wdrożeniowej,
określenie, czy konieczny jest pełny POC w jednym z obszarów (np. produkcja, finanse grupy),
doprecyzowanie wymagań procesowych i technicznych do umowy.
Jasne zdefiniowanie, co stanie się po warsztacie, ułatwia podejmowanie decyzji i ogranicza ryzyko przeciągających się analiz. Zespół wie, że po zakończeniu cyklu warsztatów trzeba np. wytypować system, z którym rozpocznie się negocjacje szczegółowe, a nie „pomyśleć i wrócić do tematu za pół roku”.
Źródło: Pexels | Autor: Pavel Danilyuk
Przygotowanie wewnętrzne – bez tego warsztat będzie atrapą
Definiowanie celów projektu ERP
Warsztat wyboru ERP ma sens tylko wtedy, gdy firma wie, po co w ogóle zmienia system. Ogólne hasła typu „chcemy nowoczesnego ERP” czy „potrzebujemy lepszych raportów” nie wystarczą. Trzeba precyzyjnie ustalić, co ma się zmienić w stosunku do stanu obecnego.
Praktyczne podejście to spisanie kilku jasno sformułowanych celów, np.:
skrócenie czasu obsługi zamówienia od przyjęcia do wysyłki,
lepsza kontrola marży na poziomie zlecenia, klienta i produktu,
redukcja liczby ręcznie utrzymywanych arkuszy Excel,
przejrzyste śledzenie realizacji produkcji w toku,
prostsze przygotowanie raportów zarządczych.
Te cele będą punktem odniesienia do wyboru procesów do warsztatu oraz do oceny, czy dany system faktycznie pomaga je osiągnąć. Bez nich istnieje ryzyko, że warsztat zamieni się w chaotyczne sprawdzanie „co jeszcze system potrafi”, co pochłonie czas bez konkretnego efektu.
Mapa procesów end-to-end – tylko tyle, ile naprawdę trzeba
Zaangażowanie właściwych ludzi po stronie biznesu i IT
Najlepszy scenariusz i dopracowane dane nie pomogą, jeśli warsztat będzie rozgrywany w wąskim gronie „ludzi od IT”. Potrzebny jest zespół, który reprezentuje realnych użytkowników i ma mandat do wypowiadania się o procesach.
Minimalny skład, który sprawdza się w większości firm:
Właściciel biznesowy projektu (np. dyrektor operacyjny, handlowy lub finansowy) – osoba, która odpowiada za cele biznesowe i potrafi powiedzieć: „to jest dla nas akceptowalne”, „tego nie przyjmiemy”.
Koordynator projektu / PM – spina komunikację, pilnuje agendy, podejmuje decyzje organizacyjne, dba o porządek w notatkach i wnioskach.
Przedstawiciele kluczowych działów – handlowiec, planista, magazynier, księgowy, ktoś z produkcji (jeśli dotyczy). Nie muszą być dyrektorami. Lepiej, żeby byli to faktyczni „operatorzy procesu”.
IT / osoba techniczna – nie po to, żeby „rządziła” wyborem, tylko żeby oceniała realność integracji, utrzymania i bezpieczeństwa.
Ten zespół powinien uczestniczyć przynajmniej w części wspólnej warsztatu (prezentacja procesów, dyskusja, podsumowanie). Szczegółowe konfiguracje mogą odbywać się w węższym gronie, ale decyzje nie powinny zapadać wyłącznie między działem IT a dostawcą.
Dla oszczędności czasu można zastosować prosty model: nie wszyscy siedzą na całym warsztacie. Np. magazyn i produkcja dołączają na 2–3 godziny przy swoich scenariuszach, finanse na osobny blok, a jedynie właściciel projektu i koordynator są obecni cały czas.
Minimalny poziom uporządkowania obecnych procesów
Warsztat nie jest konsultingiem procesowym ani terapią dla chaotycznej organizacji. Jeśli firma nie wie, jak <empowinna przebiegać obsługa zamówienia czy procesu produkcyjnego, zobaczy w ERP głównie swoje własne bałagany.
Przed zaproszeniem dostawców dobrze jest przygotować choćby uproszczone opisy procesów „tak jak chcemy, żeby było” (niekoniecznie tak jak jest dziś). W wersji budżetowej wystarczy:
spisanie kroków procesu w Excelu lub prostym narzędziu do mapowania (np. diagram przepływu),
wskazanie odpowiedzialnych ról (kto co robi),
oznaczenie głównych dokumentów i systemów, które biorą udział w danym procesie,
wypunktowanie największych problemów w obecnym przebiegu (co jest ręczne, gdzie są opóźnienia).
Chodzi o minimum jasności, żeby podczas warsztatu nie toczyć wielogodzinnych sporów „jak to u nas w ogóle powinno działać”. ERP nie uporządkuje same z siebie procesu, który nie ma właściciela i ustalonych zasad.
Przygotowanie kryteriów oceny przed startem
Bez kryteriów oceny warsztat zamieni się w festiwal wrażeń: „ten system wygląda nowocześnie”, „tamten szybciej się ładuje”. Trzeba wcześniej uzgodnić, co jest ważne, a co jest tylko „miłym dodatkiem”.
Praktyczny sposób:
Wypisać 10–15 kryteriów, podzielonych na kilka grup: procesowe, użytkowe, techniczne, kosztowe.
Dla każdego kryterium ustalić wagę (np. w skali 1–5), tak aby suma wag wyniosła 100 lub 10.
Przygotować prosty arkusz oceny, w którym po każdym warsztacie z dostawcą zespół wystawia punkty i komentarze.
Przykładowe kryteria procesowe: liczba obejść w obsłudze zamówienia, obsługa wyjątków w magazynie, elastyczność planowania produkcji. Kryteria użytkowe: czytelność ekranu, liczba kliknięć dla typowego zadania, dostępność kluczowych informacji na jednym ekranie. Techniczne: integracja z istniejącymi systemami, dostępność wersji chmurowej, elastyczność konfiguracji. Kosztowe: szacowany nakład konfiguracji, liczba niezbędnych modyfikacji, przewidywane koszty utrzymania.
Ocena nie musi być idealnie obiektywna, ale ma wymusić rozmowę o konkretach. Lepiej po warsztacie usłyszeć: „System A wymaga dwóch obejść w przyjęciu zwrotu, system B robi to standardowo” niż ogólne „A jakoś nam bardziej leżał”.
Jak wybrać i przygotować własne dane do warsztatu
Dlaczego „piękne” dane z Exceli nie wystarczą
Wiele firm na warsztat przygotowuje specjalnie „ładne” próbki danych – pozbawione błędów, dubli i wyjątków. To błąd. System w realnym życiu nie będzie pracował na sterylnym zbiorze, tylko na danych, które od lat żyją własnym życiem.
Jeśli na co dzień występują:
klienci z niepełnymi danymi adresowymi,
produkty bez uzupełnionych wszystkich parametrów,
zamówienia z nietypowymi rabatami lub terminami dostaw,
zlecenia produkcyjne bez kompletu informacji technologicznych,
to właśnie takie przypadki powinny trafić na warsztat. Inaczej testuje się nie prawdziwy system, lecz jego marketingową wersję.
Dobór reprezentatywnych przypadków zamiast pełnej bazy
Nie ma sensu ładować całej bazy klientów czy wszystkich indeksów magazynowych. Dla warsztatu liczy się reprezentatywność, a nie ilość.
Dobry zestaw danych warsztatowych to np.:
kilkunastu–kilkudziesięciu klientów z różnymi warunkami handlowymi (rabatami, walutami, terminami płatności),
zestaw produktów obejmujący: proste towary kupowane i sprzedawane 1:1, produkty z zestawów, produkty z wariantami (kolor, rozmiar), wyroby produkcyjne z różną złożonością technologii,
przynajmniej kilka przypadków „brudnych”: niepełne dane, literówki, brakujący kod, modyfikacje „poza procedurą”.
Zestaw powinien być tak dobrany, żeby przejść przez wybrane scenariusze end-to-end: od pozyskania zamówienia, przez rezerwację towaru i produkcję, aż po fakturę i rozliczenie. Nie chodzi o objęcie wszystkiego, tylko o to, by w wybranych procesach nie zabrakło danych do demonstracji.
Anonimizacja i bezpieczeństwo danych
Dostawca ERP nie potrzebuje znać prawdziwych danych klientów czy wysokości rabatów, żeby przeprowadzić warsztat. W większości przypadków wystarczy logiczna struktura i typowe wartości.
Rozsądne podejście to trzy proste kroki:
Anonimizacja identyfikatorów – zamiana nazw klientów, numerów NIP, adresów na techniczne identyfikatory lub fikcyjne dane o podobnej strukturze.
Agregacja wrażliwych wartości – np. zaokrąglenie cen i rabatów, zmiana waluty, przesunięcie dat o kilka lat.
Umowa NDA – prosta umowa o poufności podpisana przed przekazaniem danych (często dostawcy mają własne wzory, można też użyć krótkiego, jednostronicowego dokumentu).
Jeżeli firma nie ma zasobów, by samodzielnie przygotować dane testowe, można zacząć skromniej: przekazać dostawcy jedynie szablony Exceli z kilkoma przykładowymi rekordami. Na warsztacie część danych może być wprowadzana „na żywo” przez użytkowników – to dodatkowo pokazuje ergonomię pracy.
Format danych – jak nie utopić się w technikaliach
Dostawcy mają różne narzędzia importu, ale nie ma powodu, by na etapie warsztatu inwestować w rozbudowane integracje. Standardowo wystarczy:
kilka prostych plików CSV/XLSX: klienci, produkty, cenniki, magazyny, dokumenty przykładowe,
opis relacji między plikami (np. jaki klucz łączy zamówienia z klientami i produktami),
kilka zrzutów ekranu z obecnego systemu, jeśli nazwy pól są niejednoznaczne.
Zakres techniczny trzeba uzgodnić z dostawcami przed warsztatem. Rozsądne jest postawienie granicy: np. 1–2 dni pracy po stronie dostawcy na przygotowanie środowiska i import danych. Jeśli ktoś żąda więcej – to sygnał, że konfiguracja systemu będzie czasochłonna także w projekcie.
Źródło: Pexels | Autor: Tima Miroshnichenko
Projektowanie scenariuszy procesowych pod warsztat
Wybranie 3–7 krytycznych procesów zamiast „pokrycia wszystkiego”
Kuszące jest, by w czasie warsztatu „zahaczyć” o wszystkie moduły: sprzedaż, zakupy, magazyn, produkcję, finanse, serwis, projekty… Efekt jest prosty: poświęca się po 20–30 minut na każdy obszar i nie widać niczego w całości.
Zdecydowanie lepsze i tańsze podejście to wybór kilku procesów end-to-end, które naprawdę decydują o sukcesie wdrożenia. Przykłady:
„Od oferty do faktury” dla sprzedaży B2B z rabatami i dostawami częściowymi,
„Od zapotrzebowania do przyjęcia towaru” w zakupach z uwzględnieniem braków i reklamacji,
„Od zlecenia sprzedaży do wysyłki” wraz z rezerwacjami i kompletacją magazynową,
„Od planu produkcji do przyjęcia wyrobu gotowego” z obsługą zmian i braków materiałowych.
Dla większości średnich firm 3–5 takich scenariuszy w zupełności wystarczy, by zobaczyć różnice między systemami. Kolejne obszary można poruszyć krócej lub pozostawić na późniejsze etapy (np. pilotaż).
Struktura scenariusza – jak go opisać, żeby dostawcy zrozumieli to samo
Scenariusz musi być opisany w sposób, który nie pozostawia dużego pola do interpretacji. W przeciwnym razie każdy dostawca pokaże inny przebieg procesu i porównanie będzie niewiarygodne.
Dobry opis scenariusza zawiera:
Cel biznesowy – np. „Obsługa zamówienia klienta projektowego z kilkoma dostawami częściowymi, z rozliczeniem marży na poziomie projektu”.
Wejścia – jakie dane startowe są potrzebne (np. karta klienta, cennik, technologia produktu, stan magazynu).
Kroki procesu – w kolejności, z przypisaniem do ról (kto co robi) i z zaznaczeniem, które kroki są krytyczne, a które poboczne.
Wyjątki – minimum 1–2 typowe sytuacje niestandardowe (np. brak towaru, zmiana terminu, zmiana ilości w trakcie realizacji), które muszą zostać pokazane.
Oczekiwane efekty – jakie dane raportowe, dokumenty, alerty mają być dostępne po zakończeniu scenariusza.
Ten opis powinien trafić do wszystkich dostawców w identycznej formie, najlepiej w jednym dokumencie. To zmniejsza ryzyko, że ktoś przygotuje się „po swojemu” i potem trudno będzie porównać jego rozwiązanie z innymi.
Uwzględnienie scenariuszy „trudnych”, a nie tylko „książkowych”
ERP świetnie radzi sobie w katalogowych przykładach. Prawdziwy test zaczyna się tam, gdzie życie odbiega od instrukcji. Dlatego w każdym scenariuszu dobrze jest celowo umieścić sytuację, która dziś sprawia najwięcej kłopotów.
Przykłady takich trudnych przypadków:
klient zmienia zamówienie już po wystawieniu dokumentów magazynowych,
na produkcji brakuje jednego z komponentów i trzeba podmienić go na zamiennik,
dostawca spóźnia się z dostawą kluczowego materiału i trzeba przeplanować produkcję,
magazyn znajduje fizycznie towar, którego brakuje w systemie, albo odwrotnie.
Jeżeli system potrafi obsłużyć takie sytuacje w miarę elegancko, istnieje duża szansa, że codzienna praca użytkowników nie zamieni się w serię desperackich „obejść na boku”. Jeżeli podczas warsztatu konsultant proponuje: „To w takich przypadkach robimy takiego Excela dodatkowego…”, zapala się czerwona lampka.
Poziom szczegółowości – jak nie ugrzęznąć w detalach
Scenariusz musi być na tyle szczegółowy, żeby dostawca mógł się przygotować, ale nie na tyle drobiazgowy, by spędzić miesiąc na jego pisaniu. Rozsądny kompromis:
opis procesu na 2–5 stron A4,
maksymalnie kilkanaście kroków głównych,
wyraźne oznaczenie 3–5 punktów, które koniecznie trzeba zobaczyć (np. kalkulacja marży, śledzenie partii, rozliczenie zlecenia).
Jeśli przy tworzeniu scenariusza pojawia się potrzeba opisania każdej możliwej ścieżki i wyjątku, warto się zatrzymać. Znacznie lepiej przygotować jeden sensowny scenariusz na dany obszar i porządnie go przepracować z dostawcami niż 10 półgotowych, które wszyscy „przeklikają” po łebkach.
Ustalenie zasad gry z dostawcami ERP
Jeden wspólny brief warsztatowy
Każdy dostawca, który bierze udział w warsztacie, powinien dostać ten sam komplet informacji. Inaczej z góry tworzy się nierówne warunki – ktoś przygotuje się lepiej tylko dlatego, że miał więcej danych lub dostał je wcześniej.
Dobry, prosty pakiet startowy to:
Zakres informacji przekazywanych dostawcom
Pakiet informacji dla dostawców powinien być możliwie prosty, ale kompletny. Zbyt rozbudowany dokument odstraszy część firm albo zostanie pobieżnie przeczytany, a zbyt skromny spowoduje serię doprecyzowań i chaos.
Praktyczny zestaw to zwykle:
krótkie (1–2 strony) streszczenie firmy: profil działalności, model sprzedaży, kanały dystrybucji, główne typy klientów,
mapa procesów w wersji roboczej lub chociaż lista kluczowych obszarów (sprzedaż, zakupy, magazyn, produkcja, serwis, finanse),
opis scenariuszy warsztatowych w jednej, wspólnej strukturze,
instrukcja, jak interpretować dane testowe (co jest uproszczeniem, co jest dla was krytyczne),
zasady organizacyjne warsztatu: czas, miejsce, liczba uczestników, wymagane role po stronie dostawcy,
jasne kryteria oceny: na co będziecie patrzeć i jak to będzie mierzone.
Ten pakiet nie musi być wyszlifowany graficznie. Ważniejsze, żeby był spójny i trafił do wszystkich w tej samej wersji, najlepiej jednocześnie.
Ograniczenie „magii konsultanta” – co wolno, a czego nie
Podczas warsztatu dostawcy naturalnie próbują pokazać system w najlepszym świetle. To normalne. Problem zaczyna się wtedy, kiedy połowa z tego, co widzicie, to sztuczki nie do powtórzenia w realnym projekcie bez dodatkowych dni programowania.
Dobrym zabezpieczeniem są proste reguły:
pokazujemy wyłącznie funkcje, które są dostępne w standardzie lub w jasno opisanych dodatkach (bez „możemy to dopisać, tylko nie teraz”),
każda ręczna ingerencja w dane (np. poprawki w SQL, edycja parametrów w tle) musi być nazwana i omówiona,
nie dopuszczamy prezentacji na „innym, lepiej przygotowanym” środowisku niż to, na którym są wasze dane,
jeżeli konsultant mówi „tu pominę kilka kroków konfiguracyjnych”, prosicie o ich omówienie choćby skrótowo – żeby zrozumieć, ile jest tej „magii”.
Nie chodzi o to, żeby utrudniać życie dostawcy, tylko żeby uniknąć efektu: na demo wszystko działało, bo było „podkręcone” ręcznie. A potem w projekcie wychodzi, że połowa z tego wymaga dodatkowego budżetu.
Transparentność prac przygotowawczych po stronie dostawcy
Przygotowanie warsztatu też kosztuje. Jeżeli dostawca inwestuje kilkanaście dni w konfigurację pod was, jest oczywiste, że będzie chciał to potem odzyskać w projekcie. Dlatego lepiej z góry ustalić rozsądny limit.
Praktyczny model:
ustalenie maksymalnej liczby dni na przygotowanie warsztatu (np. 1–2 dni konsultanta),
prośba o krótkie wyszczególnienie, co w tym czasie będzie zrobione (import danych, konfiguracja kluczowych słowników, scenariusze),
zakaz wykonywania dedykowanych modyfikacji pod warsztat, chyba że są jasno opisane i później wycenione jako potencjalne rozszerzenia.
Jeśli któryś dostawca deklaruje, że żeby „cokolwiek sensownego” pokazać, potrzebuje tygodnia pracy – to ważna informacja o złożoności systemu i o tym, jak bardzo będziecie zależni od konsultantów na co dzień.
Ujednolicenie warunków licencyjnych na czas warsztatu
Żeby nie przepłacać na etapie wyboru, warto ustalić, że warsztat odbywa się na podstawie krótkiej, bezpłatnej lub symbolicznie płatnej licencji testowej. To standard u większości producentów, ale trzeba to nazwać wprost.
W praktyce pomaga krótka umowa ramowa, która reguluje:
czas trwania dostępu testowego do systemu i środowiska,
ograniczenia wykorzystania (tylko na potrzeby oceny systemu, bez pracy produkcyjnej),
prawo do zrobienia zrzutów ekranu na użytek wewnętrzny,
sposób likwidacji środowiska po zakończeniu warsztatu (wraz z danymi).
Dzięki temu unikacie sytuacji, w której po warsztacie ktoś próbuje doliczyć dodatkowe opłaty za „pożyczone moduły” lub przedłużenie dostępu, choć jeszcze nie zapadła decyzja zakupowa.
Prosty, wspólny arkusz oceny
Bez ujednoliconej oceny warsztat szybko zamienia się w festiwal wrażeń: „ten system jest fajniejszy”, „tamten ma ładniejsze kolory”. To zabija sens pracy na waszych danych.
Najprościej przygotować krótki arkusz (np. w Excelu) z kilkunastoma kryteriami, które będą oceniane w jednakowej skali, np. 1–5. Obszary mogą wyglądać tak:
obsługa scenariuszy procesowych (osobno dla każdego scenariusza),
łatwość wykonania typowych czynności przez użytkownika,
czytelność i kompletność informacji na ekranie,
raportowanie i możliwość „drążenia” danych z poziomu ekranu,
elastyczność konfiguracji bez programisty,
odporność na wyjątki i „życiowe” przypadki.
Po każdym bloku warsztatu zespół ocenia system na świeżo, osobno dla każdego dostawcy. Zajmuje to kilka minut, a pozwala uniknąć ocen po dwóch tygodniach, opartych głównie na pamięci ogólnego wrażenia.
Struktura warsztatu krok po kroku
Planowanie harmonogramu – ile czasu naprawdę potrzeba
Dla średniej firmy sensowny warsztat z 2–3 dostawcami da się przeprowadzić w 2–4 dni robocze. Rozbijanie tego na tygodnie tylko podnosi koszty i rozmywa uwagę zespołu.
Najprostszy układ:
dzień 1 – dostawca A,
dzień 2 – dostawca B,
opcjonalnie dzień 3 – dostawca C lub dogrywka pytań do A/B,
dzień 4 – wewnętrzne podsumowanie i porównanie ocen (bez dostawców).
Jeśli czasu jest mało, można zrobić krótsze, półdniowe sesje, ale wtedy lepiej na starcie obciąć liczbę scenariuszy niż próbować „upchnąć” wszystko kosztem jakości.
Otwarcie warsztatu – wyrównanie oczekiwań
Pierwsze 30–45 minut z każdym dostawcą powinno być poświęcone na krótkie wprowadzenie, a nie od razu „klikanie”. Chodzi o to, żeby:
potwierdzić, że wszyscy rozumieją scenariusze tak samo,
uzgodnić, co na pewno zostanie pokazane, a co może zostać tylko omówione,
przedstawić skład zespołu po obu stronach i ich role,
uzgodnić, jak będą zadawane pytania (na bieżąco czy blokowo).
Prosty trik organizacyjny: na tablicy lub slajdzie pokazujecie listę scenariuszy z przewidzianym czasem. Dzięki temu łatwiej pilnować, żeby nie ugrzęznąć na pierwszym procesie i potem nie gonić z resztą.
Realizacja scenariuszy – kto „trzyma kierownicę”
Standardem jest, że pokaz prowadzi konsultant dostawcy. Warto jednak wpleść element, w którym użytkownik końcowy sam wykonuje kilka kluczowych czynności. Różnica jest kolosalna.
Dobrze sprawdzają się dwie zasady:
konsultant pokazuje pierwszy przebieg scenariusza, komentując decyzje i logikę,
Po kilku minutach widać, czy ekran jest intuicyjny, ile razy trzeba „pytać konsultanta, gdzie to jest” i ile kliknięć wymaga typowe zadanie. To oszczędza wielu rozczarowań po wdrożeniu.
Obsługa wyjątków i „psucie” scenariusza
Scenariusz powinien zawierać przewidziane wcześniej wyjątki. Dobrą praktyką jest dodatkowo zaplanowanie krótkiej części, w której świadomie „psujecie” idealny przebieg:
zmiana ilości lub terminu już po zarezerwowaniu towaru,
wprowadzenie błędnych danych i sprawdzenie, jakie komunikaty pojawią się w systemie,
zmiana parametrów technologii lub zamienników materiałowych w trakcie realizacji.
Najoszczędniej jest ograniczyć się do 1–2 takich eksperymentów na scenariusz. Chodzi o to, by zobaczyć, czy system pomaga, czy przeszkadza, gdy rzeczywistość odkleja się od planu, a nie o kompletną analizę wszystkich wyjątków.
Blok na pytania i „co by było gdyby”
Zamiast zasypywać konsultanta pytaniami w trakcie każdego kliknięcia, wygodniej jest zebrać je w krótkie bloki, np. po zakończeniu scenariusza. To zmniejsza ryzyko, że cała sesja rozmyje się w dyskusjach o szczegółach, które i tak będą dopracowywane na etapie analizy przedwdrożeniowej.
Dobry schemat:
pokaz scenariusza „tak jak jest opisany”,
5–10 minut na pytania o modyfikacje typu „czy da się to zrobić inaczej?”,
zanotowanie pomysłów i potencjalnych rozszerzeń w osobnej sekcji (bez wchodzenia w wyceny).
Jeśli coś wymaga większej przebudowy systemu, konsultant powinien to jasno zaznaczyć. To nie jest wada, o ile jest nazwana – daje możliwość świadomego wyboru, z czym wiąże się dana ścieżka.
Rola moderatora po stronie firmy
Bez osoby, która pilnuje czasu i porządku, warsztat szybko zamienia się w otwarte forum. Moderator nie musi być ekspertem od ERP, ale powinien umieć:
trzymać się agendy i odcinać wątki poboczne („wrócimy do tego na koniec”),
pilnować, żeby głos mieli nie tylko „najgłośniejsi” (często sprzedaż), ale też magazyn czy księgowość,
przerywać, kiedy konsultant odpływa w technikalia mało istotne na tym etapie,
zbierać na bieżąco pytania, które wymagają doprecyzowania po warsztacie.
Najlepiej, jeśli moderator nie reprezentuje jednego, wąskiego działu – to zmniejsza ryzyko „przekierowania” warsztatu tylko na jeden obszar biznesu.
Dokumentowanie ustaleń „na gorąco”
Pamięć po kilku intensywnych dniach bywa zawodna. Zamiast liczyć na to, że wszyscy zapamiętają istotne szczegóły, lepiej prosto to zanotować.
W praktyce wystarczy:
krótki protokół po każdym dniu (jedna strona): najważniejsze wnioski, zalety, ryzyka, otwarte kwestie,
zdjęcia lub zrzuty ekranu kluczowych widoków (z oznaczeniem, którego dostawcy dotyczą),
lista pytań otwartych, które trzeba wyjaśnić po warsztacie – np. mailowo lub na krótkim follow-upie.
Takie notatki nie zastąpią późniejszej analizy, ale pozwolą uniknąć sytuacji, w której po dwóch tygodniach nikt nie pamięta, który system lepiej poradził sobie z konkretnym wyjątkiem w procesie.
Wewnętrzne podsumowanie bez udziału dostawców
Po zakończeniu wszystkich sesji z dostawcami zespół powinien spotkać się wewnętrznie. Bez sprzedaży po drugiej stronie, bez prezentacji marketingowych – tylko użytkownicy, IT i osoby decyzyjne.
Na tym etapie przydaje się:
wspólne przejście przez arkusze ocen i porównanie rozbieżności,
omówienie, gdzie różnice wynikają z funkcjonalności, a gdzie z przygotowania warsztatu przez dostawcę,
ustalenie krótkiej listy dodatkowych pytań do 1–2 faworytów,
podjęcie decyzji, kto przechodzi dalej, a kto odpada – na podstawie danych, a nie wrażeń „bo się lepiej rozmawiało”.
W tym momencie zwykle wychodzi też, czy warsztat przyniósł wystarczająco dużo informacji, czy konieczny jest jeszcze wąski, dodatkowy pokaz jednego obszaru (np. finansów) z udziałem głównej księgowej. Najważniejsze, żeby ten dodatkowy krok był precyzyjnie zdefiniowany i krótki, a nie kolejnym „mini wdrożeniem na próbę”.
Najczęściej zadawane pytania (FAQ)
Dlaczego samo demo ERP to za mało, żeby wybrać system?
Demo jest przygotowaną prezentacją sprzedażową: idealne dane, wyczyszczone procesy, konsultant zna scenariusz na pamięć. Nie widać tam typowych problemów z firmy – błędnych dokumentów, opóźnień, wyjątków czy konieczności wprowadzania korekt „na ostatnią chwilę”.
Na tej podstawie łatwo przecenić prostotę systemu i zaniżyć koszty oraz czas wdrożenia. Realny obraz daje dopiero praca na własnych danych i procesach, z udziałem ludzi, którzy faktycznie będą z systemu korzystać.
Na czym polega warsztat wyboru ERP na własnych danych?
Warsztat to 1–2 dni, podczas których dostawca pracuje razem z zespołem firmy na kilku kluczowych procesach, zasilonych przykładowym wycinkiem waszych danych (często zanonimizowanych). Chodzi o sprawdzenie, jak system przechodzi przez realny dzień pracy, a nie pokaz slajdów.
W czasie warsztatu można zobaczyć m.in., ile faktycznie jest kliknięć, jak system reaguje na błędy, co się dzieje przy korektach i wyjątkach oraz czy użytkownicy „łapią” interfejs po krótkim wprowadzeniu. To szybki, stosunkowo tani filtr, który odsiewa rozwiązania kompletnie niedopasowane.
Jak przygotować firmę i dane do warsztatu ERP?
Najpierw trzeba wybrać 3–7 procesów krytycznych dla biznesu, np. przyjęcie zamówienia, planowanie produkcji krótkich serii, kompletacja i wysyłka, fakturowanie, reklamacje. Dobrze, jeśli wśród nich są też procesy „kłopotliwe”, a nie tylko te najprostsze.
Następnie przygotowuje się mały, reprezentatywny pakiet danych: kilka realnych zamówień, kartoteki produktów (wraz z błędami, które pojawiają się w praktyce), typowe rabaty, przykładowe korekty. Na tej bazie dostawca konfiguruje uproszczone środowisko demonstracyjne – bez całego wdrożenia, ale wystarczające, żeby pokaz nie był oderwany od rzeczywistości.
Czym różni się warsztat, proof of concept i pilot ERP?
Warsztat wyboru ERP to najlżejsza forma: 1–2 dni, ograniczony zakres procesów, uproszczona konfiguracja, brak integracji lub minimalne połączenia. Służy głównie porównaniu kilku dostawców pod kątem dopasowania do procesów i komfortu pracy użytkownika.
Proof of concept (POC) jest już większym projektem – obejmuje więcej procesów, głębszą konfigurację i czasem jedną integrację, np. z systemem magazynowym. Często jest płatny i służy sprawdzeniu, czy system „udźwignie” kluczowe obszary przed decyzją o pełnym wdrożeniu.
Pilot to w praktyce mini-wdrożenie w wybranym dziale lub na ograniczonej skali (np. jedna linia produkcyjna, wybrani handlowcy). Jest najdroższy i najdłuższy, ale daje najbardziej wiarygodny obraz. Warsztat pozwala często uniknąć kosztownego pilota nieudanego systemu.
Jakie korzyści finansowe daje warsztat na własnych danych?
Największa oszczędność to uniknięcie złego wyboru systemu, który po roku czy dwóch wymaga drogich modyfikacji albo jest omijany przez kluczowe działy. Jeden warsztat kosztuje ułamek tego, co późniejsze customizacje, dodatkowe moduły czy przedłużające się wdrożenie.
Dodatkowo warsztat pomaga realnie oszacować koszty: od razu widać, które obszary wymagają niestandardowych prac i gdzie „ukrywają się” potencjalne dopłaty. Dzięki temu łatwiej negocjować warunki umowy i uniknąć sytuacji, w której budżet rośnie o kilkadziesiąt procent po podpisaniu kontraktu.
Jak ocenić wynik warsztatu ERP i porównać dostawców?
Najprościej zbudować krótką, wspólną dla wszystkich dostawców listę kryteriów: obsługa kluczowych procesów „end to end”, liczba obejść i ręcznych trików, intuicyjność dla użytkowników, elastyczność przy zmianach i korektach, sygnały potencjalnych dodatkowych kosztów. Każdy zespół (sprzedaż, magazyn, produkcja, finanse) powinien ocenić system z własnej perspektywy.
Dobrym, „budżetowym” podejściem jest też prosty scoring: np. skala 1–5 dla każdego procesu i kryterium oraz krótki komentarz, gdzie pojawiły się problemy. Zamiast opierać się na wrażeniu „system był ładny”, decyzja wynika wtedy z konkretów, które da się obronić przed zarządem i działem finansowym.
Czy mała lub średnia firma też potrzebuje warsztatu, czy to tylko dla korporacji?
Dla małych i średnich firm warsztat bywa wręcz ważniejszy, bo margines na pomyłkę jest mniejszy – nietrafiony ERP potrafi na kilka lat „zamrozić” rozwój i budżet inwestycyjny. Nie musi to być rozbudowane przedsięwzięcie: często wystarcza 1 dzień, 3–4 procesy i podstawowe dane.
Zamiast inwestować od razu w drogi pilot, lepiej zorganizować krótki, dobrze przygotowany warsztat z 2–3 finalistami. To kompromis między kosztem a bezpieczeństwem decyzji: minimalizuje ryzyko przepalenia setek godzin i dziesiątek tysięcy złotych na system, który w realnej pracy się nie sprawdza.
