Chcę rozważać skalę osiąganego powodzenia oraz aspekty, które wydają się mieć istotny wpływ na to powodzenie. Wdrożenia systemów ERP i później funkcjonowanie takich systemów dotyczą bardzo wielu ludzi w bardzo różny sposób, z których wielu z kolei ma wpływ na kształt wdrożenia. To właśnie postawa tych wszystkich ludzi i sposób w jaki postępują oni z systemem wyznaczają skalę efektów wdrożenia.

Na pierwszy ogień chciałbym wziąć kwestie metodyk wdrożeniowych. Szczególnie modnego od kilku lat nakładania na własne metodyki dostawców systemów ERP – takich jak ASAP w przypadku firmy SAP – metodyk typu PRINCE2 czy PMI opisanej w PMBOK. Szerzej zajmę się tą tematyką w następnych odcinkach tutaj celowo prowokacyjnie (aby wywołać dyskusję) stwierdzę, że uważam to za działanie w wielu przypadkach niepotrzebne i że często prowadzi to do gmatwania projektów, rozmywania odpowiedzialności czy do odwracania uwagi od spraw rzeczywiście istotnych. Ujmując rzecz obrazowo: analizując przebieg i efekty wielkich projektów kilkanaście lat temu i teraz zauważam, że trwają one tyle samo i mają tak samo dobre efekty pomimo tego, iż kilkanaście lat temu nie było takiego zwyczaju. Można zaryzykować zatem tezę, że korzyści z zastosowania uznanych metodyk wdrożeniowych nakładanych obecnie na wdrożenia są niwelowane zjawiskami patologicznymi. Dochodzę zatem na tej podstawie do wniosku, że istnieje spory potencjał poprawy efektywności wdrożeń ERP i właśnie tym chcę się zająć.

Zaryzykuję też tezę, że nierzadko działania nakładające na wdrożenia systemów ERP takich metodyk jak PMBOK czy PRINCE2 robione są w sposób niezgodny z ich fundamentalnymi zasadami. Te najczęstsze patologie to mnożenie produktów powstających w trakcie wdrożenia, mnożenie dokumentów i formularzy i hodowanie ryzyk i problemów. Należy tu przypomnieć, że rolą dobrego project managera jest właściwe rozpoznawanie ryzyk i inicjatywa w doborze środków je neutralizujących, a nie kwieciste rozpisywanie się na ten temat w raportach do komitetu sterującego. Takie hodowanie ryzyk jest przecież w sprzeczności z zasadą „zarządzania przez wyjątki” zgodnie z którą komitet sterujący uruchamiać powinny sprawy wymykające się spod kontroli project managera.

Najwyraźniej zatem osoby, które nabyły wiedzę o zarządzaniu projektami zapominają o tym, co było napisane w podręcznikach metodyk na pierwszych stronach czyli, że nie ma konieczności stosowania zawsze całej wiedzy i rozwiązań i że to zespół zarządzający projektem powinien dobrać metodyczne „instrumentarium” do potrzeb danego projektu. W przypadku systemu SAP takim gotowym instrumentarium jest metodyka ASAP, jest ona skonstruowany zgodnie z zaleceniami opisanymi w PMBOK (ale nie na jej podstawie tylko wyrasta z tego samego pnia najlepszych praktyk i została do PMBOK zunifikowana) z właściwie dobranymi proporcjami narzędzi i w sposób kompletny opisanymi produktami.

Innymi słowy osoby obeznane z PRINCE2 czy PMBOK mają w postaci metodyki ASAP gotowy konspekt metodyki i nie powinny mieć absolutnie żadnego kłopotu by zarządzać takim projektem zgodnie z nim. Jeżeli widzą potrzebę wzbogacenia tej metodyki to również nic nie stoi na przeszkodzie byleby jej tym nie psuli.

Stwierdzić należy również, że nakładanie metodyk bardziej ogólnych na metodykę ASAP (związanej z konkretnym przedmiotem wdrożenia) jest też działaniem logicznie wątpliwym gdyż często prowadzi do odkrywania koła na nowo, a przez to ryzykuje się, że koło to nie będzie okrągłe. Np. podział koncepcji (blueprintu) na różne produkty czyli przejście od rzeczy precyzyjnie opisanej najpierw do postaci bardziej ogólnej, a potem doprecyzowanie w postaci jakichś rozłącznych blueprintów nakłada na projekt ogromne dodatkowe ryzyko, że w miejsce dobrej specyfikacji produktu przetestowanej na wielu projektach powstaje coś nowego, co tak naprawdę testowane będzie na projekcie. Przecież rolą projektu wdrożeniowego nie jest testowanie nowych rozwiązań metodycznych! Bardzo ciekaw jestem uwag i doświadczeń z tym związanych.

Podkreślam na wszelki wypadek, że celowo opisane sprawy przerysowałem. Praktyka projektowa pokazuje, że wdrożenia ERP toczą się pomyślnie - czasami tylko nękane są jakimiś dolegliwościami. To podkreśla jedną z zalet systemów ERP, że są one niezawodne wdrożeniowo.

Przy tej okazji temat nostalgiczny – tzw. polska wersja. Wydaje się, że obecnie sprawy związane z dostosowaniem systemu do polskich przepisów, w szczególności Ustawy o rachunkowości, nie mają już znaczenia. Po pierwsze systemy ERP są dobrze przygotowane, a po drugie zmalało ciśnienie związane z takim czy innym przepisem. Ciekaw jestem Państwa opinii i doświadczeń w tej sprawie.

Poruszam ten temat dlatego, że patrząc na wdrożenia „na osi czasu” widać wyraźne zmiany środka ciężkości. Kiedyś uwagę pochłaniała sprawa specyfiki polskiej, a obecnie podobne emocje i dylematy budzą inne sprawy w tym kwestia metodyk wdrożeniowych. Te dwa obszary bezpośrednio nie łączy niemal nic. Czy zatem to musi być tak, że jakiś temat jest modny i koncentruje uwagę choć być może jego znaczenie nie uzasadnia aż tak wielkiego zaangażowania? Aby temu się przyjrzeć i sprawdzić, czy to ciekawy i pouczający temat do dyskusji napiszę o tym parę słów.

Z racji pełnionej funkcji w SAP Polska byłem aktywnym uczestnikiem realizacji polskich wymagań prawnych. W roku 2000 przeprowadziłem wewnętrzny projekt, którego efektem było uzyskanie przez system R/3 tzw. rekomendacji Stowarzyszenia Księgowych w Polsce. Mniej więcej wtedy dało się zauważyć spadek znaczenia tego tematu.

W tej kwestii było widać dwie skrajności pokazujące pojmowanie systemów ERP przez potencjalnych użytkowników: jedni chcieliby aby system ERP był czymś w rodzaju ograniczonej funkcjonalnie kasy fiskalnej, drudzy z kolei chcieliby aby można było w nim zmieniać dane w sposób - nazwijmy to - niezbyt formalny. To drugie wynikało z przyzwyczajenia dosyć kiedyś powszechnego, że jak się zarejestrowało źle dokument to wezwani informatycy coś tam w systemie zmieniali i wszystko było w porządku. Abstrahując od tego, na ile szczególnie w tym drugim przypadku oczekiwania te mogły wykraczać poza przepisy to oczywiście system ERP jest bliższy kasie fiskalnej przy jednocześnie ogromnej funkcjonalności. To były jednak czasy gdy nawet w wielkich firmach stosowano różne niezbyt zintegrowane aplikacje i informacja, że w systemie takim jak R/3 działanie zarejestrowane np. przez magazyniera miało efekt w księgach rachunkowych wywoływało gwarantowane przerażenie u pań/ panów głównych księgowych. Jak się potem okazywało zupełnie niepotrzebnie.

Pewnie ktoś zapyta, co powyższy akapit ma wspólnego z wersją polską? Odpowiadam: wtedy wszystko miało związek z wersją polską i niemal każde oczekiwanie wobec systemu formułowane było wraz z zastrzeżeniem, że przecież tak wymaga prawo w Polsce – najczęściej przywoływano Ustawę o rachunkowości. Z tego powodu stałem się ekspertem do spraw ustawy o rachunkowości aby móc takie „zaczepki” formułowane w postaci zaskakujących „wrzutek” w trakcie spotkań spokojnie rozbrajać.

Także w tym zakresie zdarzały się sytuacje zabawne – przypomina mi się, kiedy w trakcie komitetu sterującego jeden z uczestników zarzucił systemowi R/3, że w zakresie kadrowym nie jest zgodny z przepisami ponieważ umożliwia zatrudnienie na stanowisku dyrektorskim niemowlaka. Choć byłem trochę senny (na spotkaniach na projekcie tym podawano tylko wodę mineralną, a trwały dosyć długo) ożywiłem się i mało brakowało abym tej osoby nie poparł wspominając, że nie jest też zgodny z konwencją ONZ o zakazie handlu żywym towarem, jako że można w nim założyć indeks materiałowy na człowieka, wprowadzić go do magazynu, a nawet sprzedać wystawiając fakturę! Przypomniał mi się wtedy od razu kolega nazywany „Brykiet” który by się idealnie do tego nadawał.

W praktyce można sprawdzać i walidować wartości wpisane do pól na ekranie. ale tu chodziło o dużo więcej – chodziło o „pilnowanie” użytkowników. Wspominam to po to by zilustrować poruszony temat „kasy fiskalnej” czyli systemu, który pilnuje i wręcz koryguje użytkowników. To też pokazuje różnicę jaką rolę mieli tzw. referenci kiedyś i jaką mają osoby będące na podobnych stanowiskach, a będący użytkownikami systemów ERP dziś. Pokazuje jakie było zaufanie do takich pracowników kiedyś i jakie jest teraz. To z kolei dobrze ilustruje, iż na wdrożeniach ERP zyskują wszyscy. Gdyby zatem skoncentrować uwagę na statusie osób które po wdrożeniu stały się użytkownikami systemu ERP to jasne jest, że wzrósł on znacznie. To już jednak zupełnie inny wątek.

Wracając do specyfiki polskiej: kto to dzisiaj pamięta pasjonujące dyskusje dotyczące długości czy struktury konta, sposobu naliczania odsetek, wyglądu rejestru VAT czy amortyzacji samochodów osobowych? Ciekawe były refleksje po latach samych użytkowników, którzy najpierw chcieli aby numery kont były jak najdłuższe i boleli bardzo ograniczeniem tej długości w systemie, a po latach sami wracali do sprawy żałując z kolei, że wykorzystali całą długość gdy można było zrobić te numery dużo krótsze i ile to by dało oszczędności czasu przy wpisywaniu i ile zaoszczędziło by pomyłek.

W tej kwestii uczynię wyjątek od reguły, którą sam na początku zapisałem i chętnie powspominam stare czasy. Ku nauce i pokrzepieniu serc. Zapraszam do dyskusji.