Wstęp

W tym odcinku podcastu „Odkoduj wdrożenie ERP” rozmawiamy o tym, jak przygotować firmę do wdrożenia systemu ERP. Dowiesz się, czym jest analiza systemowa, jak oszacować koszt wdrożenia ERP i jakie kroki warto podjąć, aby uniknąć błędów.
W skrócie – o czym rozmawialiśmy w tym odcinku 🎙️

• Zacznij od pytań, które naprawdę mają znaczenie – zamiast szukać „idealnego” systemu, najpierw odpowiedz sobie, co Twoja firma chce osiągnąć i jakie procesy chce usprawnić.
• Traktuj ERP jak inwestycję, nie koszt – najtańsze rozwiązanie często wychodzi… najdrożej, jeśli policzyć poprawki i stracony czas.
• Analiza systemowa to Twój filtr na chaos – dzięki niej od razu wiesz, które funkcje systemu są niezbędne, a z których możesz zrezygnować bez bólu.
• Przygotowanie do wdrożenia ERP skraca projekt nawet o kilka miesięcy – bo zespół wie, co ma robić, a decyzje zapadają szybciej.
• Brak nowego systemu może Cię sporo kosztować – od utraty klientów po zwiększone ryzyko awarii i cyberataków.

Transkrypcja, odcinek 1:

…Przeważnie mamy do czynienia z sytuacją kiedy, projekt informatyczny, projekt wdrożeniowy jest traktowany jako koszt…

…System nie będzie wspierał takiej naszej organizacji, jaką mamy dzisiaj, tylko taką organizację, która się pojawi za 3, 4, 5, 6 lat…

Dzień dobry. Witam w pierwszym odcinku naszego podcastu. Dzisiaj opowiem o tym, dlaczego uważam, że firma, która planuje wdrożenie systemu ERP powinna poświęcić czas i zasoby na to, żeby przygotować się solidnie do tego przedsięwzięcia. Jak również opowiem o tym, co rozumiem mówiąc o przygotowaniach – jakiego typu działania, jakiego typu ustalenia, jakiego typu kroki warto moim zdaniem podjąć.

Zobacz, co możemy dla Ciebie zrobić.

Ten odcinek jest rozwinięciem artykułu „Wdrożenie systemu ERP – koszt czy inwestycja? Analiza biznesowa w pięciu krokach”. Link do niego znajdziecie w opisie odcinka.

Jest to pierwsza część z cyklu prezentacji materiałów o tym, jak firma wdrażająca oprogramowanie może swoimi działaniami wpłynąć na sukces przedsięwzięcia wdrożeniowego. Ta część dotyczy w szczególności wagi definicji celów przedsięwzięcia, szacowania korzyści i kosztów wynikających z realizacji danego przedsięwzięcia. Ale dotyczy także strat, które mogą się pojawić jeśli projekt, o którym myślimy, nie zostanie zrealizowany.

Na początek kilka definicji.

Jeśli mówię o systemie ERP – to mówię o systemie wspierającym zarządzanie organizacją, w takich obszarach jak finanse, księgowość, kadry, płace, produkcja, magazyny, sprzedaż, zakupy, a czasami będą to też dodatkowe moduły takie jak utrzymanie ruchu czy na przykład zarządzanie transportem.

Jeśli mówię o wdrożeniu – to mówię o projekcie, który trwa co najmniej 9 miesięcy, ale raczej myślę tutaj o przedsięwzięciach trwających 1,5 roku do 2 lat i angażujących zarówno po stronie firmy wdrożeniowej, jak i klienta zespoły osobowe liczące po kilkadziesiąt osób.

Te rozważenia dotyczą również sytuacji, w których klient ma możliwość samodzielnie podejmować decyzje co do zakresu, tempa i sposobu realizacji projektu, a nie sytuacje, w których jest to narzucone przez regulatora lub też zdefiniowane przez jakiś byt zewnętrzny, którym mogła być centrala albo ktokolwiek, kto ma z jakiegokolwiek powodu możliwości narzucenia podejścia wdrożeniowego i sposobu realizacji planowanego projektu. Też raczej dotyczy to sytuacji, w których ani dostawca ani klient nie ma pozycji monopolistycznej, ponieważ wtedy swoboda podejmowanych decyzji jest dużo, dużo mniejsza.

Celem tego artykułu jest zwrócenie uwagi na istotność analizy koszt-korzyść. Zwrócenie również uwagi na szerszy kontekst znaczenia wyników tej analizy w czasie.

Dlaczego wdrożenie ERP to inwestycja, a nie koszt

Najprościej rzecz ujmując, proponuję traktowanie wdrożenia jak każdej, dosłownie każdej, innej inwestycji. Takie podejście, taki pomysł, nie jest szczególnie odkrywczy. Natomiast faktem jest, że w mojej karierze zawodowej trwającej 30 lat na rynku informatycznym niezmiernie rzadko spotykałem się z takim podejściem. Muszę powiedzieć, że jak tylko miało to miejsce, to były to naprawdę bardzo efektywne, szybkie, sprawne procesy uzgodnieniowe – czy też w obszarze doboru systemu, czy też potem w trakcie analizy, czy testów czy odbiorów. Dużo prościej, dużo klarowniej, dużo szybciej się rozmawiało, dużo szybciej dochodziło się do porozumienia, dużo szybciej mogliśmy dostarczyć klientowi narzędzie, z którego mógł korzystać i które mogło przynieść mu korzyść.

W związku z tym, że takie podejście nie jest zbyt częste, to przeważnie mamy do czynienia z sytuacją, kiedy projekt informatyczny, projekt wdrożeniowy jest traktowany jako koszt. Więc często nie wybieramy tego co nam da więcej korzyści, co lepiej będzie pasowało do naszego biznesu, do naszych procesów, tylko to, co jest tańsze – co nie zawsze jest najlepszym rozwiązaniem. Wybieramy też do prowadzenia takich przedsięwzięć ludzi, osoby, które nie do końca mają wiedzę i kompetencje pozwalające im na ocenę poszczególnych decyzji w trakcie projektu pod kątem uzyskania założonych korzyści. I często są to osoby, które są daleko od biznesu, które raczej z perspektywy informatycznej patrzą na przedsięwzięcie, a nie z punktu widzenia tego, jak to przedsięwzięcie ma wspierać w przyszłości biznes.

Kolejnym skutkiem takiego podejścia jest to, że procesy doboru rozwiązania zajmują mnóstwo czasu. Spędzamy miesiące na weryfikowaniu możliwości systemu, które realnie nie są tak naprawdę istotne. Są to procesy czasochłonne, męczące, a na koniec często i tak nie wiemy, które rozwiązanie jest dla nas lepsze, które rozwiązanie da nam więcej korzyści, które rozwiązanie sprawniej, taniej i bezpieczniej wesprze nas biznes, jak już zostanie uruchomiony.

Posłuchaj, jak przeprowadzić analizę i wybrać najlepszą technologię i partnera wdrożeniowego. 

Trudno jest też w sytuacji, takiego braku podejścia – nazwijmy to inwestycyjnego – o podejmowanie sprawnych decyzji już w trakcie samego procesu wdrożeniowego. Czyli odpowiadanie sobie na tysiące pytań – czy potrzebujemy tej funkcji, czy musimy ją zmienić, czy ona jest realizowana dobrze czy źle, czy wystarczająco dobrze, czy wystarczająco źle dla nas i co by było, gdybyśmy tej funkcji nie uruchomili?

Dlaczego przygotowanie do wdrożenia ERP jest kluczowe

Bardzo rzadko mamy do czynienia z sytuacją, kiedy klient potrafi nam sprawnie na takie pytania odpowiedzieć. Dlatego, co naturalne, proponujemy w ramach przygotowań do procesu wdrożeniowego zaplanować i przeprowadzić analizę – szacowanie korzyści potencjalnych wynikających z wdrożenia nowego narzędzia, oszacowania wartości ryzyk, które się pojawią, jeśli zaniechamy to przedsięwzięcie. I co najważniejsze – odpowiedzenie sobie na pytanie, ile to jest dla nas warte – najlepiej w wartościach bezwzględnych – pieniądzach.

Elementy, które mogą być rozważane są bardzo różnorodne:

• oszczędności w poziomie stanów magazynowych wpływające na zmniejszenie zaangażowanego kapitału,
• możliwości związane ze zwiększeniem skali działania,
• lepsze procesy doboru dostawców,
• lepsze prognozowanie sprzedaży,
• lepsze planowanie produkcji.

Jak przeprowadzić analizę systemową przed wdrożeniem

Wiele jest elementów, które mogą zostać ujęte w tej analizie, zweryfikowane, skwantyfikowane, przeliczone na pieniądze i one będą mogły nam dać odpowiedź na pytanie – ile, dzięki przeprowadzeniu tego projektu, możemy w przyszłości zarobić.

Do tego na drugiej szalce możemy położyć analizę, która odpowie nam na pytanie, co by było, jakie zagrożenia, jakie straty możemy ponieść, jeśli nie przeprowadzimy tego projektu, jeśli nie uzyskamy tych celów, które sobie dzisiaj zakładamy i jeśli zostaniemy przy systemie takim, jakim mamy go dzisiaj. I mamy tutaj różne zagrożenia – od kwestii natury technicznej, czyli sprawność systemu, kwestie wydajności, które przekładają się na niemożność obsłużenia klientów, na niemożność obsłużenia partnerów, na nieposiadanie przez dany system wszystkich dostępnych dzisiaj kanałów komunikacji. Może to być też kwestia wydłużenia czasu realizacji zgłoszeń klienckich. Może to być kwestia niemożności obsłużenia planowanej ilości punktów sprzedaży, czy też złożoności cenników, o których myślimy czy kwestii konfigurowania produktów, które planujemy wprowadzić. To są wszystko kwestie, których nie mając w systemie nie będziemy mogli uzyskać korzyści, o których myślimy. Do tego jest oczywiście kwestia bezpieczeństwa samego systemu i tutaj dotykamy kwestii takich jak bezpieczeństwo cybernetyczne, zagrożenie wynikające z tego, że nasz system pochodzący sprzed 10, 15 czy 17 lat nie jest przygotowany na dzisiejsze realia zagrożenia cybernetycznego – czy to na ataki hakerskie, czy po prostu na to, że za chwilę nie będziemy w stanie znaleźć sprzętu, na którym mogłoby być to oprogramowanie zainstalowane.

Takie przypadki wbrew pozorom nie zdarzają się rzadko. To jest dość częsta sytuacja. I potem mamy do czynienia z bardzo, bardzo szybkimi procesami, które mają de facto takie znamiona „akcji ratunkowej”. Klient doszedł do ściany, za chwilę nie będzie mógł skorzystać, czy to z przeglądarki, czy nie da się kupić komputerów, serwerów, dysków, które mogłyby zostać użyte do eksploatacji posiadanego przez niego systemu i kolokwialnie mówiąc „na gwałt” trzeba zmienić wersję oprogramowania po to, żeby ona w ogóle mogła funkcjonować. Już nie mówimy tu o korzyściach tylko o tym, że system może przestać funkcjonować. Na tym w zasadzie można byłoby zakończyć ten materiał natomiast jest jeszcze kilka kwestii dodatkowych.

Kluczowe pytania, które trzeba zadać na starcie

Warto pamiętać o tym, że samo przedsięwzięcie, o którym myślimy będzie trwało około dwóch lat, z procesem doborowym to na pewno. Potem ten system, który będziemy budować wyrażać będziemy mu użytkować przez 5-10 lat. Więc prowadząc tę analizę koszt-korzyść, powinniśmy też uwzględnić to, że system będzie nas wspierał za czas jakiś i te korzyści powinny się odnosić do tego, jak nasz biznes będzie funkcjonował już po wdrożeniu. Czyli powinniśmy sobie uwzględnić takie elementy jak planowane zmiany oferty produktowej, jeżeli chcemy zwiększyć lub zmniejszyć skalę działania, jeżeli chcemy zredefiniować rynki na których działa nasza firma, jeżeli chcemy zmienić struktury sprzedażowe albo planujemy ekspansję na rynki zagraniczne i wiele, wiele innych elementów które powinniśmy dzisiaj uwzględnić ponieważ system nie będzie wspierał takiej naszej organizacji, jaką mamy dzisiaj, tylko taką organizacji, która się pojawi za 3, 4, 5, 6 lat i do tego powinniśmy odnosić wszystkie nasze wyliczenia.

To, co też jest istotne to fakt, że te decyzje te odpowiedzi co warto robić, a co nie warto, dotyczą zarówno decyzji w skali makro, jak i w skali mikro. W skali makro będą to decyzje o tym, że wdrażamy taki czy inny moduł, o tym, że taki czy inny obszar przedsiębiorstwa będzie wspierany informatycznie przez ten system. A może, że kupimy dedykowane rozwiązanie, które na przykład w obszarze magazynu wysokiego składowania dużo lepiej się sprawdzi i trzeba będzie go z tym centralnym systemem zintegrować. Natomiast będzie to też dotyczyło dziesiątek setek, a nawet czasami tysięcy decyzji w skali mikro – czyli dotyczących poszczególnych funkcjonalności, konkretnych raportów konkretnych wydruków, konkretnych zestawień, konkretnych procesów które gdzieś tam są realizowane w organizacji i wspierane przez system.

I system, który przychodzi do nas wprost od producenta – tak zwany „system z pudełka” – nie do końca spełnia nasze oczekiwania – wynikające z przyzwyczajeń, z praktyki codziennej z tego, że zawsze tak robiliśmy, a system nie jest gotowy na to, żeby nas wspierać w ten sposób. Kwestie związane z decyzjami to są zagadnienia, które się pojawiają na każdym etapie projektu, o którym myślimy. Począwszy od procesu doborowego, gdzie bardzo często spotykamy się z sytuacją gdzie klient ma przygotowane zestawienia 1500-1700 funkcjonalności, których weryfikuje, czy system je oferuje, czy nie.

Zapewniam Państwa że jest to bardzo mało efektywny sposób, ponieważ systemy z natury rzeczy będą 99% z tych wymagań spełniały. Natomiast to, co warto zrobić, to odnieść się do tych celów biznesowych, do korzyści i zweryfikować, czy 5, 7, 10 tych krytycznych elementów, które są dla nas ważne. Czy system spełni je w taki sposób, jak my sobie tego życzymy. I na bazie tego wyrabiać sobie zdanie, wyrabiać sobie opinię który z systemów jest dla nas lepszy, który z dostawców jest dla nas lepszy, który daje nam większe szanse na uzyskanie tych korzyści, o których myślimy rozpoczynając przedsięwzięcie.

I tu muszę powiedzieć, że miałem doświadczenia takie. Jeden z procesów doborowych trwał, no można powiedzieć, dwa tygodnie. Po analizie wewnętrznej na bardzo wysokim szczeblu decyzyjnym po stronie klienta zespół udał się, spędził tydzień u jednego z dostawców, tydzień u drugiego z dostawców, zweryfikował naprawdę policzalne wymagania funkcjonalne, ale za to dogłębnie i po tych dwóch tygodniach podjął decyzję – „tak to ten system jest dla nas lepszy, i wiemy dlaczego, i wiemy jakie korzyści nam da, jak już go wdrożymy”. I to jest jeden z najlepszych procesów doborowych, w których miałem szansę uczestniczyć. Szybki, konkretny, przeliczalny na pieniądze. Prosto się potem też negocjowało kwestie finansowe, ponieważ klient wiedział ile zarobi jeśli ten projekt mu się uda i co straci jeśli go nie wykona lub wykona o rok później.

Drugi obszar, też o którym już mówiłem, czyli to są te decyzje podejmowane w trakcie projektu. Tutaj mamy, też mogę podać przykład, taką sytuację gdzie przedłużające się procesy decyzyjne wpływają na opóźnienie projektu. I tutaj jednym z przykładów, którym mogę się posłużyć to jest sytuacja, w której po stronie klienta osoba odpowiedzialna za zamawianie modyfikacji skądinąd słusznie dążyła do tego, żeby minimalizować ilość tych modyfikacji. Natomiast mając świadomość, że dana funkcja nie jest w tej wersji programowania realizowana tak, jakby sobie ta osoba życzyła, przeprowadziła 3-miesięczną analizę. Czy przyszłe wersje nie mają tego robić tak, jak klient potrzebuje? Czy nie ma możliwości jakiejś specyficznej implementacji, która by pozwoliła w jak największym stopniu te funkcje zrealizować zgodnie z oczekiwaniami klienta? Bardzo dobre podejście, tylko niestety trwało ono 3 miesiące. Koszty całego procesu weryfikacyjnego wynosiły dwa razy czy trzy razy więcej pewnie niż sama modyfikacja. A w dodatku przesunięcie prac, spowolnienie prac o trzy miesiące nie pozostało bez wpływu na termin końcowy uruchomienia.

W związku z tym mieliśmy sytuację, gdzie weryfikację czy zaimplementować modyfikację za kilkadziesiąt tysięcy złotych spowodowała zaangażowanie kilku osób na trzy miesiące i spowolniła proces wdrożeniowy, czyli odsunęła korzyści wynikające z procesu wdrożeniowego. Było to nierozsądne choć przesłanki, choć takie ideologiczne założenia stojące za tym były poprawne, natomiast sposób realizacji dawał wiele do życzenia.

Przy tych wszystkich analizach warto też pamiętać o tym, że koszty to nie tylko licencja i wdrożenie. Gdzieś za tym idą też koszty utrzymania, koszty rozwoju systemu koszty wdrażania nowych wersji więc często jest tak, że nadmiernie rozbudowany system w trakcie wdrożenia powoduje, że potem utrzymanie jest bardzo drogie. I coś co na pierwszy rzut oka jest dla nas akceptowalne, coś, co dla nas jest atrakcyjne, w czasie może się okazać, że jednak niestety przyszłe koszty skonsumują te korzyści, które uzyskujemy dzięki temu, że daną funkcjonalność zaimplementowaliśmy, że daną funkcjonalność zbudowaliśmy, że daną modyfikację przygotowaliśmy.

Ryzyka związane z brakiem wdrożenia nowego systemu ERP.

Ostatni punkt to coś, o czym już mówiłem, natomiast chciałbym to jeszcze raz podkreślić. Bardzo często będziemy mieli do czynienia z obszarami z funkcjami, z wymaganiami gdzie główną korzyścią jest unikanie zagrożeń. I to zagrożeń od najprostszych – czyli poczynając od tego, czy system ma, obsługuje, wspiera, realizuje wymagania prawne, poprzez sytuacje gdzie mamy kwestie związane z bezpieczeństwem cybernetycznym, ale także z tym, że czasami nie jesteśmy pewni czy dana funkcja, dany moduł, dana funkcjonalność jest dla nas niezbędna ponieważ dzisiaj z niej nie korzystamy. No i tutaj mam takie przykłady, gdzie zaniechanie wdrożenia powodowało potem bardzo gigantyczne straty. Najczęstszym takim obszarem jest na przykład utrzymanie ruchu, gdzie mieliśmy projekt wdrożenia klient będący hutą zrezygnował z wdrożenia utrzymania ruchu i trzy miesiące po zakończeniu wdrożenia uległ awarii piec hutniczy, którego koszt wymiany wielokrotnie, kilkudziesięciokrotnie przekraczał koszt całego wdrożenia. Nie mówię już o wdrożeniu samego modułu utrzymania ruchu. Nie ma oczywiście gwarancji, że wdrożenie tego modułu by spowodowało, że uniknęlibyśmy tej awarii natomiast na pewno zwiększylibyśmy szansę uniknięcia – może przyspieszony zostałby proces naprawy, może skala awarii byłaby trochę mniejsza.

Mamy również do czynienia z takimi banalnymi kwestiami jak kwestia wydajności. System działa, ale zbyt wolno system działa, ale nie przetwarza takiej ilości danych jakbyśmy potrzebowali. W związku z tym z niektórych analiz rezygnujemy, w związku z tym upraszczamy trochę procesy związane z prognozowaniem czy planowaniem czy nawet raportowaniem. Nie chcemy kolokwialnie mówiąc zatykać systemu, więc nie realizujemy niektórych funkcji, których system mógłby zrobić, gdyby tylko Które miało możliwości z punktu widzenia technicznego.

No i na koniec to, o czym już wspominałem, uniknięcie ryzyka utraty danych – czy to w wyniku awarii czy to w wyniku ataku hakerskiego, czy to w wyniku jakiegokolwiek innego problemu jakiegokolwiek innego przypadku, są nie do policzenia. Korzyści z tego, że to się nie wydarzy, czy też straty w sytuacji kiedy zaistnieje taka sytuacja, są nieporównywalne z kosztami zabezpieczeń, z kosztami, z którymi mamy do czynienia przy projekcie wdrożeniowym.

Podsumowanie

Podsumowując, wydaje się naturalnym, że dużo przedsięwzięcia jakimi są często wdrożenia informatyczne, wdrożenia systemów ERP powinny być traktowane tak samo jak inwestycje. Natomiast niestety nie są. Nie patrzymy na te projekty tak jak na budowę nowego salonu sprzedaży, zakup nowej linii produkcyjnej czy magazynu. Nie wiedzieć czemu tak jest.

Co istotne, taka analiza powinna uwzględniać korzyści, straty, zagrożenia, możliwości nie tylko na dzisiaj, ale w perspektywie 3, 5, a nawet 10 lat. Jeśli by z tej analizy nam wyszło, że przewidywane korzyści są bardzo zbliżone do kosztów, że środki, które musimy zainwestować w ten proces zwrócą nam się z małym naddatkiem to może warto jest w ogóle zrezygnować z takiego przedsięwzięcia, ponieważ koszty przeważnie będą wyższe cel uzyskamy później, a korzyści będą troszeczkę niższe niż nam się wydawało.

Zresztą z takimi sytuacjami mieliśmy do czynienia kilka lat temu, kiedy to koszty usług informatycznych wyrosły dramatycznie i wiele dużych organizacji wstrzymywało międzynarodowe projekty, wstrzymywało uruchomienie przedsięwzięć informatycznych właśnie ze względu na to, na niepewność korzyści i gigantyczne koszty związane z realizacją planowanych przedsięwzięć.

To wszystko, co przygotowałem dla Was w tym odcinku. Jeśli chcielibyście się podzielić Waszymi doświadczeniami lub zależy Wam, żeby jakiś wątek został rozwinięty w kolejnych odcinkach, proszę wysłać wiadomość na adres podany w opisie odcinka. Chętnie odpowiem też na pytania. Dziękuję za dzisiaj. Do usłyszenia.

W następnym odcinku zajmiemy się praktycznymi aspektami przygotowania firmy do wdrożenia systemu ERP. Porozmawiamy o tym, jak uporządkować procesy w organizacji przed takim projektem i jak przygotować zespół oraz infrastrukturę IT. Nowe odcinki publikujemy w drugi wtorek miesiąca. Tydzień wcześniej na naszej stronie pojawia się artykuł, który stanowi bazę do podcastu. Link do naszego bloga znajdziecie w opisie tego odcinka. Znajdziecie tam także adres e-mail, pod którym możecie się z nami skontaktować. Jeśli macie jakieś pytania lub sugestie, dajcie nam znać. Do usłyszenia w kolejnym odcinku!

Ten odcinek podcastu pokazuje, jak ważne jest przygotowanie do wdrożenia ERP i rzetelna analiza systemowa. Więcej o ofercie ERP znajdziesz tutaj. Jeśli chcesz omówić sytuację w swojej firmie, skontaktuj się z nami.