| REKLAMA |
 |
Szacunki mówią o 80% wskaźniku niepowodzeń. Te 80% to nie tylko spektakularne procesy sądowe i nagłówki w mediach. To tysiące wdrożeń, które po prostu nie przyniosły tego, co obiecywano - cicho, boleśnie, latami. Eric Kimberling, CEO Third Stage Consulting, i Fred Hesler, szef praktyki biegłych sądowych, od lat rozkładają takie porażki na czynniki pierwsze. Ich obserwacje, wynikające z bezpośredniego udziału w dziesiątkach sporów sądowych i audytów, dają obraz nieprzyjemny, ale wart poznania.
Organizacja nie wie, ile ją to będzie kosztować nie finansowo, a operacyjnie
Gdyby trzeba było wskazać jedną przyczynę porażek wdrożeń, byłaby nią niedoszacowanie zaangażowania, jakiego projekt wymaga od organizacji. Firmy traktują wdrożenie ERP jak upgrade systemu operacyjnego jak przejście z Windows 98 na nowszą wersję. Tymczasem to gruntowna przebudowa sposobu, w jaki firma funkcjonuje na co dzień.
Projekt ERP wymaga pełnego zaangażowania kluczowych pracowników tych samych, bez których firma z trudem działa operacyjnie. Ktoś musi zdefiniować wymagania. Ktoś musi testować. Ktoś musi podejmować decyzje szybko i konsekwentnie. Ktoś musi oczyścić dane a to zadanie, którego większość organizacji w ogóle nie przewiduje po swojej stronie.
Problem ma dwie strony. Firma nie zdaje sobie sprawy ze skali wysiłku. Ale integratorzy też nie pomagają klientom się przygotować. Jak mówi Fred Hesler:
Nie sądzę, żebyśmy jako branża dobrze radzili sobie z pomaganiem klientom w wypełnianiu ich obowiązków wynikających z kontraktów. To nie są rzeczy, które klienci robią na co dzień.
Presja na start - kto ją wywiera i dlaczego
Jest taki schemat, który powtarza się niemal w każdym problematycznym wdrożeniu. Dzień po podpisaniu kontraktu dostawca mówi: „Mamy zespół gotowy do pracy. Jeśli nie zaczniecie teraz, ten zespół trafi do innego projektu." Klient nie ma jeszcze swoich ludzi, nie ma planu, nie ma oczyszczonych danych ale zgadza się, bo boi się stracić „najlepszych konsultantów".
To taktyka sprzedażowa. Dostawca zarabia na godzinach konsultantów. Im wcześniej zaczną, tym szybciej płynie przychód. Interes klienta jest odwrotny: dać sobie czas na mobilizację zespołu, przygotowanie danych, opracowanie planu zarządzania zmianą i governance'u projektu. Ale ten głos przegrywa z presją, bo klient z natury rzeczy deferencyjnie traktuje „eksperta" i tego eksperta słucha.
Efekt? Przedwczesny start projektu. Zmarnowane tygodnie. Narastający dług organizacyjny, który potem eksploduje w najbardziej nieodpowiednim momencie. Co ciekawe, ta taktyka działa też w drugą stronę. Gdy projekt zaczyna się sypać i pojawia się pomysł pauzy, integrator mówi: „Jeśli teraz się zatrzymacie, nie gwarantuję, że odzyskacie ten sam zespół."
Szczerze mówiąc, to po prostu nieprawda. A poza tym - jeśli sprawy idą tak źle, to nie jestem pewien, dlaczego chcielibyście ten sam zespół z powrotem - komentuje Hesler.
Kiedy porażka staje się katastrofą - brakujący moment „stop"
Porażki wdrożeniowe nie zdarzają się z dnia na dzień. To powolne osuwanie się projekt zaczyna opóźniać, budżet puchnie, testowanie jest kompromisowane, a nikt nie mówi „stop".
Tymczasem zatrzymanie projektu w odpowiednim momencie potrafi uratować miliony. Hesler jest tu kategoryczny:
Bardzo często widzimy przypadki, w których klient powinien był zatrzymać projekt i go przebudować, bo czuł, że coś jest nie tak i miał rację. Ale tego nie zrobił.
Klienci nie przerywają, bo ufają integratorowi. Integratorzy nie przerywają, bo każda pauza to ludzie na ławce i przerwa w przychodach. Z obu stron działa ekonomia, która każe ciągnąć projekt dalej, nawet gdy jest już widoczne, że zmierza do ściany.
Z perspektywy ewentualnego sporu sądowego to ma poważne konsekwencje. Jak mówi Hesler:
Jeśli jako klient nie podniesiecie ręki, nie zaprotestujecie formalnie i zgodnie z kontraktem, to druga strona powie: «Płaciliście rachunki. Nie zgłaszaliście zastrzeżeń. Widocznie było w porządku.» Nikt nie da wam punktów za cierpliwość.
„Najlepsze praktyki" ulubione zaklęcie dostawców
Jest takie sformułowanie, którego używa każdy dostawca oprogramowania: „best practices". „Nasz system zawiera najlepsze praktyki branżowe." Brzmi przekonująco do momentu, gdy zaczniemy zadawać pytania.
Czyje to najlepsze praktyki? Kto je zdefiniował? Czy istnieje jakieś międzynarodowe ciało certyfikujące najlepsze praktyki? Nie istnieje. W praktyce „najlepsze praktyki" oznaczają najczęściej „tak nasz system już działa". Dostawca twierdzi, że to standard, a odchylenie od tego standardu jest problemem klienta.
To prowadzi do jednego z najbardziej toksycznych wzorców wdrożeniowych: podejścia „fit-to-standard", w którym klient ma dopasować swoje procesy do oprogramowania. Teoria jest piękna standaryzacja, redukcja customizacji, szybsze wdrożenie. W praktyce wygląda to tak:
- Dostawca i klient zgadzają się: minimalizujemy kastomizację.
- Nikt nie poświęca czasu, żeby zrozumieć, jak klient naprawdę pracuje.
- Pracownicy klienta mówią: „To nie działa, nie da się tak realizować naszych procesów."
- Przez jakiś czas trwa wzajemna frustracja.
- Zespół wdrożeniowy w końcu się poddaje i zaczyna odtwarzać stare procesy w nowej technologii.
- Cel minimalnej kastomizacji pada. Korzyści ze standaryzacji nie ma. A kosztów przybyło.
Hesler trafnie diagnozuje problem:
Jako branża nie robimy dobrej roboty w zrozumieniu zarówno fizycznych, jak i logicznych modeli obecnych procesów operacyjnych klienta. A bez tego nie jesteśmy w stanie pomóc klientowi wyobrazić sobie nowych sposobów pracy.
Excel nie jest problemem jest symptomem
Po każdym trudnym wdrożeniu pojawia się ta sama obserwacja: ludzie wracają do Excela. Pracują poza systemem. Prowadzą równoległe arkusze z danymi. Łatwo to zrzucić na opór przed zmianą. Ale w większości przypadków powód jest prostszy: system nie pozwala im robić tego, co robili wcześniej. Nie dlatego, że są oporni. Dlatego, że ktoś na etapie zbierania wymagań nie zrozumiał, co jest naprawdę potrzebne.
To efekt domina. Złe zarządzanie wymaganiami prowadzi do luk funkcjonalnych. Luki prowadzą do obejść. Obejścia prowadzą do spadku zaufania do systemu. Spadek zaufania prowadzi do Excela. A Excel prowadzi do sytuacji, w której firma ma dwa źródła prawdy i żadnemu nie ufa w pełni.
Vendor lock-in problem, który dopiero rośnie
Jedno z pytań, które padło podczas dyskusji Kimberlinga z Heslerem, brzmiało: „Czy rynek rozwiązał problem uzależnienia od dostawcy?" Odpowiedź: nie, jest gorzej. Model subskrypcyjny SaaS zmienił zasady gry. Dawniej firma kupowała licencję jednorazowo. Dziś płaci miesięcznie, a umowa na 3–5 lat z ograniczoną możliwością wyjścia jest standardem. Nie ma klauzuli „termination for convenience". Jeśli chcesz odejść przed końcem umowy, zapłacisz za cały pozostały okres albo nawet więcej, bo przyszłe płatności mogą być natychmiastowo wymagalne.
Dostawcy to wiedzą i z tego korzystają. Hesler i Kimberling widzieli przypadki, w których dostawca podwyższał opłaty za odnowienie umowy, licząc na to, że klient nie zdecyduje się na migrację bo jest po prostu za trudna i za droga.
Eric Kimberling idzie dalej:
Jeszcze nie zaczęliśmy widzieć pełnych konsekwencji tego zjawiska. Za 10 lat firmy z obecnej fali migracji do chmury zaczną szukać alternatyw i odkryją, jak trudno jest z tych platform wyjść.
Kiedy winny jest integrator, a kiedy klient
Porażka ma zwykle więcej niż jednego ojca. Hesler widziała przypadki z obu stron:
Po stronie integratorów: niekompetentni konsultanci, kompletny brak zrozumienia wymagań biznesowych klienta, fatalne praktyki testowe, złe zarządzanie projektem, a sporadycznie zachowania nieetyczne.
Po stronie klientów: brak zaangażowania, opóźnienia w podejmowaniu decyzji, powracanie do decyzji, które już zostały podjęte (tzw. relitigating decisions), a w ekstremalnych przypadkach również zachowania nieetyczne, włącznie z nadużyciami.
Jest w tym pewna ironia: to klient ma największą kontrolę nad projektem. Ale większość klientów nie czuje się tak, jakby ją miała. Zamiast aktywnie zarządzać wdrożeniem, podążają za tempem i regułami narzuconymi przez dostawcę co często prowadzi w kierunku, który jest korzystny technologicznie dla dostawcy, ale niekoniecznie dla biznesu klienta.
Czego dostawcy uczą się z procesów sądowych
Na pytanie, czy wielcy dostawcy SAP, Oracle, Microsoft wyciągają wnioski z głośnych procesów sądowych, Hesler i Kimberling odpowiadają zgodnie: uczą się pisać lepsze kontrakty. Nie zmieniają swoich praktyk.
To racjonalne z ich perspektywy. Ilość przychodów z subskrypcji i migracji do chmury wielokrotnie przekracza koszty okazjonalnych procesów. SAP jest tego najlepszym przykładem kurs akcji rośnie, bo firma skutecznie sprzedaje migracje do S/4HANA. Inwestorzy to doceniają. Sporadyczne pozwy to szum, nie sygnał.
Zmiana, jeśli przyjdzie, przyjdzie raczej od regulatorów. Unia Europejska bada SAP pod kątem praktyk antykonkurencyjnych. Celonis pozwał SAP za blokowanie konkurencyjnych technologii process mining. Kimberling uważa, że to dopiero początek:
Nie sądzę, żeby dostawcy zmienili się sami. Pokusa subskrypcji chmurowej jest zbyt duża. Strażniki będą musieli ustawić regulatorzy.
Co zrobić, żeby nie trafić na listę porażek
Fred Hesler podsumowuje jedną radą: bądźcie szczerzy wobec siebie. Szczerzy w ocenie, ile ten projekt naprawdę kosztuje nie finansowo, ale organizacyjnie. Ile uwagi waszych najlepszych ludzi pochłonie. Jak szybko realistycznie jesteście w stanie się ruszyć. I kogo zatrudniacie do pomocy.
Kilka konkretnych rekomendacji z ich doświadczenia:
- Ocena gotowości przed startem.
Zanim podpiszecie kontrakt, sprawdźcie: czy dane są czyste? Czy procesy są udokumentowane? Czy macie ludzi, których możecie oddelegować na projekt na miesiące? Jeśli nie naprawcie to najpierw. - Rozumienie kontraktu.
Nie wystarczy, że przeczyta go dział prawny. Prawnik nie zrozumie implikacji technicznych i wdrożeniowych. Potrzebujecie kogoś, kto rozumie zarówno prawo, jak i specyfikę projektów IT. - Zdefiniowana ścieżka eskalacji.
Kontrakt powinien jasno określać, co zrobić, gdy coś idzie nie tak. Do kogo idziecie? Jak formalnie zgłaszacie zastrzeżenia? Brak takiego mechanizmu jest równoznaczny z brakiem hamulca w samochodzie. - Wybór integratora pod kątem dopasowania kulturowego.
Nie wybierajcie największego ani najtańszego. Wybierajcie takiego, który uszanuje tempo waszej organizacji i zrozumie specyfikę waszego biznesu. - Gotowość do powiedzenia „stop".
Jeśli czujecie, że coś jest nie tak prawdopodobnie macie rację. Im wcześniej zatrzymacie projekt do rekalibracji, tym mniej boli.
Prawdziwy koszt porażki nie mieści się w bilansie
O jedno firmy często zapominają: nieudane wdrożenie niszczy coś więcej niż budżet IT. Niszczy morale, zaufanie pracowników, wiarę w zdolność organizacji do przeprowadzenia zmiany. Hesler widział firmy, w których echo nieudanego projektu sprzed 8–10 lat wciąż wpływało na zachowania i postawy ludzi.
Cynizm, zmęczenie, sceptycyzm to spadek po złym wdrożeniu. Następnym razem, gdy firma spróbuje wdrożyć nowy system, zacznie z deficytem zaufania, który trzeba najpierw odbudować. A to wymaga czasu, którego nikt nie chce przyznać.
FAQ
Czy porażka wdrożenia ERP to zwykle wina oprogramowania?
Prawie nigdy. W zdecydowanej większości przypadków oprogramowanie działa zgodnie ze specyfikacją. Problemy wynikają z błędnych decyzji, złego zarządzania projektem, niedoszacowania zaangażowania organizacji lub niedopasowania systemu do procesów biznesowych ale to są kwestie ludzkie i organizacyjne, nie technologiczne.
Kiedy warto rozważyć zatrzymanie projektu wdrożeniowego?
Kiedy czujecie, że coś jest nie tak i wasze przeczucie potwierdza się w danych: opóźnienia w testach, kompromisowanie kryteriów wejścia do kolejnych faz, narastający backlog nierozwiązanych problemów. Im wcześniej podejmiecie decyzję o pauzie, tym mniej boli finansowo i organizacyjnie. Kluczowe: protest musi być formalny i zgodny z procedurą opisaną w kontrakcie.
Jak uniknąć pułapki vendor lock-in przy wyborze systemu ERP?
Nie podpisujcie dłuższych umów tylko dla kilku procent rabatu. Analizujcie koszty wyjścia z umowy przed jej podpisaniem. Zadbajcie o to, by architektura wdrożenia pozwalała na wymianę komponentów bez konieczności wymiany całej platformy. Zachowajcie opcjonalność - dziś system pasuje, ale za pięć lat sytuacja może wyglądać zupełnie inaczej.
Kto powinien kierować projektem wdrożeniowym osoba techniczna czy biznesowa?
Najlepsze efekty daje tandem: ktoś, kto rozumie techniczną złożoność wdrożeń IT i ma wyczucie na ryzyka projektowe, połączony z liderem biznesowym, który zna organizację, jej procesy i specyfikę. Sam data scientist czy sam dyrektor operacyjny to za mało potrzebne są oba spojrzenia jednocześnie.
Najnowsze wiadomości
Miele wdraża IFS Cloud w ponad 25 krajach - co to oznacza dla zarządzania serwisem w skali globalnej
Miele przenosi zarządzanie serwisem terenowym na platformę IFS Cloud z wbudowaną sztuczną inteligencją. Po dziewięciomiesięcznym wdrożeniu w Australii i Nowej Zelandii, obejmującym 200 techników i agentów contact center, firma planuje rozszerzyć system na ponad 25 krajów w ciągu pięciu lat. W centrum strategii stoi IFS.ai, silnik AI, który optymalizuje planowanie wizyt i dobór techników na podstawie ich kompetencji oraz dostępności części zamiennych.
Najpierw był chaos w dokumentach
Problemy zaczęły się od niespójności systemów informatycznych. To prowadziło do chaosu, błędów i braku realnej analizy rentowności. Tak do niedawna wyglądała codzienność firmy Termomodernizacje, działającej w zakresie usług budowlanych oraz na rynku OZE. Organizację pracy zmieniło wdrożenie systemu Comarch ERP Optima, który zapewnił automatyzację i uporządkował przepływ dokumentów.
Problemy zaczęły się od niespójności systemów informatycznych. To prowadziło do chaosu, błędów i braku realnej analizy rentowności. Tak do niedawna wyglądała codzienność firmy Termomodernizacje, działającej w zakresie usług budowlanych oraz na rynku OZE. Organizację pracy zmieniło wdrożenie systemu Comarch ERP Optima, który zapewnił automatyzację i uporządkował przepływ dokumentów.
“Zamrożony software” obciąża biznes i administrację
Nieefektywność wydatków na oprogramowanie w firmach poważnie obciąża ich budżety. Sytuacja ta może dotyczyć ponad 40, a według niektórych raportów nawet 50% środków na zakup oprogramowania rocznie. Powód? Część zakupionych licencji po prostu jest nieużywana, ponadto funkcje poszczególnych narzędzi często się dublują, a różne zespoły do realizacji tego samego zadania używają różnych rozwiązań.
Co sprawdziło się w prognozach cyberbezpieczeństwa na 2025 rok i czego spodziewać się w 2026?
Ponad 80% prognoz sformułowanych przez F5 Labs na 2025 rok okazało się trafnych. Botnety sterowane przez AI, ataki na API modeli językowych, grupy APT udające hacktywistów - to nie scenariusze z konferencyjnych prezentacji, lecz realne wektory ataków, które kształtowały miniony rok. Na 2026 rok analitycy wskazują nowe kierunki: protokół MCP jako rosnąca powierzchnia ataku, centralizacja danych tożsamościowych i rosnące ryzyko nadmiernego zaufania do wyników generowanych przez modele AI. Poniżej analiza tego, co się potwierdziło, co nie, i co z tego wynika dla organizacji planujących budżety bezpieczeństwa na kolejne miesiące.
PSI prezentuje nową identyfikację wizualną
W ramach realizowanej strategii transformacji PSI Software SE zaprezentowała nową identyfikację wizualną. Odświeżony wizerunek w spójny sposób oddaje technologiczne zaawansowanie firmy, jej głęboką wiedzę branżową oraz silne ukierunkowanie na potrzeby klientów. Zmiany te wzmacniają pozycję PSI jako innowacyjnego lidera technologicznego w obszarze skalowalnych rozwiązań informatycznych opartych na sztucznej inteligencji i chmurze, rozwijanych z myślą o energetyce i przemyśle.
W ramach realizowanej strategii transformacji PSI Software SE zaprezentowała nową identyfikację wizualną. Odświeżony wizerunek w spójny sposób oddaje technologiczne zaawansowanie firmy, jej głęboką wiedzę branżową oraz silne ukierunkowanie na potrzeby klientów. Zmiany te wzmacniają pozycję PSI jako innowacyjnego lidera technologicznego w obszarze skalowalnych rozwiązań informatycznych opartych na sztucznej inteligencji i chmurze, rozwijanych z myślą o energetyce i przemyśle.
Najnowsze artykuły
Dlaczego 80% wdrożeń ERP kończy się porażką - i co z tego wynika?
Wdrożenia ERP wykolejają się najczęściej nie na poziomie technologii, lecz na styku ludzi, decyzji i interesów, które uruchamiają się już przy podpisaniu umowy. Jeśli organizacja myśli o projekcie jak o „upgrade’ie”, zderzy się z realnym kosztem operacyjnym: czasem kluczowych pracowników, brudnymi danymi, presją na start i brakiem momentu „stop”. Na bazie doświadczeń Erica Kimberlinga i Freda Heslera pokazujemy, skąd biorą się ciche porażki i jak zbudować governance, który ratuje projekt zanim stanie się katastrofą — zanim koszty urosną latami.
KSeF w firmach handlowych: jak wdrożyć go bez przestojów i przy okazji zautomatyzować obieg faktur
W firmie handlowej KSeF nie jest tylko projektem księgowym. To raczej projekt operacyjny, bo wpływa na sprzedaż, zakupy, magazyn, logistykę i integracje z e-commerce oraz marketplace’ami. Darmowe narzędzia wystarczą, żeby wystawić fakturę, ale nie rozwiązują problemu skali: przy dziesiątkach lub setkach dokumentów dziennie bez automatycznego odbioru i kontroli statusów rośnie ryzyko opóźnień, błędów i zatorów w płatnościach. Jeśli chcesz tego uniknąć, przeczytaj ten poradnik.
W firmie handlowej KSeF nie jest tylko projektem księgowym. To raczej projekt operacyjny, bo wpływa na sprzedaż, zakupy, magazyn, logistykę i integracje z e-commerce oraz marketplace’ami. Darmowe narzędzia wystarczą, żeby wystawić fakturę, ale nie rozwiązują problemu skali: przy dziesiątkach lub setkach dokumentów dziennie bez automatycznego odbioru i kontroli statusów rośnie ryzyko opóźnień, błędów i zatorów w płatnościach. Jeśli chcesz tego uniknąć, przeczytaj ten poradnik.
5 pułapek zarządzania zmianą, które mogą wykoleić transformację cyfrową i wdrożenie ERP
Dlaczego jedne wdrożenia ERP dowożą korzyści, a inne kończą się frustracją, obejściami w Excelu i spadkiem zaufania do systemu? Najczęściej decyduje nie technologia, lecz to, jak organizacja prowadzi zmianę: czy liderzy biorą odpowiedzialność za decyzje czy tempo jest dopasowane do zdolności absorpcji oraz czy ludzie dostają klarowność ról i realne kompetencje. Do tego dochodzi pytanie: co po go-live - stabilizacja czy chaos w firmie? Poniżej znajdziesz 5 pułapek, które najczęściej wykolejają transformację i praktyczne sposoby, jak im zapobiec.
SAP vs Oracle vs Microsoft: jak naprawdę wygląda chmura i sztuczna inteligencja w ERP
Wybór systemu ERP w erze chmury i sztucznej inteligencji to decyzja, która determinuje sposób działania organizacji na lata — a często także jej zdolność do skalowania, adaptacji i realnej transformacji cyfrowej. SAP, Oracle i Microsoft oferują dziś rozwiązania, które na pierwszy rzut oka wyglądają podobnie, lecz w praktyce reprezentują zupełnie odmienne podejścia do chmury, AI i zarządzania zmianą. Ten artykuł pokazuje, gdzie kończą się deklaracje, a zaczynają realne konsekwencje biznesowe wyboru ERP.
Transformacja cyfrowa z perspektywy CFO: 5 rzeczy, które przesądzają o sukcesie (albo o kosztownej porażce)
Transformacja cyfrowa w finansach często zaczyna się od pytania o ERP, ale w praktyce rzadko sprowadza się wyłącznie do wyboru systemu. Dla CFO kluczowe jest nie tylko „czy robimy pełną wymianę ERP”, lecz także jak policzyć ryzyko operacyjne po uruchomieniu, ocenić wpływ modelu chmurowego na koszty OPEX oraz utrzymać audytowalność i kontrolę wewnętrzną w nowym modelu działania firmy.
Dlaczego 80% wdrożeń ERP kończy się porażką - i co z tego wynika?
Wdrożenia ERP nie udają się przede wszystkim dlatego, że organizacje nie rozumieją, w co się pakują… / Czytaj więcej
KSeF w firmach handlowych: jak wdrożyć go bez przestojów i przy okazji zautomatyzować obieg faktur
W firmie handlowej KSeF nie jest tylko projektem księgowym. To raczej projekt operacyjny, bo wpływa… / Czytaj więcej
5 pułapek zarządzania zmianą, które mogą wykoleić transformację cyfrową i wdrożenie ERP
Dlaczego jedne wdrożenia ERP dowożą korzyści, a inne kończą się frustracją, obejściami w Excelu i s… / Czytaj więcej
SAP vs Oracle vs Microsoft: jak naprawdę wygląda chmura i sztuczna inteligencja w ERP
Wybór systemu ERP w erze chmury i sztucznej inteligencji to decyzja, która determinuje sposób dział… / Czytaj więcej
Transformacja cyfrowa z perspektywy CFO: 5 rzeczy, które przesądzają o sukcesie (albo o kosztownej porażce)
Transformacja cyfrowa w finansach często zaczyna się od pytania o ERP, ale w praktyce rzadko sprowa… / Czytaj więcej
Composable ERP: Przewodnik po nowoczesnej architekturze biznesowej
Czy Twój system ERP nadąża za tempem zmian rynkowych, czy stał się cyfrową kotwicą hamującą rozwój… / Czytaj więcej
