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”….