- Czy możemy się spodziewać startu nowego systemu pierwszego stycznia? - to pytanie może usłyszeć dostawca systemu, podpisując z klientem w październiku umowę na zakup i wdrożenie systemu. W obliczu oczekiwań klienta, który liczy na to, że implementacja i uruchomienie systemu zajmą 3 miesiące, możemy mówić o dużym zagrożeniu całego projektu. W tym artykule postaram się opisać najczęstsze błędy, które są popełniane po parafowaniu umowy na zakup i wdrożenie systemu ERP.
W artykułach zawsze staram się być obiektywny i pisać o błędach popełnianych zarówno przez dostawcę usług, jak i klienta. Tak będzie i tym razem.
Dla mnie projekt wdrożenia to proces składający się z 4 faz.
4 fazy wdrożenia systemu ERP
- Faza 1 - Analiza wdrożeniowa, szkolenie użytkowników kluczowych wraz z wykonaniem prototypu systemu
- Faza 2 - Modyfikacje programistyczne i szkolenia użytkowników końcowych
- Faza 3 - Start produkcyjny i asysta powdrożeniowa
- Faza 4 - Opieka serwisowa – proaktywny serwis, nowe wersje oraz projektowanie nowych rozwiązań
Nie możemy patrzeć na cały projekt przez pryzmat jednej fazy. Źle przeprowadzone elementy procesu wdrożenia mogą skutkować przesunięciem daty startu produkcyjnego, zwiększeniem budżetu na obsługę projektu, perturbacjami w bieżących procesach firmy oraz, co najczęściej występuje, „zmęczeniem materiału” - czyli każdy marzy o tym, by projekt jak najszybciej się zakończył.
Faza 1 – Analiza i wykonanie prototypu dla użytkowników kluczowych
Komunikacja - otwórzmy się na nowe
Podczas procesu poznawania przedsiębiorstwa nawiązuje się porozumienie pomiędzy zespołem klienta a zespołem dostawcy. Dostawca podczas analizy poznaje biznes klienta. To poznanie wzajemnych, nieraz zaskakujących zadań, powinno skutkować nieszablonowym podejściem do projektowania i prezentacji procesów.
Nie można z góry zakładać, że każdy proces sprzedaży lub przyjmowania materiałów wygląda tak samo u każdego klienta i tak samo należy go ustawić. Nie zawsze to, co sprawdziło się u kilku klientów, jest dobre dla kolejnego klienta w naszym portfolio.
Podobnie jest w przypadku klienta - nie każdy nowy system podlega tym samym regułom procesu wdrożeniowego. Klient, nieraz pomimo bogatego doświadczenia w wymianie oprogramowania, powinien zaufać doświadczeniu dostawcy.
Zwróćmy uwagę, że rynek IT zmienia się każdego dnia. Forma, sposób prezentacji i implementacji systemu znacznie się zmieniły. Na rynku najważniejszą rolę zaczynają odgrywać duże podmioty informatyczne. W swojej ofercie posiadają szeroki wachlarz produktów, usług oraz narzędzi służących do integracji. W takich firmach istnieją specjalistyczne zespoły, działy, których zadaniem jest poznawanie funkcjonalności nowych wersji systemów, nowych rozwiązań technologicznych, w tym tych opartych o infrastrukturę chmurową.
Posłuchajmy zatem zespołu ekspertów IT w procesie analizy i wykonywania prototypu rozwiązania. Zaufajmy ich wiedzy i doświadczeniu, gdyż może zaproponowana integracja podniesie jakość i efektywność naszych wewnętrznych procesów.
Kiedyś procesy w systemach ERP były związane ściśle z przetwarzaniem wprowadzonych przez użytkownika danych. Dziś integracje ERP z systemami wizyjnymi, z automatyzowaną linią produkcyjną dostarczają na bieżąco do systemu dane, które są analizowane i automatycznie procesowane według ustalonych wcześniej wskaźników.
Pokaż firmę i zachodzące w niej procesy
Pamiętajmy, że analiza jest kluczowym elementem podczas zmiany systemu i dlatego zawsze wyznawajmy zasadę: nie mówmy o problemach, tylko pokażmy je dostawcy. Około 65% populacji stanowią wzrokowcy. To właśnie treści wizualne powodują wzrost zaangażowania i zrozumienia u dostawcy oprogramowania. Jeśli masz firmę produkcyjną, pokaż problemy występujące na hali produkcyjnej, a jeśli chcesz czerpać korzyści z zaawansowanych funkcjonalności transportowych - pokaż swój park transportowy i zapytaj o automatyzację procesów, które w nim zachodzą.
Kompletacja i dostępność członków zespołów
Aby proces przebiegł według założonych wcześniej celów, należy optymalnie dobrać i zsynchronizować zespoły. Klient niech dobierze członków zespołu według kompetencji obejmujących wszystkie obszary firmy. Osoby kluczowe powinny być tak dobierane, aby cechy charakteru pozwalały na przekazanie zdobytej wiedzy na późniejszym etapie wdrożenia.
Najważniejszym jednak jest dostępność członków zespołu wdrożeniowego. Wybierając osoby kluczowe, należy ustalić priorytety pracy dla takich osób. Priorytetem jest ich dostępność w procesie analizy i odbioru prototypu. Osoba kluczowa na czas prac nad nowym systemem powinna mieć zastępstwo w bieżących pracach w firmie. Podejmowanie i kreowanie procesów w nowym systemie powinno być nadrzędne nad bieżącymi procesami w firmie.
Większość „nieudanych” wdrożeń związanych było z brakiem zaangażowania się osób kluczowych, następstwem czego zostały stworzone produkty i procesy niedostosowane do specyfiki nowej organizacji.
Mówiąc o kompetencjach zespołów, muszę również odnieść się do zespołu wdrożeniowego. Kierownik projektu podczas pierwszego spotkania analitycznego powinien przedstawić swój zespół, każdego członka zespołu oraz jego obszar kompetencyjny w projekcie.
Podczas spotkań analitycznych kierownicy projektu powinni być obecni, obserwować pracę zespołów i wymieniać się wnioskami z tych obserwacji.
Firma wdrożeniowa w procesie analizy będzie zawsze oceniana za swój profesjonalizm i innowacyjność. Znajomość najnowszych rozwiązań technologicznych może sprawić, że proces wytwórczy przeniesie wdrożenie w inny wymiar, a nie zapewni jedynie parametryzacji systemu ERP.
Spotkanie inauguracyjne proces wdrożenia systemu
Myślę, że pierwsze spotkanie zespołów projektowych jest kluczowe. Podczas tego spotkania powinny być zrealizowane dwa ważne punkty.
Pierwszy punkt to czas na tworzenie par projektowych składających się z osoby ze strony klienta i dostawcy. Kierownicy projektu po stronie klienta, jak i dostawcy oprogramowania prezentują osoby kluczowe związane z obszarami firmy.
Drugi punkt podczas tego spotkania to prezentacja przez zespół klienta procesów zachodzących w firmie. Realizacja tego punktu uświadamia wszystkim stopień znajomości i spójności procesów przez zespół projektowy klienta.
Zawsze uważałem, że ryzyko należy wyeliminować na początkowym etapie projektu lub określić współczynnik rekompensaty w procesie wdrożenia. Z doświadczenia wiem, że organizacja im jest większa, tym jest bardziej podatna na nieznajomość całych procesów w firmie oraz redundancję danych. Dla mnie zawsze najważniejszy jest proces.
Zarządzanie ryzykiem sprowadza się do przedstawienia przez członków zespołu klienta procesów w ich firmie oraz efektów, które powinno przynieść wdrożenie nowego systemu. Wielokrotnie byłem świadkiem, że wiedza osób wybranych do projektu ograniczała się tylko do własnego obszaru działalności bez świadomości wpływu na całe procesy w firmie. Niestety kolejnym problemem jest odmienność celów co do korzyści z nowego systemu.
Również wielką górą lodową, której klient nie widzi, jest jego nieznajomość procesów.
Klient podczas zakupu systemu określa, że jedynym problemem są ograniczenia systemu. Spotkanie inauguracyjne uświadamia, że niestety istnieją inne problemy, których rozwiązanie jest elementem nadrzędnym przed rozpoczęciem wdrożenia.
Informacja przekazana firmie wdrożeniowej na etapie analizy powinna być spójna w obrębie wszystkich działów oraz zarządu. To bardzo ważny element, który może storpedować cały proces wdrożenia poprzez niedoszacowanie oferty ze strony dostawcy i niezabezpieczenie odpowiednich środków w budżecie przez klienta.
Harmonogram prac Fazy 1
Głównym błędem jest brak podstawowego harmonogramu wdrożenia wraz z jego przekazaniem członkom zespołu. Brak harmonogramu powoduje improwizacje ze strony kierowników projektu, a poszczególni członkowie zespołów dowiadują się o spotkaniach analitycznych w „ostatniej chwili”. Takie podejście powoduje, że realizacja harmonogramu nie idzie w parze z korzyściami, jakie spotkania powinny wnosić do projektu. Brak optymalnego przygotowania do spotkań powoduje nie tylko frustrację, ale inicjuje konieczność dodatkowych spotkań.
Pamiętajmy, że członkowie zespołów po jednej i drugiej stronie powinni z wyprzedzeniem otrzymywać datę i cel spotkania, przecież wykonują również bieżącą pracę w innych projektach.
Chciałbym również zaakcentować potrzebę spotkań międzyobszarowych. Na etapie analizy powinniśmy znaleźć rozwiązanie, a nie przenosić problem do kolejnych faz projektu.
Fluktuacja osobowa - zespoły projektowe
Dużym problemem w procesie wdrożenia jest rotacja osób w zespołach projektowych. Szczególnie jest to widoczne w procesie analizy.
W przypadku klienta wielokrotnie ważniejszy jest bieżący biznes, więc na spotkanie analityczne są wysyłane, zamiast osób kluczowych wpisanych do projektu, osoby „zastępujące”. Wielokrotnie te osoby mają mniejsze kompetencje i doświadczenie. Głównym zadaniem takich osób jest omówienie, czym się obecnie zajmują. Na spotkaniach brak jest osoby, która weryfikuje przekazywaną wiedzę. Wielokrotnie zdarza się, że takich zastępców w danym obszarze jest kilku. Muszę nadmienić, że osoby te nie znają celów osób kluczowych ani zarządu firmy.
Prowadząc w ten sposób projekt, nie będziemy widzieć zagrożeń. Kierownicy projektu mają zaznaczony punkt z realizacją spotkania analitycznego zgodnie z ustalonym harmonogramem. Ja to nazywam „bombą z opóźnionym zapłonem”.
W przypadku firmy wdrażającej, w tej fazie projektu błąd polega na marginalizowaniu fazy analizy. Na spotkanie wysyłane są osoby z małym doświadczeniem, których głównym celem jest spisanie potrzeb klientów, w myśl zasady - „co klient powie, to my zrobimy”.
Brak doświadczenia uwidoczni się w obszarze komunikacji. Osoba doświadczona na podstawie otrzymanych informacji powinna zadawać pytania uszczegóławiające, które w głównej mierze wyznaczą kierunek i sposób rozwiązania. Każdy konsultant rozmawiający z klientem powinien móc sam zaprojektować w swoim obszarze kompetencji rozwiązanie w zakresie wymogów i potrzeb klienta.
Szkolenie użytkowników kluczowych
Bardzo ważnym elementem procesu analizy jest budowanie świadomości użytkowników kluczowych. Pamiętajmy, że oni dostarczają nam wiedzę na temat bieżącej i przyszłej pracy podczas spotkań analitycznych. Nie zapominajmy jednak, że na nich spadnie odpowiedzialność za przygotowanie podległych im struktur do bieżącej pracy na środowisku produkcyjnym. Musimy ich zatem dobrze przygotować.
Na etapie analizy przeprowadzane są ogólne szkolenia ze standardowego zakupionego systemu ERP. Użytkownicy poznają podstawowe funkcjonalności wraz z propozycją rozwiązania na podstawie spotkań analitycznych. Ten sposób - „powiedz co chcesz, a ja pokażę ci, jak to zrobić” - daje wiele korzyści dla każdej ze stron. Budujemy wzajemne kompetencje oraz poznajemy i przyswajamy język procesowy przedsiębiorstwa oraz nomenklaturę nowego systemu. Szybciej i efektywniej powstaje dokumentacja projektowa i techniczna.
Na tym etapie wielokrotnie wychodzi potrzeba zwiększenia budżetu, co po procesie wykonanej analizy może być podstawą do przygotowania aneksu do umowy.
Niestety większość firm wdrożeniowych pomija proces budowy świadomości użytkowników kluczowych na tym etapie. Powód jest prozaicznie prosty, bo jest związany z etapami płatności projektu. Przeważnie użytkownicy pierwszy raz widzą system podczas testów modyfikacji Fazy 2.
Rodzaj i sposób tworzenia dokumentacji
Dokumentacja stanowi wyzwanie zarówno dla klienta, jak i firmy wdrażającej. Dokumentację możemy podzielić na dokumentację papierową i multimedialną.
W przypadku dokumentacji papierowej podstawowym problemem jest spójność opisywanych procesów. Każdy z konsultantów wdrożeniowych koncentruje się na swoim obszarze kompetencyjnym. Powinien zwrócić jednak uwagę na obszary nakładające się. Jeśli widzi niezgodności, to już na tym etapie powinien zgłosić do swojego kierownika projektu potrzebę zorganizowania spotkania roboczego w gronie wewnętrznym lub poszerzonym o odpowiednie osoby ze strony klienta. Większość dokumentacji jest „sklejana” z dokumentacji obszarowej bez osoby recenzującej spójność danych i procesów.
Drugim poważnym problemem jest używanie pojęć i nazw nieznanych drugiej stronie. Jeśli przekazywana treść w przedstawionej formie jest niezrozumiała dla drugiej strony, to będzie to stanowić poważne zagrożenie dla całego procesu wdrożenia. Znam wiele wdrożeń, gdzie kilka słów zapisanych, a niezrozumianych przez jedną ze stron spowodowało, że wdrożenie zakończyło się porażką.
W przypadku dokumentacji multimedialnej dobrze przed nagrywaniem ustalić pewne reguły związane z formą i nazewnictwem w celu katalogowania. Ważne są dwa elementy: nagrania mają być jakościowe, a nie ilościowe oraz w dokumentacji papierowej dobrze określić numer nagrania i czas, na który dany fragment dokumentacji się powołuje.
Architekt systemowy
W mojej ocenie architekt systemowy jest w projekcie tak samo ważny jak kierownik projektu. Powinien być recenzentem dokumentacji oraz projektowanych rozwiązań. On bierze na siebie tworzenie spójnego systemu opartego w pierwszej kolejności o funkcjonalności standardowe systemu ERP.
Architekt systemowy dzięki swojej wiedzy w zakresie logistyki i finansów powinien dbać o spójność danych merytorycznych przekazywanych przez konsultantów do kierownika projektu.
Ten punkt w większości wdrożeń niestety nie jest realizowany. Brak takiej osoby w projekcie wpływa na rozbieżność danych w systemie, jak również na zniekształcenie odbioru raportów przekazywanych do kierownika projektu przez konsultantów.
Prototyp rozwiązania
Pamiętajmy, że każda analiza powinna zakończyć się prototypem rozwiązania obejmującym całość wdrożenia.
Prezentacja prototypu powinna zawsze odbyć się z udziałem wszystkich osób kluczowych w firmie oraz osób kluczowych po stronie dostawcy. Prezentacja prototypu zawsze wskazuje dwa ważne wskaźniki: spójność procesów po stronie organizacji i zrozumienie przez dostawcę procesów zachodzących w nowym systemie.
Prototyp rozwiązania powinien być zaprezentowany przez architekta rozwiązania, który dodatkowo powinien być moderatorem spotkania.
Zamknięcie procesu analizy i prezentacji rozwiązania
Czas prezentacji prototypu to czas końcowy Fazy 1. Po akceptacji prototypu pozostaje dokończenie i przekazanie dokumentacji projektowej.
Dokumentacja projektowa szczegółowo opisuje i prezentuje niezbędne w procesie wdrożenia zmiany programistyczne, które powinny zostać wykonane i wdrożone w Fazie 2 projektu.
Proszę zauważyć, że w tej fazie proces zatoczył koło.
Podczas pierwszego spotkania zespół projektowy ze strony klienta prezentował swoje obszary procesowe wraz z naciskiem na to, czego zarząd oraz każda osoba kluczowa oczekuje od nowego systemu. Podczas prezentacji prototypu firma wdrożeniowa wskazuje sposób realizacji powyższych założeń.
W następnym artykule opiszę, jak wiedza zdobyta w Fazie 1 może być w różny sposób wykorzystana w fazie przygotowania systemu do testów przez użytkowników.
