O integracji i unikaniu kastomizacji monolitów poprzez wdrażanie dziedzinowych podsystemów napisałem tu wiele. Tym razem kilka komentarzy do krótkiego tekstu pewnego dostawcy monolitu ERP. Tekst krótki więc cytowanie stanowi niemalże jego połowę ale cóż, prawo cytowania treści bezpośrednio komentowanych…

Artykuł

Choć wyspecjalizowane pod konkretny obszar systemy oferują szerokie możliwości i najłatwiej je dopasować do potrzeb organizacji, może okazać się, że wraz z rozwojem firmy przestaną być efektywne. (źr.: 6 przesłanek, które mogą wskazywać, że powinieneś wdrożyć kompleksowe oprogramowanie)

Pierwsze zdanie to prawda, a drugie (zaczynając sie od “może”) sugeruje, że nie zawsze. Popatrzmy jak autor argumentuje drugie zdanie, pisząc że systemy wyspecjalizowane “wraz z rozwojem firmy przestaną być efektywne” (wszystkie cytaty z powyższego źródła).

1. Nieefektywna integracja danych
Stosowanie kilku rozwiązań informatycznych wiąże się z koniecznością zapewnienia skutecznej wymiany danych pomiędzy nimi. Zazwyczaj nie jest ona tak efektywna jak w przypadku jednego systemu z różnymi modułami.

Niestety nie jest to prawda. Poziom standaryzacji interfejsów od dawna pozwala robić to w sposób niezauważalny dla użytkownika. Powiem tylko tyle, że każdy zgodny z prawem system ERP/FK wysyła dane (JPK) do systemów rządowych, bez potzreby żadnej ręcznej integracji, i nie ma z tym żadnego problemu. Dla czytelników, którzy tego nie wiedzą, informacja: każde pobranie gotówki z bankomatu czy też dokonanie płatności kartą płatniczą w sklepie, to każdorazowo wynik współracy (integracja) co najmniej kilkunastu zintegrowanych systemów co najmniej kilku firm i instytucji. Warto też wiedzieć, że dane z różnych dziedzin bardzo często nie są możliwe do umieszczenia w jednej i tej samej bazie danych (to zresztą główne źródło problemów kastomizacji systemów monolitycznych), forsowanie architektury monolityczne jest wręcz wysoce szkodliwe .

Dostęp do wszystkich dokumentów i danych w jednym centralnym systemie pozwala księgowości na dokładną analizę w czasie zbliżonym do rzeczywistego, a to umożliwia lepsze zarządzanie finansami całej organizacji.

Dowody księgowe (podstawowe dokumenty w FK/ERP) stanowią mniej niż 20% wszystkich dokumentów operacyjnych, reszta i tak jest poza ERP. To co widzimy jako dokumenty w systemach ERP (np. Faktura) to tak na prawdę raporty ad-choc z tych baz danych, nie ma tam ŻADNYCH dokumentów. Aby były, należy jest dodatkowo archiwizować jako pliki PDF i/lub XML.

2. Błędy i opóźnienia
W przypadku konieczności ręcznego wprowadzania danych do kilku systemów, przedsiębiorstwo naraża się na opóźnienia, a także błędy.

Nie ma takiej potrzeby w środowisku zintegrowanym. Integracja kilku różnych dziedzinowych systemów między służy temu, by nie wprowadzać dokumentów więcej niż raz.

3. Systemy od różnych dostawców
Choć w codziennej pracy może nie stanowić to dużego utrudnienia, w przypadku jakiejkolwiek awarii systemów, fakt, że pochodzą od różnych dostawców, może być kłopotliwy. Wiąże się bowiem z koniecznością skontaktowania z kilkoma osobami, żeby móc rozwiązać problem.

Jest dokładnie odwrotnie: jak sie zepsuje monolit to NIC nie działa. Jak awarii ulegnie jeden z podsystemów dziedzinowych, reszta działa poprawnie, co jest dla odmiany OGROMNĄ zaletą rozproszonej architektury. Kontaktujemy się wyłącznie z administratorem tego co nie działa. Poprawnie wykonana integracja to także separacja skutków takich awarii.

4. Utrudnienie dla pracowników
Korzystanie z kilku systemów może stanowić dodatkowe wyzwanie dla pracowników, którzy muszą nauczyć się pracy na zróżnicowanym oprogramowaniu, często z innymi funkcjonalnościami, interfejsem i sposobem działania.

To także nie jest prawda: systemy dziedzinowe, jak sama nazwa wskazuje, są adresowane do określonych grup zawodowych czy kompetencji. Jeżeli gdziekolwiek pojawia się wyżej opisana sytuacja, to jest to raczej skutek bałaganu, który należy uporządkować przed wdrożeniem.

5. Nadmierne obciążenie działów IT
Korzystając z wielu rozwiązań informatycznych, konieczne jest stworzenie zespołu IT, który będzie miał odpowiednią wiedzę i doświadczenie w każdym z nich.

Kolejna nieprawda: dział IT z zasady zajmuje się administracją a nie rozwojem tych aplikacji. Za utrzymanie i rozwój odpowiada dostawca programowania w ramach stałej corocznej opłaty i licencji.

6. Utrudniona organizacja pracy z domu
Wciąż wiele firm pracuje w trybie home office, co wymaga od przedsiębiorstw zapewnienia dostępu do wszystkich koniecznych do pracy systemów, informacji czy dokumentów. Nie wszystkie aplikacje są dostosowane do pracy poza biurem.

Owszem, stare i wiekowe systemy ERP w architekturze klient/serwer się do tego praktycznie nie nadają. Każdy nowoczesny system, to w całości dostępna przez przeglądarkę aplikacja, z którą pracować można gdziekolwiek.

Obserwujemy, że niektóre firmy obawiają się zmian, nawet gdy rozwiązania, z których korzystają, nie w pełni spełniają ich potrzeby lub są już nieco przestarzałe. Często myślą o wysokich kosztach kompleksowych systemów. I choć rzeczywiście, konieczna jest inwestycja finansowa i czasowa, to utrzymanie jednego rozwiązania zamiast kilku mniejszych jest w dłuższej perspektywie kosztowo bardziej opłacalne.

To także jest nieprawda, choćby dlatego, że wdrażanie dedykowanych podsystemów dziedzinowych nie wymaga żadnych kastomizacji dlatego i wdrożenie i później upgrade są znacznie tańsze niż wdrożenie i dostosowanie monolitu.

Podsumowanie

Nie raz myślałem, że nie będę już musiał pisać takich artykułów ale znowu jest okazja. Nie raz pisałem, że dostawcy systemów ERP, bardzo często, bez żadnych skrupułów wykorzystują niewiedzę swoich klientów. Tu mamy kolejny taki przykład. Nawet jeżeli istnieją tak złe wdrożenia, że artykuł ten mówi prawdę, to jest to tylko opis wyjątkowych złych wdrożeń.

Pisanie, że “Choć wyspecjalizowane pod konkretny obszar systemy oferują szerokie możliwości i najłatwiej je dopasować do potrzeb organizacji, może okazać się, że wraz z rozwojem firmy przestaną być efektywne.” jest szkodliwą manipulacją.

Źródła

Martin Fowler. (2014). bliki: BoundedContext [Martinfowler.com]. Martinfowler.Com. https://martinfowler.com/bliki/BoundedContext.html

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.