Generalnie modele referencyjne mają i dobrą i złą sławę. Nie są to wzorce projektowe, czyli dobre praktyki w postaci uniwersalnych abstrakcyjnych meta-modeli, są to najczęściej narzucane gotowe architektury, pozostaje pytanie: kto narzuca?.
Procesy referencyjne krytykowałem nie raz (Procesy referencyjne czyli kto żyw niech ucieka), referencyjny model ERP oznaczałby, że istnieje jakaś jedynie słuszna architektura systemu ERPII. I właśnie dostawcy wielu systemów ERPII (szczególnie ci duzi, których produkty mają wiele lat) promują model oparty o jedną wspólną relacyjną bazę danych, wokół której są osadzone dziedzinowe moduły, nazywają taki model modelem referencyjnym. Biorąc pod uwagę fakt, że systemy te wszystkie tak działają, można taki model nazwać referencyjnym w tej kategorii. Promowana jest tu integracja poprzez współdzielenie danych. Taka integracja jest niestety krytykowanym od lat monolitem, który jest też przyczyną wielu niepowodzeń wdrożeń: wprowadzanie jakichkolwiek zmian do takiego systemu jest zawsze ingerencją w cały system. Zarówno na moim blogu jak i w sieci znaleźć można wiele materiałów na ten temat (np. Monolity vs. …).
Więc jak inaczej?
Wewnętrzny łańcuch wartości
Zacznijmy od przypomnienia, uznawanego nadal za standard, modelu wewnętrznego łańcucha wartości M.E.Portera :
Model ten dzieli procesy wewnątrz organizacji na dwie grupy: wspierające i operacyjne. Procesy wspierające to procesy zapewniające organizacji zasoby niezbędne do działania. Procesy operacyjne, to procesy tworzące wartość dodaną produktów i usług w rynkowym łańcuchu wartości (to jaką wartość dodaną wnosi dana organizacja na rynku). Schematycznie przedstawiono to poniżej:
Marża budowana jest zarówno w obszarze procesów wspierających (minimalizując koszty stałe) jak i w obszarze procesów operacyjnych (marża na produktach i usługach czyli własnej inwencji tworzącej wartość dodaną na rynku). W obszarze procesów wspierających możemy konkurować praktycznie tylko w wewnętrznej efektywności. W tym obszarze procesy biznesowe i informacje są dość ściśle regulowane prawem (księgowość i finanse, zatrudnienie i wynagrodzenia, itp.). Zbudowanie tu przewagi rynkowej jest bardzo trudne, gdyż prawo dotyczy wszystkich podmiotów – czyli konkurentów także – w jednakowym stopniu.
W obszarze procesów operacyjnych mamy jednak niemalże pełną swobodę. To tu budujemy wartość dodaną jaką jest oferowany produkt lub usługa (być może są one unikalne, chronione prawem autorskim lub patentem). Na podstawie powyższego można stworzyć pewien wzorzec: meta-model procesów biznesowych organizacji.
Meta-model ten zbudowany został jako system procesów end-2-end, czyli procesów, gdzie wejścia i wyjścia to zdarzenia na styku organizacji z jej otoczeniem. W tej lub podobnej postaci, diagram ten był nie raz omawiany na tym blogu, dlatego tu tylko kilka ogólnych uwag.
W zależności od specyfiki danej organizacji, pokazane tu procesy mogą występować jako mniej lub bardziej wewnętrznie rozbudowane (modelujemy je precyzyjnie z użyciem notacji BPMN), niektóre mogą nie wystąpić (np. firma usługowa nie ma produkcji). Gdyby był to urząd, w miejscu Obsługi zamówień pojawi się obsługa podań i decyzje administracyjne (i podobne). To procesy operacyjne. Procesy wspierające, w tym obsługa rachunkowości i zasoby osobowe, to cecha każdej organizacji czy urzędu. Nawiązując do architektury biznesowej, powyższy model to warstwa środkowa na poniższym diagramie obrazującym poziomy opisu organizacji .
System informacyjny
Pewnym zaskoczeniem dla czytelnika najprawdopodobniej będzie to, że architektura oprogramowania wcale nie musi odwzorowywać powyższej mapy procesów. Zaryzykuje tezę, że nie miało by to sensu. Dlaczego? Bo aplikacje to narzędzia przetwarzające dane a nie uczestnicy procesów. procesy biznesowe są niezależne od systemów IT .
Modelowanie systemów IT jako torów w modelach procesów to jeden z najczęstszych błędów w analizach!
Po drugie procesy biznesowe skupiają się na treści dokumentów i celu ich tworzenia, aplikacje traktują je inaczej: ich detaliczna treść ma znaczenie tylko czasami i rzadko kiedy cała. Dokumenty tworzone są w aplikacjach dziedzinowych, bardzo często, po powstaniu, ich treść przetwarzana jest w innym procesie i w innym celu. Nie każdy dokument ma ścisłą strukturę. Np. dowody księgowe to ściśle strukturalne dokumenty i powstają w dedykowanych aplikacjach, jednak zarówno zapytania, oferty czy reklamacje, także np. umowy (w tym umowy o pracę), to dokumenty o dość swobodnej strukturze i zarządzamy nimi raczej z pomocą wybranych ich cech (metadane), bardzo rzadko ktoś poza człowiekiem wczytuje się w ich treść (maszyna nie). W efekcie architektura systemu informatycznego nie będzie odwzorowywała mapy procesów, mimo tego, że intuicyjnie takie są oczekiwania od dostawców analiz
Narzędzia w skrzynce narzędziowej stolarza nie noszą nazw etapów produkcji mebli! Aplikacje to dziedzinowe narzędzia pracy, przy czym dziedziną nie są tu procesy biznesowe (cel biznesowy) a struktura danych i ich znaczenie. Innymi słowy zarówno wnioski urlopowe jak i zapytania od klientów, to przepływ pracy i archiwum dokumentów. Wystawienie faktury czy dokumentu magazynowego, to tworzenie specjalistycznych formularzy, jednak ich dalsze przekazywanie (albo przyjmowanie np. faktur kosztowych) to już także przepływ pracy i zarządzanie dokumentami jako bytami archiwalnymi. Tu dziedzinowość nie polega na tym co i po co robimy (procesy biznesowe) a na tym, jakiego rodzaju dane przechowujemy i przetwarzamy (metadane). Np. Faktura dla klienta, ramowa umowa na rabaty z nim, jego reklamacje, to historia kontaktów z tym klientem. Detale struktur tych dokumentów nie maja tu znaczenia (nie są po raz drugi ani zmieniane ani weryfikowane, te dokumenty już powstały w aplikacjach im dedykowanych). Dlatego pewnym ogólnym wzorcem architektury systemu IT organizacji, będzie poniższy diagram :
Można to z powodzeniem nazwać: System ERP II. Nie jest to monolit, wdrażać można te moduły praktycznie w dowolnej kolejności, są zintegrowane, dane wprowadzamy tylko raz. Obecna na rynku standaryzacja powoduje, że integracja nie stanowi problemu. Modułów tych może być więcej, a wdrożenie takie na pewno można nazwać zwinnym.
Na zakończenie
Obserwacja rynku pokazuje, że podaż dedykowanych modułów jest bardzo duża, wybór jednego monolitycznego systemu – mimo, że nadal popularny – jest dzisiaj nieracjonalny, choćby z uwagi na zmienność i rynku i profili działania firm oraz zmienność prawa. Drugim powodem, dla którego decydowanie się na monolityczne systemy jest dużym ryzykiem, jest to, że jest to także decyzja o “wdrażaniu wszystkiego naraz i z jednego źródła”, co bardzo rzadko ma obecnie sens i stanowi ogromne ryzyko .
