SAP Project Manager a PMI, PRINCE2, AGILE i “Biały Słoń” …

…czyli jak się okazało największa katastrofa wdrożenia ERP w 2011 nie dotyczy systemu ERP.

Ma za to związek ze znaną metodyką… o tym nieco dalej!

Mógłbym powiedzieć: „nie chcem ale muszem”. Temat dotarł do mnie z powrotem jak bumerang wiec się za niego biorę. Co zrobić – co i rusz słychać, że ktoś oczekuje wdrażania SAP zgodnie z PMI albo PRINCE2. No dobrze skoro mus to mus – ale słyszałem też o wdrażaniu SAP’a ERP AGILE’m. rany Julek, a to po co komu? Nie przychodzi mi nic innego jak stwierdzić, że najwyraźniej wdrażanie ERP stało się za łatwe i zbyt przewidywalne i trzeba je skomplikować.

AUTOR: Waldemar Faliński

Muszę też wytłumaczyć, dlaczego skoro chciałem pisać o wdrożeniach ERP teraz zaś piszę o SAP – otóż tylko ten system i metodykę jego wdrażania znam. Nadal podtrzymuję, że chcę go stosować w moich publikacjach jako odnośnik do wszystkich innych ERP’ów jako SAP ERP Benchmark, ale skoro teraz ma być mowa o faktach to muszą dyskusję zawęzić do tego, na czym się znam najlepiej.

Nie jestem bynajmniej żadnym przeciwnikiem metodyk (czy też bardziej precyzyjnie zbiorów zasad i metodologii do tworzenia konkretnych metodyk – ale dla prostoty będę pisał jak o metodykach) typu PMI czy PRINCE2 – po prostu odpowiem cytując mojego kolegę Jurka Stawickiego, który profesjonalnie po latach kierowania projektami wdrożeń SAP wg metodyki ASAP został mentorem metodyki PMI. Na moje pytanie jak ocenia zastosowanie PMI do wdrożenia SAP odpowiedział zdecydowanie: „A po co to robić!”. No właśnie – na początku wszelkiego racjonalnego działania musi leżeć biznesowa przyczyna: PO CO?

I od razu doleję oliwy do ognia – postanowiłem bowiem sprawdzić jakie metodyki zostały zastosowane w opisywanych w mediach WIELKICH katastrofach wdrożeń ERP. Otóż listę największych katastrof wdrożeń ERP w 2011:

http://www.computerworld.com/s/article/9222864/10_biggest_ERP_software_failures_of_2011

Otwiera NHS czyli brytyjski odpowiednik naszego NFZ (zdaje się że połączonego z ZOZ). Otóż zawalił się tam projekt dotyczący rekordów wszystkich pacjentów. Ładne określenie tej pięknej katastrofy przez urzędowego audytora („white elefant in the final states of collapse”) znajdziemy:

http://www.computerweekly.com/blogs/public-sector/2011/05/nhs-it-system-condemned.html

Przeglądałem informacje w celu identyfikacji systemu, dostawcy i metodyki. Dostawca jest wymieniony kilka razy – wielka firma telekomunikacyjna, nazwa systemu nic nie mówi, a zastosowaną metodyką była podobno AGILE:

http://www.computerweekly.com/blogs/public-sector/2011/08/agile-in-the-nhs-10-years-5bn.html

– co może świadczyć, że system o którym mowa (BT RIO) był wykonywany „na miarę” – zatem nie jest to system ERP gdyż aktualna definicja mówi, że takim jest standardowy pakiet dostosowywany za pomocą konfiguracji! Z opisu wynika, że to coś jak CRM i administracja personelem robione specjalnie dla NHS – czyli dewelopment! To o tyle istotne gdyż jak już napisałem w pierwszym moim wpisie – ERP jest niemal w 100% wdrażalny, za to projekty dewelopmentu to ruletka.

Szukając dalej znalazłem dokumenty związane z początkiem tego projektu z nazwiskami i uzgodnieniami – muszę przyznać, że robią bardzo dobre wrażenie - i …. popatrzcie sobie sami:

www.southwarkpct.nhs.uk/documents/3076.doc

http://www.swlstg-tr.nhs.uk/_uploads/documents/board-reports-2012/29-march-2012/strategic-and-local-health-economy-issues/10-rio-replacement-soc-v02.pdf

Nie chce wyjść inaczej! Dodatkowo znaleźć można wiele świadectw, że cały management NHS szkolony był intensywnie już od początku roku 2000 w jednej ze wspomnianych na wstępie metodyk (która przecież jest standardem zarządzania w projektach IT w administracji brytyjskiej). Tym razem jak widać „Księciunio Drugi” nie pomógł.

Podkreślam po raz drugi, że nie mam z tego odkrycia żadnej satysfakcji. Zresztą w wielu publikacjach autorzy i mentorzy tych modnych metodyk zastrzegają, że nie są one żadnym automatycznym panaceum na możliwe niepowodzenie. To pokazuje zatem, że z metodykami jak ze wszystkim w biznesie trzeba postępować z głową.

Znalazłem też statystyki projektów pokazujące, że prawdopodobieństwo sukcesu w projektach IT w dobrze już nam znanym NHS jest wyższe w przypadku zastosowania PRINCE2:

http://www.bcs.org/content/conWebDoc/20341

Tym razem nie potrafię powstrzymać wrodzonego sarkazmu i stwierdzić, że statystyki te są z lat sprzed zapadającego się „Białego Śłonia” – po nim statystyki te będą zapewne wyglądać inaczej.

Wracając do wdrażania SAP inną metodyką aniżeli ASAP – można stwierdzić, że skoro tego chce Klient to nie ma siły i po co o tym gadać. A chcą bo pewnie doradzili im tak mądrzy doradcy. Często też uprzedzając to sama firma wdrożeniowa popisuje się, że może wdrażać tymi metodykami. U podstaw tego działania leży przekonanie, że metodyki PMI czy PRINCE2 są jakieś lepsze od ASAP. Wypada zatem zapytać: gdyby tak istotnie było to przecież ASAP zostałby już o to co lepsze zmodyfikowany, jako że metodyki te są dostępne dla każdego. A skoro nie został zmodyfikowany zatem … już to ma.

Kiedyś pojawił się komunikat, że ASAP został „uzgodniony” do PMI. Uważam to za działanie w większości marketingowe bo zgodny był i wcześniej ale niech tam – to formalnie powinno załatwić tą sprawę.

No właśnie i tak dochodzimy do zasadniczej kwestii – ASAP jest zgodny z metodyką PMI i bardzo zbliżony do PRINCE2 (w znaczeniu znacznie uproszczony formalnie a rozbudowany narzędziowo) i stanowi najlepszą metodykę wdrażania SAP!

Analizując tą sprawę nie potrafię dopatrzyć się żadnego sensu we wdrażaniu SAP ERP inną metodyką niż ASAP. Jak wspomniałem referencyjny czas wdrożenia (SAP ERP Benchmark) wynosi 9 miesięcy. Z PMI a szczególnie PRINCE2 czas ten będzie na pewno dłuższy, jako że metodyki są ogólne i zakładają jako etap prac zdefiniowanie wielu podstawowych pojęć – które w ASAP są już zdefiniowane i bardzo dobrze opisane. To wynajdowanie koła od początku musi kosztować czas. Zatem szybciej na pewno nie będzie. Taniej zatem też nie – więc czy istnieje jakaś korzyść? Zobaczymy.

Moje doświadczenia z wdrażaniem SAP ERP zgodnie z zaleceniami metody PMI i PRINCE2 są zdecydowanie złe. Mam tu na myśli projekty w których w całości albo przynajmniej w sposób wyraźnie zauważalny zastosowano ogólne zapisy tych metodyk ignorując zapisy ASAP. Prowadziło to najczęściej do:

1. mnożenia „produktów”
2. hodowania ryzyk
3. gmatwania komunikacji
4. zamazywania odpowiedzialności

Może wynikało to w moim przypadku z faktu, iż z takimi sytuacjami miałem do czynienia na projektach, które „odziedziczyłem” po kimś i już były w mniejszych lub większych kłopotach. Od razu pierwsza refleksja: ASAP jest zrozumiały dla wszystkich specjalistów SAP na całym Świecie zatem jego modyfikacja czy całkowite zastąpienie inną metodyką prowadzi do sytuacji nieczytelnej dla kogokolwiek z zewnątrz, a przecież zmiany w trakcie projektu się zdarzają. Takie zmiany utrudniają również udzielenie z zewnątrz pomocy czy dokonanie oceny sytuacji.

Od razu uprzedzę poszukiwaczy nazw projektów, o których piszę. W moim CV nie ma wymienionych wszystkich projektów w których brałem udział. Właśnie dlatego, że nie o wszystkich projektach można mówić. Projekty naprawiane to przeważnie takie, w których sukcesem będzie doprowadzenie do sytuacji jakiejś formy ugody, z czego do końca nikt nie jest zadowolony i przeważnie nikt o tym nie chce opowiadać. Tak więc piszę to zupełnie spokojny, że ani konkretne sytuacje ani konkretne nazwy czy nazwiska nie zostaną rozpoznane.

W szczególności mam na myśli jeden projekt, w którym brało udział kilka osób co chwilę podkreślających posiadane certyfikaty z PRINCE2. Projekt gdy go zastałem był w dziwnym stanie – w części był niemal gotowy do startu produktywnego czyli rozpoczęcia użytkowania, w innej zaś miał postać zaakceptowanej koncepcji która jednak była podważana i zmieniana. Wyraźnie podkreślam, że dotyczyło to zakresu, który przynajmniej w założeniach miał być uruchomiony razem. Jedną z przyczyn tego stanu rzeczy było rozmnożenie „produktów”. ASAP jasno określa jakie „produkty” mają powstać na koniec którego etapu, jaka jest ich rola, zakres i kto w jakim zakresie za nie odpowiada. Gdy dochodzi do ponownego „odkrycia koła” czyli ustalenia własnym sumptem tych produktów to oczywiście otwiera się pole do popisu dla różnych grup interesów i definiowania własnych produktów. To miało miejsce w tym przypadku. Produkty – nazwijmy je roboczo koncepcjami fragmentarycznymi – jak to bywa z rzeczami, które niby mają się ze sobą zgadzać ale ponieważ powstają w różnym momencie i zatwierdzane są osobno – nie zgadzają się. No i była zabawa!

Do czego zmierzam – otóż do pokazania, że zastosowanie metodyki bardziej ogólnej od ASAP prowadzi do dodatkowego wysiłku w definiowaniu parametrów projektu na poziomie „wykonawczym”, a to z kolei niesie dla projektu ryzyko powstania rozwiązania projektowego unikalnego, które będzie testowane po raz pierwszy na tym właśnie projekcie. Czy o to chodzi?

Warto w tym miejscu przypomnieć jedną z podstawowych zalet systemów ERP, która spowodowała niemal zupełne wyparcie przez te systemy rozwiązań „szytych na miarę”: otóż są to systemy standardowe, które zawierają funkcje odzwierciedlające najlepsze praktyki i których przebieg determinuje się poprzez parametryzację. Znana metodyka ASAP wpisuje się w tą zaletę systemu ERP – jest standardowa i parametryzowalna. Zastępując ASAP inną metodyką „psujemy” właśnie jedną z tych zalet i mocno podnosimy ryzyko iż projekt zejdzie ze swojej drogi i wykroczy poza budżet i/lub termin zakończenia.

Wracamy zatem do pytania „po co to robić” – skoro takie są ryzyka i dodatkowy nakład pracy, to co zatem usprawiedliwia zastosowanie innej metodyki lub poważnego modyfikowania ASAP. Mogą oczywiście wystąpić sytuacje patologiczne, w których jedna ze stron celowo dąży do powstania sytuacji opisanej powyżej, ale to pomińmy. Przyjmijmy, że celem projektu jest jego powodzenie w ustalonym kształcie i że strony biorące udział w projekcie chcą jego powodzenia.

Argumentami za zastosowaniem tych metodyk jest – z takimi się spotkałem – że one kładą duży nacisk na sprawy zaniedbane w ASAP czyli najczęściej zarządzenie ryzykiem i komunikacją. Nie powiedziałbym że ASAP zaniedbuje te sprawy – on ma je stosowanie do ich wpływu i wpisane już w konkretne punkty metodyki i nie trzeba o tym rozmawiać w sensie ustalania polityki zarządzania ryzykami. Skoro ktoś tak uważa i w tym zakresie „implementuje” np. PMI to od razu zaznaczam, że nie widzę aby to samo w sobie powodowało jakieś zagrożenia. Niestety spotkałem się z patologicznym przerostem tego typu „nakładek”.

Były to co prawda pojedyncze sytuacje, ale warte wspomnienia. Na jednym z projektów mimo intensywnego „zarządzania komunikacją” strony nie potrafiły się dogadać i dochodziło do sytuacji gdy na spotkaniach rozmawiano o komunikacji i była ona pięknie sprecyzowana w dokumentach, ale jej samej nie było w sposób odpowiedni na projekcie. Na innym z kolei projekcie prowadzonym przez osoby z certyfikatami w sposób modelowy opisane było w karcie projektu na czym polega i jak ma być prowadzone zarządzanie ryzykami ale … nie chciano ich wpisywać aby nie psuć „pozytywnego obrazu” projektu.

Co do zarządzaniem ryzykiem to czasami przybiera to karykaturalne postacie gdy znaczną część spotkań poświęca się na wymyślanie co może się zdarzyć i co może nie wyjść. Potem profesjonalny kierownik projektu zarządza tymi informacja w ten sposób, że je miarkuje i sumuje i wychodzi mu np. prawdopodobieństwo 50%, że projekt nie uda się. Pisze następnie wypracowanie na ten temat i jest bardzo dumny z tego jakim to profesjonalizmem się wykazał. Takie zarządzani ryzykiem to zwykłe głupoty nie mówiąc już o tym że na pewno ciągłe rozmawianie na ten temat jest demotywacyjne i prowadzi samo w sobie do „wywołania wilka z lasu”.

W tym miejscu rekomenduję wszystkim zwolennikom takiego zarządzania ryzykiem aby sobie przed wyjściem rano do pracy zrobili listę co im się może przytrafić i na tej podstawie niech wyliczą prawdopodobieństwo że nie wrócą z powrotem do domu. Ciekaw jestem z jakim humorem wyruszą w drogę!

W tym celu również przywołam argument wielce obrazowy: wg moich badań projekty wdrożeń SAP ERP, które prowadzone były kilkanaście lat temu (gdy nie były modne metodyki typu PRINCE2, a metodyka SAP nie nazywała się jeszcze ASAP) trwały tyle samo i kończyły się nie mniejszym powodzeniem niż te obecne. Projekty te były w moim przekonaniu obarczone większym ryzykiem od obecnych, ponieważ były to początki i ani SAP ani firmy wdrożeniowe nie dysponowali wtedy w Polsce taką kompetencją i doświadczeniem, jakim dziś dysponują. W tej chwili po setkach projektów pewność powodzenia projektów wdrożenia SAP zbliżona jest do 100% i aby popaść na projekcie w kłopoty trzeba wykazać się naprawdę brakiem rozumu, organizacji albo sporą dawką złej woli.

Muszę też wyraźnie powiedzieć, że nie widzę żadnej przeszkody w sytuacji gdy wdrożenie SAP zgodnie z metodyką ASAP prowadzi konsultant posiadający potwierdzoną certyfikatami kompetencję z metodyk PRINCE2 i/lub PMP. Korzystając z gotowego konspektu prowadzenia projektu jaki daje ASAP na pewno świetnie sobie poradzi.

Zatem podsumowując:

Nie ma żadnego racjonalnego powodu aby wdrożenia systemu SAP prowadzone były wg innej metodyki niż ASAP – co więcej samodzielne modyfikowanie lub zastępowanie metodykami ogólniejszymi typu PRINCE2 czy PMI tworzy dla projektu wdrożenia SAP szereg nowych ryzyk.

Ponieważ jak już wspomniałem ASAP jest metodyką zgodną z PMI można więc śmiało przyjąć, że wdrażając SAP ERP za pomocą metodyki ASAP wdraża się go zgodnie z metodyką PMI. Takie podejście rekomenduję.

Na samo zakończenie chciałbym jeszcze krótko wrócić do tej listy największych katastrof wdrożeń ERP w roku 2011 – w nawiązaniu do moich wcześniejszych wystąpień podejmujących dyskusję z obecnym w mediach nurtem straszenia obecnych i przyszłych użytkowników systemów ERP. Lista ta jest typowym tego przykładem i nawet pobieżna lektura pokazuje kto ma w tym straszeniu interes. Zamierzam przyjrzeć się szczegółowo każdemu z opisanych przypadków jednak już teraz uchylę rąbka: nie wszystkie opisane katastrofy pochodzą z 2011 roku (np. niepowodzenie w Marin County wdrożenia SAP ogłoszono katastrofą już w 2009) i nie wszystkie dotyczą systemów ERP. Wniosek jest prosty: skoro trudno jest ułożyć listę 10 katastrof systemów ERP z jednego roku to biorąc pod uwagę ogrom tego rynku pokazuje „namacalnie” niemal 100% gwarancji powodzenia wdrożeń ERP. Warto to szczególnie zestawić z wymienionym powyżej materiałem dotyczącym statystyk porażek szeroko pojętych systemów IT w NHS.

Bardzo ciekawe spostrzeżenie znalazłem w materiale analizującym „katastrofy” wdrożeń ERP:

http://www.r3now.com/sap-erp-project-failure-lessons-learned-and-mini-case-studies-1/

Pozwolę sobie zacytować fragment: