[toc]

Wprowadzenie

Bardzo wie­le pro­ble­mów w toku wdro­żeń IT rodzą wadli­wie zapro­jek­to­wa­ne struk­tu­ry doku­men­tów. Dotyczy to w szcze­gól­no­ści zarzą­dza­nia dostę­pem do tre­ści, a patrząc sze­rzej: do infor­ma­cji. Ostatnie lata to mię­dzy inny­mi pro­ble­my urzę­dów z udzie­la­niem dostę­pu do infor­ma­cji publicz­nej, od dwóch lat dodat­ko­wo pro­ble­my stwa­rza RODO. Źródłem pro­ble­mów jest treść doku­men­tów, rozu­mia­na jako pyta­nie: ​„Czy te infor­ma­cje muszą być zawar­te w tym doku­men­cie”. Najpierw opi­szę mecha­nizm powsta­wa­nia przy­czyn pro­ble­mów i spo­sób ich roz­wią­za­nia. W pod­su­mo­wa­niu wska­żę jak i gdzie sobie z tym radzić. 

Struktury treści dokumentów

Po pew­nym dość dużym pro­jek­cie, mają­cym w zakre­sie tak­że ochro­nę 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 jed­nak 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ż­li­wia sko­ja­rze­nie tych doku­men­tó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 nie­do­ku­men­ty.… czy­li zarzą­dza­nie infor­ma­cją i jej stan­da­ry­za­cja)

Dlatego bar­dzo waż­ną czę­ścią pro­jek­tu jest opra­co­wa­nie poli­ty­ki zarzą­dza­nia infor­ma­cją. Jednym z klu­czo­wych jej ele­men­tów są sza­blo­ny struk­tur doku­men­tów, bo tu wła­śnie reali­zo­wa­ne są wyma­ga­nia 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 apli­ka­cji czy­li bazy doku­men­to­we)

Kontrola dostępu do treści

Jednym z głów­nych pro­ble­mów ochro­ny danych oso­bo­wych oraz ochro­ny know-how są prze­cią­żo­ne tre­ścią doku­men­ty. Niestety, w toku wymia­ny doku­men­tów mię­dzy pod­mio­ta­mi, nie zawsze jest moż­li­we ​„gum­ko­wa­nie” ich frag­men­tów. Problem bywa poważ­ny, gdy cho­dzi o ochro­nę danych oso­bo­wych i dostęp do infor­ma­cji publicz­nej. Dlatego bar­dzo waż­ne jest, by w spe­cy­fi­ka­cji wyma­gań poja­wi­ły się Wymagania na for­mu­la­rze (o czym pisa­łem wcze­śniej). Jest to ele­ment poli­ty­ki zarzą­dza­nia infor­ma­cją w orga­ni­za­cji (Dokumenty czy nie­do­ku­men­ty.… czy­li zarzą­dza­nie infor­ma­cją i jej stan­da­ry­za­cja).

Budowanie poli­tyk dostę­pu do tre­ści jest znacz­nie prost­sze na pozio­mie doku­men­tów niż ich pól: zamiast two­rzyć odręb­ne regu­ły dla poszcze­gól­nych pól doku­men­tów, two­rzy­my nowy doku­ment o zmie­nio­nej struk­tu­rze (zawar­to­ści infor­ma­cji) i two­rzy­my regu­ły dostę­pu dla całe­go doku­men­tu (okre­ślo­na nazwa takiej struk­tu­ry to kla­sa dokumentów). 

Dokumenty zna­ne nam od lat (umo­wy, zamó­wie­nia, fak­tu­ry, wyda­nia z maga­zy­nów, itp.) czę­sto intu­icyj­nie były two­rzo­ne jako dedy­ko­wa­ne odręb­ne zesta­wy redun­dant­nych danych np. fak­tu­ra zawie­ra­ją­ca dane o cenach pro­duk­tów i nie­mal­że bliź­nia­czy doku­ment, jakim jest zle­ce­nie wyda­nia sprze­da­ne­go towa­ru z maga­zy­nu, nie­za­wie­ra­ją­ce­go cen, co pozwa­la zle­cić maga­zy­nie­rom doko­na­nie ope­ra­cji bez infor­mo­wa­nia ich o cenach trans­ak­cyj­nych towa­rów (w wie­lu fir­mach ceny sta­no­wią chro­nio­ną infor­ma­cje han­dlo­wą). Dlatego war­to sto­so­wać zasa­dę utrzy­ma­nia jed­ne­go kon­tek­stu dla doku­men­tu: fak­tu­ra ma kon­tekst finan­so­wo-księ­go­wy a doku­men­ty maga­zy­no­we mają kon­tekst ilo­ścio­wy, bar­dzo czę­sto mają innych adresatów. 

Ogromnym pro­ble­mem, są wdro­że­nia sys­te­mów ERP nie respek­tu­ją­cych zasa­dy roz­dzie­le­nia kon­tek­stów tre­ści doku­men­tów! Jeżeli wewnętrz­na inte­gra­cja w sys­te­mie ERP pole­ga na współ­dzie­le­niu danych w opar­ciu o rela­cyj­ny ich model, będzie to nie­moż­li­we do zrealizowania. 

Forma doku­men­to­wa orga­ni­za­cji danych słu­ży wyłącz­nie do zarzą­dza­nia tre­ścią i dany­mi, dla­te­go wszel­kie obli­cze­nia i sta­ty­sty­ki pro­wa­dzo­ne są z pomo­cą kopii danych zor­ga­ni­zo­wa­nych ina­czej, np. w Hurtowniach Danych lub sys­te­mach typu Business Intelligence. 

Opisana meto­da orga­ni­za­cji infor­ma­cji (opra­co­wy­wa­nie dedy­ko­wa­nych, kon­tek­sto­wych sza­blo­nów doku­men­tów) zosta­ła z powo­dze­niem prze­ze mnie wyko­rzy­sta­na do pro­jek­to­wa­nia i wdra­ża­nia opro­gra­mo­wa­nia dla admi­ni­stra­cji publicz­nej i dla prze­my­słu (ten frag­ment to cytat z mojej publi­ka­cji nauko­wej, w przy­go­to­wa­niu, na temat zarzą­dza­nia treścią). 

Prawie zawsze obser­wu­ję, że pod­sta­wo­wym domyśl­nym zało­że­niem wdro­żeń sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie, jest uzna­nie a prio­ri nie­zmien­no­ści struk­tu­ry i wzo­rów ist­nie­ją­cych doku­men­tów. Co jest poważ­nym błędem. 

Z doświad­cze­nia mogę powie­dzieć, że ana­li­za i opty­ma­li­za­cja tre­ści doku­men­tów wewnętrz­nych może przy­nieść bar­dzo duże korzy­ści prze­kła­da­ją­ce się na duży wzrost wewnętrz­nej efek­tyw­no­ści i jako­ści pra­cy, a w przy­pad­ku wdro­żeń opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, pozwa­la nie raz cał­ko­wi­cie unik­nąć bar­dzo kosz­tow­nych i ryzy­kow­nych kasto­mi­za­cji. Zaryzykuje tezę, że kil­ka pro­jek­tów w ten spo­sób wręcz uratowałem?

Projektowanie struktury dokumentu

Kluczowym ele­men­tem opi­su orga­ni­za­cji jest jej model infor­ma­cyj­ny.

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 infor­ma­cyj­ne)

Prostym i popu­lar­nym doku­men­tem biz­ne­so­wym, obec­nym w każ­dej fir­mie, jest np. Wniosek urlo­po­wy. W apli­ka­cjach na ekra­nie wyglą­da np. tak:

W wie­lu przy­pad­kach jest to for­mu­larz wyge­ne­ro­wa­ny z bazy danych. Jednak wnio­sek urlo­po­wy może być (na wydru­kach czę­sto jest) tak­że tek­stem, w posta­ci takiej jak np. ta poniższej:

Oznaczone na powyż­szym pro­to­ty­pie sza­re pola to miej­sca na wpro­wa­dza­ne dane (znacz­ni­ki XML) i w tym miej­scu mozna w doku­men­ta­cji wpi­sy­wać poję­cia ze słow­ni­ka np. tak: ?urlop [typ urlo­pu] w dniach od [data począt­ku] do [data koń­ca]?. (wię­cej o for­ma­cie XML)

Dokument taki moż­na zapi­sać w sys­te­mie infor­ma­tycz­nym w posta­ci struk­tu­ral­ne­go 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łów­nie z dwóch powo­dów: pro­ble­my wdro­żeń sys­te­mów ERP oraz pro­ble­my ze sto­so­wa­niem RODO i udo­stęp­nia­nia infor­ma­cji publicz­nej. Te ostat­nie mają pew­ną wspól­ną cechę: czę­sto wyma­ga­ne ręcz­ne ano­ni­mi­zo­wa­nie treści. 

Przeciążone doku­men­ty (zbyt wie­le tre­ści) i blo­ko­wa­nie użyt­kow­ni­ko­wi dostę­pu do wybra­nych pól doku­men­tu powo­du­je, że mon­stru­al­nie rośnie zło­żo­ność logi­ki opro­gra­mo­wa­nia. Wyobraźmy sobie, że mamy 10 typów doku­men­tów i każ­dy ma 10 pól. Tradycyjna kon­tro­la dostę­pu do tre­ści to regu­ła dla każ­de­go pola. Nawet, jeże­li uzna­my, że poło­wa tre­ści jest na doku­men­tach powie­la­na (np. dane pod­mio­tów) to i tak mówi­my o kil­ku­dzie­się­ciu regu­łach kon­tro­li dostę­pu do tych danych, któ­re łącz­nie powin­ny być spój­ne i nie­sprzecz­ne. W mode­lu zakła­da­ją­cym kon­tro­lę dostę­pu do doku­men­tu jako cało­ści tych reguł będzie dokład­nie 10. Dodatkowo będą rela­tyw­nie pro­ste, bo dostęp do kon­kret­nych doku­men­tów to kon­se­kwen­cja roli użyt­kow­ni­ka (w fir­mie, w pro­ce­sie, itp.). 

Gdyby np. sys­te­my infor­ma­tycz­ne i doku­men­ty urzę­do­we w nich prze­twa­rza­ne, były zapro­jek­to­wa­ne według ww. reguł, pro­ble­my dostę­pu do infor­ma­cji publicz­nej oraz kon­tro­li dostę­pu do danych wewnątrz tych insty­tu­cji w zasa­dzie by nie wystę­po­wa­ły. Na żąda­nia dostę­pu do infor­ma­cji publicz­nej odsy­ła­ne były­by auto­ma­tycz­nie doku­men­ty mają­ce z góry okre­ślo­ny kon­tekst, w cało­ści. W przy­pad­ku RODO ana­lo­gicz­nie. Anonimizowanie doku­men­tów też moż­na by robić auto­ma­tycz­nie (powyż­szy przy­kład: wnio­sek urlo­po­wy moż­na zano­ni­mi­zo­wać, auto­ma­tycz­nie usu­wa­jąc zawar­tość znacz­ni­ków <xxx> zawie­ra­ją­cych dane oso­bo­we. Wiele z tych infor­ma­cji moż­na było­by udo­stęp­niać na stro­nie WWW (np. BIP) nawet w rybie bez­wnio­sko­wym automatycznie. 

W cza­sie gdy piszę ten arty­kuł, na Facebooku, w jed­nej z grup, toczy się dys­ku­sja jak udo­stęp­nić infor­ma­cję publicz­ną, jaką są wyna­gro­dze­nia osób peł­nią­cych funk­cje publicz­ne, jeże­li sys­tem infor­ma­tycz­ny dru­ku­je wyłącz­nie listę płac zawie­ra­ją­cą tak­że inne, wraż­li­we dane oso­bo­we (np. potrą­ce­nia komor­ni­cze). Prawdopodobnie urzęd­ni­ków cze­ka ręcz­na ano­ni­mi­za­cja tych list płac na koszt urzędu. 

W opi­sa­ny powy­żej spo­sób zapro­jek­to­wa­łem mię­dzy innymi: 

• System infor­ma­tycz­ny do obsłu­gi ofert na reali­za­cję zadań publicz­nych w zakre­sie opie­ki nad Polonią i Polakami za gra­ni­cą: Generator Ofert. (ogło­sze­nie o prze­tar­gu i kon­takt do zama­wia­ją­ce­go, uwa­gi i pyta­nia zgło­szo­ne do tre­ści) [ana­li­za i opra­co­wa­nie OPZ – 1 mie­siąc, imple­men­ta­cja i wdro­że­nie 4 m‑ce]
• ?System Wspierania Realizacji Zadań ŻW? dla Oddziału Zabezpieczenia Żandarmerii Wojskowej (Opis Techniczny Przedmiotu Zamówienia). [ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie ok. 6 m‑cy z prze­rwa­mi, imple­men­ta­cja i odda­nie do użyt­ku 4 m‑c]
• Projekt stan­da­ry­za­cji pro­ce­dur i doku­men­tów sys­te­mu utrzy­ma­nia ruchu KGHM SA Polska Miedź. [ana­li­za pro­ce­sów, doku­men­tów, mode­le poję­cio­we, opra­co­wa­nie stan­da­ry­za­cji poję­cio­wej i struk­tur doku­men­tów, model stan­da­ry­za­cji pro­ce­dur, 8 m‑cy].
• wszyst­kie powyż­sze pro­jek­ty obję­te nad­zo­rem autor­skim w toku reali­za­cji przez dostaw­ców i wykonawców.