System monolityczny czy rozwiązania komponentowe

Wiele osób utożsamia systemy zintegrowane z pojęciem współdzielenia danych – taką zbitkę powtarzają im sprzedawcy aplikacji biznesowych. Czy systemy monolityczne bronią się przed konkurencją ze strony specjalizowanych rozwiązań dziedzinowych? Popatrzmy na tę kwestię z perspektywy architektury biznesowej oraz architektury systemów ERP.

Pracodawca potrzebuje danych o swoich pracownikach, np. o ich wykształceniu. Czy to oznacza, że systemy kadrowo-płacowe powinny współdzielić wszystkie dane z urzędami stanu cywilnego i uczelniami? Wiadomo, że po wielu latach spędzonych w szkołach, mimo ogromnej ilości szczegółowych danych na temat edukacji przyszłego pracownika, pracodawcy wystarczy świadectwo ukończenia uczelni oraz imię, nazwisko, data i miejsce urodzenia.

Zarówno uczelnie, jak i urzędy stanu cywilnego, mają znacznie bogatsze dane na nasz temat – nie oznacza to jednak, że inne podmioty powinny je współdzielić. Szkoła na żądanie wyda odpis świadectwa, a USC odpis aktu urodzenia (a nie poszczególne oceny czy dane osobowe).

Zobacz również:

Mając to na uwadze, widać, że korzystna będzie minimalizacja interfejsów oraz separacja danych. Projektowanie aplikacji jako oddzielnych, zintegrowanych, dziedzinowych, wyspecjalizowanych systemów jest bardziej efektywne niż tworzenie rozwiązań „dobrych zawsze i do wszystkiego”. „Warto mieć świadomość, że miliony dolarów zostały bezpowrotnie zmarnowane na opracowywanie wspólnych korporacyjnych modeli danych, dla wszelkich aspektów ich działalności. Warto tu podkreślić fakt, że stawały się one nieaktualne jeszcze przed zakończeniem projektów ich opracowywania. Próby rozwiązania zbyt wielu problemów jednym wspólnym modelem kończą się porażką, znacznie skuteczniej jest tworzyć oddzielne modele, każdy dla konkretnego problemu dziedzinowego” (źródło: „Designing Objects Systems”, Steve Cook, John Daniels, 1994 r.).

Konstrukcja rozwiązań ERP

Na rynku pojawia się coraz więcej specjalizowanych podsystemów dziedzinowych. W tej sytuacji wdrażanie systemów monolitycznych staje coraz trudniejsze. Wydzielanie dziedzinowych, własnych, przeznaczonych do tego celu podsystemów to jedyny sposób na ochronę swojego know-how.

Konstrukcja oprogramowania ERP oparta na jednym, wspólnym i współdzielonym modelu danych jest trudna nie tylko do opracowania, ale także w późniejszym utrzymaniu. Czy mityczna „integracja w systemach ERP” w rozumieniu wspólnych danych jest reliktem technologicznym sprzed kilkudziesięciu lat, wynikającym z konformizmu kupujących oraz oporu przed zmianą wśród projektantów i dostawców tych aplikacji?

Zaryzykuję tezę, że wielu dostawców systemów ERP funduje klientom narastający dług technologiczny. Aby uzasadnić to stwierdzenie, przytoczę jedno z ostatnich badań Gartnera: „omawiając strategie firm, Gaughan podkreślił również znaczenie działających przy nich ośrodków badawczych. Ich nadrzędnym celem jest tworzenie innowacji w taki sposób, aby – zachowując pozory rozwoju – utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe”(źródło: What Microsoft, Oracle, IBM, And SAP Don't Tell Customers, 2011 r.). Co to oznacza?

Model rynku i przedsiębiorstwa

Dla porządku przypomnieć należy pojęcie wartości dodanej Michaela Portera.

W tym ujęciu wartość dodana pracy to różnica postrzeganej wartości rynkowej produktu przed wykonaniem i po wykonaniu przy nim pracy. Skoro wartość rynkowa to konsekwencja powstającej wartości dodanej, nietrudno się domyślić, że cena rynkowa produktu także wzrośnie po jego przetworzeniu.

Powyższy diagram pokazuje ogólną zasadę wartości postrzeganej: dokonujący wyboru nabywca wie, że cena towaru przetworzonego jest wyższa od ceny towaru uzyskanego bezpośrednio ze źródła zaopatrzenia. Jeżeli mimo to nabywca decyduje się na droższy towar, oznacza to, że dostrzega wartość jego przetworzenia i jest skłonny za to zapłacić. Przykłady? Dla rowerzysty żelazo i guma będą miały mniejszą wartość niż rower; świeże ryby dostępne w sklepie znajdującym się w miejscowości 800 km od morza będą miały większą wartość niż w przypadku lokali położonych nad morzem.

Jak wytwarzana jest wartość dodana? Popatrzmy na to, co się dzieje w podmiocie gospodarczym przedstawionym na diagramie obok. Podmiot gospodarczy to np. następująca struktura:

Podmiot gospodarczy tworzy wartość dodaną poprzez przemieszczenie produktu w przestrzeni i czasie (ten sam produkt zostaje dostarczony w określone miejsce, np. sieci dystrybucji) oraz (lub) wytwarzając lub przetwarzając określone produkty (tu półprodukty) lub surowce. Ogólnie rzecz ujmując, podmioty gospodarcze to złożenie (kombinacje) czynności wytwarzania i dystrybucji. Aby możliwe było wytwarzanie, potrzebna jest aktywność polegająca na projektowaniu; diagram przedstawia to w postaci pewnego określonego, logicznego ciągu działań. Z uwagi na to, że projektowanie nie odbywa się w sposób przypadkowy, informacje na temat potrzeb nabywców (rynku) zbierane są z rynku w sposób przemyślany.

System informacyjny

Aby możliwe było zarządzanie podmiotem gospodarczym, konieczne jest śledzenie jego aktywności, jej skutków i przyczyn – zbieranie danych o tym, co chcemy wiedzieć. Jak mawiają specjaliści z dziedziny zarządzania: „Zarządzać można tylko tym, co potrafimy mierzyć”. O czym mowa? O faktach:

Wszystkie aktywności podmiotu gospodarczego tworzą określone fakty. Faktem jest np. sprzedaż, tj. moment przeniesienia własności produktu na nabywcę. Ten fakt udokumentowany jest fakturą VAT. Oczywiście, wiele innych faktów występuje wewnątrz danego podmiotu (np. przekazanie wytworzonego produktu do magazynu wyrobów gotowych itp.).

Takich faktów w firmach jest wiele, jednak do celów zarządzania opisujemy ich ściśle określoną liczbę. To, które fakty rejestrujemy (zbieramy dane), zależy od przyczyny, np. prawo i podatki są przyczyną dokładnego śledzenia faktów związanych z wszelkimi operacjami dotyczącymi kosztów działalności i przychodów. Wewnętrzne potrzeby związane z zarządzaniem są z kolei powodem gromadzenia (monitorowania) i analizowania kolejnych szczegółów.

Poza opisem faktów w różnej formie przedstawia się zasady regulujące to, w jaki sposób fakty mają prawo lub muszą zajść – to reguły biznesowe. Zbiór tych danych (opisów faktów) i ich wzajemnej zależności to system informacyjny – informacje o tym, co się wydarzyło. Czego jeszcze brakuje? Na przykład księgowości czy zarządzania kadrami (w tym kwestiami wynagrodzeń). Te są jednak tylko narzędziami do przetwarzania danych o faktach. Celowo nie umieściłem w diagramach tego typu kwestii, ponieważ są to prace polegające na śledzeniu i monitorowaniu, na sprawozdawczości. Tak naprawdę wystawienie faktury VAT (opis faktu sprzedaży) jest częścią aktywności, jaką jest sprzedaż. Do celów podatkowych potrzebne są tylko zagregowane dane z faktur itd.

Architektura biznesowa

Wiemy już, że podmiot gospodarczy to struktura, na którą składają się określone aktywności: projektowanie, wytwarzanie, sprzedaż, zaopatrzenie czy obsługa „pytań”, czyli tak naprawdę różnych spraw, często zależnych od specyfiki podmiotu i branży, np. zarządzanie projektami w firmie usługowej. Każda z tych aktywności tworzy określone fakty; pewna część danych o tych faktach będzie potem potrzebna dla zewnętrznych podmiotów. Dotyczy to praktycznie każdej wymienionej aktywności. Jaki z tego wniosek? Nie ma potrzeby współdzielenia w jednym miejscu wszystkich danych o poszczególnych aktywnościach przedsiębiorstwa. Aktywności te polegają na przekazywaniu pomiędzy sobą tworzonych produktów i tylko przekazywanie danych opisujących te produkty ma sens.

Zarządzanie każdą aktywnością odbywa się lokalnie – wewnątrz podmiotu gospodarczego – i tylko tu potrzebna jest pełna wiedza. Każda z tych aktywności to zamknięty i względnie niepodzielny proces tworzenia wartości dodanej (hermetyzacja), od którego na zewnątrz wymaga się wyłącznie zagregowanej informacji. Udostępnianie nadmiaru szczegółów na zewnątrz niczemu nie służy – poza specyficznymi przypadkami, gdy część z nich udostępniamy do szczegółowych analiz; te jednak także wykona zewnętrzny przeznaczony do tego celu podsystem. Prowadzenie rozliczeń i sprawozdawczość to kolejna aktywność, która wymaga jedynie określonych, zagregowanych danych, a nie wszystkich, jakimi dysponuje przedsiębiorstwo.

Rozwiązania ERP – pierwotnie pod postacią systemów finansowo-księgowych, potem MRP i MRP II – powstawały jako systemy rejestrujące dla określonych podmiotów. W latach 80. i 90., kiedy powstawały, firmy przede wszystkim się rozrastały, a ich wewnętrzna zmienność była bliska zeru. Z tego powodu architektura w postaci jednej, dużej, relacyjnej bazy danych i zestawu funkcji je przetwarzających miała swoje uzasadnienie; obejmowała dość wąski dziedzinowo obszar (oparty głównie na dowodach księgowych), który zmieniał się bardzo powoli. Rozwój przedsiębiorstwa wymagał w zasadzie jedynie dodawania nowych funkcji, czasem zmiany już istniejących; nie było konieczności wprowadzania zmian w modelu danych.

Co istotne, opisane wyżej aktywności nie zawsze realizowane są w ramach jednego podmiotu. Dotyczy to np. prowadzenia rozliczeń, przy którym firma może wspierać się zewnętrznym biurem rachunkowym bądź spółką zależną. Sytuacja na rynku jest zmienna – aby dostosować się do jego wymagań, przedsiębiorstwo może być zmuszone do zmiany strategii, przejęcia innej spółki czy wydzielenia spółek zależnych. Innymi słowy, podmiot gospodarczy może być złożony z dowolnego, zmieniającego się zestawu różnych aktywności. Jaki z tego wniosek?

Skoro omawiane aktywności są od siebie niezależne, takie też powinno być oprogramowanie, które wspiera zarządzanie przedsiębiorstwem oraz jego komponenty. Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych monolit, to nic innego jak zafundowanie firmie długu technologicznego już w momencie podjęcia decyzji o zakupie. Żadne przedsiębiorstwo działające obecnie nie może dać sobie gwarancji, że jego wewnętrzne aktywności nie zmienią się co do swojej specyfiki. Nie da się przewidzieć, czy organizacji nie przybędzie nowych aktywności, czy nie zrezygnuje z innych, czy też nie wydzieli spółek zależnych. Monolityczny system ERP będzie stanowił przeszkodę wobec każdej takiej zmiany. Oparcie całości firmowego zaplecza IT na centralnym, współdzielonym module rejestrującym (którym zwykle jest księgowość) to niemalże zabetonowanie jej architektury biznesowej.

Architektura biznesowa i architektura systemów ERP

Każda firma, szukając sposobu na uzyskanie przewagi rynkowej, stara się pewne obszary operacyjne budować według własnej strategii. To powoduje, że każde wdrożenie jest inne i nie ma jednej słusznej architektury IT. Podstawą jest możliwość wdrażania tych podsystemów w dowolnie wybranej kolejności.

Na rynku pojawia się coraz więcej specjalizowanych podsystemów dziedzinowych – głównym powodem jest potrzeba dostosowania architektury IT nie tylko do specyfiki firmy, ale także do taktyki działania i strategii. W tej sytuacji wdrażanie systemów monolitycznych staje coraz trudniejsze, gdyż rozwiązania te cechuje integracja poprzez współdzielenie danych, dzięki czemu moduły są nierozłączne. Co ważne, wydzielanie dziedzinowych, własnych, przeznaczonych do tego celu podsystemów to także jedyny sposób na ochronę swojego know-how.

Modele pojęciowe

Podstawowym narzędziem analizy biznesowej jest tworzenie modeli pojęciowych – są to słowniki pojęć w formie graficznej. Zdefiniowane w słowniku pojęcia na diagramach łączy się z rzeczywistymi faktami.

Powyższy diagram to uproszczony model pojęciowy firmy (opracowanie własne autora, diagram faktów notacji SBVR; nie jest to model danych). Analiza pojęciowa ma dwa podstawowe cele: uporządkowanie pojęć i ich znaczeń oraz wykrycie i opracowanie podziału zakresu działania firmy na spójne, dziedzinowe obszary. Na modelach pojęciowych pojawiają się skupiska połączonych ze sobą pojęć; między tymi skupiskami zaś liczba połączeń jest relatywnie mała. Na diagramie wyróżniono typowe obszary w firmach – od lewej: Produkcja, Logistyka, Zarządzanie produktami, Rachunkowość, Obsługa kontaktów z klientami. Jest to oczywiście bardzo uproszczona wersja, ale pokazuje mechanizm prowadzenia analizy pojęciowej. Pojęcia to nazwy, którymi opisuje się przedmioty, działania lub ich cechy. Są one wykorzystywane w treści dokumentów, np. w nazwach pól formularzy, w ich tytułach itp. Istotne zastrzeżenie: nie należy utożsamiać modeli pojęciowych z modelami danych. Ten etap analizy pozwala wychwycić ewentualne specyficzne dla danej firmy obszary dziedzinowe, a także granice między tymi obszarami, które nie muszą być typowe.

Analiza pojęciowa jest przesłanką do opracowania architektury komponentów IT. Należy założyć, że każdy silnie powiązany wewnętrznie obszar pojęciowy to „kandydat” na spójny (i niepodzielny) komponent, zaś proste i rzadkie fakty między tymi skupiskami będą wskazywały potencjalne miejsca podziału na komponenty i wymiany informacji, tj. interfejsy między podsystemami lub aplikacjami. Praktyka analiz pojęciowych wykazuje znaczną różnorodność i specyfikę poszczególnych firm, np. czasem uzasadnione okaże się umieszczanie fakturowania w zakresie systemu CRM (obsługa kontaktów z klientem), innym razem nie będzie to miało sensu. Takich przykładów różnorodności jest oczywiście znacznie więcej. Przykładową strukturę dziedzinowych podsystemów przedstawia diagram poniżej.

Model obrazuje opisane podsystemy oraz podstawowe elementy komunikacji miedzy nimi. Komunikacja ta polega głównie na wzajemnym „użyciu [danych]”, tj. ich wymianie na żądanie, a nie współdzieleniu. Podaż tych aplikacji na rynku potwierdza opisany na początku artykułu podział na kluczowe podsystemy dziedzinowe. Powyższy opis jest siłą rzeczy dość ogólny – firmy różnią się między sobą, nieraz istotnie, podobnie zresztą jak aplikacje dziedzinowe.

Każda firma, szukając sposobu na uzyskanie przewagi rynkowej, stara się pewne obszary operacyjne budować według własnej strategii. To m.in. powoduje, że każde wdrożenie jest inne i nie ma jednej słusznej architektury IT. Podstawą jest możliwość wdrażania tych podsystemów w dowolnie wybranej kolejności. Co ciekawe, najmniej problemów w firmach sprawia księgowość kontowa, zaś wdrożenie monolitycznego ERP wymaga jej wymiany na nową już na samym początku.

Autor jest niezależnym analitykiem IT i projektantem systemów wyspecjalizowanym w modelowaniu procesów biznesowych, analizie wymagań i pomocy wdrożeniowej.


TOP 200