Implementacija InDoc EDGE od zunaj pogosto izgleda kot tehnični projekt: izberi sistem, prenesi podatke, zaženi produkcijo. V praksi je drugače. Implementacija je predvsem pogovor - o procesih, navadah, omejitvah in pričakovanjih. Pogodba je samo začetek, projekt pa se nadaljuje še dolgo po tem, ko gre rešitev v produkcijo. Med njima je delo, ki odloča, ali bo rešitev v praksi zaživela.
To delo opravlja ekipa poslovnih rešitev InDoc EDGE - vodje projektov, analitiki in procesni arhitekti, ki vsak dan prevajajo zahteve organizacij v delujoče procese. V pogovoru z njimi smo pogledali v zakulisje implementacij: kako potekajo projekti, kje nastajajo največji izzivi in zakaj naročniki rešitev pogosto opišejo bolj kot partnerstvo kakor kot dobavo.
Implementacija ni samo izpolnjevanje ponudbe
»Implementacija pri nas ni samo tehnični projekt,« pojasnjuje Tatjana Jaklič, vodja ekipe poslovnih rešitev. »Začne se z razumevanjem stranke - kako dela danes, kje so ji dokumenti v breme in kaj želi s spremembo doseči.«
Ta perspektiva spreminja vidik vodenja projekta. Ponudba določi okvir, a v praksi se na vsakem koraku presoja, kaj bo v konkretnem okolju dolgoročno delovalo. »Naš cilj ni slediti ponudbi do pike natančno, ampak postaviti rešitev, ki bo dolgoročno delovala v njihovem okolju,« dodaja Tatjana.
Zato implementacija ni izpolnjevanje seznama zahtev. Je proces, v katerem se zahteve in rešitve srečujejo, usklajujejo in pogosto na novo opredeljujejo - dokler ne nastane nekaj, kar v praksi zaživi.
Rešitev pokažemo zgodaj, ker takrat se pogovor spremeni
Veliko stvari se v projektu razjasni šele takrat, ko naročnik rešitev vidi. Dokler je sistem abstrakten, so tudi pričakovanja abstraktna. Ko začne uporabnik klikati po vmesniku, postanejo zahteve konkretne in z njimi tudi povratne informacije.
»Zelo hitro pokažemo osnovno rešitev. Ko stranka začne klikati in uporabljati sistem, se pogovor premakne iz teorije v prakso. Takrat šele vidiš, kaj jim ustreza in kaj ne,« pojasnjuje Sebastjan Zemljak.
“Ko stranka začne klikati in uporabljati sistem, se pogovor premakne iz teorije v prakso.”
Zato zgodnja demonstracija ni samo predstavitev. Je orodje za pravočasno usklajevanje. Brez nje se nesporazumi pokažejo šele tik pred produkcijo - ko je popravljanje dražje, zamiki pa skoraj neizogibni.
Standard in prilagoditev: kdaj se odločiti za eno ali drugo
Odnos do standardnih rešitev je močno odvisen od področja. Pri sistemskih dokumentih, kjer veljajo ISO standardi in druga regulativa, ekipa praviloma vztraja pri preverjenih rešitvah. Stabilnost, sledljivost in skladnost tam pretehtajo pred prilagajanjem. Na področjih, kot so likvidacija računov ali interna pravila, je slika drugačna: prilagoditve so pogostejše, ker se sistem povezuje z drugimi okolji in obstoječimi procesi.
»Pri sistemskih dokumentih rešitve praktično ne spreminjamo. Na drugih področjih pa že v izhodišču vemo, da bodo prilagoditve nujne,« pojasnjuje Tatjana Jaklič.
Pri časovno omejenih projektih je odločitev bolj jasna. »Če bi v časovno omejenih projektih začeli spreminjati preverjeno rešitev, bi tvegali rok in stabilnost,« dodaja Andreja Vehar. V takih situacijah ekipa zavestno izbere preverjeno pot, izboljšave pa uvede fazno - ne kot kompromis, temveč kot premišljeno strategijo.
Razvoj se vključi, ko ima rešitev širšo vrednost. V drugih primerih se išče najboljša pot znotraj obstoječih funkcionalnosti. Cilj ni popoln standard ali popolna prilagoditev. Cilj je rešitev, ki je stabilna, razumljiva uporabnikom in dolgoročno vzdržna.
Kako razvojna ekipa razmišlja o tehničnih odločitvah, ki to omogočajo, si preberite v blogu Kako razvijamo InDoc EDGE – in zakaj to pomeni dolgoročno stabilnost.
Migracije so najbolj občutljiva faza in tudi najbolj poučna
Migracije sodijo med najbolj občutljive faze projektov. Ne gre samo za prenos dokumentov. Gre za prenos strukture, metapodatkov, pravic, integracij in pogosto za spremembo načina dela, ki uporabnike spremlja že leta.
Posebnost migracijskih projektov je tudi izhodiščna pozicija naročnika. Podatki niso vedno idealno pripravljeni. Del informacij je treba dopolniti ročno, del metapodatkov rekonstruirati, včasih pa se je treba sprijazniti z dejstvom, da vsega ni mogoče pridobiti - bodisi zaradi omejenega dostopa ali dodatnih stroškov.
Vloga ekipe pri tem je v realni presoji: kaj je mogoče rešiti takoj, kaj fazno in kje je treba poiskati alternativno pot. Migracija se zato vedno prilagaja dejanskemu stanju, ne idealnemu scenariju.
Druga plat migracije je človeška. Sprememba sistema je za uporabnike vstop v neznano - še posebej za tiste, ki so v prejšnjem okolju gradili svoje navade leta. Zato se ključni uporabniki v projekt vključujejo zelo zgodaj: rešitev spoznajo še pred produkcijo, sodelujejo pri oblikovanju procesov in se nanjo postopoma navadijo. Migracija tako ni nenaden rez, ampak postopen prehod.
Kdo na strani naročnika odloča o uspehu projekta
Tehnologija in metodologija sta pomembni, a v praksi pogosto najbolj odloča, kdo je v projekt vključen na strani naročnika. Idealna postava je znana: nekdo, ki dobro pozna vsebino in procese, nekdo z mandatom in podporo vodstva, ter nekdo z osnovnim tehničnim razumevanjem, ki zna povezati poslovne zahteve s sistemom.
V praksi se pogosto izkaže, da idealni pogoji niso vedno izpolnjeni. V večjih organizacijah je v projekt vključenih več oddelkov brez enotnega pregleda, v manjših pa pogosto manjka IT podpora. Ekipa poslovnih rešitev se teh razlik zaveda in projekte vodi v skladu z realnim stanjem, ne idealnimi predpostavkami. Manjkajoče vloge dopolni z dodatno razlago, vodenjem in jasnimi dogovori.
“Ključno je, da je na strani naročnika človek, ki si novo rešitev res želi in je zanjo tudi zagnan."
Takšna oseba pogosto prevzame vlogo notranjega povezovalca: med oddelki, med vodstvom in operativo, med poslovno zahtevo in tehnično izvedbo. Daje projektu zagon, ki ga formalne vloge ne morejo nadomestiti. Prav ta notranja motivacija je pogosto odločilna za to, ali se rešitev ne le uvede, ampak v praksi tudi zaživi.
Po produkciji se sodelovanje šele začne
Prehod v produkcijo je pomemben mejnik, a ne konec projekta. Pravzaprav se ravno takrat začne najbolj iskreni del sodelovanja - ko sistem ni več v testnem okolju, ampak v dnevni rabi, in se nanj zanašajo realne odločitve, roki in odgovornosti.
»Po prehodu v produkcijo smo prve tedne praktično v 'stand-by' načinu. Takrat se pokažejo realne potrebe in pričakovanja,« pojasnjuje Sebastjan Zemljak. Šele ob dejanski uporabi sistem razkrije, kako se obnaša v rokah različnih uporabnikov in v stiku z realnimi procesi.
Ko se delovanje stabilizira, se komunikacija preseli v ustaljene kanale. Vsebinska vprašanja - prilagoditve procesov, nadgradnje, fazne izboljšave - ostajajo v domeni ekipe poslovnih rešitev. Rešitve niso 'set and forget'. Razvijajo se skozi čas, na podlagi povratnih informacij naročnikov.
Kako se zanesljivost teh rešitev preverja še pred prehodom v produkcijo, razlaga Klavdija Blatnik v blogu Kako zagotavljamo zanesljivost dokumentnega sistema v praksi.
Tehnologija je orodje, način dela je razlika
Uvedba InDoc EDGE torej ni linearen projekt. Je proces, ki se začne pred podpisom pogodbe in se nadaljuje še dolgo po prehodu v produkcijo. V tem procesu ne odločajo samo funkcionalnosti, temveč način dela: kako se posluje z naročnikom, kdaj se vztraja pri standardu, kdaj se prilagodi, kako se obravnavajo migracije in kako se gradi zaupanje skozi vsako fazo.
Ravno zato naročniki sodelovanje pogosto opišejo kot partnerstvo. Ker se gradi skozi projekt in ne nastane s podpisom pogodbe.
Vir: Ta blog je nastal na osnovi pogovora z ekipo poslovnih rešitev InDoc EDGE. Celoten intervju si preberite na jubiljeni strani Mikrocop-a.