Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Analizy Biznesowe i Systemowe Przedsiębiorstw - Projektowanie Systemów Informatycznych
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:
zobowiązał się do realizacji wymagań nie testując ich wykonalności,
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:
jedna monolityczna baza danych zawierająca znormalizowaną logikę związków między danymi i i ch współdzielenie,
moduły dziedzinowe zawierające wyłącznie logikę przetwarzania tych danych,
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:
moduły obsługujące zdarzenia gospodarczej (co najmniej rachunkowość, magazyny) są obligatoryjne, czyli zawsze muszą być wdrożone i zawsze jako pierwsze),
pewne elementy logiki są niemodyfikowalne (logika związków pomiędzy danymi jest w centralnej bazie danych, ta zaś jest praktycznie niemodyfikowalna),
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),
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,
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.
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)
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę 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.
Masz pytania to treści artykułu?
Kliknij tu!
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.