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
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:
analiza i określenie celu projektu
analiza biznesowa, opracowanie wymagań
projekt architektury rozwiązania (ogólny model dziedzinowy), podział na komponenty (obszary dziedzinowe)
okreslenie, które komponenty (podsystemy) należy wytworzyć, a które można kupić na rynku (tak zwane COTS, ang. [[Commercial off-the-shelf]])
sprawdzenie dostępności i kosztów
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:
Analiza biznesowa: model biznesowy, optymalizacja procesów, określenie kluczowych czynników sukcesu,
Określenie wymagań na oprogramowania w kontekście kluczowych czynników sukcesu.
Wskazanie miejsc, w których można użyć gotowego oprogramowania
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:
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).
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:
Opracować własne wymagania.
Dać dostawcom systemów ERP by wykonali tak zwaną analizę gap/fit (co nasz system ma a czego nie ma).
Wybrać najkorzystniejszą ofertę, wdrożyć system szybko (bo bez kastomizacji).
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”.…
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!
Faktycznie APS to kolejny klocek ERP (zapewne jako COTS) i warto o nim napisać. Pojawia się jednak dodatkowa potrzeba: oddzielenie serwisów biznesowych jako takich od ich złożoności bo pomieszanie tych dwóch obszarów prowadzi do błędnych wniosków, że dwa systemu o porównywalnej liczbie linii kodu są porównywalnie złożone z perspektywy biznesowej a to nie prawda. Prosty przykład: system BI (Business Inteligence i w tym hurtownia danych) do prognozowania obrotów ma jedną główną funkcjonalność: wyliczyć prognozę sprzedaży za dany okres i będzie miał jednego użytkownika (aktora): analityka. System zarządzający repozytorium dokumentów i ich przepływem w zasadzie niczego nie liczy za to ma dziesiątki aktorów i dziesiątki funkcjonalności. Złożoność każdego z nich jest duża ale leży w zupełnie innych obszarach. W przypadku porównania ERP i APS widzę to podobnie. ERP to zarządzanie zasobami, APS to jeden (ważny ale jednak jeden) z aspektów zarządzania nimi.
Problem z APS jest taki, że jest to jednak szczególny typ produktów gdyż wymaga dość specjalizowanej wiedzy (matematycznej) od strony dostawcy. Prace programistyczne są dość małej złożoności. Mi wychodzi, że około 10% całego projektu stanowią prace zespołu robiącego moduł analityczny. Mówię oczywiście o programowaniu.
Nie mniej jednak, moje doświadczenie jest takie, że przeciętna firma informatyczna nie dysponuje odpowiednimi kompetencjami aby z sukcesem wykonać projekt, który wymaga rozwiązania złożonych problemów obliczeniowych (słowo klucz: NP-trudne). Co nie dziwi bo tego się nigdzie nie uczy…
Jest takie pojęcie jak LSCO (Large Scale Combinatorial Optimization). Powstała nawet metodyka wdrażania rozwiązań zawierających takie elementy. Na google można znaleźć trochę materiałów jak to kogoś interesuje.
W ogólności APS należą do szerszej klasy systemów wspomagania decyzji. I w pełni się zgadzam, że to po prostu kolejny klocek obudowujący ERPa. Ja zawsze zaczynam rozmowę z klientem od pytania czy ma ERPa i jak nie ma to proszę o zakup a dopiero potem o powrót do rozmów o bardziej zaawansowanych rozwiązaniach.
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.
Dobry artykuł, ale ja bym go rozszerzył także na produkty APS (Advanced Planning System). Ostatnio na GL (http://www.goldenline.pl/forum/2283726/systemy-aps/s/1#42035040) prowadziłem dyskusję na ten temat. Myślę, że może Pana zainteresować.
Faktycznie APS to kolejny klocek ERP (zapewne jako COTS) i warto o nim napisać. Pojawia się jednak dodatkowa potrzeba: oddzielenie serwisów biznesowych jako takich od ich złożoności bo pomieszanie tych dwóch obszarów prowadzi do błędnych wniosków, że dwa systemu o porównywalnej liczbie linii kodu są porównywalnie złożone z perspektywy biznesowej a to nie prawda. Prosty przykład: system BI (Business Inteligence i w tym hurtownia danych) do prognozowania obrotów ma jedną główną funkcjonalność: wyliczyć prognozę sprzedaży za dany okres i będzie miał jednego użytkownika (aktora): analityka. System zarządzający repozytorium dokumentów i ich przepływem w zasadzie niczego nie liczy za to ma dziesiątki aktorów i dziesiątki funkcjonalności. Złożoność każdego z nich jest duża ale leży w zupełnie innych obszarach. W przypadku porównania ERP i APS widzę to podobnie. ERP to zarządzanie zasobami, APS to jeden (ważny ale jednak jeden) z aspektów zarządzania nimi.
Problem z APS jest taki, że jest to jednak szczególny typ produktów gdyż wymaga dość specjalizowanej wiedzy (matematycznej) od strony dostawcy. Prace programistyczne są dość małej złożoności. Mi wychodzi, że około 10% całego projektu stanowią prace zespołu robiącego moduł analityczny. Mówię oczywiście o programowaniu.
Nie mniej jednak, moje doświadczenie jest takie, że przeciętna firma informatyczna nie dysponuje odpowiednimi kompetencjami aby z sukcesem wykonać projekt, który wymaga rozwiązania złożonych problemów obliczeniowych (słowo klucz: NP-trudne). Co nie dziwi bo tego się nigdzie nie uczy…
Jest takie pojęcie jak LSCO (Large Scale Combinatorial Optimization). Powstała nawet metodyka wdrażania rozwiązań zawierających takie elementy. Na google można znaleźć trochę materiałów jak to kogoś interesuje.
W ogólności APS należą do szerszej klasy systemów wspomagania decyzji. I w pełni się zgadzam, że to po prostu kolejny klocek obudowujący ERPa. Ja zawsze zaczynam rozmowę z klientem od pytania czy ma ERPa i jak nie ma to proszę o zakup a dopiero potem o powrót do rozmów o bardziej zaawansowanych rozwiązaniach.