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

Czy wdrożenie zawsze wymaga reorganizacji?

Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi ini­cjo­wa­ny­mi przez śred­nie kadry kie­row­ni­cze dużych firm i urzę­dów, czę­sto mają one pew­ną wspól­ną cechę: nie może­my nic zmie­niać w stra­te­gii orga­ni­za­cji ale chce­my uspraw­nić pra­cę w naszym wydzia­le”. To z regu­ły bar­dzo cen­na ini­cja­ty­wa ale tak­że dobra dro­ga do poraż­ki pro­jek­tu. W urzę­dach czę­sto na gra­ni­cy łama­nia pra­wa… a nie raz z jego łama­niem. 

Projekty w admi­ni­stra­cji publicz­nej mają dodat­ko­wą spe­cy­fi­kę: zasa­dy usta­la pra­wo­daw­ca a nie mene­dżer orga­ni­za­cji. Bardzo dobrze opi­sał to zja­wi­sko prof. Bolesław Szafrański wska­zu­jąc przy­czy­nę wie­lu pora­żek wdro­żeń w admi­ni­stra­cji. Opisał trzy-eta­po­wy refe­ren­cyj­ny (i zale­ca­ny) pro­ces wdra­ża­nia nowych roz­wią­zań, a na jego tle, w swo­im opra­co­wa­niu, wska­zał dostrze­żo­ne zanie­dba­nia administracji:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, Architektura kor­po­ra­cyj­na ? pro­ble­my nie tyl­ko pojęciowe”)

Cytuję to opra­co­wa­nie, bo model ten jest bar­dzo podob­ny do ogól­nej trój­war­stwo­wej kon­cep­cji orga­ni­za­cji. Prof Szafrański zwra­ca uwa­gę na to (z czym się zga­dzam), że kolej­ność podej­mo­wa­nia decy­zji i dzia­łań, powin­na być nastę­pu­ją­ca: opra­co­wa­nie nowej lub zmie­nio­nej stra­te­gii (Dokument stra­te­gicz­ny), opra­co­wa­nie tak­ty­ki dzia­ła­nia (Model ope­ra­cyj­ny dzia­ła­nia) oraz opra­co­wa­nie pla­nu wdro­że­nia IT (Fundament dzia­łal­no­ści, w kon­tek­ście Architektury Korporacyjnej). Oczywiście nic nie stoi na prze­szko­dzie, by ini­cja­ty­wa wyszła od dołu”.

W swo­im opra­co­wa­niu prof. Szafrański wska­zu­je, że wdro­że­nie nowej stra­te­gii wyma­ga spraw­dze­nia i ewen­tu­al­ne­go opra­co­wa­nia nowych mecha­ni­zmów, pro­ce­dur, pra­wa, pozwa­la­ją­ce­go nie tyl­ko wdro­żyć nową stra­te­gię ale tak­że sku­tecz­nie ją wymu­sić”.

Jeżeli powyż­szy model uogól­nić do posta­ci obra­zu­ją­cej zwią­zek pomię­dzy: stra­te­gią ryn­ko­wą orga­ni­za­cji, wewnętrz­ną tak­ty­ką reali­za­cji misji oraz tym jak zosta­ły one zaim­ple­men­to­wa­ne, to powsta­nie taki oto dia­gram (po pra­wej zna­ne od lat opra­co­wa­nie Business Process Trends):

Jeżeli pomiąć for­mę praw­ną, każ­da orga­ni­za­cja ma stra­te­gię i każ­da jakoś ją reali­zu­je (imple­men­tu­je: ma pra­cow­ni­ków a Ci umie­jęt­no­ści i zakre­sy obo­wiąz­ków). Mało któ­ra orga­ni­za­cja ma tak zwa­ny model ope­ra­cyj­ny”, czy­li to co łączy stra­te­gię i ludzi z ich obo­wiąz­ka­mi i uzy­ski­wa­ny­mi efek­ta­mi pra­cy. Czym jest taki model? To model pro­ce­sów biz­ne­so­wych: środ­ko­wa war­stwa” powyż­sze­go dia­gra­mu po prawej.

Rozwijające się ewo­lu­cyj­nie orga­ni­za­cje zawsze doku­men­tu­ją deta­le prac (infor­ma­cje w pro­ce­du­rach zarzą­dza­nia jako­ścią i tak zwa­nych doku­men­tach kadro­wych), czę­sto doku­men­tu­ją to, jaką rolą peł­ni orga­ni­za­cja w swo­im oto­cze­niu (misja, wizja, stra­te­gie itp.) i bar­dzo rzad­ko doku­men­tu­ją wewnętrz­ny łań­cuch war­to­ści czy­li pro­ce­sy biz­ne­so­we oraz, no naj­waż­niej­sze, logi­ka tego jak to wszyst­ko dzia­ła” w środ­ku (i czy dzia­ła z sen­sem). Wadą więk­szo­ści tego typu pro­jek­tów, jakie obser­wu­ję, jest sku­pia­nie się na deta­lach i pomi­ja­nie pryn­cy­piów. W efek­cie pro­jekt pochła­nia wie­le pra­cy i nadal nie mamy zro­zu­mie­nia cało­ści (w lit. ang. big pic­tu­re”), osią­ga­ne efek­ty są losowe. 

Pokażę na dość pro­stym przy­kła­dzie o czym mowa (pole­cam ww. opra­co­wa­nie prof. Szafrańskiego, opi­sał w nim błę­dy popeł­nio­ne w przy­pad­ku infor­ma­ty­za­cji Państwa). 

Poniższy dia­gram to uprosz­czo­ny model orga­ni­za­cji z zain­sta­lo­wa­nym sys­te­mem EOD (Elektroniczny Obieg Dokumentów) oraz zacho­wa­nym, nadal wyko­rzy­sty­wa­nym po sta­re­mu” opro­gra­mo­wa­niem pocz­ty elektronicznej. 

Linie cią­głe to dro­ga jaką poko­nu­ją doku­men­ty z uży­ciem EOD. Linie prze­ry­wa­ne to pocz­ta elek­tro­nicz­na. Jeżeli zosta­nie w jakiejś orga­ni­za­cji zain­sta­lo­wa­ny EOD (celo­wo nie uży­wam sło­wa wdro­żo­ny”) i nie zosta­nie z niej usu­nię­ty ema­il jako narzę­dzie alter­na­tyw­nej wewnętrz­nej komu­ni­ka­cji, to użyt­kow­nik będzie sam decy­do­wał, o tym któ­rym kana­łem prze­ka­że daną treść. W efek­cie EOD, któ­ry miał mieć wszyst­ko” nie ma wszyst­kie­go, dane w EOD są nie­wia­ry­god­ne i nie­kom­plet­ne. Jeżeli jest to urząd, to metry­ka spra­wy w zasa­dzie nie ma sen­su, celem jej two­rze­nia była moż­li­wość odtwo­rze­nia peł­ne­go prze­bie­gu spra­wy, a tu urzęd­nik sam decy­du­je, któ­re infor­ma­cje i doku­men­ty prze­ka­zu­je kana­łem for­mal­nym (EOD), a któ­re na boku”. Czy wszyst­ko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tyl­ko uzna­nio­wym archi­wum dokumentów. 

Aby sku­tecz­nie wdro­żyć EOD nale­ży naj­pierw opra­co­wać nowy model ope­ra­cyj­ny dzia­ła­nia orga­ni­za­cji, model uwzględ­nia­ją­cy nowe narzę­dzie pra­cy, model któ­ry w spo­sób sys­te­mo­wy wyeli­mi­nu­je nie­po­żą­da­ne ele­men­ty złe­go sta­re­go sys­te­mu”. Dla przy­kła­du powy­żej nale­ży wyeli­mi­no­wać kana­ły komu­ni­ka­cyj­ne ozna­czo­ne linią prze­ry­wa­ną. Domyślam się, że wie­lu czy­tel­ni­ków myśli teraz no jak to tak bez maila?!”. Po wdro­że­niu EOD, wewnętrz­ny mail jest już nie potrzeb­ny (a nawet jest szko­dli­wy), a na zewnątrz nadal jest narzę­dziem komu­ni­ka­cji fir­ma-fir­ma (tak np. dzia­ła mój sys­tem komu­ni­ka­cji z klien­ta­mi). Bardzo czę­sto spo­ty­kam urzę­dy i fir­my, w któ­rych obieg ema­il i obieg for­mal­ny” to uzna­nio­wość pra­cow­ni­ków. Te wdro­że­nia nie speł­nia­ją pod­sta­wo­wej roli sys­te­mów EOD: śle­dze­nie spraw, sta­ty­sty­ki zaję­to­ści pra­cow­ni­ków, wychwy­ty­wa­nie wąskich gar­deł, łatwe zastę­po­wa­nie się pra­cow­ni­ków, moż­li­wość skon­tro­lo­wa­nia i prze­ję­cia spra­wy w dowol­nym momen­cie, peł­na histo­ria wymia­ny informacji. 

Takie wdro­że­nia to wła­śnie bar­dzo czę­sto ini­cja­ty­wy na śred­nich szcze­blach, gdzie mogą powstać decy­zje o wyda­niu środ­ków na takie wdro­że­nie, ale nie ma żad­nych szans na decy­zje o opra­co­wa­niu i wdro­że­niu zmian ope­ra­cyj­nych w ska­li orga­ni­za­cji (np. aktu­ali­za­cja instruk­cji kan­ce­la­ryj­nej w urzę­dzie, bez cze­go wdro­że­ni EOD nie ma tu żad­ne­go sensu).

Celowo poda­łem ten przy­kład, bo typo­wym powo­dem nie­po­wo­dzeń wdro­żeń sys­te­mów EOD czy CRM (te sys­te­my mają naj­gor­szą sta­ty­sty­kę nie­po­wo­dzeń, a są bar­dzo podob­ne do sie­bie), jest brak opra­co­wa­ne­go i wdro­żo­ne­go sku­tecz­ne­go nowe­go ope­ra­cyj­ne­go mode­lu dzia­ła­nia orga­ni­za­cji po wdro­że­niu”. Takim mode­lem są mode­le pro­ce­sów biz­ne­so­wych, ale nie w posta­ci mon­stru­al­nych ilo­ści deta­licz­nych dia­gra­mów (te są tu do nicze­go nie przy­dat­ne). Nie znam przy­pad­ku, by takie obraz­ki” się do cze­go­kol­wiek przy­da­ły. Chodzi o mode­le sfor­ma­li­zo­wa­ne, o ści­śle usta­lo­nym pozio­mie gra­da­cji pro­ce­sów. Ile dia­gra­mów powin­no być”? Tylko i aż tyle, ile trze­ba do roz­wią­za­nia pro­ble­mu… co opi­sa­łem mię­dzy inny­mi tu.

Powyższe ma tak­że inny istot­ny aspekt: pla­no­wa­nie i wdra­ża­nie zmian. Typowy roz­wój orga­ni­za­cji prze­bie­ga w spo­sób ewo­lu­cyj­ny, dość powol­ny. Nie wyma­ga żad­nych dodat­ko­wych zabie­gów poza prze­my­śla­nym wpro­wa­dza­niem nowych, poje­dyn­czych zarzą­dzeń czy drob­nych zmian orga­ni­za­cyj­nych. Jednak pró­by wdro­że­nia znacz­nych zmian w krót­kim cza­sie, z regu­ły skut­ku­ją nie­ocze­ki­wa­ny­mi efek­ta­mi, nie zawsze pożą­da­ny­mi. Moda” na re-inży­nie­rię pro­ce­sów biz­ne­so­wych w latach 90-tych prze­mi­nę­ła tak szyb­ko jak się poja­wi­ła. Dzisiejszy sil­nie kon­ku­ren­cyj­ny rynek nie daje cza­su na powol­ne, ewo­lu­cyj­ne zmia­ny. Bezpieczne zaś wpro­wa­dza­nie takich zmian nie jest moż­li­we bez przy­go­to­wa­nia. Opisane powy­żej pla­ny ope­ra­cyj­ne i ich testy, to nic inne­go jak wła­śnie przy­go­to­wa­nie się do takich zmian. Mając dobrze opra­co­wa­ne mode­le pro­ce­sów i archi­tek­tu­ry IT (jako całość Architektura Biznesowa/Korporacyjna), może­my prze­wi­dzieć i prze­te­sto­wać, więk­szość skut­ków pla­no­wa­nych zmian, i powo­li ale coraz wię­cej firm to robi… 

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… 

ECM i EOD czyli od mody do realiów

Obydwa te, spo­ty­ka­ne czę­sto w pra­sie, skró­ty mają wie­le wspól­ne­go: ozna­cza­ją apli­ka­cje zarzą­dza­ją­ce obie­giem infor­ma­cji i jej maga­zy­no­wa­niem (ECM – Electronic Content Management czy­li zarzą­dza­nie tre­ścią w posta­ci elek­tro­nicz­nej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawar­tą nie wprost” w tych nazwach jest zarzą­dza­nie tak­że skła­do­wa­niem i prze­pły­wem tej infor­ma­cji. Osiem lat temu pisa­łem o kwe­stiach poję­cio­wych (czym jest wie­dza, jej prze­twa­rza­nie, czym są dane):

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miej­sca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)

Niedawno, 26 stycz­nia 2016, mia­łem refe­rat na kon­fe­ren­cji pod hasłem Business Process Management:

W trak­cie refe­ra­tu zwró­ci­łem uwa­gę na to, że to co czę­sto nazy­wa­my zarzą­dza­niem pro­ce­sa­mi (popu­lar­ny skrót [[BPM]]) biz­ne­so­wy­mi, tak na praw­dę jest zarzą­dza­niem prze­pły­wem pra­cy, zarzą­dza­niem infor­ma­cją i nad­zo­ro­wa­niem tych aktyw­no­ści. Tu zwró­cę uwa­gę na to, że prze­pływ pra­cy odwzo­ro­wy­wa­ny jest w apli­ka­cji jako ciąg rapor­tów i notatek:

prze­ło­żo­ny dowia­du­je się o wyko­pa­niu rowu nie z wła­snej obser­wa­cji a z rapor­tu swo­je­go podwładnego 

dla­te­go opro­gra­mo­wa­nie może ope­ro­wać wyłącz­nie udo­ku­men­to­wa­ny­mi fak­ta­mi a nie zja­wi­ska­mi w real­nym świe­cie: to są zapi­sy jaki­mi zarzą­dza opro­gra­mo­wa­nie zarzą­dza­ją­ce sze­ro­ko poję­tą tre­ścią. Tak więc

zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi to nic inne­go jak zbie­ra­nie infor­ma­cji, prze­twa­rza­nie ich i decy­do­wa­nie o kolej­nych pra­cach do wyko­na­nia, infor­mu­jąc o tym wyko­naw­ców tych kolej­nych prac.

Aplikacja wspie­ra­ją­ca prze­pływ pra­cy to opro­gra­mo­wa­nie, któ­re pozwa­la na two­rze­nie for­mu­la­rzy (i zasad wery­fi­ka­cji ich popraw­no­ści) spe­cy­ficz­nych dla każ­de­go zada­nia, reguł biz­ne­so­wych narzu­ca­ją­cych opcjo­nal­ność i kolej­ność reali­za­cji zadań (aktyw­no­ści), kate­go­ry­zo­wa­nie tre­ści i zadań, udo­stęp­nia­nie powsta­łych treści:

ECM EOD Przypadki Użycia

Powyższy dia­gram przy­pad­ków uży­cia moż­na w zasa­dzie uznać za refe­ren­cyj­ny”, każ­da apli­ka­cja tego typu tak mogła by wyglą­dać, czy to wystar­czy dostaw­cy opro­gra­mo­wa­nia? Nie, bo cała wie­dza o kon­kret­nym wdro­że­niu tkwi w szcze­gó­łach. Gdzie one są? Pisałem o tym pra­wie rok temu:

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodza­je: (1) funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej apli­ka­cji), (2) poza-funk­cjo­nal­ne czy­li cechy jako­ścio­we, (3) dzie­dzi­no­we czy­li logi­ka biz­ne­so­wa. I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? (Źródło: Gdzie są te cho­ler­ne szcze­gó­ły | | Jarosław Żeliński IT-Consulting)

Jak widać, klucz tkwi w mode­lu dzie­dzi­ny sys­te­mu czy­li w spe­cy­fi­ce bran­ży, kon­kret­nej fir­my lub orga­ni­za­cji. Powyższe przy­pad­ki uży­cia, jak wyżej, to opis dowol­ne­go ECM/EOD”. Referencyjna archi­tek­tu­ra takie­go sys­te­mu mogła by mieć taką postać:

EOD BPM Architektura referencyjna

Dlaczego tak? Komponent zarzą­dza­ją­cy pro­ce­sa­mi odpo­wia­da za logi­kę kolej­no­ści prze­twa­rza­nia tre­ści. Repozytorium odpo­wia­da za zacho­wy­wa­nie i udo­stęp­nia­nie tre­ści. Dodano tu kom­po­nent Filesystem, gdyż oso­bi­ście jestem zwo­len­ni­kiem podej­ścia, w któ­rym doku­men­ty elek­tro­nicz­ne są skła­do­wa­ne nie w bazie danych (tak zwa­ne BLOB) a na dys­kach, a logi­ka zarzą­dza­nia nimi to odręb­ne opro­gra­mo­wa­nie (patrz euro­pejk­sie zale­ce­nia Moreq). Dzięki temu utra­ta lub zmian apli­ka­cji (i bazy danych) nie powo­du­je utra­ty zasobów.

Na czym więc pole­ga ana­li­za biz­ne­so­wa przed wdro­że­niem EOD/ECM? Czym są tu wyma­ga­nia? Są nimi regu­ły biz­ne­so­we, wzo­ry doku­men­tów i słow­ni­ki pojęć (danych). To tu tkwi naj­więk­sze ryzy­ko wdro­że­nia, klu­czem jest tu zawsze tak zwa­ny model poję­cio­wy. Powyższa archi­tek­tu­ra jest prze­ze mnie trak­to­wa­na jako refe­ren­cyj­na, gdyż gwa­ran­tu­je moż­li­wość odwzo­ro­wa­nia dowol­ne­go sys­te­mu zarzą­dza­nia infor­ma­cją”, taką lub podob­ną zale­ca­ną archi­tek­tu­rę moż­na spo­tkać w wie­lu opra­co­wa­niach na temat ECM.

Czy aby na pewno zarządzamy procesami biznesowymi?

Swego cza­su w arty­ku­le na temat reguł biz­ne­so­wych, pra­wie dwa lata temu, napi­sa­łem że pro­ces biz­ne­so­wy to nie przy­czy­na a sku­tek ogra­ni­czeń. W jed­nym ze swo­ich arty­ku­łów Ronald Ross (autor i współ­za­ło­ży­ciel Business Rules Group) napi­sał niedawno:

?Rules defi­ne the boun­da­ry betwe­en accep­ta­ble and unac­cep­ta­ble busi­ness acti­vi­ty.? (w dys­ku­sji o regu­łach: When can you call a busi­ness archi­tec­tu­re ?smart??) 

Przypominam ten cytat, gdyż regu­lar­nie sły­chać mod­ny slo­gan ostat­nich lat: zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi”. Tak więc sko­ro regu­ły wyzna­cza­ją gra­ni­cę pomię­dzy akcep­to­wal­ny­mi i nie­ak­cep­to­wal­ny­mi zacho­wa­nia­mi w biz­ne­sie” to zna­czy, że zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi” ozna­cza zarzą­dza­nie tymi gra­ni­ca­mi a nie pro­ce­sa­mi, bo te są efek­tem ist­nie­nia tej gra­ni­cy a nie odwrotnie.

Chyba nikt roz­sąd­ny nie powie, że ma bez­po­śred­ni wpływ na nurt wody w rze­cze, zarzą­dza­my linią brze­go­wą, bo ją może­my inży­nie­ryj­nie kształ­to­wać, woda popły­nie zawsze z góry na dól, nigdy pod górkę.

W ostat­nim roku bylem na kil­ku kon­fe­ren­cjach na temat obie­gu doku­men­tów, pro­ce­sach biz­ne­so­wych i zarzą­dza­niu tym wszyst­kim. Wszędzie moż­na było usły­szeć, że zarzą­dza się pro­ce­sa­mi”. Moim zda­niem to fałsz, uza­sad­nie­nie powyżej.

Wśród ogrom­nej licz­by funk­cjo­nu­ją­cych firm, jaki odse­tek ma mapy pro­ce­sów”? Znikomy. Czym więc zarzą­dza­ją tam Zarządy tych firm?

Poniżej umie­ści­łem pre­zen­ta­cje z kil­ku kon­fe­ren­cji na ten temat i na temat EOD (Elektroniczny Obieg Dokumentów). Opisałem tam pew­ne mecha­ni­zmy, któ­rych brak zro­zu­mie­nia jest jed­ną z głów­nych przy­czyn pora­żek wie­lu wdro­żeń sys­te­mów zwa­nych wdzięcz­nie work­flow czy docu­ment­flow. Należy pamię­tać, że pro­ces biz­ne­so­wy w orga­ni­za­cji to tak na praw­dę sekwen­cja prac koń­czo­nych doku­men­tem (opis tego co zro­bio­no, raport, notat­ka, dowód księ­go­wy, nowy doku­ment itp.)

Kluczowe tezy pierw­szej prezentacji:

  1. Przepływ doku­men­tów: prze­ka­zy­wa­nie tre­ści w wer­sji papie­ro­wej lub elek­tro­nicz­nej, pomię­dzy punk­ta­mi jej prze­twa­rza­nia. Ścieżka prze­pły­wu doku­men­tów może być z góry narzu­co­na lub kształ­to­wa­na decy­zja­mi w punk­tach prze­twa­rza­nia. Decyzje te tak­że mogą pod­le­gać ogra­ni­cze­niom (źr. opr. wła­sne autora).
  2. Procesy biz­ne­so­we są kształ­to­wa­ne przez sytu­ację praw­ną oraz struk­tu­rę orga­ni­za­cyj­na, zakre­sy obo­wiąz­ków i kompetencje.
  3. Pewne te same role są peł­nio­ne przez róż­nych pracowników.
  4. Przepływ doku­men­tów oraz ich repo­zy­to­rium to odręb­ne sys­te­my”.
  5. Większość wyma­gań funk­cjo­nal­nych jest reali­zo­wa­na wła­ści­wym zbu­do­wa­niem sys­te­mu meta­da­nych w repozytorium.
  6. Systemu ERP nie są sys­te­ma­mi pro­ce­so­wy­mi, to sys­te­my obsłu­gu­ją­ce sta­tu­sy poje­dyn­czych doku­men­tów, są nimi prak­tycz­nie tyl­ko dowo­dy księ­go­we (poza sys­te­ma­mi ERP prze­twa­rza­nych jest ok. 80% doku­men­tów takich jak umo­wy, ofer­ty, zapy­ta­nia, stro­ny WWW czy pro­ste notat­ki ze spo­tkań a tak­że doku­men­ty for­mal­ne np. zarządzenia).

Dlatego ana­li­za i spe­cy­fi­ko­wa­nie wyma­gań na sys­te­my prze­pły­wu doku­men­tów czy po pro­tu popra­wy pro­ce­sów biz­ne­so­wych to przy­go­to­wa­nie fir­my do zmian orga­ni­za­cyj­nych a nie spi­sy­wa­nie ocze­ki­wań pra­cow­ni­ków z nadzie­ją, że dział HR nie odczu­je tej zmia­ny. Nie zarzą­dza­my pro­ce­sa­mi, kształ­tu­je­my je.

Proponuje zapo­zna­nie się z tego­rocz­ny­mi moimi pre­zen­ta­cja­mi do refe­ra­tów na temat EOD:

  1. JZelinski – obieg infor­ma­cji co współ­dzie­li­my a co przepływa
  2. Kolejna rzecz to auto­ma­ty­za­cja, wie­le się o niej mówi, jed­nak nie jest to łatwe i rzad­ko kie­dy uda­je się osią­gnąć: Automatyzacja pro­ce­sów biz­ne­so­wych ? jak to zro­bić dobrze.
  3. Co nas cze­ka, co i jak wdra­żać, czy ERP to lekar­stwo na wszyst­ko? Kierunki roz­wo­ju sys­te­mów obie­gu doku­men­tów. 

Firmy zain­te­re­so­wa­ne szcze­gó­ła­mi refe­ra­tów a tak­że prze­pro­wa­dze­niem jed­no­dnio­we­go semi­na­rium dla pra­cow­ni­ków na ten temat zapra­szam do kontaktu.

Ginące dokumenty c.d. – Serwis Samorządowy PAP

Dwa lata temu w arty­ku­le W sądach i urzę­dach giną doku­men­ty, nie musi tak być pisa­łem o giną­cych doku­men­tach w urzę­dach i o tym jak tego uni­kać, pod­sta­wą był arty­kuł www​.PortalSamorzadowy​.pl gdzie pisa­no mię­dzy inny­mi o zagi­nię­ciu w sądach i urzę­dach 321 akt spraw w 2010 roku.

Osobiście uwa­ża­łem i nadal uwa­żam, że pro­blem tkwi w nie­wie­dzy i nie­chę­ci urzęd­ni­ków do sto­so­wa­nia instruk­cji kan­ce­la­ryj­nej, któ­ra – w wie­lu urzę­dach – czę­sto jest doku­men­tem wręcz nie zna­nym urzęd­ni­kom, mimo, że for­mal­nie wszy­scy są z nim zazna­jo­mie­ni. Potwierdza to nie­ste­ty ministerstwo:

MAC zapo­wia­da zwięk­sze­nie nad­zo­ru nad zarzą­dza­niem doku­men­ta­cją w urzę­dach i prze­strze­ga­niem instruk­cji kancelaryjnej.

Zdaniem [[wice­mi­ni­stra Stanisława Huskowskiego]] urzęd­ni­cy czę­sto posia­da­ją małą wie­dzę o zasa­dach pra­cy kan­ce­la­ryj­nej lub świa­do­mie nie prze­strze­ga­ją prze­pi­sów kan­ce­la­ryj­nych.

Na pro­blem bała­ga­nu w ozna­ko­wa­niu doku­men­tów urzę­do­wych zwró­cił uwa­gę poseł Henryk Siedlaczek. Jego zda­niem obec­nie panu­je nie­po­rzą­dek w nada­wa­niu przez urzę­dy róż­nych sygna­tur pism doty­czą­cych tej samej spra­wy. (Serwis Samorządowy PAP).

To co zaob­ser­wo­wa­łem w urzę­dach, z któ­ry­mi mia­łem do czy­nie­nia to nie­ste­ty potwier­dze­nie powyż­sze­go. Bywa, że nawet kie­row­ni­cy wyso­kie­go szcze­bla igno­ru­ją zapi­sy JRWA (Jednolity Rzeczowy Wykaz Akt – sys­tem zna­ko­wa­nia pism, inte­gral­na część każ­dej Instrukcji Kancelaryjnej) i two­rzą jakieś swo­je” sys­te­my zna­ko­wa­nia pism, szczy­tem było stwier­dze­nie pew­nej Pani, pod­czas ana­li­zy jaką pro­wa­dzi­łem (sze­fo­wa Sekretariatu!), że nie musi się do tej instruk­cji stosować.

Od tam­te­go cza­su minę­ły dwa lata, teraz dopie­ro Ministerstwa odpo­wie­dzial­ne za ten stan rze­czy, uzna­ło, że nale­ży coś z tym zrobić.

Swego cza­su, pra­cu­jąc dla jed­ne­go z urzę­dów cen­tral­nych, mode­lo­wa­łem sys­tem obie­gu doku­men­tów. Urząd był podzie­lo­ny na depar­ta­men­ty, doku­men­ty były czę­sto wysy­ła­ne (np. opi­nie, eks­per­ty­zy itp.) do innych urzę­dów, tam wsz­czy­na­ły nowe spra­wy (tecz­ki). W efek­cie jed­na zło­żo­na spra­wa (a tam pra­wie każ­da taka była) owo­co­wa­ła lawi­ną spraw” lokal­nych i teczek.

Tu małe wtrą­ce­nie” Archiwum Państwowe, przyj­mu­jąc doku­men­ty od urzę­dów, zarzą­dza nimi jako cało­ścią, pod­sta­wą jest znak spra­wy. Obecny sys­tem (każ­dy urząd ma swo­je JRWA) w zasa­dzie nie pozwa­la na łatwe powią­za­nie doku­men­tów z róż­nych urzę­dów powsta­łych w jed­nej sprawie.

Opracowałem pro­po­zy­cję zna­ko­wa­nia spraw, ujed­no­li­ca­ją­cą sys­tem zna­ko­wa­nia. Propozycja prak­tycz­nie do szu­fla­dy, bo nie nikt nie był tym zain­te­re­so­wa­ny, bez odgór­ne­go usta­le­nia taki pomysł był uto­pią. Nie zmie­nia to fak­tu, że z per­spek­ty­wy Narodowego Zasobu Archiwalnego pomysł cen­tra­li­za­cji wyda­je się sen­sow­ny. Tu akurat:

Huskowski nega­tyw­nie odno­si się przy tym do pro­po­zy­cji ujed­no­li­ce­nia spo­so­bu zna­ko­wa­nia pism dla wszyst­kich urzędów.

- Jeden znak spra­wy dla wszyst­kich urzę­dów, dopro­wa­dzi­ło­by do roz­my­cia odpo­wie­dzial­no­ści jed­no­stek za powsta­ją­cą i napły­wa­ją­cą do urzę­du doku­men­ta­cję. Obecny spo­sób zna­ko­wa­nia pism pozwa­la w spo­sób jed­no­znacz­ny ziden­ty­fi­ko­wać wytwór­cę pisma ? tłumaczy.

Przyznam, że nie zro­zu­mia­łem oba­wy Ministra, ale pew­nie o czymś nie wiem, pew­nie kon­sul­to­wał się już z Archiwum Państwowym. Mając jed­no­li­ty znak spra­wy oraz usta­wo­wo wyma­ga­ne metry­ki każ­de­go doku­men­tu, moim zda­niem nie powin­no być pro­ble­mu z usta­le­niem odpo­wie­dzial­no­ści. Co cie­ka­we, znak spra­wy zawie­ra­ją­cy mię­dzy inny­mi jej rodzaj oraz datę wsz­czę­cia, pozwa­lał by natych­miast oce­nić czy dana spra­wa jest roz­pa­try­wa­na w ter­mi­nie czy już nie na dowol­nym jej etapie.

Podczas wpro­wa­dza­nia usta­wy wyma­ga­ją­ce metry­ki słusz­nie zauwa­żo­no, że:

Zdaniem auto­rów usta­wy ma ona zwięk­szyć trans­pa­rent­ność czyn­no­ści podej­mo­wa­nych w okre­ślo­nej spra­wie admi­ni­stra­cyj­nej lub podat­ko­wej przez oso­by dzia­ła­ją­ce w ramach i w imie­niu dane­go orga­nu admi­ni­stra­cji. Dzięki temu moż­li­wa będzie kon­tro­la podej­mo­wa­nych czyn­no­ści oraz iden­ty­fi­ka­cja osób uczest­ni­czą­cych w zała­twia­niu spra­wy. (Serwis Samorządowy PAP).

Tak więc trzy­mam kciu­ki za Pana mini­stra Stanisława Huskowskiego, gra war­ta świecz­ki, bała­gan w urzę­dach jest ogrom­ny. Problem nie­ste­ty w tym, że opór będzie chy­ba wiel­ki, tam gdzie spo­ty­ka­łem wadli­wie zna­ko­wa­ne doku­men­ty (chy­ba wszę­dzie) stwier­dza­łem, że to woda na młyn” tych urzęd­ni­ków, któ­rzy nie lubią być roz­li­cza­ni ze swo­jej pracy.

listy, korespondencja, dużo, papierJest jed­nak dru­gi, bar­dzo duży, pro­blem o któ­rym się czę­sto mil­czy: prze­tar­gi i spe­cy­fi­ka­cje wyma­gań na sys­te­my obie­gu doku­men­tów. Bardzo czę­sto obser­wu­ję kry­ty­ko­wa­ny prze­ze mnie nie raz, spo­sób ogła­sza­nia prze­tar­gów: na opra­co­wa­nie i wyko­na­nie” czy­li dostaw­ca po wygra­niu prze­tar­gu dopie­ro opra­co­wu­je wyma­ga­nia na sys­tem EOD (elek­tro­nicz­ny obieg doku­men­tów). W efek­cie, sys­tem zna­ko­wa­nia doku­men­tów sta­je się zgni­łym kom­pro­mi­sem pomię­dzy tre­ścią instruk­cji kan­ce­la­ryj­nej a żąda­nia­mi urzęd­ni­ków, bez pod­pi­su któ­rych wyko­naw­ca nie zamknie pro­jek­tu (wyko­naw­ca bywa wręcz szan­ta­żo­wa­ny w ten spo­sób przez urzęd­ni­ków, sam tego doświadczałem).

Niestety, czę­sto fir­my IT – mimo dekla­ra­cji, że mają w tym obsza­rze doświad­cze­nie – pro­jek­tu­jąc opro­gra­mo­wa­nie nie raz w 100% bazu­ją na żąda­niach urzęd­ni­ków. W efek­cie, docho­dzi do kurio­zal­nych zapi­sów w doku­men­tach wyma­gań sys­tem ma pozwa­lać na pod­pi­sy­wa­nie decy­zji prze­ter­mi­no­wa­nym pod­pi­sem elek­tro­nicz­nym” (autor­ka zapi­su tego wyma­ga­nia była sze­fo­wa sekre­ta­ria­tu wyzna­czo­ną jako eks­pert mery­to­rycz­ny w pro­jek­cie w jed­nym z cen­tral­nych urzę­dów!). W zasa­dzie nie ma zna­cze­nie czy był to efekt złej woli tej Pani czy jej nie­kom­pe­ten­cji, błąd tkwi w sys­te­mie, któ­ry na to – tak pro­wa­dzo­ne pro­jek­ty – pozwala.

Nic nie trze­ba chy­ba wię­cej pisać, jeże­li pra­cow­ni­cy urzę­dów będą mie­li tu jaką­kol­wiek swo­bo­dę będzie źle.