Artykuł jaki ukazał się w COMPUTERWORLD skłonił mnie do konfrontacji moich doświadczeń i obserwacji z jego treścią, uwagami innych doświadczonych specjalistów. Być może warto pokusić się o pewne wnioski i sugestie…

Wina klienta

Według niego większość firm nie jest przygotowana na wdrożenie systemu ERP. „Firmy generalnie nie radzą sobie ze zmianami. Tymczasem wdrożenie systemu ERP pociąga ich za sobą nadzwyczaj dużo. Poza tym wiele organizacji ma problemy z odpowiednim definiowaniem procesów biznesowych. To właśnie te firmy będą miały największe problemy w uzyskaniu wymiernych korzyści z posiadanego systemu” – mówi David Bergen, były szef informatyki w firmie Levi Strauss, który uczestniczył w realizacji kilku projektów wdrożenia systemu SAP. Na to nakładają się również problemy wynikające z nadmiernie rozdmuchanych wyobrażeń dotyczących wdrażanego rozwiązania. Nierzadko handlowcy – po stronie producenta systemu lub bezpośredniego dostawcy – kreślą przed przyszłymi użytkownikami oprogramowania wizje trudne lub wręcz niemożliwe do zrealizowania w praktyce. Ponadto takie działania sprzyjają sztucznemu rozdmuchiwaniu zakresu funkcjonalnego oprogramowania.¹

Zmiany w organizacji

Tu pewna ciekawostka, moim zdaniem pewien paradoks: specjaliści od wdrażania zmian w organizacjach, psycholodzy biznesu także, zgodnie twierdzą, że zmiana mentalności pracowników i tak zwana dojrzałość organizacji (poziomów dojrzałości)  to proces na trzy do pięciu lat. Przeciętny zintegrowany system ERP to setki funkcjonalności, nauka na lata. Jak więc traktować obietnice dostawców oprogramowania, że wdrożą cały system ERP w rok a nawet w kwartał? Gdy patrzę na niektóre wdrożenia to nie raz mam wrażenie, że wdrażającym jest kierownik projektu i prawnik perswadujący zakres prac wykonanych i zafakturowanych, a nie faktyczne „przyjęcie” nowych narzędzi przez kupującego. Nie raz kolejny etap jest zrealizowany nie dlatego, że kolejne moduły są używane a raczej dlatego, że zostały dostarczone.

Procesy biznesowe

To kolejna choroba wdrożeniowa, niestety zamawiających: wierzą, że to nie oni, jako odbiorcy będą ciężko pracować. Problem w tym, że ktoś musi wiedzieć jak pracuje firma, bez tego nic się tak na prawdę nie wdroży. Modelowanie procesów biznesowych to nic innego jak opisanie tego jak pracuje firma: co i po co się robi. Daleko temu do stwierdzenia „to jest nam potrzebne”.  Niestety model procesów biznesowych nie suchym obrazkowym zapisem opowiadań tego „co i jak robimy”, to nie jest zapis stanu faktycznego, jednego (wielu) z nieskończonej ilości wariantów. Tak powstaje stenogram. Model procesów biznesowych to specyfikacja (mapy) tego co i po co powstaje (produkty). Opis taki (model) należy uzupełnić o reguły biznesowe, by uchwycić w tym gąszczu działań te istotne oraz faktyczny sens działań a nie tylko ich aktualny sposób realizacji (który raczej się zmieni po wdrożeniu).

Taki model powinien powstać dla całej firmy przed wdrożeniem jakiegokolwiek oprogramowania wspomagającego zarządzanie. Podstawowym powodem modelowania jest zrozumienie kontekstu wdrożenia oraz możliwość oceny jego wpływu na resztę firmy.

Oferta przerasta rzeczywistość

No cóż, często słyszę od firm programistycznych narzekania, że klienci w ramach specyfikacji wymagań, serwują im stek „pobożnych życzeń”. Jak wobec tego nazwać ofertę dostawcy systemu ERP wysłaną w odpowiedzi na takie zapytanie? Po prostu tak samo: jako nadużycie celowe lub niezamierzone, wynikające z niewiedzy.

Wina integratora

Większość prac bezpośrednio związanych z wdrożeniem systemu biznesowego spada na firmę wdrożeniową. W nieunikniony sposób od zaangażowania i kompetencji konsultantów zależy powodzenie całego projektu. Tymczasem najważniejsze zarzuty adresowane w ich kierunku dotyczą: nieznajomości oprogramowania, które mają wdrażać, nieznajomości podstaw funkcjonowania systemów klasy ERP i słabej organizacji pracy. Ostatni zarzuty jest bezpośrednio związany z klasycznym modelem zakładającym godzinowe rozliczanie pracy konsultantów. W rezultacie, z punktu widzenia integratora, najbardziej opłacalne jest kierowanie do prac wdrożeniowych najmniej doświadczonych konsultantów. Ten konflikt interesów często odbija się negatywnie na relacjach między klientem, a dostawcą oprogramowania.¹

Niskie kompetencje wdrażających konsultantów to niemalże klasyka. To często częsty grzech dostawców, uważających, że zawarta umowa i stosowna liczba dość dobrze opisanych „milstonów” do „zaliczenia” i zafakturowania pozwala zaangażować do projektu początkujących (tanich) konsultantów, potrafiących jednynie pracowicie realizować te „milstony”. To się niestety nie udaje.

Kontrakty „czas i materiał”

To kolejna choroba projektów IT: „pracujemy aż skończymy”. Często klient sprawy sobie nawet nie zdaje, że zawierając taki kontrakt w zasadzie traci panowanie nad nim i jego budżetem. Owszem, to ładnie brzmi: „Państwo poznali nasze kompetencje i wierzą, że warto za nie płacić”.  Kolejnym, należy powiedzieć jasno kłamstwem, jest teza: „Państwa wymagania nie są możliwe do zdefiniowania,  dlatego będziemy opracowywali kolejne prototypy aż wdrożymy potrzebne oprogramowanie”.

Cóż, jeżeli nie są znane wymagania to sygnał, że niepotrzebny jest ten program (system).

Na zakończenie

„Do wyboru firmy wdrożeniowej należy podchodzić jak do procesu rekrutacji nowych pracowników. W ramach analizy ofert warto choćby porozmawiać z kadrą zarządzająca i kierownikami zespołów wdrożeniowych oraz przeanalizować, a najlepiej także potwierdzić u źródła ich referencje” – twierdzi Greg Hatch z firmy konsultingowej Alvarez & Marsal Business Consulting.¹

Po pierwsze: należy dobrze poznać własną firmę zanim cokolwiek, nie tylko wdrożymy, zanim podejmiemy decyzje by cokolwiek wdrażać.

Po drugie: należy wdrażać (kupować) system w „kawałkach” po 20-50 funkcjonalności zamykających się w kilku całych procesach biznesowych (a nie działach czy pionach), zamiast setek funkcjonalności wraz z całym systemem ERP za jednym zamachem.

Po trzecie: z czystego bezpieczeństwa projektu i zarządzanie ryzykiem – wymagania (a konkretnie specyfikacja tego co ma zostać dostarczone) i nadzór nad ich realizacją, to nie jest praca ani dla dostawcy ani dla kupującego, pierwszy najprawdopodobniej będzie koloryzował swój produkt a drugi posłuży się stereotypami.

W wielu organizacjach pojawia się zjawisko zwane Citizen Developer. Jest to tak zwany „Programista obywatelski”, pracownik, który tworzy aplikacje do użytku przez siebie lub innych, korzystając z narzędzi, które nie są aktywnie zabronione przez dział IT lub jednostki biznesowe (bardzo często jest to MS Excel i MS Access, od pewnego czasu Pyton). Początkowo ich praca może przynosić drobne lokalne korzyści, jednak w dłuższej perspektywie stanowi poważne zagrożenie dla bezpieczeństwa informacji i spójności danych w organizacji. Takie osoby często wnoszą swoje pomysły jako wymagania dla systemów ERP, kierując się emocjami, w efekcie doprowadzają często do poważnych kłopotów.

Co robić?

Tak jak w branży budowlanej: podzielić projekt na kilka etapów, każdy traktować jak analizę wykonywalności, dopuścić zarzucenie projektu na każdym z tych etapów. Aha, i zlecić projekt zewnętrznej firmie (tu biuro projektowe) niezwiązanej ani z przyszłym (nie powinien być nawet znany) dostawcą ani z pracownikami zamawiającego (z wielu powodów).