Migracija dokumentnog sustava najčešće se predstavlja kao tehnički projekt. U stvarnosti, riječ je o odluci o tome kako će organizacija raditi s dokumentima za tri godine, a ne samo o tome kako ćemo prenijeti datoteke u dvanaest tjedana.
Ta razlika ima ime: TO-BE model. Odluka hoćemo li ga definirati prije prijenosa ili ne najpouzdanije predviđa hoće li migracija biti uspješna.
TO-BE model je definicija ciljnog stanja dokumentnog sustava, odnosno načina na koji organizacija želi raditi s dokumentima nakon migracije. Uključuje strukturu dokumenata, klasifikaciju, metapodatke, procese, uloge i prava pristupa, integracije te zahtjeve za usklađenost. Definira način rada, a ne tehničke specifikacije.
TO-BE nije tehnička specifikacija
TO-BE model često se pogrešno shvaća kao dokument koji priprema tehnički tim: popis funkcionalnosti, podatkovni model, arhitektonski dijagram. To je samo manji dio slike.
TO-BE model je definicija budućeg načina rada s dokumentima. Određuje kako će dokumenti nastajati, tko će s njima raditi, kako će se povezivati s procesima i kako će ih organizacija nadzirati. Tehnologija je posljedica tih odluka, a ne njihovo polazište.
Ako organizacija pripremi TO-BE model na razini specifikacije, dobiva sustav koji odgovara zahtjevima. Ako pripremi TO-BE model na razini načina rada, dobiva sustav koji korisnici zaista koriste. To nije isto.
TO-BE model opisuje ciljno stanje, odnosno kako želimo raditi nakon migracije. AS-IS analiza opisuje postojeće stanje, odnosno kako radimo danas. TO-BE definiramo prvi jer bez ciljnog okvira AS-IS analiza ostaje samo popis postojećeg stanja, a ne podloga za odluke o tome što prenijeti, što preoblikovati i što napustiti.
6 pitanja koja definiraju TO-BE model
U praksi TO-BE model znači da prije početka migracije moramo jasno definirati šest dimenzija. Svako pitanje određuje kako će novi sustav funkcionirati u svakodnevnoj upotrebi. Svako preskočeno pitanje predstavlja rizik koji će se pokazati nakon produkcije, a ne prije nje.
Kada u projektu definiramo TO-BE model? TO-BE model definiramo na samom početku migracijskog projekta, prije AS-IS analize i prije bilo kakvog prijenosa podataka. U praksi je to prva faza migracije i preduvjet za sve daljnje korake.
1. Kakva će biti struktura dokumenata?
Klasifikacija, predmeti, mape: kako će dokumenti biti organizirani u novom sustavu. To nije pitanje IT-a, nego organizacijsko pitanje. Klasifikacija mora odražavati stvarni način rada, a ne povijesne strukture koje su se nakupile tijekom posljednjih 10 ili 20 godina.
U praksi se tu pokaže prva pogreška: organizacije često prenesu postojeću strukturu jer je "poznata". No poznato nije isto što i funkcionalno.
2. Koji će metapodaci biti obvezni i kako će se dodavati?
Metapodaci su temelj pretraživanja, filtriranja, automatizacije i izvještavanja. Bez dosljednih metapodataka dokumentni sustav postaje veliki “file server”.
Ključno pitanje nije samo koji će metapodaci biti obvezni, nego i kako će se dodavati. Ručno? Automatski iz povezanih sustava? Pomoću OCR-a ili AI klasifikacije? Ta odluka određuje hoće li standardizacija funkcionirati u praksi ili ostati na papiru.
3. Kako će dokumenti biti povezani s poslovnim procesima?
Workflow i BPM nisu dodatak dokumentnom sustavu, nego njegova ključna funkcija. Dokumenti koji nisu povezani s procesima samo su datoteke. Dokumenti koji podržavaju procese dio su poslovne logike.
U TO-BE modelu moramo definirati koji se procesi odvijaju kroz dokumentni sustav, kako se pokreću, tko ih odobrava i kako se zaključuju. To je ujedno trenutak za pitanje imaju li postojeći procesi uopće smisla ili su ostatak prijašnje organizacije.
4. Kakve će biti korisničke uloge i prava pristupa?
Tko vidi što, kada i zašto, mora biti jasno definirano od početka. Prava pristupa koja su se u starom sustavu nakupila organski jedan su od najvećih izvora rizika: korisnici imaju pristupe koji im više nisu potrebni ili im nikada nisu ni bili potrebni, ali ih je tehnički teško oduzeti.
TO-BE model je prilika da se uloge ponovno definiraju na temelju stvarnih odgovornosti, a ne na temelju povijesti.
5. Kako će se dokumentni sustav povezati s drugim sustavima?
Integracije s ERP, HRM, CRM i IAM sustavima nisu opcionalni dodatak, nego preduvjet upotrebljivosti.
Dokumenti nastaju u drugim sustavima, referiraju se na njihove podatke i često pokreću procese u njima.
U TO-BE modelu moramo definirati koje su integracije kritične, koje su smislene i koje mogu pričekati. Bez toga se u fazi izvedbe često donose ad hoc odluke koje kasnije postaju dug.
6. Kako će se osigurati usklađenost, sigurnost i e-pohrana?
Regulatorni zahtjevi moraju biti dio dizajna, a ne naknadni popravak. Rokovi čuvanja, nepromjenjivost dokumenata, vremensko žigosanje, revizijski trag. Sve to mora biti definirano prije migracije, a ne uređeno nakon nje.
Usklađenost koja se uspostavlja nakon prijenosa uvijek je skuplja i manje pouzdana od usklađenosti koja je ugrađena u dizajn.
? TO-BE model nije zadatak jedne osobe ili jednog tima. Zajedno ga oblikuju poslovni korisnici koji svakodnevno rade s dokumentima, vlasnici procesa, predstavnici usklađenosti i tehnički timovi. Vodstvo određuje prioritete i daje mandat. Migracija koju definira samo IT tehnički je ispravna, ali rijetko poslovno uspješna.
Prenesimo sve, pa ćemo onda urediti
To je rečenica koju u praksi najčešće čujemo. Istovremeno je najbolji pokazatelj da rezultat neće ispuniti očekivanja. Tom rečenicom organizacija ima dobru namjeru urediti dokumente. Razumije da je uređivanje potrebno, ali ga odgađa za vrijeme nakon prijenosa jer se čini da će tada biti lakše.
U praksi se to gotovo nikada ne dogodi. Razloga je više:
Nakon migracije više nema projektne energije.
Migracija je intenzivan projekt s jasnim ciljem i rokovima. Kada je prijenos završen, organizacija se vraća u redovno poslovanje. Zadatak "uredimo dokumente" gubi prioritet jer se natječe sa svakodnevnim radom.
Nakon migracije više nema mandata.
Tijekom migracije svi su spremni donositi odluke o klasifikaciji, ulogama i pravima. Nakon prijenosa ta se spremnost izgubi: svaki se odjel vraća svojim prioritetima, odluke postaju dugotrajne i političke.
Nakon migracije navike su već učvršćene.
Korisnici koji dva mjeseca rade s nepotpunom strukturom počinju je doživljavati kao zadanu. Svaka kasnija reorganizacija promjena je njihove navike, a ne uvođenje nove. To je psihološki znatno teže.
Rezultat je sustav koji dvije godine nakon migracije funkcionira na način koji nitko nije planirao, ali su se svi na njega naviknuli. Tehnički je nov, ali sadržajno je nasljednik svega što je trebalo ostaviti iza sebe.
Organizacija prenese postojeće stanje u novi sustav, uključujući neuređene strukture, nedosljedne metapodatke i zastarjela prava pristupa. Posljedice se pokažu nakon produkcije: nisko prihvaćanje sustava među korisnicima, gubitak sljedivosti, poveznica između dokumenata i procesa, problemi s usklađenošću te neiskorištenost mogućnosti novog sustava. Migracija je tehnički provedena, ali poslovno rijetko opravdava investiciju.
Migracija kao prilika za uređivanje
U svakodnevnom poslovanju nema vremena za temeljitu reorganizaciju klasifikacije, standardizaciju metapodataka ili pregled prava pristupa. Te aktivnosti uvijek završe na kraju liste prioriteta. Migracija je, međutim, trenutak kada je sve to nužno jer se priprema novi sustav.
Ako taj trenutak ne iskoristimo, sljedeća prilika za takav pregled dolazi tek pri sljedećoj migraciji, koja je obično za 5 do 10 godina.
Svaka migracija dokumentnog sustava u konačnici je odgovor na jedno pitanje: kakav način rada s dokumentima organizacija želi imati za tri godine? Kada je odgovor jasan, sve ostalo postaje posljedica te jedne odluke. Kada odgovor nije jasan, sve ostalo postaje improvizacija.
Za cjelovit pregled svih aspekata migracije pogledajte: