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… 

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.

teczki, akta, papiery

Podwójny obieg dokumentów w urzędach

Mamy kolej­ny przy­kład zja­wi­ska”. Jest ono nie raz potę­pia­ne ale czy aby na pew­no słusz­nie? Moim zda­niem nale­ży bar­dzo ostroż­nie pod­cho­dzić do pozby­wa­nia się” papie­ru. A jak to widzą sami urzędnicy?

Jak oce­ni Pan stan e‑administracji w gmi­nach? Fatalnie. Na razie moż­li­wo­ści gmin w zakre­sie e‑administracji są bar­dzo ogra­ni­czo­ne i nie spo­dzie­wam się, żeby to szyb­ko ruszy­ło. Cały czas mamy, nie­ste­ty, podwój­ny obieg dokumentów.

Podwójny obieg doku­men­tów czy­li co? Samo ist­nie­nie doku­men­tu w wer­sji papie­ro­wej i elek­tro­nicz­nej czy może fak­tycz­nie pismo papie­ro­we dublu­je eta­py obsłu­gi doku­men­tu elektronicznego?

Usunięcie papie­ro­wych (trwa­łych posta­ci fizycz­nych) egzem­pla­rzy może być dłu­go jesz­cze nie moż­li­we. Zaryzykuję tezę, że nawet nie­ce­lo­we. Całkowite zastą­pie­nie jest ryzy­kow­ne bo znisz­cze­nie wer­sji elek­tro­nicz­nej (np. bazy danych) to może być zda­rze­nie trwa­ją­ce uła­mek sekun­dy a stra­ty mogą być nie­od­wra­cal­ne. Koszt zabez­pie­cze­nia się przed taką ewen­tu­al­no­ścią nie raz jest znacz­nie więk­szy od zarzą­dza­nia papie­ro­wym archi­wum, któ­re­go cał­ko­wi­te znisz­cze­nie jest jed­nak pra­co­chłon­ne i cza­so­chłon­ne” co w pew­nym sen­sie zabez­pie­cza przed natych­mia­sto­wą jego utra­tą. Owszem, mamy reje­stry w wer­sji elek­tro­nicz­nej: PESEL czy KRS ale to reje­stry i są zabez­pie­czo­ne, to nie archi­wa doku­men­tów o wyso­kiej rota­cji zawartości…

Idźmy jed­nak dalej. Po wdro­że­niu systemu…

[…] Został więc zaan­ga­żo­wa­ny dodat­ko­wy pra­cow­nik, któ­ry zaj­mu­je się obie­giem doku­men­tów ? prze­twa­rza je, reje­stru­je, poda­je do poszcze­gól­nych refe­ra­tów, a następ­nie kon­tro­lu­je ter­mi­no­wość zała­twie­nia spra­wy, co jest bar­dzo ważne.

OK, zatrud­nio­no jed­ną oso­bę by pod­nieść jakość obsłu­gi peten­tów. Zapytam ina­czej: ile osób nale­ża­ło by zatrud­nić, by powyż­sze osią­gnąć ręcz­nie” bez sys­te­mu IT? A dla­cze­go wcze­śniej tego nie robio­no (wyso­ka jakość obsługi)?

[…] – W sys­te­mie elek­tro­nicz­nym jest na przy­kład widocz­ny aktu­al­ny stan zała­twie­nia poszcze­gól­nych spraw, bo sys­tem wyła­pu­je wszyst­kie doku­men­ty, któ­re są ?prze­ter­mi­no­wa­ne?. Po jakimś cza­sie widzi­my na czer­wo­no, któ­ry doku­ment na danym sta­no­wi­sku pra­cy jest prze­trzy­my­wa­ny czy w trak­cie załatwiania.

Ale jak widać są korzy­ści, w zasa­dzie nie osią­gal­ne meto­da­mi ręcz­ny­mi. Tak wiec jed­nak war­to było.

[…] To uła­twia pra­cę, bo zanim doku­ment tra­fi do mnie w wer­sji papie­ro­wej do pod­pi­sa­nia to widzę go w wer­sji elek­tro­nicz­nej. Ja albo mój zastęp­ca może­my wte­dy nanieść popraw­ki. Ostatecznie, do mnie tra­fia już doku­ment goto­wy do wysła­nia, ja tyl­ko pod­pi­su­ję i wysy­łam – to jest więc bar­dzo pomoc­ne. Z tym, że – nie­ste­ty – nadal two­rzy­my dodat­ko­wą biurokrację.

Ale… nie podwój­ny obieg. Dokument papie­ro­wy to ten ini­cju­ją­cy spra­wę, któ­ry po zare­je­stro­wa­niu leży już nie­ru­cho­mo” w tecz­ce. Cały pro­ces odby­wa się na doku­men­tach w wer­sji elek­tro­nicz­nej” (ich pisa­nie, uzgad­nia­nie tre­ści, korek­ty, śle­dze­nie itp.). Jak widać, papier to prak­tycz­nie jeden doku­ment ini­cju­ją­cy i dru­gi – ostat­ni – koń­czą­cy: goto­wa, uzgod­nio­na i zatwier­dzo­na wer­sja do pod­pi­su. Korzyść ogrom­na bo: mniej papie­ru, dekre­ta­cja to sekun­dy a nie godzi­ny (albo i dni), śle­dze­nie i sta­ty­sty­ki spraw natychmiastowe.

Dodam, że aku­rat koszt papie­ru jest naj­mniej­szym kosz­tem papie­ro­we­go obie­gu i ten argu­ment zawsze wzbu­dzał uśmiech na mojej twa­rzy. Taki argu­ment świad­czy raczej o zupeł­nym bra­ku ana­li­zy pro­ble­mu, a powta­rza­nie obie­go­wych argu­men­tów w rodza­ju sys­tem elek­tro­nicz­ne­go obie­gu doku­men­tów zwró­ci się po iluś tam oszczę­dzo­nych ryzach papie­ru” nie­ste­ty raczej wzbu­dza śmiech…

[..] Czy wobec tego to w ogó­le real­ne, że nie będzie papie­ro­wych doku­men­tów? Jest to real­ne. Musimy jed­nak jesz­cze prze­zwy­cię­żyć w sobie oba­wę przed doku­men­ta­mi elek­tro­nicz­ny­mi. Chyba boimy się, że mogą gdzieś pogi­nąć i w oba­wie, że baza danych może zostać utra­co­na, trzy­ma­my w schow­ku doku­ment papie­ro­wy. Myślę jed­nak, że sys­te­my infor­ma­tycz­ne są coraz bar­dziej dosko­na­łe i jesz­cze dwa, trzy lata i będzie wszyst­ko w porządku.

Uważam, że korzy­ści z elek­tro­nicz­ne­go obie­gu w urzę­dach są ogrom­ne mimo fak­tu, że doku­men­ty ini­cju­ją­cy i koń­czą­cy są (i dłu­go jesz­cze będą) nadal papie­ro­we (ilu ludzi tak na praw­dę ma moż­li­wość posłu­gi­wa­nia się elek­tro­nicz­nym doku­men­tem?!). Ważne jest by sys­tem taki po pierw­sze, został dobrze zapro­jek­to­wa­ny gdyż jego celem nie jest zastą­pie­nie papie­ru, a zmia­na spo­so­bu pra­cy urzę­du, a to ogrom­na różnica.

Co jest moim zda­niem naj­więk­szym błę­dem? To, że wie­le urzę­dów zama­wia­jąc” taki sys­tem (two­rząc SIWZ/OPZ), z góry zazna­cza­ją, że wdro­że­nie sys­te­mu elek­tro­nicz­ne­go obie­gu doku­men­tów nie powin­no wyma­gać zmian instruk­cji kan­ce­la­ryj­nej i wewnętrz­nych pro­ce­dur” i to jest idio­tycz­ne podej­ście bo fak­tycz­nie nic nie napra­wia­jąc dokła­da­my kosz­tów i pracy…

Tak więc suge­ru­ję, by może [[nowe Ministerstwo Cyfryzacji]] zaję­ło się jak naj­szyb­szym opra­co­wa­niem dru­giej wer­sji instruk­cji kan­ce­la­ryj­nej dla Gmin (ja chęt­nie pomo­gę), pla­nu­ją­cych cyfry­za­cję” bo bez tego ten cały inte­res jest na pla­ster… wewnętrz­ny obieg doku­men­tów w urzę­dzie to zapew­ne 99% całej pra­cy z doku­men­ta­mi. Więc chy­ba war­to pozo­sta­wić papie­ro­we” doku­men­ty u oby­wa­te­la a sku­pić się na owych 99%-ach wewnątrz urzę­du bo tu tkwi problem.

A archi­wa? OK, [[kate­go­rię archi­wal­ną A]] ma zni­ko­ma ilość doku­men­tów, więc nie zaro­śnie­my bo pozo­sta­łe doku­men­ty w urzę­dach maja [[kate­go­rie archi­wal­ną B]] i są cyklicz­nie niszczone.

Mamy tak­że dru­gi pro­blem w urzę­dach, któ­ry wystar­cza­ją­co opi­sał pra­cow­nik jed­ne­go z nich:

W moim urzę­dzie 4 lata temu wdro­żo­no elek­tro­nicz­ny obieg doku­men­tów, a mimo to więk­szość pra­cow­ni­ków nawet nie zakła­da w nim spraw. Skanowane doku­men­ty tra­fia­ją do dekre­ta­cji i do mery­to­rycz­nych pra­cow­ni­ków i na tym koniec. Jest potwor­ny opór pra­cow­ni­ków przed pro­wa­dze­niem spraw elek­tro­nicz­nie, bo wte­dy widać kto ile ma pra­cy i w jakim ter­mi­nie ją wyko­nu­je. Problemem jest rów­nież brak zde­cy­do­wa­nia nie­któ­rych sze­fów, któ­rzy sami nie potra­fią z tego sys­te­mu sko­rzy­stać, zatem nie wymu­sza­ją na pra­cow­ni­kach kon­se­kwen­cji w wyko­rzy­sty­wa­niu sys­te­mu. Podziwiam, że w takiej małej gmi­nie są 2 – 3 pisma mie­sięcz­nie zło­żo­ne na skrzyn­kę podaw­czą. W moim dużym powie­cie dotych­czas wpły­nę­ło jed­no zapy­ta­nie( w cią­gu 4 lat). Mimo to nie pod­da­je­my się i z upo­rem sta­ra­my się wpro­wa­dzać nowe. Może w koń­cu się to uda…

Ale tu mamy nie­ja­ko inny, nie tech­nicz­ny pro­blem… zary­zy­ku­je tezę, że w wie­lu pry­wat­nych fir­mach pro­blem bywa podobny…

(źr. cyta­tów Serwis Samorządowy PAP).