[toc]

Wprowadzenie

Bardzo wiele problemów w toku wdrożeń IT rodzą wadliwie zaprojektowane struktury dokumentów. Dotyczy to w szczególności zarządzania dostępem do treści, a patrząc szerzej: do informacji. Ostatnie lata to między innymi problemy urzędów z udzielaniem dostępu do informacji publicznej, od dwóch lat dodatkowo problemy stwarza RODO. Źródłem problemów jest treść dokumentów, rozumiana jako pytanie: “Czy te informacje muszą być zawarte w tym dokumencie”. Najpierw opiszę mechanizm powstawania przyczyn problemów i sposób ich rozwiązania. W podsumowaniu wskażę jak i gdzie sobie z tym radzić.

Struktury treści dokumentów

Po pewnym dość dużym projekcie, mającym w zakresie także ochronę kno-how, napisałem :

Każdy pro­jekt, czy to wdro­że­nie nowych zasad zarzą­dza­nia czy nowe­go opro­gra­mo­wa­nia, zwią­za­ny z zarzą­dza­niem orga­ni­za­cją, to (powi­nien być) tak­że co naj­mniej prze­gląd doku­men­tów i ich obie­gu. Kluczowym ele­men­tem tego prze­glą­du powin­na być ana­li­za tre­ści tych doku­men­tów, ich opty­mal­ność, nie tyl­ko ich obie­gu ale tak­że tre­ści i jej struk­tu­ry. Owszem, wie­le doku­men­tów ma narzu­co­ną struk­tu­rę np. w usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra VAT), nie ma jednak zaka­zu uzu­peł­nie­nia tej struk­tu­ry i np. doda­nia do fak­tu­ry nume­ru zamó­wie­nia, z któ­rym jest zwią­za­na (co umożliwia skojarzenie tych dokumentów ze sobą).

Ogólnie moż­na okre­ślić pew­ne pra­wi­dło­wo­ści:  jeże­li doku­men­ty są prze­cią­ża­ne tre­ścią, czy­li idzie­my w kie­run­ku małej ilo­ści doku­men­tów zawie­ra­ją­cych dużo danych, rośnie zło­żo­ność reguł pra­cy z takim doku­men­tem. Jeżeli zaś idzie­my w kie­run­ku doku­men­tów ??bar­dzo pro­stych?, rośnie ilość ich typów i rośnie licz­ba reguł koja­rzą­cych te doku­men­ty ze sobą w celu ich uży­cia. (Dokumenty czy niedokumenty…. czyli zarządzanie informacją i jej standaryzacja)

Dlatego bardzo ważną częścią projektu jest opracowanie polityki zarządzania informacją. Jednym z kluczowych jej elementów są szablony struktur dokumentów, bo tu właśnie realizowane są wymagania biznesowe:

Powyższy for­mu­larz jest tak­że naj­lep­szym miej­scem do poka­zy­wa­nia miej­sca reali­za­cji wyma­gań biz­ne­so­wych. Np. wyma­ga­nie ??System powi­nien pozwa­lać na gene­ro­wa­nie sta­tystyk rze­tel­no­ści klien­tów? skut­ku­je polem sta­tus oraz słow­ni­kiem (w dal­szej czę­ści) war­to­ści tego pola (będzie zawie­rał mię­dzy inny­mi war­tość ?zigno­ro­wa­na?). Tu waż­na infor­ma­cja: to ana­li­tyk pro­jek­tant, a nie deve­lo­per, ma zagwa­ran­to­wać (jeże­li pla­no­wa­ne jest opro­gra­mo­wa­nie dedy­ko­wa­ne) reali­za­cję wyma­gań funk­cjo­nal­nych! (Projekt aplikacji czyli bazy dokumentowe)

Kontrola dostępu do treści

Jednym z głównych problemów ochrony danych osobowych oraz ochrony know-how są przeciążone treścią dokumenty. Niestety, w toku wymiany dokumentów między podmiotami, nie zawsze jest możliwe “gumkowanie” ich fragmentów. Problem bywa poważny, gdy chodzi o ochronę danych osobowych i dostęp do informacji publicznej. Dlatego bardzo ważne jest, by w specyfikacji wymagań pojawiły się Wymagania na formularze (o czym pisałem wcześniej). Jest to element polityki zarządzania informacją w organizacji (Dokumenty czy niedokumenty…. czyli zarządzanie informacją i jej standaryzacja).

Budowanie polityk dostępu do treści jest znacznie prostsze na poziomie dokumentów niż ich pól: zamiast tworzyć odrębne reguły dla poszczególnych pól dokumentów, tworzymy nowy dokument o zmienionej strukturze (zawartości informacji) i tworzymy reguły dostępu dla całego dokumentu (określona nazwa takiej struktury to klasa dokumentów).

Dokumenty znane nam od lat (umowy, zamówienia, faktury, wydania z magazynów, itp.) często intuicyjnie były tworzone jako dedykowane odrębne zestawy redundantnych danych np. faktura zawierająca dane o cenach produktów i niemalże bliźniaczy dokument, jakim jest zlecenie wydania sprzedanego towaru z magazynu, niezawierającego cen, co pozwala zlecić magazynierom dokonanie operacji bez informowania ich o cenach transakcyjnych towarów (w wielu firmach ceny stanowią chronioną informacje handlową). Dlatego warto stosować zasadę utrzymania jednego kontekstu dla dokumentu: faktura ma kontekst finansowo-księgowy a dokumenty magazynowe mają kontekst ilościowy, bardzo często mają innych adresatów.

Ogromnym problemem, są wdrożenia systemów ERP nie respektujących zasady rozdzielenia kontekstów treści dokumentów! Jeżeli wewnętrzna integracja w systemie ERP polega na współdzieleniu danych w oparciu o relacyjny ich model, będzie to niemożliwe do zrealizowania.

Forma dokumentowa organizacji danych służy wyłącznie do zarządzania treścią i danymi, dlatego wszelkie obliczenia i statystyki prowadzone są z pomocą kopii danych zorganizowanych inaczej, np. w Hurtowniach Danych lub systemach typu Business Intelligence.

Opisana metoda organizacji informacji (opracowywanie dedykowanych, kontekstowych szablonów dokumentów) została z powodzeniem przeze mnie wykorzystana do projektowania i wdrażania oprogramowania dla administracji publicznej i dla przemysłu (ten fragment to cytat z mojej publikacji naukowej, w przygotowaniu, na temat zarządzania treścią).

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 istniejących dokumentów. Co jest poważnym błędem.

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?

Projektowanie struktury dokumentu

Kluczowym elementem opisu organizacji jest jej model informacyjny.

Generalnie infor­ma­cje są orga­ni­zo­wa­ne w nazwa­ne struk­tu­ry czy­li doku­men­ty. Tu waż­na uwa­ga: ludzie w pro­ce­sie komu­ni­ka­cji zawsze ope­ru­ją infor­ma­cją o okre­ślo­nej struk­tu­rze, bywa, że jest ona ? struk­tu­ra ? pro­sta, struk­tu­rą jest tak­że podział wymia­ny infor­ma­cji na odręb­ne komu­ni­ka­ty, gdzie jeden komu­ni­kat to ??jed­no pole for­mu­la­rza?. Nie zmie­nia to fak­tu, że taki komu­ni­kat to struk­tu­ra zawie­ra­ją­ca auto­ra i nadaw­cę komu­ni­ka­tu, odbior­cę komu­ni­ka­tu oraz jego treść, jest to for­mu­larz  ? struk­tu­ra ? jaką widzi­my pisząc np. kolej­ne­go maila.

W efek­cie moż­na przy­jąć, że wszel­kie infor­ma­cje w orga­ni­za­cjach są zor­ga­ni­zo­wa­ne z uży­ciem okre­ślo­nej licz­by for­mu­la­rzy, z któ­rych każ­dy ma okre­ślo­ną struk­tu­rę. Struktury te nazy­wa­my sza­blo­na­mi doku­men­tów (for­mu­la­rzy). Nie jest nie­ste­ty praw­dą, że infor­ma­cje są zor­ga­ni­zo­wa­ne w bazach danych rozu­mia­nych jako sys­tem rela­cyj­nych tablic.  Model rela­cyj­ny jest nie­na­tu­ral­ny i strat­ny. Człowiek nie jest w sta­nie korzy­stać z nie­go wprost, jest to tyl­ko jakaś tech­no­lo­gicz­na meto­da zapi­su danych. (Modele informacyjne)

Prostym i popularnym dokumentem biznesowym, obecnym w każdej firmie, jest np. Wniosek urlopowy. W aplikacjach na ekranie wygląda np. tak:

W wielu przypadkach jest to formularz wygenerowany z bazy danych. Jednak wniosek urlopowy może być (na wydrukach często jest) także tekstem, w postaci takiej jak np. ta poniższej:

Oznaczone na powyższym prototypie szare pola to miejsca na wprowadzane dane (znaczniki XML) i w tym miejscu mozna w dokumentacji wpisywać pojęcia ze słownika np. tak: ?urlop [typ urlopu] w dniach od [data początku] do [data końca]?. (więcej o formacie XML)

Dokument taki można zapisać w systemie informatycznym w postaci strukturalnego tekstu:

<wniosek_urlopowy>
<pracodawca>nazwa firmy</pracodawca>
Wniosek Urlopowy
Na podstawie art. 167 Kodeksu Pracy wnoszę o udzielenie urlopu w trybie "na żądanie" w terminie od
<data_początku_urlopu>xxxx.xx.xx</data_początku_urlopu> do  <data_końca_urlopu>xxxx.xx.xx</data_końca_urlopu> t.j. <liczba_dni_urlopu>xxx </liczba_dni_urlopu> dni. 
Jednocześnie oświadczam, że dotychczas wykorzystałem  <liczba_wykorzystanych_dni_urlopu>xxx </liczba_wykorzystanych_dni_urlopu> dni urlopu.
<pracownik>
<imię_pracownika>imię  </imię_pracownika> 
<nazwisko_pracownika>nazwisko <nazwisko_pracownika> 
</pracownik> 
Podstawa prawna: Ustawa z dnia 26 czerwca 1974, Kodeks Pracy (dziennik ustaw rok 2018, poz 917)
</wniowek_urlopowy>

Podsumowanie

Artykuł ten pisałem głównie z dwóch powodów: problemy wdrożeń systemów ERP oraz problemy ze stosowaniem RODO i udostępniania informacji publicznej. Te ostatnie mają pewną wspólną cechę: często wymagane ręczne anonimizowanie treści.

Przeciążone dokumenty (zbyt wiele treści) i blokowanie użytkownikowi dostępu do wybranych pól dokumentu powoduje, że monstrualnie rośnie złożoność logiki oprogramowania. Wyobraźmy sobie, że mamy 10 typów dokumentów i każdy ma 10 pól. Tradycyjna kontrola dostępu do treści to reguła dla każdego pola. Nawet, jeżeli uznamy, że połowa treści jest na dokumentach powielana (np. dane podmiotów) to i tak mówimy o kilkudziesięciu regułach kontroli dostępu do tych danych, które łącznie powinny być spójne i niesprzeczne. W modelu zakładającym kontrolę dostępu do dokumentu jako całości tych reguł będzie dokładnie 10. Dodatkowo będą relatywnie proste, bo dostęp do konkretnych dokumentów to konsekwencja roli użytkownika (w firmie, w procesie, itp.).

Gdyby np. systemy informatyczne i dokumenty urzędowe w nich przetwarzane, były zaprojektowane według ww. reguł, problemy dostępu do informacji publicznej oraz kontroli dostępu do danych wewnątrz tych instytucji w zasadzie by nie występowały. Na żądania dostępu do informacji publicznej odsyłane byłyby automatycznie dokumenty mające z góry określony kontekst, w całości. W przypadku RODO analogicznie. Anonimizowanie dokumentów też można by robić automatycznie (powyższy przykład: wniosek urlopowy można zanonimizować, automatycznie usuwając zawartość znaczników <xxx> zawierających dane osobowe. Wiele z tych informacji można byłoby udostępniać na stronie WWW (np. BIP) nawet w rybie bezwnioskowym automatycznie.

W czasie gdy piszę ten artykuł, na Facebooku, w jednej z grup, toczy się dyskusja jak udostępnić informację publiczną, jaką są wynagrodzenia osób pełniących funkcje publiczne, jeżeli system informatyczny drukuje wyłącznie listę płac zawierającą także inne, wrażliwe dane osobowe (np. potrącenia komornicze). Prawdopodobnie urzędników czeka ręczna anonimizacja tych list płac na koszt urzędu.

W opisany powyżej sposób zaprojektowałem między innymi:

• System informatyczny do obsługi ofert na realizację zadań publicznych w zakresie opieki nad Polonią i Polakami za granicą: Generator Ofert. (ogłoszenie o przetargu i kontakt do zamawiającego, uwagi i pytania zgłoszone do treści) [analiza i opracowanie OPZ – 1 miesiąc, implementacja i wdrożenie 4 m-ce]
• ?System Wspierania Realizacji Zadań ŻW? dla Oddziału Zabezpieczenia Żandarmerii Wojskowej (Opis Techniczny Przedmiotu Zamówienia). [analiza biznesowa i projektowanie ok. 6 m-cy z przerwami, implementacja i oddanie do użytku 4 m-c]
• Projekt standaryzacji procedur i dokumentów systemu utrzymania ruchu KGHM SA Polska Miedź. [analiza procesów, dokumentów, modele pojęciowe, opracowanie standaryzacji pojęciowej i struktur dokumentów, model standaryzacji procedur, 8 m-cy].
• wszystkie powyższe projekty objęte nadzorem autorskim w toku realizacji przez dostawców i wykonawców.