Przypomnę na początek co prawie dwa lata temu napisałem:

Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że ?z kompletu? przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ? ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża).

Tak więc jednak polecam: zastanowić się nad potrzebami, zamówić wykonanie analizy i dokumentacji wymagań i z tym dokumentem szukać dostawcy i nie dać wcisnąć sobie teorii, że duży może więcej?. Możliwe ale nie zapominajmy, że duży to także bezwładny (polecam cały artykuł: Nigdy więcej ERP w jednym kawałku!)

No i mamy obecnie:

Przedstawiciele co trzeciej brytyjskiej firmy (35 proc.) przyznają, że byliby skłonni zastąpić wykorzystywany obecnie system klasy ERP bardziej elastycznym rozwiązaniem o podobnej funkcjonalności. (źr.  Czego najbardziej brakuje systemom klasy ERP?)

Nasuwa się pytanie: czym je zastąpić? Leży właśnie na moim stole książka ([[Large-Scale Software Architecture. A practical guide using UML. Jeff Garland, Richard Anthony]]). I co my tu mamy? Przede wszystkim opinię i wskazówki doświadczonych projektantów i developerów.

Książka jest tak “dobra”, że w zasadzie można ją w kawałkach zacytować od dechy do dechy. Jednak i nie chce i nie można tego robić :). W czym rzecz?

Duże oprogramowanie to nie jeden system

I tu leży pies pogrzebany. Kolejność zalecana przez autorów książki za każdym razem, niezależnie od wielkości projektu:

1. analiza i określenie celu projektu
2. analiza biznesowa, opracowanie wymagań
3. projekt architektury rozwiązania (ogólny model dziedzinowy), podział na komponenty (obszary dziedzinowe)
4. okreslenie, które komponenty (podsystemy) należy wytworzyć, a które można kupić na rynku (tak zwane COTS, ang. [[Commercial off-the-shelf]])
5. sprawdzenie dostępności i kosztów
6. opracowanie wynikowego projektu i wymagań na podsystemy dedykowane.

Praktyka pokazuje, że jednym z takich dużych COTS może być (i często jest) system ERP (jego wybrana część). Najczęściej moduły produkcji, księgi głównej, kadrowe itp. Jednak zarządzanie sprzedażą czy specyfika procesów wewnątrz organizacji to coś co spędza sen z powiek dostawców ERP bo to zawsze “nie pasuje”. Największym zaś, w moich oczach, nadużyciem ofert na ERP jest twierdzenie, że wspomagają zarządzanie procesami biznesowymi. Bo jeśli pomagają zarządzać dokumentami, co jest prawdą, to raczej nie są w stanie konkurować z systemami work-flow bo to zupełnie innego rodzaju systemy i nie przypadkiem powstały jako oddzielne rozwiązania. Do tego dokumenty finansowo-magazynowe to mniejsza część wszystkich dokumentów w firmie, więc dlaczego ERP miał by być tu “dobry”? A hurtownie danych? To także nie przypadek, że są osobnymi systemami. Dostawcy ERP permanentnie używają akronimu Moduł BI w swoich ofertach zaś cichaczem oferują dedykowane systemy BI i integrują je.

Tak więc najczęściej okazuje się, że niestety główną wadą systemów zintegrowanych ERP jest to, że są zintegrowane (czytaj niepodzielne) co już nie raz tu pisałem i wychodzi, że nie ja jeden.

W ubiegłym roku skończyłem projekt dla firmy [[Galeco Sp. z o.o.]]. W dużym uproszczeniu projekt wyglądał tak:

1. Analiza biznesowa: model biznesowy, optymalizacja procesów, określenie kluczowych czynników sukcesu,
2. Określenie wymagań na oprogramowania w kontekście kluczowych czynników sukcesu.
3. Opracowanie architektury systemu informacyjnego Galeco.
4. Wskazanie miejsc, w których można użyć gotowego oprogramowania
5. Zaprojektowanie wymagań na oprogramowanie (podsystemy itp.), które są potrzebne Galeco a nie są dostępne jako gotowe na rynku.

I ta własnie kolejność jest lepsza. Pozornie to samo osiągniemy gdy wpuścimy dostawcę systemu ERP i on po analizie powie czego (jakich wymagań) jego system nie realizuje. Jednak:

1. Dostawca gotowego systemu nie ma żadnej motywacji (wręcz przeciwnie) do wskazywania innych niż swoje rozwiązań (stąd permanentnie pojawiają się w ofertach i projektach tak zwane kastomizacje, które są powszechnie oferowane przez sprzedawców a odradzane przez producentów tego oprogramowania ERP).
2. U dostawcy ERP natychmiast pojawia się syndrom młotkowego: jak ktoś ma w ręku młotek natychmiast wszystko co zobaczy kojarzy mu się z gwoździem.

Wystarczy odwrócić kolejność działań: zamiast wybierać dostawcę ERP, który powie na czym wymięka jego system, warto najpierw zaprojektować całość a potem popytać kto i w czym czuje się świetnie. Tu jednak pojawia się problem: dostawca gotowego systemu nie zarobi na kastomizacji ale chyba o to chodzi by było od razu dobre a nie w nieskończoność dostosowywane.

Dlaczego producenci odradzają (metodyki zalecane przez producentów nie stosowane w Polsce!) ingerencje w ich gotowe oprogramowanie? Bo taka ingerencja odcina natychmiast użytkownika od możliwości wykonania prostego upgrade’u! Kolejna, nowa wersja systemu wdrożonego z tak dużym trudem (i kosztem) kastomizacji wymaga kompletnego projektu od zera, powtórzenia od początku całej pierwotnej pracy nad wdrożeniem.

Jak tego uniknąć? To proste, posłuchać producentów oprogramowawszy ERP:

1. Opracować własne wymagania.
2. Dać dostawcom systemów ERP by wykonali tak zwaną analizę gap/fit (co nasz system ma a czego nie ma).
3. Wybrać najkorzystniejszą ofertę, wdrożyć system szybko (bo bez kastomizacji).
4. Zaprojektować brakujące funkcjonalności i zamówić ich implementację, zintegrować z dostarczonym ERP.

Teraz upgrade ERP to proste wgranie nowej wersji (no prawie ale o niebo łatwiej i taniej!) Po drugie nie narażamy się na presję dostawcy ERP i nie uzależniamy od niego w 100% (zjawisko określane jako ‘vendor lock-in’. Tak zaprojektowany system staje się systemem otwartym, pozwalającym wymienić lub dodać funkcjonalności bez ingerencji w pozostałe. I niezależnie od tego jak “uniwersalny” jest system ERP zawsze będzie gorszy od kilku dobrze dobranych ale niezależnych komponentów. Gorszy nie dlatego, że “brzydszy” ale dlatego, że będzie kulą u nogi firmy, która powinna jednak reagować na zmiany na rynku w ciągu tygodni a nie lat… Po drugie modyfikacja jakiegokolwiek oprogramowania zawsze wymaga testowania całości, tak więc im mniejsze kawałki mamy tym szybciej i taniej wprowadza się do nich zmiany bo ich oddanie do użytku po modyfikacji jest łatwiejsze i szybsze zarazem.

Pamiętajmy pewną starą reklamę: “Banki od wszystkiego są do niczego”….

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).