Listę największych katastrof 2011r znajdziemy na stronie: http://www.computerworld.com/s/article/9222864/10_biggest_ERP_software_failures_of_2011

Przypomnę, że pierwszy z listy projekt wdrożenia w NHS czyli brytyjski odpowiednik naszego NFZ ewidencji rekordów wszystkich pacjentów (nazwany przez audytora („white elefant in the final states of collapse”) okazał się nie być projektem wdrożenia ERP tylko tzw. dewelopmentem czyli rozwiązaniem „szytym na miarę”. Ponieważ był to projekt w administracji brytyjskiej nie zdziwiło mnie odkrycie, iż był on zarządzany metodyką PRINCE2. Opisałem to w poprzednim wpisie.

Można śmiało zaryzykować twierdzenie, że wdrożenie to zgodne było z PRINCE2 tylko z nazwy (co nosi z kolei określenie PINO – czyli „PRINCE2 by Name Only”). Jest obecnie sporo materiałów opracowanych przez mentorów PRINCE2 (podobnie jak i PMI) opisujących złe zastosowania tych metodyk. Przykładem mogą być opracowania Nico Viergewera:

http://www.viergever.info/en/prince2principle.aspx

Zwracam uwagę na to, że w jednym z tych materiałów pisze on, iż PRINCE2 przeznaczony jest do kontrolowania projektów przez ODBIORCÓW, a stosowanie go przez DOSTAWCÓW (w tym wewnętrznych, którymi są zazwyczaj działy IT) jest błędem. Tak czy siak w przypadku NHS istnieje wiele materiałów świadczących o tym, że kierownictwo tej instytucji było długo i wszechstronnie kształcone w tej metodyce. Tak więc w tym przypadku kontrola projektu była po właściwej stronie.

Następnym (drugim) na liście jest projekt wdrożenia systemu City Time w Nowym Yorku. Jest to system naliczania płac i ponownie mamy tu z sytuacją gdy nie jest to system ERP tylko system wykonywany „na miarę”.

Zresztą konieczna jest tu dygresja, że jakkolwiek systemy naliczania płac są (czy bywają) w zakresie systemów ERP, ale ich natura jest zupełnie odmienna zarówno wdrożeniowo jak i użytkowo, co raczej kwalifikuje je do uznania jako osobny komponentów podobnie jak systemów CRM czy BI. System płacowy to z grubsza biorąc jedna funkcja, ale za to bardzo skomplikowana i nawet w nowoczesnych systemach ERP działająca nie w czasie rzeczywistym - w dodatku „wsadowo”. Wdrażanie płac rządzi się swoimi prawami i jest czymś pośrednim pomiędzy pisaniem programu komputerowego i parametryzacji.

Powyższe powoduje, iż bardzo często program ERP integrowany jest z obcym programem naliczania płac – najczęściej już wcześniej używanym. Utrudnia to z pewnością administrowanie całym systemem, ale z punktu widzenia istotnych parametrów systemu ERP bywa kompromisem akceptowalnym (często zresztą tymczasowym) - nie upośledza bowiem samych podstawowych zasad ERP.

Wracając do tematu zauważamy, że po dziesięciu latach projekt City Time „zadziałał” a budżet przekroczony został dziesięciokrotnie:

http://online.wsj.com/article/SB10001424052702304520804576341880233533122.html

Jest to zresztą sprawa kryminalna i dostawca skazany został przez sąd na odszkodowanie:

http://cityroom.blogs.nytimes.com/2012/03/14/company-in-citytime-payroll-scandal-to-pay-500-million/

W jeszcze ciepłym materiale znajdziemy sformułowanie „corrupted to its core…”. Jeden z zastępców burmistrza zapowiedział przygotowanie raportu w tej sprawie lecz poszukiwania tego raportu zaprowadziły mnie z kolei do informacji, że został on aresztowany – zdaje się że w sprawie prywatnej. O ile dobrze zrozumiałem miał powiedzieć żonie w trakcie kłótni, że już dawno powinien był ją zastrzelić… Nie analizowałem tej sprawy dalej jako że awantury rodzinne uczestników projektów leżą poza zakresem mojego zainteresowania.

Osobom przekonanym co do „wyjątkowości” naszej sceny politycznej i administracji polecam jednak lekturę gdyż okazuje się, że administracja amerykańska nie tylko dorównuje naszej, ale nawet ją przewyższa w produkowaniu sensacyjnych zdarzeń.

Następny w kolejności jest były pracownik dostawcy – też aresztowany ale już konkretnie za defraudację:

http://cityroom.blogs.nytimes.com/2011/05/27/consultant-on-payroll-project-is-arrested/

Niezawodnie firma Panorama Consulting Services odgrzewa tym przypadkiem „straszaka” na firmy wdrażające ERP choć przyznaje sama, że płace to zazwyczaj bywa część systemów ERP – zadziwiający profesjonalizm, że pod jednoznacznym tytułem przyznają, że być może przedmiot artykułu nie odpowiada tytułowi:

http://panorama-consulting.com/lessons-from-new-york-city-the-risks-and-benefits-of-hiring-outside-erp-consultants/

Jako niezależny konsultant również uważam, że odbiorcy systemów powinni zatrudnić zewnętrznego specjalistę (kierownika projektu) do kontroli jego przebiegu, ale nie uważam by straszenie „na oślep” jak to robią takie firmy było właściwe. Na tym kończę analizę użytej metodyki gdyż niczego w tej sprawie nie mogę znaleźć – skierowałem w tek sprawie zapytanie do dziennikarza zajmującego się tym tematem i jeżeli odpisze na pewno poinformuję.

Trzecie na liście jest wreszcie wdrożenie ERP mianowicie SAP w firmie Ingram Micro (w skrócie IM). No i co my tu mamy – skoro wreszcie dotarliśmy do katastrofy systemu ERP musimy dokładnie zbadać sprawę. Otóż powodem umieszczenia na liście Computerworld jest spadek zysku netto za 1Q2011 (rok do roku) o około 20% (o 14 milionów USD) ogłoszony w kwietniu 2011. Co gorsza niższe też były o ok. 12% wyniki za 2Q2011 co z kolei spowodowało odłożenie projektu w Brazylii.

http://www.itworld.com/software/188057/sap-project-issues-hurt-ingram-micro-profits-again

Na co warto zwrócić uwagę to, że we wszystkich tych materiałach od razu padają zapewnienia, że problemy już są rozwiązanie i emanuje z nich przekonanie, że to poświęcenie jest konieczne dla przyszłości. Niestety patrząc na kurs akcji spółki stwierdzam, że od kwietnia 2011 nie zbliżył się nawet do osiągniętej wtedy wartości pomimo iż indeksy giełdy NYSE są obecnie wyżej od poziomów w roku 2011. kurs IM po spadkach w ostatnim kwartale jest obecnie niżej o około 25% od tego w kwietniu 2011, a dotąd trzymał się nawet nie najgorzej. Jakiś problem więc jest. Przyjrzyjmy się tej sprawie.

Analizując historię wdrożenia:

http://www.crn.com.au/News/245382,ingram-plans-minimal-disruption-in-sap-upgrade.aspx stwierdzam, że wdrożenie realizowane było ostrożnie, co uzasadniał biznes w którym firma działa – sprzedaż hurtowa sprzętu elektronicznego na wielką skalę. Wdrożenie prowadzone było w postaci faz terytorialnych (co można nazwać też pilotażowo) od roku 2009 i wcześniejsze wdrożenia w Singapurze i Nowej Zelandii zakończyły się powodzeniem. Dopiero 12 miesięczne wdrożenie w Australii zakończone startem 31 stycznia przyniosło w efekcie zakłócenia.

Co ciekawe powyżej załączony materiał datowany na 19 stycznia ostrzega przed „minimalnymi” zakłóceniami – zatem ich wystąpienie nie było zaskoczeniem. Z materiału tego dowiadujemy się że zakłócenia oczekiwane są w interfejsie do portalu dla partnerów Techlink w związku z konieczną kilkudniową przerwą w jego funkcjonowaniu. Informowanie o tym klientów rozpoczęto przed Bożym Narodzeniem w 2010r.

Czas na małe podsumowanie – w 1Q2011r nie ma mowy o żadnej katastrofie tylko o planowanych zakłóceniach, których jak z tego wynika nie dało się uniknąć. Swoją drogą ciekawe dlaczego nie można było uniknąć wprowadzając dostęp do nowego portalu równolegle ze starym. Prawdopodobnie skala zmian indeksowania towarów i w ogóle przetwarzania danych uznana została za zbyt daleko idąca.

Skala spadku zysku zaskakuje bo 20% trudno nazwać „niewielkimi zakłóceniami” ale zastanówmy się co się mogło stać. Popatrzmy zresztą na wszystkie parametry finansowe działalności IM w latach 2010 i 2011 (z raportu finansowego):

Jak sądzę wielu klientów (czyli sklepów) ostrzeżonych o zbliżających się zakłóceniach i przerwie w działaniu portalu (w trakcie której zamówienia można było składać „tradycyjnie”) zakupiło więcej towarów w kończącym się kwartale. To zdaje się widać w wynikach 4Q2010. Jednak co zadziwiające zarówno sprzedaż jak i zysk brutto w kwartałach 1 i 2 roku 2011 są wyższe niż rok wcześniej - o jakich zatem zakłóceniach może być mowa skoro biznes „szedł” lepiej niż rok wcześniej? Toż widać wyraźnie, że przychód netto został „pogrążony” przez inne koszty. Otóż to: moim zdaniem mamy tu do czynienia z sytuacją gdy wdrożenie ERP stało się wygodą wymówką gorszego wyniku netto (istotnego dla akcjonariuszy) który spowodowały inne przyczyny niż biznesowe. Podsumujmy:

• wdrożenie w Australii zakończyło się planowo
• wprawdzie w raportach finansowych mowa jest o zakłóceniach większych niż się spodziewano ale dane finansowe tego nie potwierdzają
• wszyscy są zadowoleni – czyli raczej wygląda, że wdrożenie SAP było przykrywką dla jakichś innych kosztów, które przypadły w tym czasie – np. zaksięgowano koszty usług wdrożeniowych SAP i może udało się zamortyzować szybciej koszty licencji?

Na zakończenie o użytej metodyce. Nie dotarłem do żadnego materiału z którego wynika jaką metodyką było prowadzone wdrożenie znalazłem natomiast wiele osób certyfikowanych z PMI chwalących się udziałem w Tym projekcie. Znalazłem też materiały świadczące o tym, że kierownictwo IM jest aktywne w społeczności specjalistów PMI udzielając się w postaci odczytów na konferencjach i kolacjach. Zatem należy przyjąć że w IM wdrożenie prowadzone było z zastosowaniem zasad obowiązujących w PMI przy czym skoro doszliśmy do konkluzji, że nie może tu być mowy o żadnej katastrofie trzeba przyjąć że w tym przypadku zasady PMI zostały zastosowane właściwie.

Sporo mnie pracy kosztowały te analizy i jak na razie na trzy pierwsze trzy przypadki wyszło, że dwa nie dotyczą wdrożenia ERP, a w trzecim nie ma żadnych podstaw do nazywania tego katastrofą. Zobaczymy co będzie dalej.