Zintegrowany ERP: postęp czy cofanie?

Nie ulega wątpliwości, że np. pracodawca potrzebuje danych o nas, o naszym wykształceniu. Czy to znaczy, że optymalne jest, by systemy kadrowo-płacowe współdzieliły wszystkie dane z urzędami stanu cywilnego i ze szkołami? Wszyscy wiemy, że po wielu latach spędzonych w szkołach, mimo ogromnej ilości danych szczegółowych o naszej edukacji, zebranych w tych szkołach, pracodawcy wystarczy wymagane świadectwo jej ukończenia oraz nasze imię, nazwisko, data i miejsce urodzenia. Zarówno Szkoła jak i Urząd  Stanu Cywilnego mają znacznie bogatsze dane na nasz temat, co nie znaczy, że “inne podmioty” powinny je współdzielić. Szkoła na żądanie wyda odpis świadectwa a Urząd odpis aktu urodzenia (bo nawet nie poszczególne oceny czy poszczególne dane osobowe). Pisząc wcześniej o integracji wskazywałem na korzyści minimalizacji interfejsów i separacji danych.

Tak więc mityczna “integracja w systemach ERP”  w rozumieniu “wspólne dane” to może jednak relikty technologii z przed 30/40 lat, konformizm kupujących i opór przed zmianą u dostawców? Zaryzykuję tu tezę, że dostawcy wielu systemów ERP fundują nam po prostu dług technologiczny. Czy mam rację? Popatrzmy na jedne 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 takich sposób, aby – zachowując pozory rozwoju – utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe.(Czego największe firmy technologiczne nie mówią swoim klientom?)

O co tu chodzi?

Model rynku i przedsiębiorstwa

Najpierw dla porządku przypomnę pojęcie wartości dodanej Michaela Portera:


Wartość dodana pracy, to różnica postrzeganej wartości rynkowej produktu przed i po wykonaniu nad nim pracy. Skoro wartość rynkowa to konsekwencja powstającej wartości dodanej, nie trudno 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 decyduje się na ten droższy, oznacza to, że dostrzega wartość tego przetworzenia i jest skłonny za to zapłacić. Przykładem może być to, że dla rowerzysty stos żelaza i gumy ma jednak mniejszą wartość niż rower, ryba dostępna w sklepie 800 km od morza ma większą wartość niż ta sama ryba w tak oddalonym porcie. Tyle w kwestii wartości dodanej.

Popatrzmy teraz na to co się dzieje w powyższym “Podmiocie gospodarczym”. Powyższy Podmiot gospodarczy to taka oto 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. Generalizując: podmioty gospodarcze to złożenie (kombinacje) wytwarzania i dystrybucji. Aby możliwe było wytwarzanie, potrzebna jest aktywność polegająca na projektowaniu. Na diagramie połączono to wszystko w pewien określony ciąg logiczny działań. Z uwagi na to, że projektowanie z reguły nie odbywa się w sposób przypadkowy, w sposób przemyślany zbierane są informacje z rynku na temat potrzeb Nabywców (rynku).

System informacyjny

Aby możliwe było zarządzanie tym wszystkim, konieczne jest śledzenie tych aktywności, ich skutków i przyczyn. Śledzenie to nic innego jak 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, jest nim np. sprzedaż (moment przeniesienia własności produktu na nabywcę), ten fakt jest dokumentowany fakturą VAT. Oczywiście wiele takich faktów ma miejsce wewnątrz podmiotu (np. przekazanie wytworzonego produktu do magazynu wyrobów gotowych itp.).

Takich faktów w firmach jest wiele, jednak do celów zarządzania nią, kolekcjonujemy 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ą przyczyną zbierania (monitorowania) kolejnych szczegółów.

Poza opisem faktów, kolekcjonujemy w różnej formie, zasady regulujące to jakie fakty mają prawo lub muszą zajść: to reguły biznesowe. Zbiór tych danych (opisy faktów) i ich wzajemnej zależności to system informacyjny: informacje o tym co się wydarzyło. Czego nam tu “troszkę” brakuje? Tego co nazywamy np. księgowością czy zarządzaniem kadrami (w tym wynagrodzenia). Jednak one właśnie są “tylko” narzędziem do przetwarzania danych o faktach. Celowo nie umieściłem na diagramach tych “aktywności” bo one są pracami polegającymi na śledzeniu i monitorowaniu, na sprawozdawczości. Tak na prawdę 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 więc już, że Podmiot gospodarczy to określone aktywności: projektowanie, wytwarzania, sprzedaż, zaopatrzenie, obsługa “pytań” czyli tak na prawdę “różnych spraw” (mogą być jeszcze inne, zależnie 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 nich – bo nie wszystkie – mogą być potrzebne “na zewnątrz”. Np. spośród wszystkich szczegółowych informacji o realizacji dużego projektu, do rozliczenia jego koszów i wystawieniu faktury, potrzebne są wyłącznie określone zagregowane dane a nie wszystkie jakie znamy. Dotyczy to praktycznie każdej z wymienionych aktywności. Jaki z tego wniosek? Nie musimy współdzielić w jednym miejscu wszystkich danych o poszczególnych aktywnościach. Poszczególne aktywności przekazują pomiędzy sobą tylko swoje produkty, i tylko przekazywanie danych je opisujące ma sens. Zarządzanie każda aktywnością odbywa się lokalnie (w niej) i tylko tu jest potrzebna “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 wymagamy wyłącznie zagregowanej informacji, udostępnianie nadmiaru szczegółów na zewnątrz niczemu nie służy (poza przypadkami gdy część z nich udostępniamy do do szczegółowych analiz, te jednak także wykona zewnętrzny dedykowany podsystem. Prowadzenie rozliczeń i sprawozdawczość to kolejna aktywność, która także wymaga tylko określonych zagregowanych danych a nie “wszystkich jakimi dysponujemy”.

Systemy ERP (pierwotnie tylko FK, potem MRP i MRPII) powstawały jako systemy rejestrujące dla określonych podmiotów. W latach 80-tych i 90-tych (wtedy one powstawały), firmy raczej się rozrastały, ich wewnętrzna zmienność była bliska zeru, dlatego architektura w postaci jednej dużej relacyjnej bazy danych i zestawu funkcji je przetwarzających, miała swoje uzasadnienie. Rozwój firmy wymagał praktycznie tylko dodawania nowych funkcji, czasem zmiany już istniejących, raczej nie wymagał zmian w modelu danych.

Opisane wyżej aktywności mogą być realizowane w jednym podmiocie, ale mogą to być odrębne podmioty. Dotyczy to także aktywności, jaką jest prowadzenie rozliczeń (np. zewnętrzne biuro rachunkowe, spółka zależna itp.). Zmienność sytuacji rynkowej, zmiana strategii, przejęcia, wydzielanie spółek zależnych, to wszytko ma prawo przytrafić się każdej firmie i organizacji. To znaczy, że podmiot gospodarczy może być złożony z dowolnego, zmieniającego się, zestawu powyższych aktywności. Jaki z tego wniosek?

Skoro powyższe aktywności są od siebie niezależne, takie też powinno być oprogramowanie, które pozwala nimi zarządzać. Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże “zabetonowanie” architektury biznesowej firmy.

Autor: Jarosław Żeliński - IT-Consulting
Źródło: www.it-consulting.pl