Trzy miny na starcie wyboru ERP w firmie rodzinnej
ERP jako pretekst do wojny pokoleń
System ERP rzadko wybucha konfliktem sam z siebie. Zapalnikiem jest to, co niesiemy na spotkania: nawyk kontroli właściciela, ambicje sukcesora, obawy księgowości i zmęczenie zespołu produkcji. Jeśli nie zostaną nazwane i rozbrojone, każde demo stanie się dyskusją o władzy, a nie o faktach. Najczęstszy scenariusz: starsze pokolenie chce pełnej kontroli kosztów i konserwatywnego budżetu, młodsze – wygody, chmury i automatyzacji. Bez wspólnej definicji celu i reguł głosowania nawet świetny kandydat utknie w korytarzu „wróćmy do tematu za miesiąc”.
Nadmiar demokracji kontra jednoosobowe veto
Firmy rodzinne potrafią przeszarżować w obie strony. Albo każdy „musi się wypowiedzieć” (i decyzja tonie w oceanach preferencji), albo jedna osoba ma nieformalne prawo veta i przeciąga wybór tygodniami, bo „coś mu nie leży”. Jedno i drugie kosztuje: rośnie rachunek za pre-sales u dostawców, spada zaangażowanie zespołu, a najważniejsze – traci się okno czasowe, gdy firma na wyborze ERP naprawdę korzysta (np. przed sezonem lub dużym kontraktem). Potrzebne są jasne role, kryteria i termin, po którym decyzja zapada niezależnie od ostatnich wątpliwości.
Customizacja od pierwszego dnia to studnia bez dna
„Niech działa jak nasze arkusze, tylko szybciej” – to droga do przeciągniętych wdrożeń. Custom to kredyt, który spłacacie latami: utrzymanie, testy, kolizje przy aktualizacjach. W rodzinnym biznesie, gdzie koszty i zasoby są policzone, lepiej postawić na fit-to-standard w 70–80% procesów i wybrać 1–2 krytyczne obszary, gdzie dopuszczacie modyfikacje z jasnym uzasadnieniem ekonomicznym. Resztę przykrawa się do standardu, nie odwrotnie.
Brief decyzji: na te pytania odpowiedz zanim obejrzysz demo
Kilka realnych pytań, które porządkują wybór i ograniczają konflikty:
- Jaki jest jednolinijkowy cel wdrożenia ERP (co, gdzie i w jakim czasie ma się poprawić)?
- Kto decyduje o wyborze i na jakich zasadach (RACI, quorum, termin, prawo rozstrzygnięcia remisu)?
- Jakie są 3–5 twardych filtrów rynku (branża, język, wsparcie lokalne, chmura/on-prem, budżet)?
- Jakie mierniki potwierdzą „dobry wybór” (np. skrócenie zamknięcia miesiąca do X dni, redukcja zapasu do Y%)?
- Jaki jest maksymalny akceptowalny koszt i czas wdrożenia fazy 1 oraz limit customizacji?
- Jak przeprowadzimy warsztaty i porównanie ofert, by nie skończyły się licytowaniem bajerów?
- Co zrobimy, gdy pojawi się spór: kto ma prawo veta i jak je uzasadnić finansowo?
- Jak wygląda szybki pilotaż (zakres, kryteria Go/No-Go) i bezpieczna umowa etapowa?
- Jaki jest plan B: minimalny zakres startowy (MVP), jeśli pełny projekt okaże się za ciężki?
Zasady gry i bezpieczniki decyzyjne
Prosty RACI dla rodziny, czyli kto za co odpowiada
Bezformalność w rodzinie nie działa w projektach IT. Zapisz prosty RACI na jedną stronę:
- Responsible – lider wyboru (np. dyrektor operacyjny lub sukcesor), który prowadzi proces i materiał porównawczy.
- Accountable – właściciel/wspólnicy, którzy zatwierdzają wybór wg ustalonych kryteriów i budżetu.
- Consulted – księgowość/finanse, produkcja/logistyka, sprzedaż, magazyn, HR – uczestniczą w warsztatach, oceniają dopasowanie.
- Informed – szersza kadra, którą informuje się o wynikach etapów (krótkie notatki, nie tasiemce).
Jedna osoba nie może być jednocześnie Responsible i jedynym Accountable. To generuje veto ukryte w roli „ja i tak zdecyduję po swojemu”.
Cel biznesowy przełożony na ocenę: od hasła do punktów
Jednolinijkowy cel nie może wisieć w powietrzu. Zamień go na 3–5 kryteriów z wagami, które da się sprawdzić w demie lub pilocie. Przykład: „Skrócić czas od zamówienia do wysyłki i ograniczyć błędy faktur” przekładasz na: czas realizacji zlecenia, liczba ręcznych przeksięgowań, kompletność stanów magazynowych w czasie rzeczywistym, dostępność wsparcia po polsku. Każdemu nadaj wagę (np. „czas realizacji” ważniejszy niż „ładny interfejs”). Potem oceniasz nie ogólnie „podoba się”, tylko czy scenariusz „od zlecenia do wysyłki” system wykonał w przewidzianym kroku i czasie oraz co wymaga obejść lub customizacji.
W rodzinnej firmie to gasi spory. Zamiast „wolę chmurę” kontra „wolę kupić serwer” – liczy się, czy krótszy czas zamknięcia miesiąca i mniejsza liczba błędów da się uzyskać w realnym budżecie. Jeśli dwa systemy są na remis, wygra ten, który spełnia kryteria bez przeróbek lub z lżejszym utrzymaniem.
Szybka ścieżka do krótkiej listy i pilota
Wyznacz 30–40 dni na decyzję o pilocie. Pierwszy tydzień to doprecyzowanie celu, wag i budżetu. Drugi – rozmowy przesiewowe z dostawcami (maksymalnie czterema), którzy pasują do filtrów: branża, język, lokalny serwis, model wdrożenia. Trzeci tydzień – dwa scenariuszowe dema z krótkiej listy. Czwarty – porównanie według wag i decyzja o płatnym, ograniczonym pilocie z jednym z kandydatów.
Klucz to tempo i porządek: każda sesja ma agendę, scenariusz „dzień z życia” i z góry ustalone kryteria oceny. Zespół zapisuje fakty (co działa standardowo, co wymaga obejścia), a nie wrażenia. Emocje spadają, bo rola rodziny nie polega na „wyczuciu”, tylko na wybraniu najlepszego dopasowania do celu w ramach limitów.
Demo po ludzku: scenariusze zamiast pokazu bajerów
Poproś o przejście dwóch–trzech konkretnych ścieżek z waszej codzienności, na waszych przykładowych danych: przyjęcie zamówienia, kompletacja i wysyłka; przyjęcie dostawy z kontrolą jakości; zamknięcie miesiąca z korektą kursów i rozliczeniem magazynu. Niech konsultant pokaże warianty: brak towaru, zwrot, split dostawy. Zwróć uwagę, ile czynności to standard, a ile to konfiguracja lub skrypt. Gdy połowa kroków opiera się na dopiskach „to można doprogramować” – ryzyko rośnie i wracamy do pytania o sens takiego wyboru przy waszym budżecie.
Granice przeróbek: kiedy „fit-to-standard”, a kiedy wyjątek
Ustal dwa progi. Pierwszy: limit czasu i pieniędzy na customizacje w fazie 1 (np. maksymalnie X% budżetu lub Y dni konsultanta). Drugi: kryterium biznesowe, które usprawiedliwia wyjątek (np. modyfikacja skraca proces o określoną liczbę kroków i daje realną oszczędność roboczogodzin). Reszta ląduje w rejestrze „później” albo rozwiązuje się poza ERP: lekką integracją, prostym skryptem ETL, czasową automatyzacją RPA na okres przejściowy. Tańszy próg wejścia dziś często wygra z „idealnym” procesem dopiero za rok.
Pilot i MVP: mały zakres, twarde kryteria Go/No-Go
Pilot nie jest pokazem slajdów. To 4–6 tygodni pracy na zawężonym obszarze, z waszymi danymi i ludźmi. Zakres bywa prosty: sprzedaż + magazyn lub zakupy + przyjęcie + rozrachunki. Ustal mierniki na start (czas obsługi zlecenia, liczba błędów dokumentów, zgodność stanów) i punkt decyzyjny: przechodzimy do umowy wdrożeniowej albo zamykamy temat i rozglądamy się dalej. Pilot ma być na etapie umowy z jasnym wynagrodzeniem i prawem użycia wypracowanych konfiguracji niezależnie od kolejnej decyzji – płacicie za wartość, nie za „marketing techniczny”.
Dobrze działa zasada „trzech czerwonych lampek”: jeśli podczas pilota pojawią się trzy blokery o łącznym koszcie przekraczającym limit customizacji, projekt wraca na stół. Łatwiej podjąć trudną decyzję, gdy z góry widać linię przerwania.
Kontrakt, który nie rozlewa się jak farba
W rodzinnej firmie przewidywalność jest walutą. W umowie wdrożeniowej zapisuj etapowość z akceptacją wyników po każdym kawałku. Mieszany model rozliczeń ogranicza ryzyko: stała cena za analizę i konfigurację standardu, a Time & Material z limitem „not-to-exceed” na integracje i wyjątki. Każda zmiana zakresu przechodzi przez małą komisję zmian (3 osoby: odpowiedzialny biznesowo, finansowy i konsultant wiodący) i musi mieć krótkie uzasadnienie ekonomiczne. Unikaj nieograniczonego „banku godzin”, który kusi do dorabiania funkcji bez policzenia efektu.
Wpisz do umowy: kryteria akceptacji (co to znaczy „działa”), definicję danych testowych, format i terminy odbiorów, prawo do wglądu w timesheety, oraz zasady retencji zespołu wdrożeniowego (kto jest kluczowy i kiedy może być zastąpiony). Z perspektywy kosztów to często ważniejsze niż poziom rabatu na licencję.
Dane i integracje: minimalny bagaż na pierwszy lot
Najwięcej paliwa przepala się na „przeniesieniu wszystkiego”. Na start migruj słowniki i stany otwarte, a historię zamknij do widoków raportowych lub plików referencyjnych. Integruj tylko to, co bloku