Migracija dokumentnega sistema je najpogosteje predstavljena kot tehnični projekt. V resnici pa gre za odločitev o tem, kako bo organizacija delala z dokumenti čez tri leta, ne le o tem, kako bomo prenesli datoteke v dvanajstih tednih.
Ta razlika ima ime: TO-BE model. Odločitev, ali ga definiramo pred prenosom ali ne, najbolj zanesljivo napove, ali bo migracija uspešna
TO-BE model je opredelitev ciljnega stanja dokumentnega sistema, torej kako želi organizacija delati z dokumenti po migraciji. Vključuje strukturo dokumentov, klasifikacijo, metapodatke, procese, vloge in pravice dostopa, integracije ter zahteve za skladnost. Definira način dela, ne tehničnih specifikacij.
TO-BE ni tehnična specifikacija
TO-BE model je pogosto napačno razumljen kot dokument, ki ga pripravi tehnična ekipa: seznam funkcionalnosti, podatkovni model, arhitekturni diagram. To je le manjši del slike.
TO-BE model je opredelitev prihodnjega načina dela z dokumenti. Določa, kako bodo dokumenti nastajali, kdo bo z njimi delal, kako se bodo povezovali s procesi in kako jih bo organizacija nadzorovala. Tehnologija je posledica teh odločitev, ne njihovo izhodišče.
Če organizacija pripravi TO-BE model na ravni specifikacije, dobi sistem, ki ustreza zahtevam. Če pripravi TO-BE model na ravni načina dela, dobi sistem, ki ga uporabniki dejansko uporabljajo. To ni isto.
TO-BE model opisuje ciljno stanje, kako želimo delati po migraciji. AS-IS analiza opisuje obstoječe stanje, torej kako delamo danes. TO-BE definiramo prvi, ker brez ciljnega okvira AS-IS analiza ostane le popis obstoječega stanja, ne podlaga za odločitve, kaj prenesti, kaj preoblikovati in kaj opustiti.
6 vprašanj, ki definirajo TO-BE model
V praksi TO-BE model pomeni, da moramo pred začetkom migracije jasno opredeliti šest dimenzij. Vsako vprašanje določa, kako bo nov sistem deloval v vsakdanji uporabi. Vsako preskočeno vprašanje je tveganje, ki se bo pokazalo po produkciji, ne pred njo.
Kdaj v projektu definiramo TO-BE model? TO-BE model definiramo na samem začetku projekta migracije, pred AS-IS analizo in pred kakršnimkoli prenosom podatkov. V praksi je to prva faza migracije in pogoj za vse nadaljnje korake.
1. Kakšna bo struktura dokumentov?
Klasifikacija, zadeve, mape: kako bodo dokumenti organizirani v novem sistemu. To ni vprašanje IT-ja, ampak organizacijsko vprašanje. Klasifikacija mora odražati dejanski način dela, ne zgodovinske strukture, ki se je nakopičila v zadnjih 10 ali 20 letih.
V praksi se tu pokaže prva napaka: organizacije pogosto prenesejo obstoječo strukturo, ker je "znana". Toda znana ni isto kot funkcionalna.
2. Kateri metapodatki bodo obvezni in kako bodo dodani?
Metapodatki so temelj iskanja, filtriranja, avtomatizacije in poročanja. Brez konsistentnih metapodatkov dokumentni sistem postane velik “file server”.
Ključno vprašanje ni le, kateri metapodatki bodo obvezni, ampak tudi, kako bodo dodani. Ročno? Avtomatsko iz povezanih sistemov? Z OCR ali AI klasifikacijo? Ta odločitev določa, ali bo standardizacija delovala v praksi ali ostala na papirju.
3. Kako bodo dokumenti povezani s poslovnimi procesi?
Workflow in BPM nista dodatek dokumentnemu sistemu, temveč njegova bistvena funkcija. Dokumenti, ki niso povezani s procesi, so le datoteke. Dokumenti, ki podpirajo procese, so del poslovne logike.
V TO-BE modelu moramo opredeliti, kateri procesi tečejo skozi dokumentni sistem, kako se sprožijo, kdo jih potrjuje in kako se zaključijo. To je tudi trenutek za vprašanje, ali so obstoječi procesi sploh smiselni ali so ostanek prejšnje organizacije.
4. Kakšne bodo vloge uporabnikov in pravice dostopa?
Kdo vidi kaj, kdaj in zakaj, mora biti jasno definirano od začetka. Pravice dostopa, ki so se v starem sistemu nakopičile organsko, so eden največjih virov tveganja: uporabniki imajo dostope, ki jih ne potrebujejo več ali jih nikoli niso potrebovali, a jih je tehnično težko odvzeti.
TO-BE model je priložnost, da se vloge na novo definirajo na podlagi dejanskih odgovornosti, ne na podlagi zgodovine.
5. Kako se bo dokumentni sistem povezal z drugimi sistemi?
Integracije z ERP, HRM, CRM in IAM niso opcijski dodatek, temveč pogoj uporabnosti.
Dokumenti nastajajo v drugih sistemih, se sklicujejo na njihove podatke in pogosto sprožajo procese v njih.
V TO-BE modelu moramo opredeliti, katere integracije so kritične, katere smiselne in katere lahko počakajo. Brez tega se v fazi izvedbe pogosto sprejemajo ad hoc odločitve, ki kasneje postanejo dolg.
6. Kako bo zagotovljena skladnost, varnost in e-hramba?
Regulatorne zahteve morajo biti del zasnove, ne naknadni popravek. Roki hrambe, nespremenljivost dokumentov, časovno žigosanje, revizijska sled - vse to mora biti opredeljeno pred migracijo, ne urejeno po njej.
Skladnost, ki se vzpostavi po prenosu, je vedno dražja in manj zanesljiva kot skladnost, ki je vgrajena v zasnovo.
TO-BE model ni naloga ene osebe ali ene ekipe. Skupaj ga oblikujejo poslovni uporabniki, ki vsakodnevno delajo z dokumenti, lastniki procesov, predstavniki skladnosti in tehnične ekipe. Vodstvo določa prioritete in daje mandat. Migracija, ki jo definira samo IT, je tehnično pravilna, vendar redko poslovno uspešna.
Prenesimo vse, potem bomo pa uredili
To je stavek, ki ga v praksi najpogosteje slišimo. Hkrati je najboljši napovednik, da rezultat ne bo izpolnil pričakovanj. S tem stavkom ima organizacija dober namen urediti dokumente. Razume, da je urejanje potrebno, vendar ga preloži na čas po prenosu, ker se zdi, da bo takrat lažje.
V praksi se to skoraj nikoli ne zgodi. Razlogov je več:
Po migraciji ni več projektne energije.
Migracija je intenziven projekt z jasnim ciljem in roki. Ko je prenos zaključen, se organizacija vrne v običajno poslovanje. Naloga "uredimo dokumente" izgubi prioriteto, ker konkurira z vsakodnevnim delom.
Po migraciji ni več mandata.
Med migracijo so vsi pripravljeni sprejemati odločitve o klasifikaciji, vlogah, pravicah. Po prenosu se ta pripravljenost izgubi: vsak oddelek se vrne k svojim prioritetam, odločitve postanejo zamudne in politične.
Po migraciji se navade že utrdijo.
Uporabniki, ki dva meseca delajo z nepopolno strukturo, jo začnejo dojemati kot dano. Vsaka kasnejša reorganizacija je sprememba njihove navade, ne uvedba nove. To je psihološko bistveno težje.
Rezultat je sistem, ki dve leti po migraciji deluje na način, ki ga nihče ni načrtoval, a so se ga vsi navadili. Tehnično je nov, vsebinsko pa dedič vsega, kar bi morali pustiti za seboj.
Organizacija prenese obstoječe stanje v nov sistem, vključno z neurejenimi strukturami, nekonsistentnimi metapodatki in zastarelimi pravicami dostopa. Posledice se pokažejo po produkciji: nizko sprejetje sistema med uporabniki, izguba sledljivosti, povezav med dokumenti in procesi, težave s skladnostjo ter neizkoriščenost zmožnosti novega sistema. Migracija je tehnično izvedena, poslovno pa redko upraviči investicijo.
Migracija kot priložnost za ureditev
V vsakodnevnem poslovanju ni časa za temeljito reorganizacijo klasifikacije, standardizacijo metapodatkov ali pregled pravic dostopa. Te aktivnosti vedno padejo na rep prioritetnega seznama. Migracija pa je trenutek, ko je vse to nujno, ker se pripravlja nov sistem.
Če tega trenutka ne izkoristimo, naslednja priložnost za tak pregled pride šele ob naslednji migraciji, ki je običajno čez 5 do 10 let.
Vsaka migracija dokumentnega sistema je v končni fazi odgovor na eno vprašanje: kakšen način dela z dokumenti želi organizacija imeti čez tri leta? Ko je odgovor jasen, postane vse ostalo posledica te ene odločitve. Ko odgovor ni jasen, postane vse ostalo improvizacija.
Za celovit pregled vseh vidikov migracije si oglejte: