Digitalna rešitev za upravljanje projektov in integracije

Kaj je digitalna rešitev za upravljanje projektov in integracije?#

Digitalna rešitev za upravljanje projektov in integracije je informacijski sistem, ki povezuje orodja za načrtovanje, delovne tokove in poročanje z obstoječimi sistemi v podjetju, kot so ERP, CRM in dokumentni sistemi, prek API-jev. Namesto ločenih razpredelnic in e-poštnih sporočil dobi vodja projekta enoten pregled nad nalogami, roki, odgovornostmi in podatki, ki prihajajo iz različnih oddelkov. Taka rešitev ni samostojno orodje, temveč plast, ki poveže obstoječo programsko opremo v enoten sistem dela.

V podjetjih z več kot milijon evrov letnih prihodkov projekti praviloma segajo čez več oddelkov: nabava, proizvodnja, finance, kadri in poročanje vodstvu. Vsak oddelek pogosto uporablja svoj sistem, zato se podatki o istem projektu podvajajo ali izgubljajo med prehodi. Digitalna rešitev za upravljanje projektov to odpravi tako, da podatke zajame enkrat in jih nato razdeli naprej, v obliki, ki jo posamezen sistem razume. S tem se zmanjša število ročnih vnosov in napak, ki nastanejo pri prepisovanju med sistemi.

Jedro take rešitve so tri plasti: vmesnik za vodenje projektov in nalog, integracijska plast, ki prek API-jev povezuje obstoječe sisteme, in podatkovna plast, ki poskrbi, da imajo vsi udeleženci dostop do istih, usklajenih informacij. Pri gradnji take arhitekture je treba najprej določiti, kateri sistemi morajo komunicirati med seboj, kateri podatki so vir resnice za posamezno informacijo in kdo je odgovoren za njihovo vzdrževanje. Brez te odločitve integracija hitro postane zbirka posamičnih povezav brez skupne logike.

Zakaj je povezava med sistemi ključna pri večjih projektih#

Projekt, ki vključuje proizvodnjo, nabavo, finance in poročanje, ne more temeljiti na enem samem orodju, ker vsak oddelek potrebuje svoj nabor funkcij. Vodja projekta pa potrebuje pregled nad celoto, zato mora imeti sistem, ki zna te podatke združiti brez dodatnega ročnega dela. Če povezave med sistemi ni, nastanejo vrzeli: informacija o zamudi pri nabavi ne pride pravočasno do proizvodnje, sprememba v proizvodnem načrtu pa ne do finančnega poročanja. Take vrzeli so pogosto vzrok za zamude, ki jih vodstvo opazi šele, ko je škoda že nastala.

Integracija med sistemi ni le tehnično vprašanje, temveč odločitev o tem, kako bo podjetje delalo. Treba je določiti, kateri podatki se prenašajo samodejno in kateri ostanejo pod ročnim nadzorom, kako pogosto se sinhronizirajo in kaj se zgodi, če pride do neskladja. Te odločitve vplivajo na to, kako hitro vodstvo dobi zanesljivo informacijo in kako velika je verjetnost, da se napaka v enem sistemu razširi v druge. Zato je smiselno te odločitve sprejeti pred začetkom razvoja, ne med njim.

Za podjetja, ki delujejo na več lokacijah ali v več državah, se k temu dodata še vprašanje usklajevanja časovnih pasov in pravil poročanja, ki se lahko razlikujejo po trgu. Digitalna rešitev za upravljanje projektov mora v takih primerih omogočati, da ima vsaka enota svoj pogled na podatke, hkrati pa vodstvo vidi konsolidirano celoto. To zahteva jasno zasnovano podatkovno strukturo že od začetka, saj je poznejše popravljanje strukture bistveno zahtevnejše kot prilagajanje uporabniškega vmesnika.

Katere sisteme in procese je treba povezati#

Pred začetkom integracije je treba narediti seznam sistemov, ki jih projekt dejansko potrebuje, in procesov, ki jih je treba digitalizirati. Seznam je osnova za oceno obsega dela in za določitev, kateri API-ji so na voljo in kateri podatki se prenašajo. Brez tega pregleda se zgodi, da se projekt med izvedbo širi, ker se sproti odkrivajo sistemi, ki jih je bilo treba povezati že na začetku.

Za vsak sistem na seznamu je treba preveriti, ali ima odprt API, kakšne so omejitve glede frekvence klicev in kdo znotraj podjetja pozna njegovo notranjo logiko. Pri starejših sistemih ta dokumentacija pogosto ni popolna, zato je del dela že sam pregled obstoječe kode in arhitekture, preden se določi, kako bo integracija potekala. To velja tudi, kadar prevzemamo obstoječ ali nedokončan sistem: pregled izvorne kode, infrastrukture in podatkov je prvi korak, šele nato sledi načrt povezovanja.

Pri tem pregledu je pomembno tudi razumeti, kateri procesi so že digitalizirani in kateri še potekajo ročno, saj to vpliva na to, kje se integracija najprej splača. Proces, ki danes poteka prek papirnih obrazcev ali ločenih e-poštnih sporočil, pogosto prinese največjo spremembo, ko se vključi v enoten sistem, medtem ko so že digitalizirani procesi običajno lažji za povezovanje, ker imajo urejene podatkovne strukture.

• Sistemi za vodenje poslovanja (ERP) in upravljanje odnosov s strankami (CRM)
• Dokumentni in arhivski sistemi (DMS/ECM) za pogodbe, naročila in poročila
• Proizvodni in skladiščni sistemi, kjer se spremljajo zaloge in delovni nalogi
• Orodja za poročanje vodstvu in nadzorne plošče
• Komunikacijski kanali za obvestila o nalogah in rokih
• Kadrovski sistemi, kadar projekt vpliva na razporejanje ljudi

Kako poteka integracija z obstoječimi sistemi?#

Integracija z obstoječimi sistemi poteka tako, da se najprej pregleda trenutno stanje – kodo, arhitekturo, infrastrukturo in podatke – nato se določi, kateri podatki se prenašajo prek API-jev, in šele na koncu se povezave razvijejo in testirajo v ločenem okolju, preden pridejo v produkcijo. Ta vrstni red ni naključen: če se razvoj začne pred pregledom, se pogosto izkaže, da je treba delo ponoviti, ker prvotna ocena ni upoštevala omejitev obstoječega sistema.

Razvojno, testno in produkcijsko okolje so pri tem ločena. V testnem okolju se ne uporabljajo resnični osebni podatki, kar je pomembno zlasti takrat, kadar projekt vključuje kadrovske, finančne ali zdravstvene podatke. Vsaka sprememba integracije gre pred objavo v produkcijo skozi pregled in testiranje, s čimer se zmanjša tveganje, da napaka v eni povezavi poruši delovanje drugih sistemov, ki so nanjo navezani.

Pri projektih, ki prevzemajo obstoječ sistem namesto gradnje novega, je prvi korak vedno pregled tega, kaj že obstaja: kakšna je arhitektura, kje so podatki shranjeni in kako je infrastruktura postavljena. Šele na podlagi tega pregleda je mogoče oceniti, ali je integracijo smiselno nadgraditi po delih ali zamenjati celoten sloj povezav. Taka odločitev neposredno vpliva na to, koliko obstoječe funkcionalnosti ostane nespremenjene med izvedbo projekta.

Kdo je odgovoren za projekt in kako se določijo vloge#

Pri projektu, ki povezuje več sistemov in oddelkov, je treba že na začetku določiti, kdo je odgovoren za posamezen del: projektnega vodjo, odgovornosti posameznih ekip, roke in način poročanja. Brez te delitve se odgovornost med integracijo in razvojem razdrobi, kar podaljša odločanje, kadar pride do zapletov. Jasna delitev vlog je zato enako pomembna kot tehnična zasnova same rešitve.

Projekt je mogoče prevzeti v celoti, od analize do uvedbe in podpore, ali pa le kot posamezen sklop, na primer samo integracijo enega sistema ali samo vzpostavitev poročanja. Odločitev o obsegu prevzema je odvisna od tega, koliko internih virov ima naročnik na voljo in kako zahtevna je koordinacija med oddelki. V obeh primerih velja, da izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku.

Pri projektih javnega sektorja ali pri rešitvah, ki vključujejo strojno in programsko opremo hkrati, se pokaže, zakaj je jasna delitev vlog pomembna še bolj. Pri rešitvi za Občino Sevnica je bilo treba povezati programsko rešitev, interaktivne vsebine, zaslon na dotik in konfiguracijo kiosk okolja v en sistem, nameščen na lokaciji, z lastno dokumentacijo in podporo. Tak projekt zahteva usklajevanje med razvojno ekipo, tehnično ekipo za namestitev in naročnikom, ki mora vedeti, kdo odgovarja za kateri del po zagonu.

Varnost podatkov pri povezovanju sistemov#

Varnost podatkov pri integraciji sistemov se začne z ločitvijo okolij: razvojno, testno in produkcijsko okolje niso isto okolje, in v testnem se ne uporabljajo resnični osebni podatki. To pravilo je še pomembnejše, kadar projekt povezuje kadrovske, finančne ali zdravstvene podatke med več sistemi, ker se napaka v enem povezanem sistemu lahko razširi v druge, še preden jo kdo opazi.

Druga raven varnosti je nadzor nad tem, kdo ima dostop do posameznega API-ja in kateri podatki se prenašajo samodejno. Pri projektih v reguliranih panogah ali v javnem sektorju to vključuje tudi vprašanje revizijske sledi: kdo je spremenil podatek, kdaj in prek katerega sistema. Teh zahtev ni mogoče dodati naknadno brez poseganja v arhitekturo, zato jih je treba določiti pred začetkom integracije, ne po njej.

Znotraj Epixa in njegove specialistične partnerske mreže so na voljo profili za varnostno arhitekturo, upravljanje dostopov in odziv na incidente, kar je pomembno takrat, kadar projekt presega okvir enega oddelka in zahteva usklajeno varnostno politiko za vse povezane sisteme. Pri takih projektih se spremembe integracije vedno pred objavo v produkcijo preverijo, tako da morebitna napaka ne pride neposredno v delovno okolje.

Kakšen je vpliv na zaposlene, ki uporabljajo nov sistem?#

Vpliv na zaposlene je odvisen predvsem od tega, koliko se spremeni njihov vsakdanji delovni tok, zato je del projekta vedno tudi dokumentacija in uvajanje v nov način dela. Kadar sistem zamenja ročno vnašanje podatkov v več orodij z enim vnosom, ki se nato samodejno razdeli naprej, se zaposlenim zmanjša količina ponavljajočega se dela, hkrati pa se morajo navaditi na nov vmesnik in nov vrstni red korakov.

Prehod na novo rešitev je lažji, kadar je razdeljen na sklope in testiran pred širšo uvedbo, saj zaposleni tako spremembe spremljajo postopoma in ne vseh hkrati. Prevzemno testiranje po vnaprej dogovorjenih merilih je priložnost, da zaposleni, ki bodo sistem dejansko uporabljali, preverijo, ali ustreza njihovemu načinu dela, še preden gre rešitev v produkcijo. To zmanjša tveganje, da se po zagonu pokažejo vrzeli, ki bi zahtevale naknadno popravljanje procesa.

Dokumentacija, ki je del primopredaje, ni namenjena le tehnični ekipi, temveč tudi zaposlenim, ki morajo vedeti, kam se obrniti ob napaki in kako poteka obravnava glede na njeno resnost. S tem se zmanjša negotovost, ki sicer nastane, kadar se uvede nov sistem brez jasnih navodil, kaj storiti, če nekaj ne deluje po pričakovanjih.

Kako izbrati izvajalca za digitalizacijo upravljanja projektov?#

Izvajalca je smiselno izbrati glede na to, ali lahko prevzame celoten obseg projekta ali le posamezen sklop, kakšno ekipo lahko sestavi za vaš primer in kako obravnava podporo po uvedbi. Ponudnik, ki zna pokazati konkretne projektne vloge – od projektnega vodje do inženirjev za posamezno področje – lažje prilagodi ekipo obsegu in zahtevnosti projekta, kot ponudnik, ki ponuja le splošno storitev brez razdelitve odgovornosti.

Pri izbiri je smiselno preveriti tudi, kako ponudnik obravnava lastništvo: izvorna koda in podatki morajo ostati v lasti naročnika, ne glede na to, kdo jih je razvil. Enako velja za dostope in gesla, ki morajo biti del uradne primopredaje, ne le neformalno posredovani ob koncu projekta. To je še posebej pomembno pri projektih, ki povezujejo več sistemov, saj nejasna lastniška struktura podatkov kasneje otežuje menjavo izvajalca ali nadaljnji razvoj z drugo ekipo.

Znotraj Epixa in specialistične partnerske mreže je mogoče sestaviti ekipo, ki pokriva celoten obseg projekta – od analize, arhitekture in UX/UI prek razvoja, AI in podatkov do cloud infrastrukture, varnosti, QA, uvedbe, dokumentacije in SLA podpore – ali pa prevzame samo posamezen tehnični sklop, kadar naročnik že ima lastno ekipo za preostali del. Ta prilagodljivost je pomembna, ker redko kateri projekt v podjetju z več oddelki potrebuje enak obseg zunanje pomoči na vseh področjih.

• Ali lahko prevzame celoten projekt ali samo določen sklop, kot je integracija enega sistema
• Kakšne vloge lahko sestavi v projektno ekipo – od solution architecta do QA inženirja
• Ali ima izkušnje s prevzemom obstoječih ali nedokončanih sistemov po pregledu kode in infrastrukture
• Kako poteka testiranje pred objavo v produkcijo in ali je mogoč neodvisen QA
• Kakšna je raven podpore po uvedbi in kako so razvrščene stopnje nujnosti napak
• Kako je urejena primopredaja dokumentacije, dostopov in gesel ob zaključku projekta

Vzdrževanje in podpora po uvedbi#

Po uvedbi digitalne rešitve za upravljanje projektov se vprašanje podpore ne konča, temveč se šele začne, saj povezani sistemi zahtevajo stalen nadzor delovanja, odpravo napak in redne varnostne posodobitve. Obseg podpore se določi po projektu, lahko pa vključuje tudi nadaljnji razvoj, kadar se potrebe podjetja spremenijo po zagonu. Brez dogovorjenega modela podpore se odgovornost za napake po zagonu pogosto znajde v negotovosti med naročnikom in izvajalcem.

Razvrstitev napak v razrede je pomembna zato, da se vsaka prijava obravnava glede na dejanski vpliv na poslovanje, ne po vrstnem redu prispetja. Odzivni časi za posamezen razred se dogovorijo v pogodbi o podpori in se razlikujejo glede na kritičnost sistema, zato univerzalnih odzivnih časov v urah ni mogoče navesti vnaprej, saj so odvisni od konkretnega dogovora z naročnikom.

Za podjetja, ki so projekt upravljanja in integracije zgradila z zunanjim izvajalcem, je podpora po SLA način, da ostane sistem usklajen z morebitnimi spremembami v povezanih ERP, CRM ali dokumentnih sistemih, ki se posodabljajo neodvisno od projekta samega. Brez tega nadzora se lahko zgodi, da posodobitev enega povezanega sistema poruši delovanje integracije, ne da bi kdo to opazil, dokler ne pride do dejanske motnje.

• Razred 1 – izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Razred 2 – motnja: sistem deluje, posamezna funkcija ne, obravnava po dogovorjeni prednosti
• Razred 3 – napaka: manjša napaka brez vpliva na poslovanje, uvrščena v naslednjo objavo
• Razred 4 – zahteva: sprememba ali nadgradnja, za katero se oceni obseg in uskladi termin

Kaj vpliva na ceno projekta digitalizacije in integracije?#

Cena projekta digitalizacije in integracije je odvisna od obsega funkcionalnosti, števila sistemov, ki jih je treba povezati, in zahtev glede varnosti in podpore, zato se cen vnaprej ne navaja brez predhodne analize. Namesto splošne ocene se predlaga krajša analiza, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno, kar naročniku omogoči primerjavo med več možnimi pristopi.

Prevzem obstoječega ali nedokončanega sistema ima drugačno ceno kot gradnja novega, ker je treba najprej opraviti pregled kode, arhitekture in podatkov, šele nato je mogoče oceniti preostali obseg dela. Prav zato je prva faza takega projekta pogosto analiza, ne razvoj, saj se šele z njo pokaže, koliko od obstoječega sistema je mogoče ohraniti in koliko je treba zgraditi na novo.

Količina in stanje podatkov, ki jih je treba prenesti med sistemi, prav tako vpliva na obseg dela, posebej kadar gre za podatke, ki so bili leta zbirani v različnih formatih brez enotne strukture. Čiščenje in uskladitev takih podatkov je lahko zahtevnejše od same integracije, zato se ta korak vedno oceni posebej, preden se potrdi končni obseg projekta.

• Obseg funkcionalnosti in število uporabniških vlog v sistemu
• Koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• Ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• Zahteve glede varnosti, revizijske sledi in skladnosti, zlasti v javnem sektorju in reguliranih panogah
• Obseg testiranja in ali je potreben neodvisen QA
• Raven podpore po uvedbi in dogovorjeni odzivni časi