Od czasu do czasu pojawiają się w sieci wołania będące czymś co ja nazywam anty referencjami. W większości znanych mi przypadków jest to wina dostawcy, który:

1. zobowiązał się do realizacji wymagań nie testując ich wykonalności,
2. zobowiązał się do wdrożenia oferowanego rozwiązania bez wykonania (posiadania) rzetelnego audytu biznesowego (komputeryzacja bałaganu) u klienta.

Tłumaczenia w rodzaju „bo klient nie wie czego chce” są jedynie wyrazem niekompetencji dostawcy w obszarze analizy przed-wdrożeniowej.

Oto przykład takiego „wołania” z Lipca 2016 i próba wyjaśnienia tych zgłoszonych problemów (z oczywistych powodów zanonimizowane).

Od sierpnia 2014 r. moja firma – jako Zamawiający jest beneficjentem dofinansowania UE PARP 8.2 PO IG – działanie 8.2 i co za tym idzie kompleksowego wdrożenia oprogramowania XXX klasy ERP dostarczonego przez XXX. Za wdrożenie oprogramowania odpowiedzialna jest firma XXX, której zespół do dnia dzisiejszego zmaga się z wdrożeniem oraz jego skutkami technicznymi i ekonomicznymi.
Poniżej załączam główne techniczne problemy, z którymi spotkaliśmy się podczas wdrożenia XXX:…

Architektura monolitycznych systemów ERP

Zanim jednak przystąpimy do wyjaśnień, kilka słów o architekturze monolitycznych systemów ERPII (taki jest tu wdrażany). Używam tu nazwy monolit, gdyż mimo deklarowanego podziału na moduły, tych systemów, są one monolitem zbudowanym na jednej współdzielonej bazie danych. To co nazywane jest tu modułem, to wydzielone lecz nie rozłączne, elementy logiki biznesowej. Poniżej uproszczona architektura systemu ERP dla firmy produkcyjnej (uproszczenie dotyczy wyłącznie gradacji i ilości modułów systemu ERPII).

Na diagramie po lewej pokazane są podsystemy dziedzinowe, które praktycznie nie występują w oferowanych na rynku ERP. Prawa strona to typowa architektura monolitycznego system ERPII. Jej kluczowe cechy  to:

1. jedna monolityczna baza danych zawierająca znormalizowaną logikę związków między danymi i i ch współdzielenie,
2. moduły dziedzinowe zawierające wyłącznie logikę przetwarzania tych danych,
3. jednolity interfejs użytkownika.

Ważna, rzecz: Rachunkowość finansowa to szkielet bazy danych (dowody księgowe i pozostałe zdarzenia gospodarcze). Taka architektura powoduje, że:

1. moduły obsługujące zdarzenia gospodarczej (co najmniej rachunkowość, magazyny)  są obligatoryjne, czyli zawsze muszą być wdrożone i zawsze jako pierwsze),
2. pewne elementy logiki są niemodyfikowalne (logika związków pomiędzy danymi jest w centralnej bazie danych, ta zaś jest praktycznie niemodyfikowalna),
3. modyfikowanie logiki związanej z przetwarzaniem danych wymaga ingerowania w skomplikowany kod istniejących modułu, skutki tych zmian mogą się przenosić na pozostałe moduły (poprzez współdzielone dane),
4. współdzielenie danych (np. pomiędzy zamówieniem a fakturą) powoduje, że zmiany w zasadniczej treści dokumentów i ich logika są praktycznie niemożliwe,
5. możliwe tworzenie (modyfikowanie) nowej logiki biznesowej jest ograniczone do tego, co nie koliduje z modelem danych w centralnej bazie danych.

To tylko kluczowe ograniczenia. Większe wdrożenia nie unikną integracji z uwagi na to, że takie funkcjonalności jak PLM (zarzadzanie cyklem życia produktów), MES (monitorowanie produkcji) czy APS (Advaced Planing System) nie są dostępne w ramach ERPII, więc bardzo często nie jest prawdą, że sam system ERPII wystarczy.

Skutki kastomizacji

Popatrzmy teraz na zgłaszane problemy:

– wada niestabilnych cen zakupu towarów, błąd ceny zejścia towaru na WZ, błędne ceny na przesunięciach i przyjęciach na magazyn, błąd – ceny wydania i przyjęcia na magazynach MM minus / MM plus. Przykładowo ten sam towar po przesunięciu na inny magazyn z niewiadomych przyczyn zmienia swoją cenę zakupu. Wada związana z błędnymi cenami nie pozwala na prawidłowe ustalenie wartości poszczególnych magazynów firmy
– wada sald kontrahentów związana z podawaniem błędnej wysokości zadłużenia klienta,
– wada niestabilnego obszaru raportów ? raporty tworzone według tych samych parametrów przedstawiają różne dane, przykładowo 3 raporty dotyczące stanu tego samego magazynu przedstawiają 3 różne kwoty,

Są to najprawdopodobniej efekty tego, że ingerencja w logikę poszczególnych modułów spowodowała błędy. Związki między dokumentami magazynowymi i ich ewentualne współdzielenie z innymi (np. PZ, MM, WZ) są wbudowane w bazę danych, wyliczenia zaś tkwią w modułach dziedzinowych.

Zmiany wprowadzane lokalnie w poszczególnych modułach mogą burzyć logikę modułów współdzielących te dane. Kolizja wyliczeń i logiki danych w bazie danych z reguły wpływa destrukcyjnie na raporty z tych danych.

Powyższe braki i wady nie wyczerpują długiej listy problemów (ok. 200) spowodowanych moim zdaniem niskim przygotowaniem merytorycznym specjalistów z centrali XXX oraz z firmy wdrożeniowej XXX.

Naszym głównym problemem w pracy na oprogramowaniu XXX, wielokrotnie przejawiającym się w ciągu kilku ostatnich miesięcy, jest brak stabilności oprogramowania, w szczególności w podstawowych modułach jakimi są Sprzedaż i Zarządzanie Zapasami. Jedna z najważniejszych wad oprogramowania manifestuje się zjawiskiem niekontrolowanej zmiany cen towarów w różnych lokalizacjach magazynowych, objawiającym się zwiększaniem lub zmniejszaniem cen bez żadnego logicznego powodu.

Powyższe potwierdza skutki ingerencji opisane powyżej.

Prace mające na celu usunięcie tej wady nie przyniosły dotąd spodziewanych efektów, pomimo zaangażowania w nie również producenta oprogramowania. Doraźne naprawy nie pozwalały na korektę narosłych wcześniej błędów w księgowości firmy. Straty firmy polegają m. in. na błędach w stosowanej marży – utracie klientów lub zysku, konieczności prowadzenia ciągłych i absorbujących inwentaryzacji, błędach wysyłek, dodatkowych kosztach pracy, co wprost przekłada się na spadek obrotów oraz wzrost kosztów działalności.

Obawiam się, że powyższe problemy są nie do rozwiązania. Nieprzemyślana (a nie raz po prostu niemożliwa do wykonania) tak zwana kastomizacja, to nic innego próba bezkarnego wprowadzania lokalnych zmian do kodu liczącego nie raz miliony linii.

Moim zdaniem oprogramowanie XXX nie zostało prawidłowo przygotowane do wprowadzenia na rynek polski. Po zainstalowaniu okazało się, że oprogramowanie nie posiada szeregu funkcjonalności przyjętych jako standardowe, nawet w programach niższej klasy. Przykładowo XXX w module F-K nie posiada szeregu zestawień wymaganych do prowadzenia księgowości, a wypadku H-M np. prawidłowego zestawienia stanów magazynowych towarów wraz z ich cenami na poszczególnych magazynach, z których w sposób łatwy może skorzystać handlowiec.

Tu uwaga dot. zamawiającego: niestety nie ma czegoś takiego jak „funkcjonalności przyjęte jako standardowe”, co najwyżej standardem może być zgodność (niekolidowanie) z odpowiednimi przepisami (np. o rachunkowości). Bardzo często to Zamawiający jest sam sobie robi krzywdę, uważając że coś jest oczywiste, niestety nie ma rzeczy oczywistych.  

Jeżeli Zamawiający uważa, że analiza biznesowa przed wyborem i wdrożeniem systemu ERPII jest zbędna lub, że wykona ją poprawnie dostawca po zawarciu umowy, to niestety szuka kłopotów. 

Poważnym problemem utrudniającym rozwiązanie trudnej sytuacji Zamawiającego są próby uniknięcia odpowiedzialności za produkt ze strony producenta XXX, który powołując się na zapisy umowy licencyjnej stanowczo odrzuca odpowiedzialność za wady produktu. Zamiast rzeczywistych napraw ww. wad, moja firma otrzymuje jedynie deklaracje, mówiące o ?podchodzeniu ze zrozumieniem do problemów? i ?gotowości do pomocy?.

Niestety po podpisaniu umowy i producent i dostawca oprogramowania mają prawo się na te umowę powoływać. Odpowiedzialność producenta jest wyłączona już po pierwszej ingerencji w kod, udane kastomizacje są z reguły niemożliwe z powodów wyżej opisanych. Kupujący niestety także ponosi odpowiedzialność za swoje działania. Co prawda może i należy oczekiwać od dostawcy tak zwanego pełnego profesjonalizmu, jednak życie uczy, że to także należy sobie zapewnić w umowie.

Produkt wprowadzony do sprzedaży i użytkowania powinien być wyposażony w funkcjonalności wymagane na polskim rynku oraz stabilne podstawy programistyczne, które powinny gwarantować trwałość wprowadzonych danych i rzetelność generowanych raportów i analiz. Niestety XXX nie okazał się rzetelnym, i co najważniejsze, wiarygodnym narzędziem służącym zarządzaniu wszystkimi procesami przedsiębiorstwa.

Tu niestety łyżka dziegciu znowu do beczki kupującego: po „wyjęciu z pudełka”, praktycznie każde oprogramowanie pracuje poprawnie. W ogromnej większości przypadków to próby jego „dostosowania” powodują skutki jak wyżej opisane. Wdrożenie powinno mieć dwa etapy: testy wersji standardowej, wdrożenie, testy wersji wdrożonej. Bez tego praktycznie nie ma prawnej możliwości eskalacji żądań naprawy błędów powstałych w toku kastomizacji (czyli ingerencji w kod aplikacji).

Jak uniknąć kłopotów?

Wdrażanie monolitycznych systemów ERP samo w sobie nie jest niczym złym.  Powinno ono, wdrożenie, być jednak poprzedzone wnikliwą analizą uwzględniającą strategię firmy, ewentualne usprawnienia i zmiany organizacyjne, zmienność otoczenia rynkowego danej firmy. Poprzedni niedawny artykuł kończyłem słowami:

Każda firma, szukając sposobu na uzyskanie przewagi rynkowej, stara się pewne obszary operacyjne budować wg, własnej strategii. To między innymi powoduje, że każde wdrożenie jest inne i nie ma jednej jedynie-słusznej architektury IT. (Źródło: Podsystemy systemów ERP | | Jarosław Żeliński IT-Consulting)

W artykule tym opisałem ogólną, dziedzinową architekturę firmy produkcyjno-, handlowo-, usługowej (popularne w Polsce PPHU). Wygląda ona tak:

Powyższy diagram to uproszczona dziedzinowa architektura IT firmy. Analiza biznesowa powinna dać rekomendacje:

• które moduły są w ogóle wymagane w danej firmie,
• które mogą być standardowymi elementami będącymi elementami systemu ERP,
• które elementy są na tyle istotne i specyficzne, że wybór rozwiązania specjalizowanego da lepsze efekty.

Biorąc pod uwagę fakt, że samodzielne systemy rachunkowości finansowej to raczej rzadkość, można założyć, że wdrażany będzie zawsze (lub już jest) tak zwany System ERP. Wersja minimalna to moduły obsługujące dane bilansowe czyli dowody księgowe, środki trwałe itp., oraz płace, czasem tak zwane kadry. To jest trzon opisany prawem i w tym obszarze „ameryki nie odkryjemy”.

Reszta to już indywidualne potrzeby danej firmy, łatwiej dobrać i wdrożyć bez kastomizacji, kilka najbardziej pasujących, dostępnych na rynku komponentów specjalizowanych, niż dostosowywać wielki monolit. Po drugie ewentualne zmiany wprowadzane w jednym z takich niezależnych komponentów nie przeniosą się na pozostałe (bo nie współdzielą żadnych elementów). Do tego kolejność ich wdrażania jest praktycznie dowolna, więc wdrożenie jest całkowicie podporządkowane bieżącym potrzebom firmy (bardzo często najmniejszym problemem jest właśnie rachunkowość, którą można wdrażać na końcu). Możliwa jest także przyszła rezygnacja, z któregokolwiek komponentu, bez potrzeby ingerencji czy rezygnacji z pozostałych.

Pięć lat temu pisałem:

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego ?super systemu? ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci ?gotowej? tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nazwę je ?zapóźnione?, nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane API, Application Programming Interface) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing).  Przyszłość to komponenty? (Źródło: Biznes wychodzi z objęć systemu ? monolitycznego ERP | | Jarosław Żeliński IT-Consulting)

I to się już dzieje…..