ValueWithin – aby SAP nie był ekskluzywnym systemem do drukowania faktur

Wdrożenia zintegrowanych systemów zarządzania klasy ERP to skomplikowane same w sobie projekty. Dodatkowo to projekty ze swej natury drogie. Te projekty budzą przy tym ogromne emocje i wielkie nadzieje. Na ich początku wszyscy uczestnicy są bardzo optymistyczni, wielce zaangażowani, bardzo chcą jak najlepszego efektu wdrożenia. Zarządy firm łożą hojnie na te inwestycje. Dlaczego zatem tak często projekty wdrożeniowe systemów ERP przekraczają budżety, nie dotrzymują terminów, a tylko dbałość o wizerunek firmy nie pozwala nazwać ich efektów wprost klęską? Dlaczego zamiast systemu, który miał zintegrować zarządzanie firmą i przynieść jej wymierne korzyści otrzymujemy często bardzo drogi system do rejestracji dokumentów, rejestracji w skomplikowany sposób – niektórzy wprost mówią o implementacji ekskluzywnego systemu do drukowania faktur? Moim zdaniem jedna z istotnych przyczyn leży w niewłaściwej metodyce wdrożeniowej, która gubi najistotniejsze aspekty wdrożenia czyli zarządzanie zmianą, edukację i realizację korzyści.

Koncepcja, Realizacja, Start – dlaczego prosta mapa drogowa nie działa?

Projekty wdrożeniowe są zwykle realizowane w następujących fazach, pomijam tutaj aspekty stricte techniczne jak dostarczenie sprzętu czy instalacja oprogramowania:

  1. Opracowanie koncepcji
  2. Konfiguracja systemu
  3. Implementacja rozszerzeń
  4. Testy integracyjne
  5. Szkolenia użytkowników
  6. Zmiany organizacyjne
  7. Wsparcie pracy produktywnej systemu

Te fazy są przedstawiane poglądowo jako mapa drogowa projektu. Przykładowo firma SAP definiuje taką mapę następująco:

Każda faza zaczyna się po formalnym zaakceptowaniu i odebraniu fazy poprzedniej. Teoretycznie takie podejście jest jak najbardziej poprawne. Projekt jest ściśle kontrolowany w ramach faz. Każda faza ma jasno zdefiniowane produkty, które są wymagane do rozpoczęcia kolejnej fazy.  W każdej fazie są zdefiniowane czynności i zadania oraz odpowiedzialni za ich realizację. Wszystko to prawda,  ale tylko teoretycznie stanowi to gwarant udanego wdrożenia.

Z punktu widzenia metodyki prowadzenia projektów jest to typowy model kaskadowy (ang. waterfall model). Pułapki i niedoskonałości tego modelu zostały już dokładnie przeanalizowane w literaturze fachowej i obśmiane w rysunkach satyrycznych, z których najbardziej znany to ilustracja budowy huśtawki – proszę sprawdzić wyniki wyszukiwania obrazów w Google dla hasła „waterfall model swing cartoon”. W wielkim skrócie wady tego modelu wynikają z odmiennej perspektywy i optyki wykonawcy oraz zamawiającego czy klienta. W fazie Blueprint / Koncepcji wdrożenia wykonawca wspólnie z zamawiającym definiują docelowy kształt systemu i opisują go w obszernym dokumencie zwanym koncepcją wdrożenia lub business blueprint. Jednak zrozumienie tego dokumentu przez wykonawcę oraz zamawiającego i wyobrażenie jak będzie działał zintegrowany system są zgoła odmienne. To jest całkowicie naturalne i nie stanowiłoby problemu, gdyby te rozbieżności były na bieżąco weryfikowane i eliminowane. Jednak nie są – po fazie opracowania koncepcji przychodzi faza realizacji, po której zamawiający jest konfrontowany z prawie gotowym systemem i przeżywa bolesne rozczarowanie.

Dodatkowo konsultanci implementujący system skupiają się na obsłudze poszczególnych transakcji, na wdrożeniu określonych funkcjonalności systemu, gubiąc przy tym integrację i automatyzację procesów, planowanie i monitorowanie jakości obsługi procesów biznesowych przedsiębiorstwa. W efekcie dostarczony system potrafi rejestrować transakcje, ale nie potrafi wspomagać zarządzania firmą. W tym konkretnym kontekście pisząc system mam na myśli zarówno oprogramowanie, jak i dane w nim zawarte oraz przede wszystkim użytkowników tego oprogramowania, ich świadomość i wiedzę.

Takie podejście wynika wprost z wyboru systemu opartego o listę wymagań funkcjonalnych i potraktowanie implementacji jako dzieła w umowie wdrożeniowej. W istocie, nie jest tutaj wdrażany system dostarczony przez producenta oprogramowania, ale są wprost implementowane wymagania funkcjonalne na bazie tylko czy w środowisku gotowego systemu ERP. Nacisk jest tutaj położony na, często siłowe, dopasowanie systemu i jego procesów do zdefiniowanych wcześniej wymagań, zamiast na wykorzystanie „best practices” systemu, edukację użytkowników i zmiany organizacyjne.

Ten model ma jeszcze jedną istotną wadę. Jest bardzo nieefektywny kosztowo. Poniższy diagram pokazuje poglądowo wykorzystanie budżetu w poszczególnych fazach projektu.

Proszę zwrócić uwagę na fazę testów na powyższym diagramie. Ze względu na liczbę niestandardowych rozszerzeń i dopasowań systemu do wymagań funkcjonalnych, należałoby wykonać znaczną liczbę testów integracyjnych. Zwykle w tej fazie projekt jest już istotnie spóźniony i pojawia się silna presja czasu. Poniechanie dokładnych testów, skutkuje nieproporcjonalnie wysokimi kosztami wsparcia i rozwiązywania problemów w systemie działającym już produktywnie. Te koszty zamawiający będzie ponosił już praktycznie stale przez długi okres użytkowania systemu i będą się one z czasem zwiększać. Rzadko kiedy są one jednak wliczane do kosztów projektu wdrożeniowego, choć stanowią składnik całkowitych kosztów korzystania z systemu (ang. TCO –Total Cost of Ownership).

Alternatywnym podejściem jest metodyka Value Within, która skupia się raczej na edukacji i implementacji zmian organizacyjnych, na budowaniu wartości i dojrzałości informacyjnej organizacji poprzez integrację procesów gospodarczych w ramach standardowych funkcjonalności systemu ERP.

Value Within – gdzie jest wartość wdrożenia systemu ERP?

Podejście Value Within powstało z refleksji nad tym co ważne i istotne we wdrożeniu zintegrowanego systemu ERP, z refleksji na górą lodową projektu ERP.

Zwykle implementacje systemu ERP są traktowane jako projekty IT, są zarządzane przez informatyków, finansowane z budżetów IT, tylko czasami, tytularnie w strukturach zarządzania projektem zasiadają przedstawiciele zarządu firmy. Metodyka Value Within widzi wdrożenie systemu ERP jako projekt przede wszystkim biznesowy, jako projekt implementacji zmian organizacyjnych, integracji zarządzania i optymalizacji procesów, gdzie te zmiany są tylko inicjowane przez wprowadzenie nowego narzędzia informatycznego. Stąd w projekcie Value Within transakcje i funkcjonalności systemu stanowią jedynie czubek góry lodowej. Te aspekty są oczywiście bardzo ważne, ale tylko jeśli są umożliwiają wydajne zarządzanie procesami firmy, pozwalają mierzyć jakość zarządzania, są obsługiwane przez wyszkolonych użytkowników, którzy czują się właścicielami danych, automatyzują procesy i sygnalizują poprzez wyjątki sytuacje wymagające ręcznej interwencji (ang. management by exceptions). Metodyka Value Within wychodzi z założenia, że dojrzały system klasy ERP, a takim jest system SAP ERP, zawiera wszystkie funkcjonalności niezbędne do zarządzania przedsiębiorstwem, a także zawiera predefiniowane procesy biznesowe (ang. best practices) gotowe do szybkiego uruchomienia i wykorzystania. Ktoś powie, że to nazbyt radykalne podejście, że przecież każda firma ma swoją specyfikę i wymaga indywidualnego podejścia. To oczywiście prawda. Jednak prawdą również jest, że w każdej firmie produkcyjnej występują zlecenia produkcyjne, które są harmonogramowane, które obciążają moce produkcyjne, że każda firma dokonująca zakupów tworzy zamówienia zaopatrzeniowe i weryfikuje do nich faktury. W moim przekonaniu unikalność firmy leży w jej portfolio produktów, w relacjach z klientami, w polityce cenowej. Natomiast system ERP powinien tę unikalność wspierać przy pomocy możliwie standardowych procesów. Oczywiście bywają przypadki, kiedy przedsiębiorstwo wymaga określonych specyficznych funkcjonalności jak np. dostawy JIS. To powinno zostać jednak uwzględnione podczas wyboru systemu ERP. To wybór systemu ERP a nie jego wdrożenie musi zapewnić, że spełnia on takie specyficzne wymagania.

W projektach Value Within przyjmuje się również założenie, że system ERP nie jest magiczną różdżką, która rozwiąże wszystkie problemy wszystkich działów firmy. System ERP nie zrobi wszystkiego dla  wszystkich. Wystarczy, aby system ERP pozwalał na optymalizację, integrację i automatyzację kluczowych procesów firmy. Wtedy przedsiębiorstwo zrealizuje korzyści z wdrożenia, a samo wdrożenie będzie sukcesem.

Metodyka Value Within jest stosowana przede wszystkim w projektach optymalizacyjnych łańcucha dostaw, gdzie klient używa już od jakiegoś czasu systemu SAP ERP, używa systemu na poziomie rejestrowania poszczególnych operacji, nie potrafi jednak wydobyć z systemu realnej wartości, zoptymalizować zarządzania procesami, ani zintegrować informacji.

W pierwszej fazie „Przygotowania” określane są jasno cele projektu, tj. wykorzystanie standardowej funkcjonalności systemu SAP do optymalizacji zarządzania łańcuchem dostaw. Projekt jest definiowany jako przede wszystkim wprowadzenie zmian organizacyjnych i edukacja użytkowników. Zapewnione jest wsparcie zarządu firmy oraz wprowadzane są podstawowe narzędzia projektowe, tj. KPIs łańcucha dostaw oraz rejestr wszelkich zadań i problemów w projekcie.

Celem drugiego etapu „Analizy” jest odnalezienie w organizacji osób odpowiedzialnych za poszczególne procesy, edukacja tych osób i nauczenie ich w jaki sposób zarządzać procesami logistycznymi w standardzie SAP ERP. Cała magia projektu Value Within pojawia się właśnie w tej fazie. Użytkownicy zaczynają rozumieć jak działa SAP ERP, dostrzegają korzyści z wykorzystywania systemu. Praca z SAP ERP, która dotąd była uciążliwym obowiązkiem, zaczyna przynosić realne korzyści. Użytkownicy zaczynają rozumieć jak działa system, jak jest w nim zintegrowana informacja, w jaki sposób system wspomaga ich codzienną pracę. Co więcej, wszelkie zmiany w danych sterujących procesem są dokonywane bezpośrednio w systemie, przez samych użytkowników. To dodatkowo wzmacnia odpowiedzialność za dane i buduje świadomość działania systemu.

Kiedy mamy już wyedukowanych użytkowników, którzy wiedzą za co są odpowiedzialni i jak pracować z systemem, przychodzi pora na realizację korzyści i optymalizację procesów. Oczywiście nie można zmienić wszystkiego od razu. Dlatego wydzielamy obszary optymalizacji w formie określonych grup danych. W firmie produkcyjnohandlowej realnym przykładem takiego obszaru jest np. biznes handlowy. W firmie produkcyjnej może być nim określona grupa produktów. Te obszary można też definiować w funkcji struktury organizacyjnej firmy np. najpierw optymalizowane są procesy w określonej spółce.

Weryfikacja osiągniętych efektów kończy fazę realizacji. Sprawdzane są miary jakości zarządzania łańcuchem dostaw, użytkownicy przechodząc test certyfikacyjny ze znajomości systemu, kontrolowany jest status wszystkich zarejestrowanych zgłoszeń. Bardzo istotnym narzędziem w tej fazie, ale także w całym projekcie są prezentacje wyników. Są to prezentacje przygotowywane i przedstawiane komitetowi sterującemu przez uczestników projektu, użytkowników systemu. Co bardzo ważne dział IT nie przygotowuje, ani nie prowadzi tych prezentacji!!! Zwykle prezentacje odbywają się co 2 tygodnie i pokazują status projektu w formie trendów KPIs, wykonane zadania oraz plan na kolejne 2 tygodnie. Jest to też miejsce do uczciwego pokazania wszystkich kwestii problematycznych. W moim przekonaniu, bez takiej uczciwości i otwartości nie jest możliwe efektywne wdrażanie zmian organizacyjnych i budowanie świadomej odpowiedzialności za swoją pracę i jej odzwierciedlenie w zintegrowanym systemie SAP ERP.

Na koniec prawie banał, choć sam projekt Value Within kończy faza weryfikacji, to sama optymalizacja nie powinna się kończyć, powinna stać się nawykiem w codziennej pracy, wejść w krwiobieg przedsiębiorstwa. Dlatego Value Within definiuje fazę rozwoju, powinna trwać stale po zakończeniu projektu.

Metodykę opartą na tych samych zasadach stosuje się z powodzeniem nie tylko w projektach optymalizacyjnych, ale też w projektach wdrożeniowych. Wtedy użytkownicy co prawda nie pracują na swoim, żywym systemie, ale są od razu, od samego początku projektu, uczeni wykorzystywania standardowych funkcjonalności SAP ERP. Edukacja tutaj polega na pokazaniu w jaki sposób planować, realizować, raportować i automatyzować procesy przy pomocy SAP Best Practices. Pozostałe elementy metodyki takie jak zarządzanie zmianą, budowanie i integrowanie struktur odpowiedzialności za proces, stały monitoring kluczowych KPIs oraz regularne spotkania i prezentacje są takie same.

Zostaw komentarz