Dziesięć lat temu pisałem o informacji i jej strukturalnym charakterze, wpis kończył się zdaniem:

czym więc jest Zarządzanie Wiedzą (milcząco zakładam, że zarządzać można czymś materialnym)? Jest to ?przechowywanie danych jednoznacznie zrozumiałych, opisujących określone i ograniczone liczbą fakty interpretowane jako pojmowalna przez adresata informacja?.Przemyślenia związane z tą ostatnią definicją pozostawiam Państwu. Ciąg dalszy może nastąpi? (źr. : Potrzeby informacyjne firmy ? Zarządzanie wiedzą | Jarosław Żeliński IT-Consulting)

Kontynuacją cytowanego tekstu będzie dzisiaj kwestia informacji i powiązanych z nią wymagań na oprogramowanie. Każdy projekt wytworzenia, lub nawet tylko dostarczenia gotowego, oprogramowania powinien mieć co najmniej dwie warstwy opisu: (1) co chcemy stworzyć i (2) jak to chcemy stworzyć. Pierwsza to tak zwana warstwa abstrakcyjna opisująca mechanizm funkcjonowania systemu. Druga to logiczna architektura systemu czyli pomysł na realizację (model Platform Independent). Na podstawie modelu PIM developer projektuje oprogramowanie, które wykona (Platform Specific Model). Jednak często dostawca istniejącego oprogramowania chce porównać logikę oprogramowania, które oferuje, z logiką opisaną jako wymaganą. Tu potrzebny jest nie model architektury PIM a model informacyjny opisujący logikę biznesową ale nie narzucający architektury (bo ta już istnieje).

Bardzo często głównym celem biznesowym, i zarazem wymaganiem, jest zarządzanie informacją czyli skończoną liczbą typów dokumentów o ustalonej (lub wymagającej ustalenia) treści i strukturze. Niestety często jest tak, że struktura dokumentów ulega pewnym zmianom przy zachowaniu głównego celu dla jakiego powstały, co utrudnia zadanie ale nie jest prawdę, że jest to powód do permanentnego modyfikowania oprogramowania. Odporność (gotowość) aplikacji na zmienność treści jest tu wymaganiem i system powinien sobie z tym poradzić.

W takich przypadkach modelując system warto skupić się wyłącznie na informacji i na tym jak jest ona zarządzana, pozostawiając pewne detale architektury dostawcy, który z zasady – jako developer – dysponuje większą wiedzą o dostępnych na rynku technologiach i narzędziach. W takich przypadkach warto opracować tak zwany model informacyjny. Nie jest on jednak ani bazą danych ani modelem dziedziny (przypominam, że obiektowy model dziedziny to komponent architektoniczny wzorca MVC). Jest to model związków logicznych między dokumentami opisujący mechanizmy korzystania z nich.

O informacji

Kluczowymi pojęciami w tym obszarze analiz są: nośnik, dokument, informacja, treść, dane, wiadomość, które można zobrazować w postaci związków pojęciowych (diagram faktów SBVR):

Dokument elektroniczny (obecny jako pojęcie od kilku lat w polskim prawie) jest definiowany jako
stanowiący odrębną całość znaczeniową zbiór danych uporządkowanych w określonej strukturze wewnętrznej i zapisany na informatycznym nośniku danych (na podstawie ustawy KPA¹ i SJP PWN). Innymi słowy: dokument elektroniczny to (uporządkowane) informacje zapisane na elektronicznym nośniku, jednak nośnikiem może być nadal np. papier, więc generalnie pod pojęciem dokument można (należy) rozumieć  “utrwaloną odrębną całość znaczeniową, zbiór danych uporządkowanych w określonej strukturze wewnętrznej”. Skoro odrębną, to także mającą unikalną nazwę, bez czego niemożliwe było by odwołanie się do takiego dokumentu. Kolejna ważna rzecz: znaczenie i struktura. Strukturę dokumentu  określa jego szablon, treść zaś to to co zostanie zapisane z użyciem tego szablonu. Przykład: słowo faktura oznacza obowiązujący szablon dokumentu mogącego, po wypełnieniu, zawierać informacje o tym, kto, komu, co, kiedy i za jaką kwotę sprzedał.

Generalnie informacje są organizowane w nazwane struktury czyli dokumenty. Tu ważna uwaga: ludzie w procesie komunikacji zawsze operują informacją o określonej strukturze, bywa, że jest ona – struktura – prosta, strukturą jest także podział wymiany informacji na odrębne komunikaty, gdzie jeden komunikat to “jedno pole formularza”. Nie zmienia to faktu, że taki komunikat to struktura zawierająca autora i nadawcę komunikatu, odbiorcę komunikatu oraz jego treść, jest to formularz  – struktura – jaką widzimy pisząc np. kolejnego maila.

W efekcie można przyjąć, że wszelkie informacje w organizacjach są zorganizowane z użyciem określonej liczby formularzy, z których każdy ma określoną strukturę. Struktury te nazywamy szablonami dokumentów (formularzy). Nie jest niestety prawdą, że informacje są zorganizowane w bazach danych rozumianych jako system relacyjnych tablic.  Model relacyjny jest nienaturalny i stratny. Człowiek nie jest w stanie korzystać z niego wprost, jest to tylko jakaś technologiczna metoda zapisu danych.

Model informacyjny organizacji

W związku z tym, mamy prawo uznać, że wszystkie informacje w firmie są zorganizowane w użyciem skończonej liczby struktur i nie są to struktury znane z relacyjnych baz danych, są to odrębne i niepołączone (niewspółdzielące danych) formularze, czyli po prostu odrębne dokumenty. Formularze te mogą być jawnie logicznie skojarzone np. na fakturach są nanoszone numery zamówień. Mogą być skojarzone nie wprost, z użyciem określonych reguł np. podatek za dany miesiąc naliczamy na podstawie faktur wystawionych w tym miesiącu albo dany referent ma dostęp do dokumentu, jeżeli ten związany jest ze sprawą aktualnie przydzieloną temu referentowi. Ostatni przykład to typowe dynamiczne powiązanie gdyż przydział referenta do sprawy, a więc także dokumentów z nią powiązanych, może ulegać zmianie w czasie.

Formularze te, ich zawartość oraz logika powiązań pomiędzy nimi, to system informacyjny organizacji. Każda organizacja cechuje się własnym, indywidualnym system informacyjnym, gdyż tylko część dokumentów ma z góry narzuconą strukturę np. prawem lub standardem branżowym. Reszta, struktura wewnętrznych dokumentów,  to decyzje wewnętrzne organizacji.

Postrzegam jako poważny błąd uznanie, że model informacyjny to jednolita relacyjna struktura danych (pojęć) podobna do (budowana na wzór) ontologii². Po pierwsze relacyjny model  danych przechowuje nie dokumenty a pojęcia, uznając związki między pojęciami za stałe relacje (co nie zawsze jest prawdą). Po drugie usuwanie redundancji w procesie zapisu danych z formularzy wymaga ich odtworzenia przy każdej próbie odtworzenia konkretnego dokumentu. Tak więc taka relacyjna baza danych nie przechowuje żadnych dokumentów a jedynie zbiór trwale powiązanych pojęć. Bardzo często mówi się, że informacje i wiedza to ontologia. Niestety tak nie jest, ontologia to system pojęć powiązanych związkami semantycznymi, stanowi opis językowa ale nie jest to wiedza o świecie a wiedza o języku.

Generalnie uważam, że nie jest informacją pojęcie, jego definicja i semantyczne powiązanie z innym pojęciem. To tyko model syntaktyka i semantyka pojęć. Faktura zaś to zbiór pojęć mających określoną strukturę i treść, wartość ma to  – wiedza – kto, co kiedy i od kogo kupił, a nie to co znaczy słowo produkt czy nabywca i jak jest semantycznie on powiązany z pojęciem sprzedawca. To co najwyżej pozwoli nam zrozumieć jaką treść zawiera faktura.

Kolejną wadą podejścia relacyjnego jest to, że baza taka stanowi niepodzielny monolit, w efekcie to co jest możliwe w rzeczywistości (np. praca z fakturą w całkowitym oderwaniu od odpowiadających jej zamówień) jest niemożliwe w systemie relacyjnym. Usuwanie redundancji powoduje także powstawanie dużego narzutu na zarządzanie historią zmian pól baz danych, co nie ma miejsca w rzeczywistych dokumentach (kartoteka klienta zawiera wyłącznie aktualne dane adresowe, historyczne są dostępne w historycznych dokumentach, np. aktualne dane adresowe klienta są w jego kartotece, jego adres z ubiegłego roku znajdziemy na dokumentach wystawionych temu klientowi w ubiegłym roku).

Rok temu pisałem przy podobnej okazji:

warto zauważyć, że zmienność środowiska biznesowego powoduje, że żadne decyzje o logice biznesowej nie są ostateczne, jednak są elementy niezmienne takie jak np. nasze dane osobowe. Tak więc to, co powszechnie nazywane jest ?modelem danych? (business data diagram) w rozumieniu opisanym przez autorki artykułu, nie ma racji bytu. Ma sens zachowanie zamówienia i osobno faktury, ale to czy regułą jest jedno zamówienie do jednej faktury, podlega zmianom wynikającym i ze zmienności prawa i ze zmienności modeli biznesowych. Nie widzę żadnego powodu deklarowania już na początku projektu, tego by nie więcej niż 5 osób mogło korzystać z jednego konta i subskrypcji. W szczególności nie widzę powodu by taka zasada była zawarta w samym kodzie aplikacji. (źr. : Biznesowy model danych ? nie chcemy | | Jarosław Żeliński IT-Consulting).

Problemy jakie wnosi do projektu oparcie się na jednym relacyjnym modelu danych dla całej aplikacji, są znane od lat:

a mimo to nadal jest on stosowany w sposób stanowiący zagrożenie dla całego projektu.

Czym więc jest model informacyjny organizacji? Jest to system szablonów dokumentów czyli ustalonych struktur informacyjnych wraz z logiką ich wzajemnych powiązań czyli asocjacji, świadomie unikam pojęcia relacji.  Relacja to trwały związek, zaś asocjacja to skojarzenie budowane na bazie określonej logiki czy zachodzącego faktu. Przykład: faktura skojarzona jest z osobą, która dokonała sprzedaży, jednak w momencie gdy upłynie termin ważności i faktura nie jest opłacona, jest ona automatycznie kojarzona z windykatorem i sprzedawca przestaje być za nią odpowiedzialny (być może nawet traci dostęp do jej treści, zgodnie z zasadą bezpieczeństwa mówiącą, że pracownicy mają dostęp wyłącznie do informacji potrzebnej do realizowania ich bieżących zadań i obowiązków).

Jak podejść do opracowania i udokumentowania systemu informacyjnego, czyli jak wykonać jego model? Pierwszy krok to zidentyfikowanie dokumentów. Podstawą będzie tu analiza procesów biznesowych i opracowanie ich modeli. Elementarny (atomowy) proces biznesowy to aktywność mająca wejście i wyjście, a konkretnie dane wejściowe i dane, który powstają jako produkt tej aktywności. Te dane to nic innego jak informacje o określonej strukturze. Oznacza to, że na modelu procesów (tu w notacji BPMN) każda aktywność musi mieć skojarzony dokument wejściowy i wyjściowy (element o nazwie DataObect w noracji BPMN), w przeciwnym razie taka aktywność nie powinna się pojawić na modelu.

Powyższy diagram zawiera modele dwóch odrębnych procesów: obsługa zapytań ofertowych oraz obsługa zamówień. Oba diagramy to najniższy poziom modelowania procesów, poziom elementarnych (atomowych) procesów biznesowych. Pozwala zidentyfikować wszystkie dokumenty i ich statusy.

Tu mała uwaga: nie ma żadnego sensu umieszczanie na takich modelach detalicznych prac takich jak “wprowadzenie danych zamawiającego” czy “sprawdzenie salda” bo to są elementy (kroki) procedur. Innymi słowy nie “rysujemy” na diagramach tego jak i w jakiej kolejności wypełnić pola formularza. Po pierwsze zaciemni to obraz, po drugie procedur, reguł biznesowych i słowników nie modelujemy z użyciem BPMN. Robi się to w postaci odrębnych dokumentów lub diagramów.

Powyższy model obrazuje sytuację, w której pewna firma odsyła oferty na zapytania, otrzymując zaś zamówienie, sprawdza je od strony formalnej i realizuje. Każdy taki model, dla pełnej zrozumiałości,  MUSI mieć załączone (diagramy, wzory wydruków, inne) struktury tych dokumentów. Dodatkiem będzie właśnie model informacyjny czyli logiczna struktura powiązań logicznych między dokumentami (korzystają z niej osoby pracujące z tymi dokumentami).

Prosta wersja takiego modelu informacyjnego może zostać wykonaną także w notacji BPMN:

Tu jednak możliwe jest pokazanie jedynie związków jakimi są tak zwane referencje, czyli wzajemne jawne odwołania (np. formularz oferty zawiera pole z numerem zapytania). Pełny model informacyjny można wykonać z użyciem notacji UML:

Powyższy diagram to klasy reprezentujące nazwane struktury dokumentów (ich typy) oraz związki logiczne między nimi (asocjacje w UML to nie są trwałe relacje znane z baz danych a jedynie związki semantyczne).   Związki te można zobrazować jeżeli są to trwałe (wbudowane w treść) binarne powiązania (związek pomiędzy dwoma klasami). Jednak związki dynamiczne, definiowane przez reguły biznesowe, nie dają się zobrazować dlatego poprzestajemy na wyspecyfikowaniu takiej reguły.

Powyższy diagram mówi nam, że:

• powiązanie pomiędzy oryginałem zapytania (np. jego skan na dysku) a wewnętrznym dokumentem Zapytanie od klienta, jest zawarte w dokumencie (formularz) Metadane zapytań (jest to klasa asocjacyjna UML), który (hipotetyczny szablon byłby w załączeniu) zawiera informacje o położeniu pliku na dysku i przydzielonym mu np. wewnętrznym numerze Zapytania,
• powiązanie pomiędzy Ofertą handlową a Zapytaniem jest wbudowane w Oferty w postaci numeru zapytania, jako jednego z atrybutów dokumentu Oferta (Oferta w swojej treści powołuje się na numer Zapytania, zobrazowano to asocjacją kwalifikowaną UML),
• związek pomiędzy dokumentem a osobą, która ma dostęp do jego treści opisuje reguła biznesowa mówiąca, że “Sprzedawca ma dostęp do dokumentów klientów, których jest opiekunem”, reguła ta została zaimplementowana w postaci dokumentu Opiekun (klasa asocjacyjna UML) , zakładamy że jest to formularz zawierający nazwę klienta i nazwę jego opiekuna (np. udokumentowana decyzja dyr. działu sprzedaży), te dokumenty mogą być w dowolnej chwili zmieniane, dodawane i usuwane.

Jak widać diagram nie zawiera asocjacji pomiędzy Sprzedawcą a dokumentami (dostęp Sprzedawcy do treści danego dokumentu), gdyż ich sensowne zobrazowanie na diagramie jest praktycznie niemożliwe.

Taki diagram zawiera precyzyjne informacje o tym jakie i jak powiązane z sobą informacje przetwarza organizacja. Nie jest to absolutnie coś co należy odwzorować jako model kodu, nie ma tu żadnych liczności klas, bo te także są (potencjalnie zmiennymi) regułami biznesowymi (np. reguła: jeden sprzedawca nie może się opiekować więcej niż dziesięcioma klientami). Nie jest to żaden model danych, struktury formularzy dokumentujemy osobno. Nie jest też powiedziane, że implementacja formularzy to tablice z kolumnami odpowiadającymi polom formularzy (to zresztą bardzo kiepski pomysł).

Pełna dokumentacja powinna zawierać w załączeniu detaliczne struktury tych formularzy (diagramy przedstawiające struktury XML, lub skomentowane mock-up’y dokumentów). Taka specyfikacja zawiera wszystkie informacje pozwalające developerowi stworzyć oprogramowanie służące do zbierania i zarządzania informacją. Jako model wymagań na systemy typu EOD³ jest wystarczająca.

Gdyby było prawdą, że wymagamy od oprogramowania także, by zawartość wybranych pól tych formularzy była wyliczana lub weryfikowana, musimy dodatkowo udokumentować  zależności między tymi polami. Model taki często warto uzupełnić wymaganą architekturą oprogramowania, bo od niej zależą cechy jakościowe aplikacji, tak zwane pozafunkcjonalne. Będzie to właśnie  model dziedziny systemu, opisywany na moim blogu wielokrotnie.

Poniżej cel i proces budowy modeli pojęciowych [zotpressInText item=”{5085975:BIBQ5WAW},{5085975:GUF2RNXW}”]:

Zapraszam także do lektury kontynuacji tego zagadnienia w artykule Bazy Dokumentowe.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Nie raz tu już pisałem, że analizy i projekty związane bezpośrednio z wymaganiami na oprogramowanie to “tylko” ok. 3/4 moich projektów. Jednak nawet, jeżeli projekt nie jest “nazwany” informatycznym, to zawsze jest “informacyjny” w rozumieniu zarządzania informacją (także zarządzanie wiedzą). Tym razem kilka słów na temat dokumentów. Stanowią one podstawową jednostkę informacji (i danych) w każdym systemie biznesowym. Są także źródłem danych dla hurtowni danych.

Wiele projektów związanych z dokumentami jest sprowadzanych do problemu:

“jakie mamy dokumenty i co z nimi robimy?”

Zaniedbuje się bardzo ważny element: odpowiedź na pytanie:

“czy nasze obecne dokumenty, ich ilość i treść, są właściwe?”

Otóż praktyka pokazuje, że dość często problemem są dokumenty opracowane “kiedyś tam”. Inicjuje się projekt z różnymi wymaganiami ale nikomu nie przychodzi do głowy by zastanowić się nad tym czy obecne dokumenty, w ich obecnej postaci, są  dobrym pomysłem i powinny takie pozostać.

Czy dokumenty są niezmienialnym bytem? Nie, nie są.

Każda organizacja obraca skończoną liczbą dokumentów, są to różnego rodzaju formularze, w najogólniejszym przypadku dokumentem jest po prostu każda treść, także “zwykła proza” np. notatka. Warto jednak zwrócić uwagę na to, że nawet ona ma pewną strukturę: np. autora, adresata, temat, datę i treść. Dokumenty to określona konkretna treść utrwalona z określonego powodu (w przeciwnym wypadku dokument nie by powstał). Osiem lat temu opisywałem kwestie różnicy między dokumentem, wiedzą, informacją a danymi:

Czy baza danych to wiedza?[?] Model jawnie pokazuje, że bezpośredni związek z Bazą Danych mają Dane. Dalej już są wyłącznie niematerialne pojęcia czym więc jest Zarządzanie Wiedzą (milcząco zakładam, że zarządzać można czymś materialnym)? Jest to ?przechowywanie danych jednoznacznie zrozumiałych, opisujących określone i ograniczone liczbą fakty interpretowane jako pojmowalna przez adresata informacja?. (Źródło: Potrzeby informacyjne firmy ? Zarządzanie wiedzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nieco o tym, dlaczego od czasu do czasu warto się pochylić nad wzorami dokumentów i czy czasem nie zmienić nieco podejścia do nich.

Dokumenty w organizacji

Swego czasu u jednego z moich klientów “odkryłem” ciekawy dokument. Była to faktura z dodanym zestawem danych odpowiadającym dokumentom WZ oraz analogicznym zestawieniem dotyczącym opakowań zwrotnych. Ten super dokument był pomysłem z przed wielu lat osoby odpowiedzialnej za wydawanie i zarządzanie opakowaniami zwrotnymi w magazynie. Uzasadnienie brzmiało: na jednym dokumencie będą wszystkie informacje związane z konkretną sprzedażą i dostawą. Brzmi ładnie jednak: praktycznie każdy kto miał z tym dokumentem do czynienia, w toku obsługi zamówienia, dostawał nadmiarowe dane, nie raz niejawne (niektóre) ceny, szczegóły zawartości paczek, wartość towaru (po co ta wiedza kierowcom), ilości i salda (tak) opakowań zwrotnych (jak się okazało dokument nie raz pomagał w nadużyciach, niektórzy pracownicy zaś zamazywali czasami część danych przekazując dokument dalej, by ich nie ujawniać). Ale największym problemem było to, że ta osoba uczyniła z tego wzoru dokumentu wymaganie wobec oprogramowania ERP. Jak się nie trudno domyśleć, żaden rynkowy system nie ma takiego dokumentu standardowo, dostawca ERP uznał to wymaganie bez zastrzeżeń, co przyczyniło się do wielu modyfikacji oprogramowania także w innych miejscach, znacznego wzrostu budżetu (współdzielona baza danych propaguje zmiany praktycznie na całą aplikację). Nie będę tu opisywał dalszych losów tego wzoru dokumentu bo celem moim było jedynie pokazanie problemu na realnym przykładzie.

Każdy projekt, czy to wdrożenie nowych zasad zarządzania czy nowego oprogramowania, związany z zarządzaniem organizacją, to (powinien być) także co najmniej przegląd dokumentów i ich obiegu. Kluczowym elementem tego przeglądu powinna być analiza treści tych dokumentów, ich optymalność, nie tylko obiegu ale także treści i jej struktury.  Owszem, wiele dokumentów ma narzuconą strukturę np. w odpowiedniej ustawie, jednak są to minimalne zawartości (np. faktura) nie ma zakazu uzupełnienia tej struktury i np. dodania do faktury numeru zamówienia, z którym jest związana.

Ogólnie można określić pewne prawidłowości:  jeżeli dokumenty są przeciążane treścią, czyli idziemy w kierunku małej ilości dokumentów zawierających dużo danych, rośnie złożoność reguł pracy z takim dokumentem. Jeżeli zaś idziemy w kierunku dokumentów “bardzo prostych”, rośnie ilość ich typów i rośnie liczba reguł kojarzących te dokumenty ze sobą w celu ich użycia. Ogólnie obrazuje to poniższy diagram:

Tak więc skrajnym rozwiązaniem będzie stworzenie jednego dokumentu, na którym będą wszystkie informacje np. związane z danym zamówieniem. Drugą skrajnością jest podzielenie informacji na odrębne małe niepodzielne już grupki, jak to ma miejsce w znormalizowanych relacyjnych bazach danych. Jeżeli megadokumenty to raczej bardzo rzadkie zjawisko, to przypadek drugi jest dość powszechny. To co nazywamy często dokumentem to tu tak na prawdę nieistniejący byt w relacyjnej bazie danych, generowany ad-hoc “w locie” z szeregu rozdrobnionych tablic danych.  Innymi słowy nie są to “stałe struktury” a pewna określona złożona logika, tworząca z prostych danych pobieranych z tablic, konkretne zestawy informacji np. faktury (to dlatego często w “języku dostawcy” faktura to raport a nie dokument!). Ta złożona logika realizowana jest (wykonywana w pamięci komputera) za każdym razem gdy odwołamy się do takiego dokumentu.

Optymalna sytuacja to rodzaj kompromisu pomiędzy złożonością logiki tworzenia i korzystania z dokumentu a jego zawartością. Na powyższym diagramie jest to obszar stanowiący okolice minimum krzywej opisującej zależność pomiędzy liczbą dokumentów a złożonością operowania nimi. Nie ma prostej reguły na opracowywanie i optymalizacje treści i liczby dokumentów jednak są pewne sprawdzone dobre praktyki, a mianowicie jeden dokument, o określonej strukturze, powinien zawierać dane o określonym zdarzeniu w określonym kontekście [powstaje teraz publikacja na ten temat, wydaje się można to jednak zdefiniować, przyp autora 2019]. Dokumenty te, podobnie jak fakty które dokumentują, mogą mieć każdy własny i różny od innych cykl życia, dlatego często bywa bardzo szkodliwe “rozdzielanie” ich na pola bazy danych i pozbycie się redundancji.

Przykładem mogą być: zamówienie jako udokumentowanie faktu zawarcia umowy na dostawę, faktura jako udokumentowanie faktu sprzedaży (przeniesienia własności) oraz dokument WZ dokumentujący fakt wydania z magazynu określonych produktów.  Bardzo często specyfikacja tego co wydano z magazynu nie jest tożsama z treścią faktury (sprzedano odkurzacz a wydano odkurzacz i zapasowe worki), na zamówieniu mógł być wyszczególniony odkurzacz, worki oraz wymagane końcówki (które są np. u producenta pakowane w standardzie więc nie ma ich ani na fakturze ani na WZ). Dlatego ma głęboki sens by te dokumenty były jednak “osobnymi dokumentami” a nie zachowywanymi w bazie danych danymi jako odrębne pola pozbawione redundancji, wymagające skomplikowanej logiki (polecenia SQL) by je (te “dokumenty”) pokazać na ekranie czy wydrukować.

To dość trywialny przykład, bo opisane dokumenty są wymagane przepisami jako dowody księgowe, jednak każda większa organizacja ma swoje wewnętrzne dokumenty, na których ilość i treść ma pełny wpływ. Po drugie nawet te dokumenty są często właśnie zapisywane w relacyjnych bazach danych jako rozproszone po małych tabelach dane, wymagające skomplikowanych operacji łączenia w jeden “dokument”, każdorazowo przy próbie jego użycia. Tu zachodzi bardzo duże ryzyko, że postać i treść takiego dokumentu ulegnie zmianie np. po reorganizacji bazy danych. Takich “dokumentów” nie da się (w tej postaci) podpisać elektronicznie, bo one po protu fizycznie na prawdę nie istnieją.

A jak inaczej? Nie ma żadnego problemu by dowolny dokument stanowił sobą jednolity byt np. zestaw danych w formacie XML, skojarzony ewentualnie ze swoją postacią gotową do druku albo np. plik PDF skojarzony z metadanymi opisującymi go (wybór jest na prawdę duży). Nie należy zapominać, że poza dokumentami, które są tworzone w organizacji operujemy dokumentami obcymi, otrzymanymi z zewnątrz i wypadało by mieć taki dokument w postaci takiej jaką przesłał nam ich twórca. Owszem pojawia się redundancja danych ale ona nie stanowi sobą nic złego. Ogromną korzyścią takiego podejścia jest rozwiązanie problemu polegającego na niemożności rozdzielenia “dokumentów” i logiki operowania nimi jeżeli są zapisane w postaci odrębnych pól w relacyjnej bazie danych. Np. staje się niemożliwe  pozostawienie faktur i wyniesienie dokumentów magazynowych do odrębnego systemu (w tym zmiana ich struktury) co ma miejsce nie raz przy wdrażaniu systemów WMS (systemy logistyczno-magazynowe). Takie operacji prawie żaden duży zintegrowany ERP nie wytrzyma (usłyszymy raczej, że “my dostosujemy do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma także inna ciekawą zaletę: jeżeli udokumentujemy osobno struktury dokumentów i logikę operowania nimi (także ich tworzenia), to otrzymamy obiektowy model organizacji: model pokazujący wzajemną współpracę obiektów biznesowych (dokumentów) odpowiedzialnych za przechowywanie informacji, obiektów odpowiedzialnych za rejestrowanie tych informacji, obiektów mających wiedzę jak operować tymi informacjami, obiektów udostępniających to wszystko zgodnie z określoną logiką.  Poniżej obiektowy model na którym od prawej mamy: dokumenty z ich treścią oraz logikę ich tworzenia i udostępniania (repozytoria czyli kuwetki na dokumenty), logikę korzystania z informacji w repozytoriach, także ich wzajemnego kojarzenia (samodzielne usługi) oraz logikę dostępu do tego systemu (realizacja scenariuszy przypadków użycia).  Jeżeli w toku analizy uznamy, że jakieś elementy tej logiki to zadania poddające się w 100% algorytmizacji, to poniższy model jest jednocześnie modelem logiki aplikacji i nazywamy go Modelem Dziedziny Systemu. Nie jest to absolutnie żadna baza danych, poniższe repozytoria niczego nie współdzielą (można je w dowolnym momencie zamieniać na inne bez konsekwencji dla reszty systemu).

Model ten powstał z użyciem bloków funkcjonalnych wzorca BCE (opisałem go tu: Wzorzec analityczny Boundary Control Entity). Dla wyjaśnienia: powyższy diagram to w pełni poprawny Model dziedziny wykonany z użyciem diagramu klas UML, klasy mają stereotypy boundary, control i entity (powyżej od lewej do prawej), stereotypy te są reprezentowane symbolami opisanymi (ikonami) w BCE. (Źródło: Krzywe i koszty? architektury | | Jarosław Żeliński IT-Consulting) 

Podsumowanie

Prawie zawsze obserwuję, że podstawowym domyślnym założeniem wdrożeń systemów wspomagających zarządzanie, jest uznanie a priori niezmienności struktury i wzorów dokumentów.

Z doświadczenia mogę powiedzieć, że analiza i optymalizacja treści dokumentów wewnętrznych może przynieść bardzo duże korzyści przekładające się na duży wzrost wewnętrznej efektywności i jakości pracy, a w przypadku wdrożeń oprogramowania wspomagającego zarządzanie, pozwala nie raz całkowicie uniknąć bardzo kosztownych i ryzykownych kastomizacji. Zaryzykuje tezę, że kilka projektów w ten sposób wręcz uratowałem… 

Przypominam, że systemy ERP inne o podobnej architekturze, nie przechowują dokumentów, bo dynamicznie generowane treści (raporty SQL, i podobne generowane “w locie” na API) to w świetle prawa nie są dokumenty, i słusznie bo nie istnieją w czasie.

Za trwały nośnik można uznać m.in. dokument papierowy, kartę pamięci, pendrive, wiadomość mailową lub załączony do niej plik, np. w formacie pdf. Samo hiperłącze przekierowujące na stronę internetową nie spełnia wymogów trwałego nośnika, jeżeli tego rodzaju strona internetowa nie spełnia cech trwałego nośnika. (https://uokik.gov.pl/zwrot-i-rekompensata-od-mpay-i-revolut-bank-uab)