ERP za upravljanje dokumentov in dokumentacije

Kaj pomeni, da ERP postane sistem za upravljanje dokumentov in dokumentacije?#

ERP kot sistem za upravljanje dokumentov in dokumentacije pomeni, da podjetje dokumentov ne hrani v ločenem programu, temveč jih neposredno pripenja na poslovne zapise znotraj enotnega poslovnega sistema – na naročilo, račun, zaposlenega, stroj ali projekt. Namesto da uporabnik išče pogodbo v enem programu in podatke o stranki v drugem, sta oba zapisa povezana na istem mestu. To je razlika med dokumentnim arhivom in ERP za upravljanje dokumentov in dokumentacije, ki dokumentacijo obravnava kot del poslovnega procesa, ne kot priponko zraven njega.

Tak pristop se je uveljavil, ker se podjetja srečujejo z vse več dokumentacije, ki nastaja ob vsakem koraku poslovanja: naročilnice, dobavnice, pogodbe, zapisniki, tehnične risbe, kadrovski obrazci. Če je vsak dokument shranjen ločeno od podatka, na katerega se nanaša, nastane razpršenost, ki oddelkom onemogoča hiter vpogled v celotno zgodovino primera. Ko je dokument neposredno povezan z zapisom v ERP, lahko vodja proizvodnje, financ ali kadrov v nekaj sekundah preveri, kateri dokumenti spremljajo določeno naročilo, stranko ali zaposlenega, brez preklapljanja med programi.

Za naročnika to pomeni spremembo v tem, kako je dokumentacija strukturirana. Namesto splošne mape z datotekami je treba določiti, kateri tip dokumenta se veže na kateri poslovni objekt, kdo ga sme ustvariti, spremeniti ali potrditi, in kako se dokument obnaša skozi svoj življenjski cikel – od osnutka do arhiviranja. Ta struktura ni tehnična podrobnost, temveč odločitev, ki vpliva na to, kako bodo oddelki dejansko delali z dokumentacijo po uvedbi.

Zakaj podjetja dokumentacijo vse pogosteje vodijo znotraj ERP#

Podjetja se za tak korak odločajo, ker se dvojno vodenje podatkov – enkrat v ERP in enkrat v ločenem dokumentnem sistemu – dolgoročno podraži in poveča tveganje za napake. Kadar isti podatek o stranki, naročilu ali zaposlenem obstaja na dveh mestih, se prej ali slej pojavi neskladje: v enem sistemu je dokument posodobljen, v drugem ne. Če je dokumentacija del ERP, obstaja en zapis resnice, na katerega se sklicujejo vsi oddelki.

Drugi razlog je nadzor nad dostopom. V ERP so pravice dostopa že vezane na vlogo zaposlenega – kaj vidi vodja nabave, kaj vidi računovodstvo, kaj vidi zunanji sodelavec. Če dokumentacija živi v istem sistemu, se te pravice samodejno prenesejo tudi na dokumente, namesto da bi jih bilo treba vzdrževati še enkrat v ločenem orodju. To zmanjša možnost, da bi občutljiv dokument videl nekdo, ki do njega ne bi smel imeti dostopa.

Tretji razlog je sledljivost. Ko je dokument povezan z zapisom v ERP, je razvidno, kdo ga je naložil, kdo je odobril spremembo in kdaj je bil dokument nazadnje spremenjen. Za podjetja, ki morajo izkazati, od kje prihaja določena odločitev ali kdo je potrdil določeno različico pogodbe, je taka revizijska sled pogosto pomembnejša od tega, v katerem programu je dokument fizično shranjen.

Katera dokumentacija in kateri zapisi sodijo v ERP#

V ERP kot sistem za upravljanje dokumentov in dokumentacije se najpogosteje selijo tisti zapisi, ki so neposredno vezani na poslovne transakcije in na osebe znotraj organizacije. Gre za dokumentacijo, ki jo je treba najti hitro, ob konkretnem primeru, in ne le občasno prebrskati v arhivu. Odločitev, kateri tipi dokumentov sodijo v ERP in kateri ostanejo v specializiranem sistemu, je ena od prvih stvari, ki jih je treba določiti pred začetkom projekta.

Katera od teh kategorij je za posamezno podjetje najpomembnejša, je odvisno od panoge in od tega, kje nastaja največ dokumentacije. V proizvodnji je to pogosto tehnična in projektna dokumentacija, v javnem sektorju dokumentacija o postopkih in skladnosti, v storitvenih podjetjih pa pogodbe in korespondenca s strankami. Analiza pred uvedbo mora pokazati, kje dokumentacija danes nastaja, kje se izgublja in kje povzroča največ dodatnega dela.

Pri tem ni nujno, da se v ERP preseli vsa dokumentacija podjetja. Nekatere vrste vsebine, na primer obsežno tehnično arhiviranje ali specializirane inženirske datoteke, so lahko še naprej v namenskem sistemu, ki je z ERP povezan prek API-ja. Odločitev, kaj gre v ERP in kaj ostane povezano od zunaj, je arhitekturna odločitev, ki jo je smiselno sprejeti pred razvojem, ne med njim.

• pogodbe s strankami, dobavitelji in partnerji
• naročila, dobavnice in računi
• kadrovska dokumentacija in zapisi o usposabljanjih
• tehnična in projektna dokumentacija
• zapisniki sestankov in interne odločitve
• dokumentacija o skladnosti in revizijah
• korespondenca, vezana na posamezno naročilo ali projekt

Kako poteka povezovanje ERP z obstoječimi sistemi za dokumente?#

Povezovanje ERP z obstoječimi sistemi za dokumente poteka prek pregleda obstoječih podatkov in API-jev, nato pa prek postopne migracije in testiranja, preden se rešitev uvede v produkcijo. Preden se en dokument sploh premakne, je treba razumeti, kje danes dokumentacija fizično leži, v kakšni strukturi in kdo jo trenutno vzdržuje.

Naslednji korak je opredelitev, kateri podatki se prenesejo enkratno ob selitvi in kateri se bodo v prihodnje sinhronizirali stalno, prek povezave med ERP in sistemom, iz katerega dokumentacija izvorno prihaja. Pri podjetjih, ki uporabljajo ločen CRM, sistem za upravljanje dokumentov ali specializirano panožno orodje, to pomeni izgradnjo integracije prek API-ja, ki ohranja obstoječi sistem delujoč, hkrati pa dokumentacijo naredi dostopno tudi znotraj ERP.

Razvojno, testno in produkcijsko okolje morajo biti ločena, v testnem okolju pa se ne uporabljajo pravi osebni podatki, temveč testni primeri, ki posnemajo resnično strukturo dokumentacije. Šele ko je povezava preverjena v testnem okolju in prestane dogovorjena merila prevzemnega testiranja, se sprememba objavi v produkcijo. Ta zaporedje ni formalnost, temveč zaščita pred tem, da bi napaka v povezavi poškodovala dokumentacijo, ki jo podjetje dnevno uporablja.

• pregled izvorne kode, arhitekture in obstoječih podatkov
• opredelitev, kateri dokumenti se prenesejo in kateri ostanejo povezani od zunaj
• izgradnja API povezav med ERP in obstoječimi sistemi
• testiranje v ločenem testnem okolju brez pravih osebnih podatkov
• prevzemno testiranje po vnaprej dogovorjenih merilih
• postopna uvedba v produkcijsko okolje

Kaj morate določiti pred uvedbo: vloge, dostop in hramba#

Preden se dokumentni del ERP začne graditi, je treba določiti, kdo v organizaciji dokumente ustvarja, kdo jih potrjuje in kdo jih sme samo brati. Ta razdelitev vlog ni tehnično vprašanje, temveč organizacijska odločitev, ki jo mora sprejeti naročnik, ne izvajalec. Če vloge niso jasne pred začetkom razvoja, se to med projektom običajno pokaže kot zamuda, ne kot tehnična ovira.

Obdobja hrambe se med tipi dokumentov razlikujejo, zato jih ni mogoče določiti enotno za celotno organizacijo. Kadrovska dokumentacija, pogodbe in dokumentacija o skladnosti imajo pogosto različne zahteve glede tega, kako dolgo morajo biti dosegljivi in kdaj jih je treba izbrisati ali arhivirati. To pravilo je treba določiti pred uvedbo, saj se sistem za hrambo v ERP težko spremeni šele potem, ko je dokumentacija že naložena.

Podobno velja za delovni tok odobritev. Če mora določen dokument, na primer pogodba nad določenim obsegom, pred podpisom potrditi več oseb, mora ERP to zaporedje podpirati kot del procesa, ne kot dodatek po uvedbi. Naročnik, ki te korake opredeli vnaprej, s tem izvajalcu omogoči, da delovni tok vgradi v sistem takoj, namesto da bi ga dodajal kasneje kot spremembo.

• kdo dokument ustvari, spremeni, potrdi ali arhivira
• katera obdobja hrambe veljajo za posamezen tip dokumenta
• kako se dokument obnaša skozi delovni tok odobritev
• kako se vodi revizijska sled sprememb
• kdo ima dostop do dokumentacije zunanjih sodelavcev in partnerjev
• kako se dokumentacija arhivira po zaključku projekta ali pogodbe

Varnost podatkov, revizijska sled in skladnost s predpisi#

Dokumentacija, ki se seli v ERP, pogosto vsebuje osebne podatke, finančne podatke ali podatke, za katere velja posebna zakonska zaščita, zato je varnost dostopa eno od osrednjih vprašanj takega projekta. Vsak dokument mora biti dostopen samo tistim vlogam, ki ga za svoje delo dejansko potrebujejo, dostop pa mora biti mogoče kadar koli preveriti in po potrebi omejiti.

Zakonodaja, kot je splošna uredba o varstvu osebnih podatkov, določa splošna pravila glede tega, koliko časa se osebni podatki lahko hranijo in kdo do njih lahko dostopa, kar velja tudi za dokumentacijo znotraj ERP. Za javni sektor in regulirane panoge k temu pogosto pristopajo tudi dodatne zahteve glede revizijske sledi in dokazljivosti postopkov. Te zahteve je treba prenesti v strukturo pravic in v obdobja hrambe že pri načrtovanju, ne šele ob morebitnem nadzoru.

Revizijska sled – zapis o tem, kdo je dokument ustvaril, spremenil ali izbrisal – ni le varnostna funkcija, temveč tudi dokaz, da je podjetje s dokumentacijo ravnalo skladno s svojimi pravili. Za podjetja, ki delujejo v več državah ali panogah z zahtevnejšim nadzorom, je taka sledljivost pogosto pogoj za sodelovanje s partnerji ali javnimi naročniki, ne le interna dobra praksa.

Kako se uvedba dokumentnega upravljanja v ERP odrazi na delu zaposlenih?#

Uvedba dokumentnega upravljanja v ERP najbolj neposredno spremeni to, kje zaposleni iščejo dokumente in kako jih odobravajo – namesto v e-poštnih sporočilih in ločenih mapah dokumenti nastanejo in se potrjujejo znotraj istega sistema, v katerem zaposleni že delajo z naročili, računi ali kadrovskimi podatki, kar pomeni manj preklapljanja med orodji in manj vprašanj, kje je zadnja veljavna različica dokumenta.

Za oddelke, ki so dokumentacijo doslej vodili po svoje – v e-poštnih sporočilih, skupnih mapah ali papirno – to pomeni spremembo navade, ne le novega orodja. Prehod je lažji, če se pravila vnaprej pojasnijo: kateri dokument gre skozi ERP, kdo ga potrjuje in kaj se zgodi s starimi datotekami, ki so nastale pred uvedbo. Brez tega pojasnila zaposleni pogosto še naprej vzdržujejo staro mapo poleg novega sistema.

Za vodje oddelkov je sprememba predvsem v vpogledu: namesto da za status pogodbe ali odobritve povprašajo kolega, lahko stanje preverijo neposredno v ERP. To zahteva, da so podatki v sistemu res tekoče vzdrževani, kar je organizacijska obveznost, ne tehnična lastnost sistema. Projekt torej ni zaključen z uvedbo, temveč šele takrat, ko postane redna praksa vseh oddelkov, ki dokumentacijo ustvarjajo.

Kako izbrati izvajalca za povezovanje dokumentacije z ERP?#

Pri izbiri izvajalca za tak projekt je najpomembneje preveriti, ali zna pregledati obstoječe sisteme in podatke še pred pisanjem kode, in ali lahko projekt izvede po sklopih, ne le kot celoto brez vmesnih preverjanj, tako da naročnik obseg dela spremlja skozi ves projekt, ne šele ob koncu.

Ker gre za projekt, ki posega v več oddelkov hkrati, je pri večjih projektih smiselno, da izvajalec določi projektnega vodjo, odgovornosti posameznih ekip, roke in način poročanja že na začetku. To naročniku omogoča, da ima skozi celoten projekt jasno slika, kdo je za kaj odgovoren, namesto da se odgovornost razblini med razvojno ekipo in notranjimi oddelki, ki dokumentacijo uporabljajo.

Pri projektih, kjer dokumentacija in podatki že obstajajo v nedokončanem ali starejšem sistemu, je pomembno tudi, ali izvajalec zna prevzeti tak sistem po pregledu izvorne kode, arhitekture, infrastrukture in podatkov, ne le zgraditi novega od začetka. Izvorna koda in podatki so ne glede na izvajalca last naročnika, dokumentacija, dostopi in gesla pa morajo biti del primopredaje ob zaključku projekta.

Za projekte, ki vključujejo AI podprto iskanje po dokumentaciji ali samodejno razvrščanje dokumentov, je smiselno preveriti tudi, ali ima izvajalec dostop do kadra s tovrstnimi izkušnjami – bodisi znotraj lastne ekipe, bodisi prek specialistične partnerske mreže. Epix in njegova specialistična partnerska mreža na primer sestavljata projektne ekipe glede na to, ali projekt zahteva razvoj, integracije, AI podporo, varnost ali kombinacijo vsega naštetega.

Vzdrževanje, podpora in cena po uvedbi#

Po uvedbi dokumentnega dela ERP projekt ni zaključen, saj se dokumentacija in pravila dostopa spreminjajo skupaj z organizacijo. Zato je smiselno vnaprej dogovoriti, kdo po uvedbi odpravlja napake, kdo skrbi za varnostne posodobitve in kdo prevzame nadaljnji razvoj, na primer dodajanje novih tipov dokumentov ali novih delovnih tokov odobritev.

Taka razdelitev v razrede pomaga naročniku razumeti, kaj lahko pričakuje pri posamezni vrsti težave, ne glede na to, ali gre za popoln izpad dostopa do dokumentacije ali za manjšo napako, ki ne vpliva na tekoče poslovanje. Odzivni časi za posamezen razred se dogovorijo v pogodbi o podpori in so odvisni od kritičnosti sistema za naročnika.

Cena takega projekta ni fiksna številka, saj je odvisna od obsega funkcionalnosti, števila uporabniških vlog, količine in stanja obstoječih podatkov ter od tega, ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega. Prav tako nanjo vplivajo zahteve glede varnosti in revizijske sledi, morebiten mobilni del in raven podpore, ki jo naročnik želi po uvedbi.

Zato se cena določi šele po pregledu zahtev in obsega, pred tem pa je smiselna krajša analiza, ki projekt razčleni na sklope, tako da je vsak sklop – od integracije, prek delovnih tokov, do varnosti – ocenljiv in izvedljiv ločeno. Tak pristop naročniku omogoča, da se odloča po korakih, ne da bi moral vnaprej odobriti celoten obseg projekta.

• izpad – sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• motnja – sistem deluje, posamezna funkcija ne, obravnava po dogovorjeni prednosti
• napaka – manjša napaka brez vpliva na poslovanje, uvrščena v naslednjo objavo
• zahteva – sprememba ali nadgradnja, obseg in termin se uskladita posebej