Modele informacyjne

Dziesięć lat temu pisa­łem o infor­ma­cji i jej struk­tu­ral­nym cha­rak­te­rze, wpis koń­czył się zdaniem:

czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta informacja?.Przemyślenia zwią­za­ne z tą ostat­nią defi­ni­cją pozo­sta­wiam Państwu. Ciąg dal­szy może nastą­pi? (źr. : Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting) 

Kontynuacją cyto­wa­ne­go tek­stu będzie dzi­siaj kwe­stia infor­ma­cji i powią­za­nych z nią wyma­gań na opro­gra­mo­wa­nie. Każdy pro­jekt wytwo­rze­nia, lub nawet tyl­ko dostar­cze­nia goto­we­go, opro­gra­mo­wa­nia powi­nien mieć co naj­mniej dwie war­stwy opi­su: (1) co chce­my stwo­rzyć i (2) jak to chce­my stwo­rzyć. Pierwsza to tak zwa­na war­stwa abs­trak­cyj­na opi­su­ją­ca mecha­nizm funk­cjo­no­wa­nia sys­te­mu. Druga to logicz­na archi­tek­tu­ra sys­te­mu czy­li pomysł na reali­za­cję (model Platform Independent). Na pod­sta­wie mode­lu PIM deve­lo­per pro­jek­tu­je opro­gra­mo­wa­nie, któ­re wyko­na (Platform Specific Model). Jednak czę­sto dostaw­ca ist­nie­ją­ce­go opro­gra­mo­wa­nia chce porów­nać logi­kę opro­gra­mo­wa­nia, któ­re ofe­ru­je, z logi­ką opi­sa­ną jako wyma­ga­ną. Tu potrzeb­ny jest nie model archi­tek­tu­ry PIM a model infor­ma­cyj­ny opi­su­ją­cy logi­kę biz­ne­so­wą ale nie narzu­ca­ją­cy archi­tek­tu­ry (bo ta już istnieje).

Bardzo czę­sto głów­nym celem biz­ne­so­wym, i zara­zem wyma­ga­niem, jest zarzą­dza­nie infor­ma­cją czy­li skoń­czo­ną licz­bą typów doku­men­tów o usta­lo­nej (lub wyma­ga­ją­cej usta­le­nia) tre­ści i struk­tu­rze. Niestety czę­sto jest tak, że struk­tu­ra doku­men­tów ule­ga pew­nym zmia­nom przy zacho­wa­niu głów­ne­go celu dla jakie­go powsta­ły, co utrud­nia zada­nie ale nie jest praw­dę, że jest to powód do per­ma­nent­ne­go mody­fi­ko­wa­nia opro­gra­mo­wa­nia. Odporność (goto­wość) apli­ka­cji na zmien­ność tre­ści jest tu wyma­ga­niem i sys­tem powi­nien sobie z tym poradzić.

W takich przy­pad­kach mode­lu­jąc sys­tem war­to sku­pić się wyłącz­nie na infor­ma­cji i na tym jak jest ona zarzą­dza­na, pozo­sta­wia­jąc pew­ne deta­le archi­tek­tu­ry dostaw­cy, któ­ry z zasa­dy – jako deve­lo­per – dys­po­nu­je więk­szą wie­dzą o dostęp­nych na ryn­ku tech­no­lo­giach i narzę­dziach. W takich przy­pad­kach war­to opra­co­wać tak zwa­ny model infor­ma­cyj­ny. Nie jest on jed­nak ani bazą danych ani mode­lem dzie­dzi­ny (przy­po­mi­nam, że obiek­to­wy model dzie­dzi­ny to kom­po­nent archi­tek­to­nicz­ny wzor­ca MVC). Jest to model związ­ków logicz­nych mię­dzy doku­men­ta­mi opi­su­ją­cy mecha­ni­zmy korzy­sta­nia z nich.

O informacji

Kluczowymi poję­cia­mi w tym obsza­rze ana­liz są: nośnik, doku­ment, infor­ma­cja, treść, dane, wia­do­mość, któ­re moż­na zobra­zo­wać w posta­ci związ­ków poję­cio­wych (dia­gram fak­tów SBVR):

Dokument elek­tro­nicz­ny (obec­ny jako poję­cie od kil­ku lat w pol­skim pra­wie) jest defi­nio­wa­ny jako
sta­no­wią­cy odręb­ną całość zna­cze­nio­wą zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej i zapi­sa­ny na infor­ma­tycz­nym nośni­ku danych (na pod­sta­wie usta­wy KPA1 i SJP PWN). Innymi sło­wy: doku­ment elek­tro­nicz­ny to (upo­rząd­ko­wa­ne) infor­ma­cje zapi­sa­ne na elek­tro­nicz­nym nośni­ku, jed­nak nośni­kiem może być nadal np. papier, więc gene­ral­nie pod poję­ciem doku­ment moż­na (nale­ży) rozu­mieć utrwa­lo­ną odręb­ną całość zna­cze­nio­wą, zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej”. Skoro odręb­ną, to tak­że mają­cą uni­kal­ną nazwę, bez cze­go nie­moż­li­we było by odwo­ła­nie się do takie­go doku­men­tu. Kolejna waż­na rzecz: zna­cze­nie i struk­tu­ra. Strukturę doku­men­tu okre­śla jego sza­blon, treść zaś to to co zosta­nie zapi­sa­ne z uży­ciem tego sza­blo­nu. Przykład: sło­wo fak­tu­ra ozna­cza obo­wią­zu­ją­cy sza­blon doku­men­tu mogą­ce­go, po wypeł­nie­niu, zawie­rać infor­ma­cje o tym, kto, komu, co, kie­dy i za jaką kwo­tę sprzedał.

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.

Model informacyjny organizacji

W związ­ku z tym, mamy pra­wo uznać, że wszyst­kie infor­ma­cje w fir­mie są zor­ga­ni­zo­wa­ne w uży­ciem skoń­czo­nej licz­by struk­tur i nie są to struk­tu­ry zna­ne z rela­cyj­nych baz danych, są to odręb­ne i nie­po­łą­czo­ne (nie­współ­dzie­lą­ce danych) for­mu­la­rze, czy­li po pro­stu odręb­ne doku­men­ty. Formularze te mogą być jaw­nie logicz­nie sko­ja­rzo­ne np. na fak­tu­rach są nano­szo­ne nume­ry zamó­wień. Mogą być sko­ja­rzo­ne nie wprost, z uży­ciem okre­ślo­nych reguł np. poda­tek za dany mie­siąc nali­cza­my na pod­sta­wie fak­tur wysta­wio­nych w tym mie­sią­cu albo dany refe­rent ma dostęp do doku­men­tu, jeże­li ten zwią­za­ny jest ze spra­wą aktu­al­nie przy­dzie­lo­ną temu refe­ren­to­wi. Ostatni przy­kład to typo­we dyna­micz­ne powią­za­nie gdyż przy­dział refe­ren­ta do spra­wy, a więc tak­że doku­men­tów z nią powią­za­nych, może ule­gać zmia­nie w czasie.

Formularze te, ich zawar­tość oraz logi­ka powią­zań pomię­dzy nimi, to sys­tem infor­ma­cyj­ny orga­ni­za­cji. Każda orga­ni­za­cja cechu­je się wła­snym, indy­wi­du­al­nym sys­tem infor­ma­cyj­nym, gdyż tyl­ko część doku­men­tów ma z góry narzu­co­ną struk­tu­rę np. pra­wem lub stan­dar­dem bran­żo­wym. Reszta, struk­tu­ra wewnętrz­nych doku­men­tów, to decy­zje wewnętrz­ne organizacji.

Postrzegam jako poważ­ny błąd uzna­nie, że model infor­ma­cyj­ny to jed­no­li­ta rela­cyj­na struk­tu­ra danych (pojęć) podob­na do (budo­wa­na na wzór) onto­lo­gii2. Po pierw­sze rela­cyj­ny model danych prze­cho­wu­je nie doku­men­ty a poję­cia, uzna­jąc związ­ki mię­dzy poję­cia­mi za sta­łe rela­cje (co nie zawsze jest praw­dą). Po dru­gie usu­wa­nie redun­dan­cji w pro­ce­sie zapi­su danych z for­mu­la­rzy wyma­ga ich odtwo­rze­nia przy każ­dej pró­bie odtwo­rze­nia kon­kret­ne­go doku­men­tu. Tak więc taka rela­cyj­na baza danych nie prze­cho­wu­je żad­nych doku­men­tów a jedy­nie zbiór trwa­le powią­za­nych pojęć. Bardzo czę­sto mówi się, że infor­ma­cje i wie­dza to onto­lo­gia. Niestety tak nie jest, onto­lo­gia to sys­tem pojęć powią­za­nych związ­ka­mi seman­tycz­ny­mi, sta­no­wi opis języ­ko­wa ale nie jest to wie­dza o świe­cie a wie­dza o języku.

Generalnie uwa­żam, że nie jest infor­ma­cją poję­cie, jego defi­ni­cja i seman­tycz­ne powią­za­nie z innym poję­ciem. To tyko model syn­tak­ty­ka i seman­ty­ka pojęć. Faktura zaś to zbiór pojęć mają­cych okre­ślo­ną struk­tu­rę i treść, war­tość ma to – wie­dza – kto, co kie­dy i od kogo kupił, a nie to co zna­czy sło­wo pro­dukt czy nabyw­ca i jak jest seman­tycz­nie on powią­za­ny z poję­ciem sprze­daw­ca. To co naj­wy­żej pozwo­li nam zro­zu­mieć jaką treść zawie­ra faktura.

Kolejną wadą podej­ścia rela­cyj­ne­go jest to, że baza taka sta­no­wi nie­po­dziel­ny mono­lit, w efek­cie to co jest moż­li­we w rze­czy­wi­sto­ści (np. pra­ca z fak­tu­rą w cał­ko­wi­tym ode­rwa­niu od odpo­wia­da­ją­cych jej zamó­wień) jest nie­moż­li­we w sys­te­mie rela­cyj­nym. Usuwanie redun­dan­cji powo­du­je tak­że powsta­wa­nie duże­go narzu­tu na zarzą­dza­nie histo­rią zmian pól baz danych, co nie ma miej­sca w rze­czy­wi­stych doku­men­tach (kar­to­te­ka klien­ta zawie­ra wyłącz­nie aktu­al­ne dane adre­so­we, histo­rycz­ne są dostęp­ne w histo­rycz­nych doku­men­tach, np. aktu­al­ne dane adre­so­we klien­ta są w jego kar­to­te­ce, jego adres z ubie­głe­go roku znaj­dzie­my na doku­men­tach wysta­wio­nych temu klien­to­wi w ubie­głym roku).

Rok temu pisa­łem przy podob­nej okazji:

war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest ?mode­lem danych? (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie apli­ka­cji. (źr. : Biznesowy model danych ? nie chce­my | | Jarosław Żeliński IT-Consulting).

Problemy jakie wno­si do pro­jek­tu opar­cie się na jed­nym rela­cyj­nym mode­lu danych dla całej apli­ka­cji, są zna­ne od lat:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

a mimo to nadal jest on sto­so­wa­ny w spo­sób sta­no­wią­cy zagro­że­nie dla całe­go projektu.

Czym więc jest model infor­ma­cyj­ny orga­ni­za­cji? Jest to sys­tem sza­blo­nów doku­men­tów czy­li usta­lo­nych struk­tur infor­ma­cyj­nych wraz z logi­ką ich wza­jem­nych powią­zań czy­li aso­cja­cji, świa­do­mie uni­kam poję­cia rela­cji. Relacja to trwa­ły zwią­zek, zaś aso­cja­cja to sko­ja­rze­nie budo­wa­ne na bazie okre­ślo­nej logi­ki czy zacho­dzą­ce­go fak­tu. Przykład: fak­tu­ra sko­ja­rzo­na jest z oso­bą, któ­ra doko­na­ła sprze­da­ży, jed­nak w momen­cie gdy upły­nie ter­min waż­no­ści i fak­tu­ra nie jest opła­co­na, jest ona auto­ma­tycz­nie koja­rzo­na z win­dy­ka­to­rem i sprze­daw­ca prze­sta­je być za nią odpo­wie­dzial­ny (być może nawet tra­ci dostęp do jej tre­ści, zgod­nie z zasa­dą bez­pie­czeń­stwa mówią­cą, że pra­cow­ni­cy mają dostęp wyłącz­nie do infor­ma­cji potrzeb­nej do reali­zo­wa­nia ich bie­żą­cych zadań i obo­wiąz­ków).

Jak podejść do opra­co­wa­nia i udo­ku­men­to­wa­nia sys­te­mu infor­ma­cyj­ne­go, czy­li jak wyko­nać jego model? Pierwszy krok to ziden­ty­fi­ko­wa­nie doku­men­tów. Podstawą będzie tu ana­li­za pro­ce­sów biz­ne­so­wych i opra­co­wa­nie ich mode­li. Elementarny (ato­mo­wy) pro­ces biz­ne­so­wy to aktyw­ność mają­ca wej­ście i wyj­ście, a kon­kret­nie dane wej­ścio­we i dane, któ­ry powsta­ją jako pro­dukt tej aktyw­no­ści. Te dane to nic inne­go jak infor­ma­cje o okre­ślo­nej struk­tu­rze. Oznacza to, że na mode­lu pro­ce­sów (tu w nota­cji BPMN) każ­da aktyw­ność musi mieć sko­ja­rzo­ny doku­ment wej­ścio­wy i wyj­ścio­wy (ele­ment o nazwie DataObect w nora­cji BPMN), w prze­ciw­nym razie taka aktyw­ność nie powin­na się poja­wić na modelu.

Powyższy dia­gram zawie­ra mode­le dwóch odręb­nych pro­ce­sów: obsłu­ga zapy­tań ofer­to­wych oraz obsłu­ga zamó­wień. Oba dia­gra­my to naj­niż­szy poziom mode­lo­wa­nia pro­ce­sów, poziom ele­men­tar­nych (ato­mo­wych) pro­ce­sów biz­ne­so­wych. Pozwala ziden­ty­fi­ko­wać wszyst­kie doku­men­ty i ich statusy.

Tu mała uwa­ga: nie ma żad­ne­go sen­su umiesz­cza­nie na takich mode­lach deta­licz­nych prac takich jak wpro­wa­dze­nie danych zama­wia­ją­ce­go” czy spraw­dze­nie sal­da” bo to są ele­men­ty (kro­ki) pro­ce­dur. Innymi sło­wy nie rysu­je­my” na dia­gra­mach tego jak i w jakiej kolej­no­ści wypeł­nić pola for­mu­la­rza. Po pierw­sze zaciem­ni to obraz, po dru­gie pro­ce­dur, reguł biz­ne­so­wych i słow­ni­ków nie mode­lu­je­my z uży­ciem BPMN. Robi się to w posta­ci odręb­nych doku­men­tów lub diagramów.

Powyższy model obra­zu­je sytu­ację, w któ­rej pew­na fir­ma odsy­ła ofer­ty na zapy­ta­nia, otrzy­mu­jąc zaś zamó­wie­nie, spraw­dza je od stro­ny for­mal­nej i reali­zu­je. Każdy taki model, dla peł­nej zro­zu­mia­ło­ści, MUSI mieć załą­czo­ne (dia­gra­my, wzo­ry wydru­ków, inne) struk­tu­ry tych doku­men­tów. Dodatkiem będzie wła­śnie model infor­ma­cyj­ny czy­li logicz­na struk­tu­ra powią­zań logicz­nych mię­dzy doku­men­ta­mi (korzy­sta­ją z niej oso­by pra­cu­ją­ce z tymi dokumentami).

Prosta wer­sja takie­go mode­lu infor­ma­cyj­ne­go może zostać wyko­na­ną tak­że w nota­cji BPMN:

Tu jed­nak moż­li­we jest poka­za­nie jedy­nie związ­ków jaki­mi są tak zwa­ne refe­ren­cje, czy­li wza­jem­ne jaw­ne odwo­ła­nia (np. for­mu­larz ofer­ty zawie­ra pole z nume­rem zapy­ta­nia). Pełny model infor­ma­cyj­ny moż­na wyko­nać z uży­ciem nota­cji UML:

Powyższy dia­gram to kla­sy repre­zen­tu­ją­ce nazwa­ne struk­tu­ry doku­men­tów (ich typy) oraz związ­ki logicz­ne mię­dzy nimi (aso­cja­cje w UML to nie są trwa­łe rela­cje zna­ne z baz danych a jedy­nie związ­ki seman­tycz­ne). Związki te moż­na zobra­zo­wać jeże­li są to trwa­łe (wbu­do­wa­ne w treść) binar­ne powią­za­nia (zwią­zek pomię­dzy dwo­ma kla­sa­mi). Jednak związ­ki dyna­micz­ne, defi­nio­wa­ne przez regu­ły biz­ne­so­we, nie dają się zobra­zo­wać dla­te­go poprze­sta­je­my na wyspe­cy­fi­ko­wa­niu takiej reguły.

Powyższy dia­gram mówi nam, że:

  • powią­za­nie pomię­dzy ory­gi­na­łem zapy­ta­nia (np. jego skan na dys­ku) a wewnętrz­nym doku­men­tem Zapytanie od klien­ta, jest zawar­te w doku­men­cie (for­mu­larz) Metadane zapy­tań (jest to kla­sa aso­cja­cyj­na UML), któ­ry (hipo­te­tycz­ny sza­blon był­by w załą­cze­niu) zawie­ra infor­ma­cje o poło­że­niu pli­ku na dys­ku i przy­dzie­lo­nym mu np. wewnętrz­nym nume­rze Zapytania,
  • powią­za­nie pomię­dzy Ofertą han­dlo­wą a Zapytaniem jest wbu­do­wa­ne w Oferty w posta­ci nume­ru zapy­ta­nia, jako jed­ne­go z atry­bu­tów doku­men­tu Oferta (Oferta w swo­jej tre­ści powo­łu­je się na numer Zapytania, zobra­zo­wa­no to aso­cja­cją kwa­li­fi­ko­wa­ną UML),
  • zwią­zek pomię­dzy doku­men­tem a oso­bą, któ­ra ma dostęp do jego tre­ści opi­su­je regu­ła biz­ne­so­wa mówią­ca, że Sprzedawca ma dostęp do doku­men­tów klien­tów, któ­rych jest opie­ku­nem”, regu­ła ta zosta­ła zaim­ple­men­to­wa­na w posta­ci doku­men­tu Opiekun (kla­sa aso­cja­cyj­na UML) , zakła­da­my że jest to for­mu­larz zawie­ra­ją­cy nazwę klien­ta i nazwę jego opie­ku­na (np. udo­ku­men­to­wa­na decy­zja dyr. dzia­łu sprze­da­ży), te doku­men­ty mogą być w dowol­nej chwi­li zmie­nia­ne, doda­wa­ne i usuwane.

Jak widać dia­gram nie zawie­ra aso­cja­cji pomię­dzy Sprzedawcą a doku­men­ta­mi (dostęp Sprzedawcy do tre­ści dane­go doku­men­tu), gdyż ich sen­sow­ne zobra­zo­wa­nie na dia­gra­mie jest prak­tycz­nie niemożliwe.

Taki dia­gram zawie­ra pre­cy­zyj­ne infor­ma­cje o tym jakie i jak powią­za­ne z sobą infor­ma­cje prze­twa­rza orga­ni­za­cja. Nie jest to abso­lut­nie coś co nale­ży odwzo­ro­wać jako model kodu, nie ma tu żad­nych licz­no­ści klas, bo te tak­że są (poten­cjal­nie zmien­ny­mi) regu­ła­mi biz­ne­so­wy­mi (np. regu­ła: jeden sprze­daw­ca nie może się opie­ko­wać wię­cej niż dzie­się­cio­ma klien­ta­mi). Nie jest to żaden model danych, struk­tu­ry for­mu­la­rzy doku­men­tu­je­my osob­no. Nie jest też powie­dzia­ne, że imple­men­ta­cja for­mu­la­rzy to tabli­ce z kolum­na­mi odpo­wia­da­ją­cy­mi polom for­mu­la­rzy (to zresz­tą bar­dzo kiep­ski pomysł).

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up’y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD3 jest wystarczająca.

Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wielokrotnie. 

Poniżej cel i pro­ces budo­wy mode­li poję­cio­wych :

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011
M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011

Zapraszam tak­że do lek­tu­ry kon­ty­nu­acji tego zagad­nie­nia w arty­ku­le Bazy Dokumentowe.

Źródła

van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23 – 24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680‑5
Usman, Z., Young, R. I. M., Chungoora, N., Palmer, C., Case, K., & Harding, J. (2011). A Manufacturing Core Concepts Ontology for Product Lifecycle Interoperability. In M. van Sinderen & P. Johnson (Eds.), Enterprise Interoperability (pp. 5 – 18). Springer. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680-5_3

Dokumenty czy niedokumenty.… czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisa­łem, że ana­li­zy i pro­jek­ty zwią­za­ne bez­po­śred­nio z wyma­ga­nia­mi na opro­gra­mo­wa­nie to tyl­ko” ok. 3/4 moich pro­jek­tów. Jednak nawet, jeże­li pro­jekt nie jest nazwa­ny” infor­ma­tycz­nym, to zawsze jest infor­ma­cyj­ny” w rozu­mie­niu zarzą­dza­nia infor­ma­cją (tak­że zarzą­dza­nie wie­dzą). Tym razem kil­ka słów na temat doku­men­tów. Stanowią one pod­sta­wo­wą jed­nost­kę infor­ma­cji (i danych) w każ­dym sys­te­mie biz­ne­so­wym. Są tak­że źró­dłem danych dla hur­tow­ni danych.

Wstęp

Wiele pro­jek­tów zwią­za­nych z doku­men­ta­mi jest spro­wa­dza­nych do problemu:

jakie mamy doku­men­ty i co z nimi robimy?”

Zaniedbuje się bar­dzo waż­ny ele­ment: odpo­wiedź na pytanie:

czy nasze obec­ne doku­men­ty, ich ilość i treść, są właściwe?”

Otóż prak­ty­ka poka­zu­je, że dość czę­sto pro­ble­mem są doku­men­ty opra­co­wa­ne kie­dyś tam”. Inicjuje się pro­jekt z róż­ny­mi wyma­ga­nia­mi ale niko­mu nie przy­cho­dzi do gło­wy by zasta­no­wić się nad tym czy obec­ne doku­men­ty, w ich obec­nej posta­ci, są dobrym pomy­słem i powin­ny takie pozostać.

Czy doku­men­ty są nie­zmie­nial­nym bytem? Nie, nie są.

Każda orga­ni­za­cja obra­ca skoń­czo­ną licz­bą doku­men­tów, są to róż­ne­go rodza­ju for­mu­la­rze, w naj­ogól­niej­szym przy­pad­ku doku­men­tem jest po pro­stu każ­da treść, tak­że zwy­kła pro­za” np. notat­ka. Warto jed­nak zwró­cić uwa­gę na to, że nawet ona ma pew­ną struk­tu­rę: np. auto­ra, adre­sa­ta, temat, datę i treść. Dokumenty to okre­ślo­na kon­kret­na treść utrwa­lo­na z okre­ślo­ne­go powo­du (w prze­ciw­nym wypad­ku doku­ment nie by powstał). Osiem lat temu opi­sy­wa­łem kwe­stie róż­ni­cy mię­dzy doku­men­tem, wie­dzą, infor­ma­cją a danymi:

Czy baza danych to wie­dza?[?] Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta infor­ma­cja?. (Źródło: Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nie­co o tym, dla­cze­go od cza­su do cza­su war­to się pochy­lić nad wzo­ra­mi doku­men­tów i czy cza­sem nie zmie­nić nie­co podej­ścia do nich.

Dokumenty w organizacji

Swego cza­su u jed­ne­go z moich klien­tów odkry­łem” cie­ka­wy doku­ment. Była to fak­tu­ra z doda­nym zesta­wem danych odpo­wia­da­ją­cym doku­men­tom WZ oraz ana­lo­gicz­nym zesta­wie­niem doty­czą­cym opa­ko­wań zwrot­nych. Ten super doku­ment był pomy­słem z przed wie­lu lat oso­by odpo­wie­dzial­nej za wyda­wa­nie i zarzą­dza­nie opa­ko­wa­nia­mi zwrot­ny­mi w maga­zy­nie. Uzasadnienie brzmia­ło: na jed­nym doku­men­cie będą wszyst­kie infor­ma­cje zwią­za­ne z kon­kret­ną sprze­da­żą i dosta­wą. Brzmi ład­nie jed­nak: prak­tycz­nie każ­dy kto miał z tym doku­men­tem do czy­nie­nia, w toku obsłu­gi zamó­wie­nia, dosta­wał nad­mia­ro­we dane, nie raz nie­jaw­ne (nie­któ­re) ceny, szcze­gó­ły zawar­to­ści paczek, war­tość towa­ru (po co ta wie­dza kie­row­com), ilo­ści i sal­da (tak) opa­ko­wań zwrot­nych (jak się oka­za­ło doku­ment nie raz poma­gał w nad­uży­ciach, nie­któ­rzy pra­cow­ni­cy zaś zama­zy­wa­li cza­sa­mi część danych prze­ka­zu­jąc doku­ment dalej, by ich nie ujaw­niać). Ale naj­więk­szym pro­ble­mem było to, że ta oso­ba uczy­ni­ła z tego wzo­ru doku­men­tu wyma­ga­nie wobec opro­gra­mo­wa­nia ERP. Jak się nie trud­no domy­śleć, żaden ryn­ko­wy sys­tem nie ma takie­go doku­men­tu stan­dar­do­wo, dostaw­ca ERP uznał to wyma­ga­nie bez zastrze­żeń, co przy­czy­ni­ło się do wie­lu mody­fi­ka­cji opro­gra­mo­wa­nia tak­że w innych miej­scach, znacz­ne­go wzro­stu budże­tu (współ­dzie­lo­na baza danych pro­pa­gu­je zmia­ny prak­tycz­nie na całą apli­ka­cję). Nie będę tu opi­sy­wał dal­szych losów tego wzo­ru doku­men­tu bo celem moim było jedy­nie poka­za­nie pro­ble­mu na real­nym przykładzie.

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 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 odpo­wied­niej usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra) nie ma 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ązana.

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. Ogólnie obra­zu­je to poniż­szy diagram:

Liczba dokumentów vs ilośc treści na nich

Tak więc skraj­nym roz­wią­za­niem będzie stwo­rze­nie jed­ne­go doku­men­tu, na któ­rym będą wszyst­kie infor­ma­cje np. zwią­za­ne z danym zamó­wie­niem. Drugą skraj­no­ścią jest podzie­le­nie infor­ma­cji na odręb­ne małe nie­po­dziel­ne już grup­ki, jak to ma miej­sce w znor­ma­li­zo­wa­nych rela­cyj­nych bazach danych. Jeżeli mega­do­ku­men­ty to raczej bar­dzo rzad­kie zja­wi­sko, to przy­pa­dek dru­gi jest dość powszech­ny. To co nazy­wa­my czę­sto doku­men­tem to tu tak na praw­dę nie­ist­nie­ją­cy byt w rela­cyj­nej bazie danych, gene­ro­wa­ny ad-hoc w locie” z sze­re­gu roz­drob­nio­nych tablic danych. Innymi sło­wy nie są to sta­łe struk­tu­ry” a pew­na okre­ślo­na zło­żo­na logi­ka, two­rzą­ca z pro­stych danych pobie­ra­nych z tablic, kon­kret­ne zesta­wy infor­ma­cji np. fak­tu­ry (to dla­te­go czę­sto w języ­ku dostaw­cy” fak­tu­ra to raport a nie doku­ment!). Ta zło­żo­na logi­ka reali­zo­wa­na jest (wyko­ny­wa­na w pamię­ci kom­pu­te­ra) za każ­dym razem gdy odwo­ła­my się do takie­go dokumentu.

Optymalna sytu­acja to rodzaj kom­pro­mi­su pomię­dzy zło­żo­no­ścią logi­ki two­rze­nia i korzy­sta­nia z doku­men­tu a jego zawar­to­ścią. Na powyż­szym dia­gra­mie jest to obszar sta­no­wią­cy oko­li­ce mini­mum krzy­wej opi­su­ją­cej zależ­ność pomię­dzy licz­bą doku­men­tów a zło­żo­no­ścią ope­ro­wa­nia nimi. Nie ma pro­stej regu­ły na opra­co­wy­wa­nie i opty­ma­li­za­cje tre­ści i licz­by doku­men­tów jed­nak są pew­ne spraw­dzo­ne dobre prak­ty­ki, a mia­no­wi­cie jeden doku­ment, o okre­ślo­nej struk­tu­rze, powi­nien zawie­rać dane o okre­ślo­nym zda­rze­niu w okre­ślo­nym kon­tek­ście [powsta­je teraz publi­ka­cja na ten temat, wyda­je się moż­na to jed­nak zde­fi­nio­wać, przyp auto­ra 2019]. Dokumenty te, podob­nie jak fak­ty któ­re doku­men­tu­ją, mogą mieć każ­dy wła­sny i róż­ny od innych cykl życia, dla­te­go czę­sto bywa bar­dzo szko­dli­we roz­dzie­la­nie” ich na pola bazy danych i pozby­cie się redundancji.

Przykładem mogą być: zamó­wie­nie jako udo­ku­men­to­wa­nie fak­tu zawar­cia umo­wy na dosta­wę, fak­tu­ra jako udo­ku­men­to­wa­nie fak­tu sprze­da­ży (prze­nie­sie­nia wła­sno­ści) oraz doku­ment WZ doku­men­tu­ją­cy fakt wyda­nia z maga­zy­nu okre­ślo­nych pro­duk­tów. Bardzo czę­sto spe­cy­fi­ka­cja tego co wyda­no z maga­zy­nu nie jest toż­sa­ma z tre­ścią fak­tu­ry (sprze­da­no odku­rzacz a wyda­no odku­rzacz i zapa­so­we wor­ki), na zamó­wie­niu mógł być wyszcze­gól­nio­ny odku­rzacz, wor­ki oraz wyma­ga­ne koń­ców­ki (któ­re są np. u pro­du­cen­ta pako­wa­ne w stan­dar­dzie więc nie ma ich ani na fak­tu­rze ani na WZ). Dlatego ma głę­bo­ki sens by te doku­men­ty były jed­nak osob­ny­mi doku­men­ta­mi” a nie zacho­wy­wa­ny­mi w bazie danych dany­mi jako odręb­ne pola pozba­wio­ne redun­dan­cji, wyma­ga­ją­ce skom­pli­ko­wa­nej logi­ki (pole­ce­nia SQL) by je (te doku­men­ty”) poka­zać na ekra­nie czy wydrukować.

To dość try­wial­ny przy­kład, bo opi­sa­ne doku­men­ty są wyma­ga­ne prze­pi­sa­mi jako dowo­dy księ­go­we, jed­nak każ­da więk­sza orga­ni­za­cja ma swo­je wewnętrz­ne doku­men­ty, na któ­rych ilość i treść ma peł­ny wpływ. Po dru­gie nawet te doku­men­ty są czę­sto wła­śnie zapi­sy­wa­ne w rela­cyj­nych bazach danych jako roz­pro­szo­ne po małych tabe­lach dane, wyma­ga­ją­ce skom­pli­ko­wa­nych ope­ra­cji łącze­nia w jeden doku­ment”, każ­do­ra­zo­wo przy pró­bie jego uży­cia. Tu zacho­dzi bar­dzo duże ryzy­ko, że postać i treść takie­go doku­men­tu ule­gnie zmia­nie np. po reor­ga­ni­za­cji bazy danych. Takich doku­men­tów” nie da się (w tej posta­ci) pod­pi­sać elek­tro­nicz­nie, bo one po pro­tu fizycz­nie na praw­dę nie istnieją.

A jak ina­czej? Nie ma żad­ne­go pro­ble­mu by dowol­ny doku­ment sta­no­wił sobą jed­no­li­ty byt np. zestaw danych w for­ma­cie XML, sko­ja­rzo­ny ewen­tu­al­nie ze swo­ją posta­cią goto­wą do dru­ku albo np. plik PDF sko­ja­rzo­ny z meta­da­ny­mi opi­su­ją­cy­mi go (wybór jest na praw­dę duży). Nie nale­ży zapo­mi­nać, że poza doku­men­ta­mi, któ­re są two­rzo­ne w orga­ni­za­cji ope­ru­je­my doku­men­ta­mi obcy­mi, otrzy­ma­ny­mi z zewnątrz i wypa­da­ło by mieć taki doku­ment w posta­ci takiej jaką prze­słał nam ich twór­ca. Owszem poja­wia się redun­dan­cja danych ale ona nie sta­no­wi sobą nic złe­go. Ogromną korzy­ścią takie­go podej­ścia jest roz­wią­za­nie pro­ble­mu pole­ga­ją­ce­go na nie­moż­no­ści roz­dzie­le­nia doku­men­tów” i logi­ki ope­ro­wa­nia nimi jeże­li są zapi­sa­ne w posta­ci odręb­nych pól w rela­cyj­nej bazie danych. Np. sta­je się nie­moż­li­we pozo­sta­wie­nie fak­tur i wynie­sie­nie doku­men­tów maga­zy­no­wych do odręb­ne­go sys­te­mu (w tym zmia­na ich struk­tu­ry) co ma miej­sce nie raz przy wdra­ża­niu sys­te­mów WMS (sys­te­my logi­stycz­no-maga­zy­no­we). Takie ope­ra­cji pra­wie żaden duży zin­te­gro­wa­ny ERP nie wytrzy­ma (usły­szy­my raczej, że my dosto­su­je­my do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma tak­że inna cie­ka­wą zale­tę: jeże­li udo­ku­men­tu­je­my osob­no struk­tu­ry doku­men­tów i logi­kę ope­ro­wa­nia nimi (tak­że ich two­rze­nia), to otrzy­ma­my obiek­to­wy model orga­ni­za­cji: model poka­zu­ją­cy wza­jem­ną współ­pra­cę obiek­tów biz­ne­so­wych (doku­men­tów) odpo­wie­dzial­nych za prze­cho­wy­wa­nie infor­ma­cji, obiek­tów odpo­wie­dzial­nych za reje­stro­wa­nie tych infor­ma­cji, obiek­tów mają­cych wie­dzę jak ope­ro­wać tymi infor­ma­cja­mi, obiek­tów udo­stęp­nia­ją­cych to wszyst­ko zgod­nie z okre­ślo­ną logi­ką. Poniżej obiek­to­wy model na któ­rym od pra­wej mamy: doku­men­ty z ich tre­ścią oraz logi­kę ich two­rze­nia i udo­stęp­nia­nia (repo­zy­to­ria czy­li kuwet­ki na doku­men­ty), logi­kę korzy­sta­nia z infor­ma­cji w repo­zy­to­riach, tak­że ich wza­jem­ne­go koja­rze­nia (samo­dziel­ne usłu­gi) oraz logi­kę dostę­pu do tego sys­te­mu (reali­za­cja sce­na­riu­szy przy­pad­ków uży­cia). Jeżeli w toku ana­li­zy uzna­my, że jakieś ele­men­ty tej logi­ki to zada­nia pod­da­ją­ce się w 100% algo­ryt­mi­za­cji, to poniż­szy model jest jed­no­cze­śnie mode­lem logi­ki apli­ka­cji i nazy­wa­my go Modelem Dziedziny Systemu. Nie jest to abso­lut­nie żad­na baza danych, poniż­sze repo­zy­to­ria nicze­go nie współ­dzie­lą (moż­na je w dowol­nym momen­cie zamie­niać na inne bez kon­se­kwen­cji dla resz­ty systemu).

Obiektowy model dziedziny Zasada SOLID

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. (Źródło: Krzywe i kosz­ty? archi­tek­tu­ry | | Jarosław Żeliński IT-Consulting

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 dokumentów. 

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…