Wstęp

Przygotowanie organizacji do wdrożenia ERP to nie tylko kwestia planu technicznego – to przede wszystkim zarządzanie zmianą, zespołem i priorytetami. Z tego transkryptu dowiesz się, jak podejść do projektu, by zwiększyć szanse na jego sukces.

… Pierwszą podstawową rzeczą, takim niezbędnym minimum, które uważam, że powinno zawsze być zrealizowane przed tego typu przedsięwzięciami, to jest oszacowanie, jakie zaangażowanie, jaki zespół, w jakim wymiarze, ile godzin tygodniowo, ile osób musimy dedykować do prac projektowych, żeby one się toczyły płynnie, żeby zadania były realizowane na czas, żeby zadania były realizowane z właściwą jakością, a nie żebyśmy mieli co chwilę problemy jak połączyć zamknięcie miesiąca z testami, czy jak połączyć zamknięcie kwartału z ostateczną fazą analizy, gdzie potrzebne jest zaangażowanie osób o głębokiej wiedzy procesowej, o głębokiej wiedzy organizacji…

Dzień dobry. Zapraszam na drugą część serii podcastów, w których omawiam kwestie związane z tym, jak organizacja, która planuje przeprowadzić projekt informatyczny, wdrożenie systemu informatycznego, może poprzez swoje działania zwiększyć szanse na sukces tego przedsięwzięcia. Nie skupiam się tutaj na elementach związanych z dostawcą, technologią, kwestiami, które są poza firmą, tylko na działaniach całkowicie wewnętrznych, które firma planująca przedsięwzięcie informatyczne może wykonać sama, czy powinna wykonać sama i dlaczego uważam, że warto jest to zrobić i jak to się przełoży na szanse odniesienia sukcesu.

W pierwszej części omawiałem kwestie związane z planowaniem, z opracowaniem wspólnej wizji celów – po co robimy to przedsięwzięcie, ile ono będzie trwało, jakich korzyści się spodziewamy, jakich korzyści oczekujemy, jakie ryzyka chcielibyśmy wyeliminować poprzez to przedsięwzięcie. Opowiadałem o tym, że doprowadzenie do takiego stanu, w którym to przedstawiciele, decydenci w organizacji wiedzą, ile warto wydać pieniędzy, żeby założony cel uzyskać, to taka sytuacja jest bardzo komfortowa do sprawnego przeprowadzenia całego przedsięwzięcia.

Bardzo upraszczając, można by powiedzieć, że jeżeli zaczniemy traktować projekty informatyczne jako inwestycje, jeżeli zaczniemy oczekiwać zwrotu z tych inwestycji, jeżeli zaczniemy patrzeć nie jako na koszt, tylko jako na coś, co ma przynieść korzyść czy to biznesową, czy zwiększyć nasze bezpieczeństwo, no to podejście do projektów informatycznych może się trochę zmienić. Zapewniam Państwa, że z punktu widzenia drugiej strony, która ma realizować na potrzeby państwa te projekty, jest to też duże uproszczenie.

Dlaczego przygotowanie do wdrożenia ERP jest kluczowe

Ten odcinek jest rozwinięciem artykułu „Przygotuj firmę przed startem wdrożenia ERP„.

Natomiast dzisiaj przechodzimy już do takiej sytuacji, w której te cele są określone, wiemy, po co to robimy, wiemy, ile chcemy zarobić, wiemy, ile chcemy wydać, ile możemy wydać i jesteśmy w tej komfortowej sytuacji, że już na bazie tych naszych oczekiwań, na bazie tego, co potrzebujemy i jak będziemy chcieli realizować całe przedsięwzięcie, wybraliśmy dostawcę, wiemy, kto będzie tym dostawcą, wiemy, jaką technologię będziemy chcieli wdrożyć, wiemy, jakie rozwiązanie będziemy chcieli zaimplementować i zaczynamy się przygotowywać do uruchomienia całego projektu.

I tutaj proponuję trochę odejście od standardowego modelu i zanim przejdziemy od wyboru do wdrożenia, do uruchomienia projektu, to proponuję rozważenie takiego podejścia, w którym firma będzie wspólnie z wybranym dostawcą i na bazie przewidywanego do wdrożenia rozwiązania przeprowadzać przygotowanie do już uruchomienia samego procesu wdrożeniowego.

I o co chodzi? Znamy cel, wybraliśmy partnera i teraz warto sobie zdać sprawę z następujących rzeczy:

• Projekt będzie dużym wysiłkiem dla organizacji. Nie da się tego typu przedsięwzięć, tego typu projektów zrobić przy okazji.
• Nasz zespół, który ma swoje zadania codzienne, comiesięczne, cokwartalne, coroczne, będzie dodatkowo dociążony dużym przedsięwzięciem, czasochłonnym, który będzie bardzo mocno przeszkadzał im w codziennej pracy.
• Dodatkowo mamy sytuację taką, w której wewnątrz organizacji wdrażającej nowy projekt czy realizującej nowy projekt, czy wdrażającej nowe oprogramowanie, mamy ludzi z dużym doświadczeniem w tego typu przedsięwzięciach. Przeważnie nasz zespół, jeżeli wybrani jego członkowie mają doświadczenie w jednym, dwóch tego typu projektach, to jest super. Natomiast to się zdarza bardzo rzadko, a przeważnie jest tak, że nie mamy nikogo z taką wiedzą, z takim doświadczeniem. I tutaj nakładają się dwie kwestie. Po pierwsze, będziemy mieli dodatkowy zestaw zadań dla naszego zespołu, a po drugie, ci ludzie nie mają doświadczenia w realizacji tego typu przedsięwzięć. Jeżeli nie będziemy przygotowani, jeżeli nic w tym zakresie nie zmienimy, to uzyskanie celów, które sobie postawiliśmy, odsunie się w czasie, będzie trudniejsze, będzie kosztowniejsze, a zakładane korzyści mogą być mniejsze, a co najmniej odsunięte w czasie.

Warto też zdać sobie sprawę z tego, że jest to ostatni moment, w którym jesteśmy w stanie wykonywać prace przygotowawcze, prace porządkowe bez presji czasu. Czyli nie jesteśmy jeszcze w reżimie projektowym, nie mamy harmonogramów, nie mamy deadline’ów, nie kupiliśmy oprogramowania, nie wydaliśmy pieniędzy na oprogramowanie, nie konsumujemy opłaconego przez nas czasu serwisowania czy maintenance’u tego oprogramowania. Możemy w miarę spokojnie, jeszcze bez presji, bez oczekiwań, bez pytań, przeprowadzać działania, które mogą wesprzeć czy wesprą sukces naszego przedsięwzięcia. I będą dotyczyły uwzględnienia w olbrzymim stopniu tylko i wyłącznie tego, co się dzieje wewnątrz naszej organizacji, wewnątrz naszych procesów.

Idealnym stanem jest, jeżeli będziemy mieli już wybranego partnera z podpisaną umową z odroczonym terminem uruchomienia albo wybranego partnera i narzędzie, ale jeszcze nie podpisaliśmy samej umowy, i te terminy, które sobie ustalimy, są wstępnym naszym celem, do którego dążymy, a nie twardą deklaracją w stosunku do dostawcy.

Jakie działania przygotowawcze do wdrożenia ERP podjąć?

Przejdźmy więc do konkretu. Jakie prace przygotowawcze, jakie działania przygotowawcze moim zdaniem warto podjąć – między wybraniem dostawcy, między wybraniem technologii, a przed uruchomieniem projektu. Bardzo fajnie by było, gdyby te prace były prowadzone wspólnie razem z tym partnerem wdrożeniowym, którego wybraliśmy, żeby on też uczestniczył w tym, żebyśmy wspólnie się zaczęli „docierać” – kolokwialnie mówiąc.

Oszacuj zaangażowanie zespołu wdrożeniowego systemu ERP

Natomiast mogę sobie wyobrazić też, że część z tych działań, część z tych prac może być zrobiona zupełnie niezależnie, bez uczestnictwa tego dostawcy. Pierwszą podstawową rzeczą, takim niezbędnym minimum, które uważam, że powinno zawsze być zrealizowane przed tego typu przedsięwzięciami, to jest oszacowanie, jakie zaangażowanie, jaki zespół, w jakim wymiarze, ile godzin tygodniowo, ile osób musimy dedykować do prac projektowych, żeby one się toczyły płynnie, żeby zadania były realizowane na czas, żeby zadania były realizowane z właściwą jakością, a nie żebyśmy mieli co chwilę problemy, jak połączyć zamknięcie miesiąca z testami, czy jak połączyć zamknięcie kwartału z ostateczną fazą analizy, gdzie potrzebne jest zaangażowanie osób o głębokiej wiedzy procesowej, o głębokiej wiedzy organizacji.

Czyli pierwszy podstawowy punkt to jest powiedzenie sobie szczerze, ile osób i w jakim wymiarze potrzebujemy delegować do prac projektowych, żeby one się toczyły efektywnie. Na bazie tego jesteśmy w stanie ocenić, czy damy radę ten projekt w ogóle poprowadzić w takim składzie, jaki mamy w tej chwili. Bo może się zdarzyć, i czasami, żeby nie powiedzieć często, zdarza się tak, że w trakcie prac okazuje się, że po prostu mamy „braki zasobowe” – jak to się mówi kolokwialnie – czyli mamy za mało osób do zrealizowania codziennej pracy i do zrealizowania projektu, który toczymy.

Prawdą jest też to, że zarówno w zadaniach codziennych, jak i w projekcie, oczywiście najbardziej pożądane są te osoby, które są najlepsze, które wiedzą najwięcej, są energiczne, są kreatywne, są godne zaufania i te osoby przeważnie w związku z tym są przeciążane w przypadku pojawienia się zadań dodatkowych, w przypadku pojawienia się dodatkowych aktywności.

Uzupełnij braki zespołowe

Jeśli się okaże, że mamy braki, jeżeli okaże się, że dzisiejszy zespół nie będzie w stanie efektywnie, płynnie realizować zadań projektowych, no to warto jest rozważyć co najmniej czasowe zatrudnienie dodatkowych osób. Koszt jednej, dwóch osób dodatkowo zatrudnionych do projektu naprawdę jest niczym w porównaniu z tym, jakie koszty byśmy ponieśli, gdyby projekt się przesunął o rok czy półtora. To są nieporównywalne koszty. Takie dodatkowe osoby też pozwalają dedykować się do prac projektowych w większym wymiarze osobom doświadczonym i dzięki temu jakość wypracowanego, wdrożonego rozwiązania też jest wyższa, tych korzyści będziemy mieli więcej.

I pierwszy punkt to jest zwiększenie zespołu po prostu o dodatkowe osoby, które będą w stanie odciążyć naszych członków zespołu od prac codziennych i pozwolić im dedykować swój czas do prac projektowych. Inną kwestią, podobną, ale inną kwestią, jest zatrudnienie, znalezienie, zasilenie naszego zespołu wewnętrznego osobami, które mają doświadczenie w prowadzeniu prac projektowych, wdrożeniowych. Bo inaczej traktujemy opinie, sugestie, nawet narzekanie osoby z wewnątrz organizacji, która mówi – „nie dajemy rady, za dużo jest tych prac, nasze postulaty są nieracjonalne” – to inaczej się to słyszy, jeżeli to mówi osoba z wewnątrz zespołu projektowego, a inaczej, jeżeli to mówi doświadczona osoba, nawet którą szanujemy i cenimy jej wiedzę i doświadczenie, ale jest to jednak osoba z zespołu zewnętrznego. Zupełnie inny odbiór jest takich komunikatów, zupełnie inaczej je traktujemy. Łatwiej jest też osobie z wewnątrz organizacji zadbać o to, żeby pewne ustalenia, pewne deklaracje były bardziej wiarygodne, były przestrzegane, żeby to zaangażowanie w pracę było zgodne z oczekiwaniami czy to przełożonych, czy zgodne z deklaracjami złożonymi dostawcy.

Takie osoby, które potencjalnie mogłyby wzmocnić nasz zespół, należy znaleźć. No i niestety, wiąże się to też z tym, że należy je wprowadzić do organizacji, bo jeżeli znajdziemy, zatrudnimy i po trzech tygodniach one ruszą wspólnie z nami do projektu wdrożeniowego, to ani nie będą znały organizacji wewnątrz, ani nie będą dobrze czuły naszych potrzeb, procesów, będą traktowane de facto jak osoba z zewnątrz, tyle tylko, że u nas na etacie – niezależnie od formy zatrudnienia. Nie bez znaczenia jest też fakt, że potrzebują te osoby trochę czasu na stanie się częścią zespołu, ale także udowodnienie swojej wartości. Pokazanie zespołowi, że wiedzą, o czym mówią, że znają się na tym. Wyrobienie sobie takiej pozycji też chwilkę zajmuje. No tutaj oczywiście dużym atutem, dużą pomocą, dużym wsparciem byłoby, gdyby te osoby znały technologię, którą będziemy chcieli wdrożyć. Jeżeli wybraliśmy dostawcę X z produktem A, no to osoby, które współpracowały z tym dostawcą, osoby, które mają doświadczenia wdrożeniowe z wybranym przez nas oprogramowaniem, no to w sposób naturalny są świetnym wsparciem, są świetną pomocą, bardzo ułatwią nam sprawne prowadzenie projektu dzięki swojej wiedzy produktowej. To są takie zagadnienia organizacyjne, o których warto pamiętać i myślę, że gdyby skupić się na tych dwóch częściach, no to od strony zespołu i gotowości do realizacji płynnej, sprawnej realizacji prac, można by uznać to za wystarczające.

Zadbaj o przygotowanie merytoryczne zespołu wdrożeniowego

Odrębną kwestią jest sprawa związana z przygotowaniem merytorycznym tego zespołu, który ma być delegowany do prac projektowych. Tutaj wydzielić można co najmniej dwa obszary. Jeden to jest obszar związany z metodyką pracy, a drugi to jest obszar związany z samym narzędziem. Zawsze przy rozpoczynaniu współpracy z klientem zachęcam do tego, żeby wybrać zespół użytkowników. My często używamy takiego nazewnictwa, że są to użytkownicy kluczowi i zadbanie o to, żeby ci użytkownicy kluczowi przeszli jak najbardziej pełny cykl szkoleń o produkcie. Nie chodzi tutaj o wiedzę taką, jak używać tego produktu, jak na koniec po wszystkim już będziemy realizować procesy w tym produkcie. Chodzi mi bardziej o kwestię taką, żeby te osoby jak najbliżej były wiedzy osób wdrażających, konsultantów wdrażających. Ta wiedza ma dotyczyć logiki systemu, jego organizacji wewnętrznej, jak pracuje, jak zaplanowany, zaprojektowany został standardowy produkt, który otrzymujemy z pudełka, co w nim jest, czego nie ma, jakie zmiany wymagają bardzo dużo pracy, a jakie zmiany są proste do przeprowadzenia. Czyli postuluję przeprowadzenie pełnego szkolenia produktowego dla wybranych 5, 6, 10 osób. Oczywiście, specjaliści od produkcji powinni się zapoznać przede wszystkim z produkcją, specjaliści od księgowości z księgowością, a specjaliści od środków ze środkami trwałymi. Natomiast gdzieś też należy zadbać o to, żeby ta wspólna baza wiedzy i zrozumienia o produkcie była przekazana zespołowi w miarę szerokim składzie.

To jest pierwsza część. Dlaczego to jest ważne? Dlatego, że będziemy mieli do podjęcia wiele decyzji – z czego zrezygnować, co dobudować, jak dobudować, jak korzystać z funkcjonalności, które mamy w systemie, chociażby jak skonstruować system kontrolingowy. No i jeżeli osoby, które znają procesy wewnątrz organizacji, rozumieją, jakie są potrzeby zgłaszane przez kierownictwo i rozumieją, jak dany system jest w stanie realizować tego typu potrzeby, no łatwiej jest wypracować model, który jest prosty do zaimplementowania, szybki do zaimplementowania, nie wymaga wielu zmian, więc jest też tańszy w realizacji. Potem będzie też tańszy w utrzymaniu i rozwoju w przyszłości. Jeżeli te osoby nie mają zupełnie pojęcia o tym, jak funkcjonuje system, no to one mogą zapewnić nam tylko i wyłącznie wiedzę o tym, jakie mają potrzeby, ale jak one mają być realizowane, no to tutaj się zaczyna długa dyskusja. Często brak zrozumienia logiki systemu powoduje, że trudno jest wypracować efektywne rozwiązanie, które z jednej strony zadowoli użytkowników, ale z drugiej strony też będzie proste w zbudowaniu, w utrzymaniu i potem w rozwoju.

Zapoznaj zespół z metodyką wdrożeniową systemu ERP

Drugą kwestią, mniej istotną, ale też ważną, jest przekazanie wiedzy zespołowi wdrożeniowemu w zakresie samej metodyki prowadzenia prac projektowych. Czyli zapoznanie z kolejnością zadań, które będziemy realizowali, wytłumaczenie, jakiego zaangażowania, realizacji jakich zadań oczekujemy od zespołu delegowanego do prac projektowych, wspólne oszacowanie, ile tego zaangażowania będzie, kiedy to się może zacząć, jakie będą skutki podejmowanych decyzji na poszczególnych etapach, kiedy coś można zmienić, kiedy już czegoś nie powinniśmy zmieniać. Na przykład, jeżeli uzgodnimy wspólnie, że start ma się odbyć 1 stycznia, no to nawet najlepsze, najwspanialsze postulaty zgłoszone w połowie grudnia no mogą nie zostać zaimplementowane, mogą nie zostać wdrożone do systemu, ponieważ po prostu zabraknie czasu. Powinniśmy wspólnie uzgodnić taki moment w czasie, kiedy wszelkie oczekiwania zostaną zamknięte, zamrażamy to i już budujemy system w oparciu o takie założenia, które zostały uzgodnione do końca miesiąca X czy Y. I nawet najlepszy pomysł, który się pojawia później, musi poczekać ze swoją realizacją na czas po uruchomieniu, na czas po stabilizacji. Zarówno zrozumienie jednej kwestii, czyli logiki systemu, jak i metodyki pracy pomaga nam również potem w uzgadnianiu pracochłonności potencjalnych zmian i modyfikacji, które wspólnie uznamy za zasadne do wdrożenia. Najczęstszym problemem, który mamy, to jest sytuacja taka, kiedy zainteresowana osoba pyta dewelopera, ile będzie robiony ten raport, deweloper szczerze odpowiada, że zajmie mu to dwa dni, a potem się okazuje, że oferta na przygotowanie tego raportu to jest sześć dni. I jest niezrozumienie. I to na poziomie finansowym, ale też na poziomie czasowym. No i okazuje się, że sam development to rzeczywiście będzie trwał dwa dni, ale przygotowanie założeń, weryfikacja, jak te założenia wpłyną na całą resztę systemu, potem przygotowanie scenariuszy testowych, potem przygotowanie dokumentacji, same testy, no to się okazuje, że tych dni nie jest dwa, tylko sześć. I co więcej, te sześć dni to musimy rozłożyć na trzy tygodnie, ponieważ osoby ze strony klienta no nie mogą poświęcić sześciu dni po kolei na to, żeby pracować z nami wspólnie nad daną modyfikacją. Tylko jak nie ma zrozumienia, jak to się dzieje, to trudno jest samemu sobie wyobrazić, jak to się będzie układało – jakie będą skutki takiej czy innej decyzji, jaka jest pracochłonność, jakie są zadania związane z wytworzeniem danego rozwiązania.

Prace przygotowawcze, które możesz zrealizować przed startem wdrożenia systemu ERP

Odrębną kwestią są prace przygotowawcze, które można przeprowadzić przed rozpoczęciem samego wdrożenia, a dotyczą już konkretnych zadań projektowych. Można sobie wyobrazić na przykład, że przed rozpoczęciem projektu rozpoczynamy wątek pracy nad modelem kontrolingowym i jego skutkami, jego założeń, czyli jak te założenia wpłyną nam na budowany nowy plan kont. Bo w systemie, który wdrażamy, konstrukcja planu kont najefektywniejsza ma jakiś tam schemat. Czy to będą segmenty, czy to będą pola opisowe, czy to będą pola znacznikowe, to są już różne techniczne możliwości. Natomiast, jeżeli w ramach planowanego projektu chcemy zmienić model kontrolingowy, co się przekłada na plan kont, a wdrażamy system, który ma w jakiś sposób plan kont zorganizowany, no to warto jest nad tym popracować, przygotować to wcześniej, a nie potem pod presją czasu przy okazji gdzieś „na kolanie” wypracowywać te założenia. To jest proszenie się o problem. Jeśli dla nas model kontrolingowy jest ważny, skupmy się na tym, przygotujmy założenia, przełóżmy to na różne źródła danych niezbędnych do kontrolingu i wypracujmy metodę zaimplementowania tego w systemie i wcale nie musi to być robione w trakcie analizy. Jeżeli wiemy, jaki to jest system, jeżeli jesteśmy wyszkoleni i wiemy, jak on te narzędzia, te dane kontrolingowe może zbierać – jesteśmy to w stanie zrobić przed projektem, dając sobie czas na swobodną analizę, zastanowienie się, zawrócenie, zmienienie, dopracowanie.

Kolejną kwestią są prace przygotowawcze, które w zasadzie można by nazwać częścią projektu wdrożeniowego, natomiast możemy je sobie zacząć realizować przed samym projektem. Dobrym przykładem tutaj jest praca nad wypracowaniem nowego planu kont. Znamy nasze potrzeby, znamy nasz model kontrolingowy, wiemy, co jest nam potrzebne do sprawnego monitorowania, funkcjonowania organizacji, jesteśmy przeszkoleni, rozumiemy logikę systemu, wiemy, jak nasz nowy system działa, będzie gromadził dane, gdzie je będzie gromadził, w jakich strukturach. Jesteśmy w stanie wtedy odpowiedzieć sobie na pytanie: no dobrze, no to jeśli tak to wygląda, to jak w najlepszy sposób zorganizować plan kont, żeby transakcje tam gromadzone były najefektywniej, potem mogły być użyte do kontrolingu, do naszych potrzeb raportowych, do naszych potrzeb monitoringowych.

Uporządkuj dane systemowe

Innym zagadnieniem mogą być prace mające taki charakter porządkujący, mające charakter pracy nad danymi, które mamy w dzisiejszym systemie. No tutaj dobrym przykładem mogą być kwestie indeksów magazynowych. Historycznie mieliśmy ileś magazynów, historycznie mieliśmy ileś systemów magazynowych, dzisiaj chcemy to scentralizować. Jest to dobry moment na to, żeby zebrać to wszystko w całość, wymyśleć wspólne albo wymyśleć grupy różnych indeksów magazynowych, nadać te indeksy, uporządkować na nowo, gdzieś też w powiązaniu z tym systemem kontrolingowym, z modelem kontrolingowym, o którym przed chwilą mówiłem, z nowymi potrzebami – być może prawnymi – albo z nowymi potrzebami naszych kontrahentów albo z nowymi wytycznymi, które przyjdą z centrali i musimy gdzieś je uwzględnić.

Zamiast potem robić systemy do mapowania indeksów, tworzymy nowy indeks, który nie dość, że będziemy mieli możliwość zaszycia w nim wszystko to, co potrzebujemy, to jeszcze damy sobie szansę na to, żeby zanim się w ogóle projekt rozpocznie, zanim zaczniemy prace projektowe, to popracować nad tym, żeby dzisiejsze stany magazynowe, żeby dzisiejsze systemy indeksów przemapować na nowe i bez presji czasu spokojnie sobie to wszystko podorządkować i mieć już prawie gotowe dane na moment, kiedy przyjdzie do nas dostawca i powie – drogi kliencie, parametryzacja jest przeprowadzona, wprowadźmy dane, wprowadźmy nowe wartości indeksów, poprosimy o te dane. I my wtedy nie musimy tego wymyślać, tylko po prostu zdejmujemy opracowanie spółki i przekazujemy dostawcy, który zaczyna używać tego w kontekście nowego systemu, w kontekście prac wdrożeniowych.

Podobną sytuację mamy przy czyszczeniu danych. Są takie obszary, gdzie zawsze jest mnóstwo błędów danych. Jakbyśmy się nie starali, jakbyśmy nie mieli perfekcyjnie uporządkowanych pracowników, to po 5, 10, 15 latach używania systemu bardzo często pojawiają się sytuacje, w których część danych jest czy zduplikowanych, czy pewne parametry są wprowadzone w niewłaściwy sposób, nie mamy NIP-u danego kontrahenta albo ten NIP jest niewłaściwy, albo mamy dwa razy tego kontrahenta. Różne tego typu kwestie, które na co dzień nam nie przeszkadzają, bo nauczyliśmy się z nimi radzić i każda osoba w dziale obsługującym dane zagadnienie ma swoją wiedzę, ma swoje doświadczenie, jak sobie z tym radzić. Natomiast wdrożenie nowego systemu po pierwsze jest fajnym pretekstem, żeby poczyścić te dane historyczne. Punkt pierwszy. Punkt drugi – no nie wszystkie błędy „da się przenieść”, no bo być może nasz system dzisiaj nie kontroluje pewnych wartości krzyżowo, ale nowy już będzie kontrolował i nie przyjmie dwóch adresów czy dwóch danych czy dwóch NIP-ów dla jednego kontrahenta. A stary jakoś sobie z tym radził. Nowy sobie nie będzie radził. Więc warto jest ten proces przeprowadzić, a to są procesy bardzo uciążliwe, czasochłonne, więc lepiej to zrobić przed rozpoczęciem, a nie będąc już w rygorze harmonogramu wdrożeniowego, kiedy obie strony potrzebują sprawnego działania, sprawnej współpracy.

Innym takim obszarem jest na przykład bardzo często, czy to kwestie związane z danymi pracowników, czy to kwestie związane ze środkami trwałymi, czy to kwestie związane z prowadzonymi przez daną organizację projektami, gdzie po prostu jest mnóstwo danych, mnóstwo źródeł, mnóstwo dokumentów – część danych jest importowana z dodatkowych współpracujących systemów, więc jest tam cała masa możliwości na to, żeby popełnić błędy i gdzieś te dane mieć nie w pełni poprawne. Warto tę pracę porządkującą wykonać przed projektem, a nie w trakcie tego projektu. Jeżeli mamy ten nasz zespół wewnętrzny, który zrozumiał logikę nowego systemu, który zrozumiał, jak wygląda struktura tego systemu, to możemy się nawet pokusić o prace przygotowawcze do samej migracji danych. Choć tutaj raczej warto zaczekać na koniec fazy opracowania modelu docelowego i wtedy dopiero zacząć te dane zbierać, te dane przygotowywać do migracji, ale część prac przygotowawczych czasami może się udać przeprowadzić wcześniej. Szczególnie jeżeli będziemy blisko współpracować z dostawcą, który ma duże doświadczenie we wdrażaniu i w parametryzowaniu systemu, który nam oferuje.

Oszacuj zasoby sprzętowe przed wdrożeniem systemu ERP

Kolejną rzeczą, która wydaje się być prosta, ale czasami nas zaskakuje, to jest kwestia realnego oszacowania zasobów sprzętowych. No bo mamy swoje oczekiwania dotyczące bezpieczeństwa, wydajności, sposobu zorganizowania danych. Mamy dzisiaj jakieś zasoby sprzętowe, którymi dysponujemy, mamy stary system, mamy nowy system. Natomiast warto zdać sobie sprawę z tego, że w trakcie wdrożenia będziemy mieli co najmniej dwie, a przeważnie trzy kopie naszego nowego systemu, które będziemy wdrażali. Czyli będzie kopia, na której będziemy budowali system, czyli nazwijmy to kopia produkcyjna. Będzie kopia testowa, na której się będą odbywały testy. Czasami mamy trzecią kopię, to jest kopia, na której będziemy robili testy wydajności, które troszeczkę różnią się charakterem od testów takich funkcjonalnych. No i docelowo pojawi się to środowisko, na którym będziemy funkcjonować w codziennej pracy, czyli mamy środowisko do budowy, środowisko do testów, środowisko do testów wydajnościowych i środowisko produkcyjne. No i dzisiaj nie mamy tych środowisk. Być może mamy wystarczająco dużo sprzętu, a może nie mamy wystarczająco dużo sprzętu. Może przy okazji chcielibyśmy sprzęt odnowić, może chcielibyśmy zmienić dostawcę. To wszystko warto sobie położyć na stół, zadać pytanie, co chcemy począć w danej sytuacji i zrealizować to przed projektem albo przynajmniej mieć zrozumienie, że ok, ten sprzęt, który mamy, jest wystarczający, nic nie musimy dokupić albo musimy dokupić połowę nowego sprzętu i musimy to zrobić w ciągu trzech miesięcy. No bo czym innym jest precyzyjne cyzelowanie już co do ostatniego procenta niezbędnych zasobów, które gdzieś tam możemy robić w trakcie prac projektowych i potem pracować nad wydajnością, nad dostępnością naszego systemu, a czym innym jest doprowadzenie do sytuacji, w której projekt musi się zatrzymać, ponieważ bez infrastruktury sprzętowej nie jesteśmy w stanie dalej funkcjonować. I wbrew pozorom to nie jest rzadki przypadek. Oczywiście, dostawca może nam potem zaoferować swoje wewnętrzne środowiska, możemy gdzieś próbować się przenieść na chmurę, możemy podejmować różne działania, które mają nam umożliwić ciągłość pracy. Natomiast po co się prosić o takie wyzwania? Warto na początku zweryfikować, co mamy, czy jest to ten sprzęt, który chcemy mieć po projekcie, uzmysłowić sobie, że przez pewien okres czasu będziemy mieli tych środowisk więcej, no bo dzisiejszy system też będzie funkcjonował jednocześnie i odpowiedzieć sobie na pytanie, czy aby nie potrzebujemy szybko zaopatrzyć się w dodatkowe zasoby sprzętowe.

Podsumowanie

Można by było pewnie znaleźć jeszcze kilka takich sugestii, natomiast zrealizowanie chociażby tych, albo przeprowadzenie rozmowy z dostawcą i wspólnie z nim zastanowienie się, jakie prace przygotowawcze warto zrobić, to gdybyśmy takie kroki podjęli, to i tak byłoby super. Dlatego że one by znakomicie przyspieszyły prace projektowe, znakomicie pomogły w uzyskaniu szybciej oczekiwanych efektów, no i też obniżyłyby koszty. Ta suma prac też wpłynęłaby na taki rozsądny kompromis między naszymi oczekiwaniami a tym, co da się uzyskać w miarę rozsądnym kosztem, w miarę rozsądnym czasie z naszego systemu, który będziemy wdrażać, a nie doprowadziłoby to do tego, że proces będzie trwał dwa razy dłużej niż myśleliśmy, a korzyści będą o połowę mniejsze.

Można by jeszcze zaproponować kilka tego typu działań, ale już te wymienione, gdyby udało się Państwu przeprowadzić, gdyby udało się przynajmniej częściowo wykonać te sugestie, to one znakomicie naprawdę ułatwią prace wdrożeniowe – skrócą te prace wdrożeniowe, obniżą koszty projektu, obniżą koszty zmian, które się będą pojawiały w trakcie projektu i znakomicie przyspieszy to czas, kiedy będziemy mogli zacząć używać systemu i realizować te korzyści, o których myśleliśmy, planując, myśląc o przedsięwzięciu i rozpoczynając je.

Dzięki takim działaniom, szczególnie tym działaniom przygotowawczo-szkoleniowym, też możemy mieć nadzieję, że wdrożony system będzie rozsądnym kompromisem pomiędzy naszymi potrzebami, naszymi oczekiwaniami, naszymi przyzwyczajeniami a tym, co oferuje system i co w racjonalny sposób jesteśmy w stanie wdrożyć i użytkować jak najszybciej, w jak najkrótszym okresie czasu. Jeszcze raz podkreślam kwestię kosztową, te wszystkie działania rozpoczynamy, realizujemy, wykonujemy i kończymy przed rozpoczęciem projektu, czyli przed zaangażowaniem się w zakup licencji. Nie ponosimy kosztów licencji, nie ponosimy kosztów maintenance’u, odsuwamy to w czasie. Natomiast realizujemy zadania, które tak czy inaczej wcześniej czy później musimy zrobić, natomiast wykonujemy je w momencie, kiedy jeszcze nasze zaangażowanie finansowe jest dużo niższe, nie musimy ponosić kosztów, nie musimy finansować zakupów licencyjnych.

Ostatni punkt może zabrzmieć trochę kontrowersyjnie, ale uważam, że warto jest go poruszyć. Przygotowując zespół, pracując nad celami, prowadząc prace przygotowawcze, prowadząc prace szkoleniowe, warto jest zdiagnozować, wyszukać, zidentyfikować osoby, które są przeciwne realizacji projektu – z jakiegokolwiek powodu, mają inną wizję, nie zgadzają się z celami, nie zgadzają się z priorytetami, kontestują harmonogram, kontestują wybrane narzędzie, kontestują wybranego dostawcę. Jeśli takie osoby będą zaangażowane w projekt, one będą znakomitym utrudnieniem na każdym etapie. Jeśli zidentyfikujemy takie osoby i mimo wszystko, mimo ich zastrzeżeń, postanowimy, że ten projekt ma być zrealizowany zgodnie z przyjętymi założeniami, z którymi te osoby się nie zgadzają, warto jest zadbać o to, żeby one nie brały udziału w projekcie. Szanujemy ich opinie, być może nawet się częściowo z nią zgadzamy, natomiast nie powinniśmy dawać możliwości, żeby te osoby brały udział w projekcie, chyba że są w stanie – kolokwialnie mówiąc – „schować do kieszeni” swoje pomysły, oceny, przekonania i współpracować z całym zespołem, zarówno dostawcy, jak i wewnętrznym, w celu uzyskania założonych efektów. Jeśli o to nie zadbamy – prosimy się o konflikt w projekcie, prosimy się o przedłużające się procesy decyzyjne, prosimy się o niezgodne oczekiwania i wszelkie inne zagrożenia, ryzyka wynikające z braku spójności wizji. Sam projekt jest skomplikowany, długi, trudny. Postarajmy się wyeliminować wszelkie zagrożenia, wszelkie możliwości utrudnień, jeśli tylko jesteśmy w stanie sobie na to pozwolić.

I to by było wszystko na dzisiaj. Jeśli chcielibyście się podzielić waszymi doświadczeniami lub chcielibyście, żeby któryś z wątków został bardziej rozwinięty w którymkolwiek z kolejnych odcinków, no to proszę o wiadomość na adres podany w opisie. Chętnie też odpowiem na pytania, uwagi, spostrzeżenia. Dzięki za dzisiaj i do usłyszenia.

W następnym odcinku zajmiemy się rolą doradcy zewnętrznego w projektach wdrożenia systemów ERP. Porozmawiamy o tym, w jakim celu zatrudnić doradcę, a także opowiemy o najczęściej popełnianych błędach we współpracy z doradcą i wskażemy, jak ich uniknąć. 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.