Wdrożenia ERP – cz. VI Monolit vs. kompozycja podsystemów

Wpis gościnny dr hab. inż. Andrzeja Zalewskiego

Kolejny z serii wpisów gościnnych dr hab. inż. Andrzeja Zalewskiego na temat wdrożenia ERP. Wpisy te pierwotnie opublikowane były na grupie FB, dzięki uprzejmości autora prezentujemy je również na łamach Rudej Strony Zarządzania.

Monolit vs. kompozycja podsystemów

Dziś odcinek architektoniczny – o architekturach systemów ERP.

Ci, którzy mnie znają wiedzą, że jestem przeciwnikiem wszelkich mód i ideologii w konstruowaniu systemów informatycznych. Zawsze powtarzam, że konstruowanie systemów, tak samo jak większość życiowych decyzji to sztuka kompromisu między stopniem zaspokojenia różnych oczekiwań.

KLASYCZNY DYLEMAT: SCENTRALIZOWANY CZY ROZPROSZONY

W przypadku systemów ERP dylemat brzmi: czy wybrać jeden, wielki scentralizowany kombajn firm typu SAP czy Oracle (czy może mniejszy, ale jeden do wszystkiego), czy też zbudować system z odrębnych podsystemów połączonych jakimś rozwiązaniem integracyjnym.

PROPOZYCJA: CENTRALIZACJA

Kiedyś odpowiedź była jedna: integracja była w powijakach i trzeba było kupić jeden wielki system, tylko to pozwalało analizować dane wiążąc różne obszary działalności i informatyzować procesy biznesowe na całym ich przebiegu przez różne merytoryczne komórki. Duże systemy ERP stały się czymś w rodzaju ziemi obiecanej dla wielkich firm, z trudem radzących sobie z opanowaniem i informatyzowaniem swojego funkcjonowania.

Stopniowo odkryto, że nie ma nic darmo. Jeden duży system, to uzależnienie od jednego dostawcy i związanie z nim losu własnej firmy. I że obsługa i rozwój takiego systemu nie mało kosztuje.

Odkryto też, a raczej wiedziano to od samego początku, że takie całościowe rozwiązania są mocno skomplikowane i wcale nie łatwe we wdrożeniu i obsłudze.

Ci co wdrożyli SAP’a czy Oracle EBS w miejsce starego, małego, czasem lokalnie napisanego systemu, wiedzą o czym tu mowa.

PROPOZYCJA: ROZPROSZENIE

Na przestrzeni ostatnich 15 lat wyłoniła się alternatywa. Kupić systemy dziedzinowe u różnych dostawców a następnie z integrować. Niewątpliwie ogranicza to opisane efekty związane z wielkimi kombajnami – łatwiej dobrać takie ograniczone rozwiązanie do upodobań poszczególnych grup użytkowników, likwidujemy uzależnienie od jednego dostawcy (vendor lock-in). Zwykle oderwane od siebie systemy są mniej skomplikowane i prostsze we wdrożeniu – bo wdrażamy je niezależnie.

Same korzyści? Nie ma tak dobrze. Co tracimy:

1. musimy sobie radzić z wieloma dostawcami (i ich narowami),
2. ograniczamy sobie możliwości analizy danych, które ograniczają się do poszczególnych systemów, a wszelkie szersze analizy wymagają już skomplikowanego oprogramowania niezbędnych do tego interakcji między systemami. Alternatywnie można dobudować system analityczny (Business Intelligence czy po prostu hurtownię danych) zbierającą dane z różnych systemów na potrzeby analityczne – czyli znowu centralizacja;
3. integracja systemów – to tylko pozornie coś łatwego. W praktyce wiąże się ona z wieloma problemami – np. przeniesienie danych między zintegrowanymi systemami nie jest natychmiastowe i trzeba na nie zaczekać (czasem nawet wiele minut), integracja systemów wymaga wykonania niezbędnych interfejsów, co nie musi być proste i wygodne, integracja systemów lubi się skomplikować prowadząc do tzw. integracyjnego spaghetti, jak też
4. integracja bywa wrażliwa na zmiany w systemach integrowanych, co unaoczni się wtedy, gdy dostarczają te systemy różni dostawcy czy producenci, utrzymanie rozwiązania integracyjnego to nie musi być nic łatwego.

Czy zatem należy porzucić tą drogę i wrócić do klasycznych „ciężkich” ERP’ów?

A ZATEM: CENTRALIZACJA CZY ROZPROSZENIE?

Decyzja o wyborze systemu ERP jest nietrywialna, wielowymiarowa. Architektura systemu nie jest tu jedynym czy głównym dylematem. Błąd, jeśli architektura stanowi główne kryterium wyboru.

W niektórych przypadkach równie dobrze mogą sprawdzić się rozwiązania scentralizowane, jak i rozproszone.

Dobrze dopasowany system scentralizowany oszczędzi bólu związanego z integracją, ułatwi analizę danych. Niedopasowany będzie koszmarem.

System rozproszony, z podsystemami od różnych dostawców może (ale nie musi!) być łatwiejszy we wdrożeniu, ale jeśli planujemy rozległe i wieloobszarowe analizy – będzie to oddzielnym wyzwaniem.

Niestety, prostych dróg w skomplikowanych sytuacjach nie ma, co widać na poniższym zdjęciu…

O autorze

Andrzej Zalewski, dr hab.

Informatyk pracujący na Politechnice Warszawskiej, gdzie uczy algorytmiki oraz zarządzania projektami informatycznymi w firmach. Udziela się również jako ekspert i biegły w dziedzinie inżynierii oprogramowania. Kieruje Studiami Podyplomowymi Zarządzanie Zasobami IT oraz Zarządzanie projektami.