Książka adresowana do programistów, sam tytuł to sugeruje. Warto ją kupić (programiści) bo bardzo  wyczerpująco opisuje to, co nazywam “implementacją obiektowości”. Samo nauczenie się (semantyka i syntaktyka) obiektowo zorientowanego języka programowania to mało, warto poznać na czym ta implementacja polega: czym jest obiekt, dziedziczenie czy kompozycja. Autor skupia się jednak na implementacji samej “obiektowości”.

Moim zdaniem książka jak najbardziej przydatna programistom, bo przykłady są ilustrowane kodem i diagramami UML. Jednak nie znajdziecie tam zbyt wiele o obiektowo zorientowanym opisie modelowanej rzeczywistości, czyli o biznesowym aspekcie programowania i projektowania. Z treści książki domyślam się, że autor zostawia obiektową analizę i projektowanie analitykom i projektantom, programistów uczy korzystania z obiektowo zorientowanego kompilatora i rozumienia go.

Książkę gorąco polecam każdemu programiście korzystającemu z obiektowo zorientowanych narzędzi. Jeżeli jakiś analityk lub projektant chce zrozumieć ograniczenia implementacji, to jemu także tę książkę polecam.

 

Tytuł: Myślenie obiektowe w programowaniu
Autor: Matt Wesfeld
Wydanie: Helion 2014

Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają “zwinną”, że “nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu, bo klient zna tylko cel i razem do niego dążymy, prototypy – tak właśnie radzimy sobie z nieprzewidywalnością wymagań”.

Przypomnę: wymagania to “warunki jakie coś musi spełnić aby było przydatne” (sł. j.polskiego PWN), jak mam tu rozumieć “brak wymagań na początku projektu”, skoro jego – projektu – celem jest wytworzenie czegoś przydatnego? Co to znaczy “wymagania dzisiaj są nieprzewidywalne”? To znaczy chyba tylko to, że zamawiający kompletnie nie ma pojęcia po co rozpoczyna projekt! (Co nie raz niestety bywa prawdą).

 

Niedawno miałem kolejne spotkaniu z pewnymi “developerami” i co mogę po nim powiedzieć? Otóż warto się uczyć i czytać, bo wtedy Ci ludzie, wiedzieli by, że nie należy mylić wymagań z cechami rozwiązania (dotyczy to także zamawiających i namawiam ich do korzystania z usług profesjonalistów) i źle jest, gdy ktoś taki (nie dostrzegający tych różnic) robi wodę z mózgu nabywcom oprogramowania. Prawdą jest, że skoro nie powstało rozwiązanie, to nie znamy wszystkich jego cech i odkryjemy je (powstaną) w toku prac nad jego tworzeniem. Nie prawdą jest jednak, że nie znamy wymagań na początku projektu z powodów jak powyżej, a jeżeli faktycznie ich nie znamy, to co i po co robimy?! (i to jest pytanie do tych, którzy zamawiają oprogramowanie!).

Warto więc poznać troszkę tej “wstrętnej, nie mającej nic wspólnego z praktyką”, teorii co pozwoli lepiej się komunikować i nie wciskać nikomu kitu, zaś w kwestii prostego słownictwa typy, wymaganie czy cecha, gorąco polecam po prostu poznanie ojczystego języka… 😉

Generalnie wymaganiem (nazywam je “biznesowym”) jest pomysł lub oczekiwanie “biznesu”, np. “system ma usprawnić obsługę zapytań ofertowych”, “system ma pozwalać na archiwizowanie wszystkich  zapytań i ofert w sposób pozwalający na łatwe dotarcie do każdego dokumentu”, itp. (to prawdziwe zapisy z pewnego projektu). Są wymagania? Są! Co teraz? Popatrzmy na “klasyczny” tok analizy specyfikowania wymagań po prawej stronie. taki diagram można zobaczyć na niemalże każdym szkoleniu z tego zakresu, jednak na mało którym, usłyszycie jak przeprowadzić ową “walidację” (sł j.polskiego: walidacja ?ogół czynności mających na celu zbadanie odpowiedniości, trafności lub dokładności czegoś?). 

Sam przegląd wymagań nic nie daje, one mają być spójne, kompletne i niesprzeczne. Sam przegląd pozwoli co najwyżej sprawdzić spójność i niesprzeczność, a kompletność? Właśnie po to się robi analizę procesów: tworzymy model działania firmy, by po pierwsze upewnić się, że wiemy i rozumiemy jak ona działa, a potem na tej podstawie ocenić, czy wymagania są kompletne (zakres projektu, czyli wymagania, faktycznie obejmują wszystkie te działania firmy, które chcemy by były nim objęte).

Tak więc można nie znać szczegółów przyszłego produktu i projektu zarazem, w końcu powstaje on – jego kolejne cechy – np. iteracyjnie, ale całość, jako projekt, powinna być znana w kwestii “do czego ma to służyć i jak”.  Nikt rozsądny nie podejmie się budowy wieżowca, nie mając pojęcia ile docelowo ma mieć pieter i do czego posłuży każde z nich… na pałę to zbijamy raczej budę dla psa lub stodołę (cyt. E.Yourdon ;)), ale faktycznie nie ma sensu szczegółowe planowanie wystroju wnętrz przed zakończeniem budowy całej konstrukcji.

Tu więc także rada dla zamawiających oprogramowanie: kompletnie pozbawione sensu jest pisanie na początkowym etapie analizy wymagań czegoś w rodzaju “system, podczas wystawiania faktury, powinien pozwalać na wybór, z rozwijanej listy uruchamianej prawym klawiszem myszy, listy kontrahentów i produktów” (to także cytat z pewnej specyfikacji).  Jest to zupełnie nieuprawniona i przedwczesna próba projektowania rozwiązania. Po pierwsze są inne metody podpowiadania na ekranie, po drugie, kontrahent i produkty mogą się np. podpowiadać z treści, wcześniej wprowadzonego, zamówienia. po trzecie jest jeszcze masa innych możliwych rozwiązań i wybór najlepszego to rola projektanta developera.

W tym momencie, na zakończenie, polecam artykuł z ubiegłego roku, gdzie opisałem taksonomię wymagań: Produkty w procesie analizy wymagań.

____

(dodane po pytaniu czytelnika)

[czytelnik] Jak radzić sobie z wymaganiami, które pojawiają się w trakcie realizacji projektu?

[autor] Po dobrze przeprowadzonej analizie jest ich na prawdę mało. Z racji tego, że mogą się jednak pojawić, warto przed rozpoczęciem realizacji projektu opisać i zatwierdzić z klientem, procedurę zarządzania zmianą zakresu projektu (który bywa nie raz załącznikiem do umowy), klient powinien czuć ciężar takich zmian. Dobrą praktyką jest także, by zakresem projektu (wprowadzaniem zmian do specyfikacji wymagań) zarządzał ktoś trzeci, nie będący ani zamawiającym ani wykonawcą, z uwagi na konflikty interesów (zamawiający ma tendencje do poszerzania zakresu bez zwiększania budżetu a wykonawca dokładnie odwrotnie), polecam by autor wymagań był osobą z zewnątrz, i jako trzecia strona, sprawował tak zwany nadzór autorski, wtedy staje się przy okazji mediatorem przy próbach wprowadzania zmian (to sprawdzona metoda w branży budowlanej i nie tylko).

Jeżeli jednak zakres projektu nie istnieje, to obawiam się, że nie ma na to: odkrywanie wymagań w toku projektu, sposobu.

Jakiś czas temu pisałem o uruchomianej usłudze “zdalnej analizy”. Dla wielu ludzi brzmi to kuriozalnie: “przecież analiza to kontakt z ludźmi!” I tu widzę podstawowy błąd postrzegany w ocenie tym czym jest analiza, która  nie jest “dialogiem”. Metafora z lekarzem jest chyba bardzo dobrym porównaniem: lekarz pracuje w “dwóch etapach”: analiza i postawienie diagnozy, projektowanie rozwiązania oraz zaplanowanie i wdrożenie kuracji. Owszem, są pewne różnice w stosunku do projektów IT, ale większość z nich to projekty polegające na ocenia stanu faktycznego (co chcemy ulepszyć) i planowaniu zmian (kuracji).

Niestety, podczas tak zwanych typowych analiz, opartych na wywiadach  i spotkaniach warsztatowych, im więcej interakcji tym większe pole do manipulacji i perswazji (świadomej lub nie, ale jednak). Po drugie, nie ma żadnej gwarancji, że niczego nie pominięto (w takich rozmowach w zasadzie omawiane są rzeczy ciekawe i rzadkie a prawie nigdy oczywiste). Świat radzi sobie z tym na różne sposoby, np. w medycynie są to badania specjalistyczne na odległość, gdzie lekarz specjalista nie zna pacjenta, widzi jedynie np. jego zdjęcie RTG lub wynik badania tomografem.

Drugim problemem i poważnym błędem jest uznanie, że “skoro te analizy to spotkania i zapisywanie ich wyników, to może to robić niemalże każdy byle był komunikatywny”. Bzdura. Po pierwsze takie działanie to nie są analizy a stenogramy ze spotkań, po drugie są one zapisem subiektywnego oglądu sytuacji, jaki mają odpytywani pracownicy danej firmy (do tego z ich tylko perspektywy).

Tak więc wykonanie analizy organizacji (analizy systemowej) nie polega na “rozmowach i wywiadach” a na dogłębnej ocenie tego co i jak się dzieje w “organizmie” danej firmy i ocena tego stanu rzeczy. Dalsze działania to opisanie sytuacji problemowej i ocena możliwych rozwiązań (scenariuszy). Dopiero teraz przychodzi pora na wdrożenie wybranego wariantu (kuracja o najniższym ryzyku). Można tu już dostrzec dwa etapy: analiza i rekomendacje oraz faktyczne leczenie (wdrażanie rozwiązania). Dobra praktyką (uodpornienie na perswazje i subiektywizm) jest oddzielnie analizy od wdrożenia a także bardziej studiowanie faktów niże subiektywnego ich opisu z ust “pacjenta” (ten może być uzupełnieniem ale nie jedynym źródłem).

Od pewnego czasu dobrze radzi sobie z tym medycyna:

Poziom znajomości elektrokardiografii jest znacznie zróżnicowany – różny zakres umiejętności w zakresie interpretacji EKG jest problemem zgłaszanym w wielu krajach nie tylko w Polsce. Centrum Telemedycyny odpowiada w tym zakresie na zapotrzebowanie wielu małych ośrodków (ZOZów, NZOZów), które bądź nie posiadają etatowo zatrudnionych specjalistów konsultujących zapisy EKG bądź specjaliści tacy są dostępni w bardzo ograniczonym zakresie.

Dzięki dedykowanym urządzeniom EKG ośrodek medyczny ma możliwość przesyłania do konsultanta-specjalisty badań elektrokardiograficznych i uzyskanie pełnej oraz fachowej informacji na temat rodzaju wady pacjenta i sposobu dalszego postępowania.  [wytł. moje] (Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w Instytucie Kardiologii – Artykuły – Nowoczesna klinika).

 

O co chodzi z tą zdalną analizą? W dużym skrócie badana firma gromadzi dokumenty operacyjne (czyli zapisy faktów) i przekazuje je do analizy, na ich podstawie odtwarzana jest wewnętrzna organizacja działania: procesy biznesowe, modele logiki biznesowej itp.(zdalna analiza biznesowa). Wymaga to jednak stosownego “wyposażenia”, o czym pisałem w poprzednim artykule (moje narzędzia analityka). Owszem skala takiej  analizy jest inna niż wykonanie i ocena badania tomografem komputerowym, ale metoda jest taka sama: prześwietlenie (analiza dokumentów operacyjnych), opracowanie modeli (zdjęcie) i rekomendacje (możliwe sposoby dalszego postępowania). Potem, zależnie od decyzji, angażowane są firmy (wybrane na bazie wymagań) wdrażające określone rozwiązanie.

 

Niedawno skończyłem projekt prowadzony właśnie tą metodą, drugi dobiega końca. Owszem, były spotkania, gdyż pewne działania (są takie w każdej firmie) są niesformalizowane i jedynym sposobem by je postać, jest zapytać i usłyszeć. Jednak cała analiza odbywa się w sposób praktycznie wykluczający, jakiekolwiek naciski czy perswazje. Informacje pozyskiwane z dokumentów są “zimne i obiektywne”, bardzo często zarządy badanych firm są zaskoczone wynikami. Praca odbywa się niemalże w czasie rzeczywistym, gdyż każdy powstający model (schemat blokowy) jest natychmiast przekazywany do oceny osobom odpowiedzialnych za dany obszar biznesowy i natychmiast komentowane (oprogramowanie do zdalnej pracy z modelami). Tak powstałe modele i opisy działania są “odarte” z wszelkiego “narzutu” zaciemniającego obraz sytuacji (produkt takiej analizy to nie 1000 stron a raczej 100 czyli można to przeczytać). Firma wdrażająca rozwiązanie także ma taki dostęp, wygląda to tak:

(zobacz także : opis pełnego procesu analizy)

Ludzie wykonujące dane prace mają tendencje do opisywania wszelkich znanych im wariantów, są ich nie raz setki, a tak na prawdę proces bywa jeden i to relatywnie prosty. Typowym przykładem jest gospodarka magazynowa: składa się tylko z kilku operacji i dokumentów: przyjęcie z zewnątrz, wydanie na zewnątrz, rozchód wewnętrzny, przyjęcie wewnętrzne, przesunięcie międzymagazynowe. Złożoność produkcji montażowej, sprzedaży czy dystrybucji tkwi w ilości tych operacji i złożoności opisu każdego faktu. Model gospodarki materiałowej jest prosty, problem bywa w tym, że materiałów jest dużo, mogą mieć ograniczony czas przydatności, skomplikowany sposób zamawiania itp.

Tak więc warto się zastanowić jak dotrzemy do wiedzy o naszej firmie, i na ile jest ona wiarygodna, nie zaciemniona nadmiarem zbędnych szczegółów i czy wiedza ta jest obiektywna. Dobra analiza konkretnej organizacji, firmy, urzędu, i jej wyniki nie może być np. polityczna (regularnie spotykam w firmach analizy, których celem jest wykazanie przydatności określonego rozwiązania!) bo to działanie polegające na oferowaniu leków przed diagnozą (reklamy leków bez recepty w TV!). Tak można sobie tylko zaszkodzić. A zdalna analiza (faktycznie zdalnie odbywa się ok. 80% pracy) pozawala po pierwsze obniżyć jej koszt, a po drugie zobiektywizować jej wyniki.

Osoby zainteresowane testem zdalnej analizy proszę o kontakt email, bezpłatny test nie dotyczy firm świadczących usługi o podobnym charakterze.

Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :).  O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech.

Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę, wykonywać jak najwięcej żmudnej pracy by dać czas analitykowi na pracę twórczą oraz wspierać prace grupową. Pamiętamy, że cały projekt powinien być kompletny, spójny i niesprzeczny, więc tak zwane śladowanie i analizy wzajemnego wpływu elementów projektu są ważne ale bardzo żmudne. To narzędzie robi je w tle automatycznie.

 

Jedną z najpopularniejszych i najskuteczniejszych technik analizy wymagań jest modelowanie procesów i mapowanie ich na przypadki użycia:

 Jeżeli z jakiegoś powodu preferowane są w projekcie zwinne metody pracy też można:

 

Jak może wyglądać analiza firmy i specyfikowanie wymagań:)?

 Dobre oprogramowanie powinno także pomagać w pracy grupowej, bo analiza to zawsze praca w zespole z pracownikami (ekspertami) organizacji analizowanej. Wspólna z klientem praca nad modelami:

 

Opracowanie prototypów ekranów, ważna część wymagań na dedykowane oprogramowanie:

 

Zarządzanie zadaniami w projekcie:

 

i wiele innych… 🙂

Kolejne analizy przedsiębiorstw za mną, a wraz z nimi obserwowane stereotypy i konformizm wielu moich klientów. Tym razem kilka słów o tym co to jest “system zintegrowany”. Otóż bardzo wielu ludzi utożsamia to pojęcie z “współdzieleniem danych”.  Sprzedawcy oprogramowania ERP jak mantrę powtarzają “nasz system jest zintegrowany bo wszystkie dane są wspólne, więc wszystkie informacje wprowadzany tylko raz i są wszędzie dostępne”. O ERP i integracji pisałem w Duży ERP czy integracja, o idei i wyższości integracji na poziomie usług zamiast współdzielenia danych pisałem w Wymagania pozafunkcjonalne … Teraz popatrzmy na to od strony architektury biznesowej.

 

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.