Integracija sistema za vodenje projektov z ERP

Kaj pomeni digitalna integracija sistema za upravljanje projektov z ERP?#

Digitalna integracija sistema za upravljanje projektov z ERP pomeni, da podatki o nalogah, urah, virih in stroških projekta samodejno stečejo v finančni, nabavni in kadrovski del poslovanja, namesto da jih zaposleni vnašajo ločeno v dva sistema. Projektna ekipa še naprej dela v svojem orodju za načrtovanje in sledenje nalogam, ERP pa prejme tiste podatke, ki vplivajo na račune, zaloge, naročila in poročanje vodstvu. Smer povezave je lahko enosmerna ali dvosmerna, odvisno od tega, kateri sistem velja za primaren vir posameznega podatka.

Brez take povezave projektni vodje in finančna služba pogosto delata z različnimi, med seboj neusklajenimi podatki. Ure in stroški se vnašajo najprej v projektno orodje, nato pa še ročno prepišejo v ERP za fakturiranje in spremljanje zalog, kar podaljša zapiranje projektov in povečuje tveganje za napake. Integracija to ročno prepisovanje odpravi in zagotovi, da je stanje projekta v vsakem trenutku enako v obeh sistemih, ne glede na to, kateri oddelek podatke pregleduje.

Za naročnika to pomeni odločitev, kateri podatki se smejo prenašati samodejno in kateri ostanejo pod ročnim nadzorom, na primer potrditev izdanih računov ali odobritev dodatnih ur. Ta odločitev ni tehnična podrobnost, temveč del notranje organizacije dela, saj določa, kdo je odgovoren za točnost podatka in kdaj se sprememba v enem sistemu odrazi v drugem. Pogovor o integraciji je zato smiselno začeti pri procesih, ne pri izbiri orodja.

Zakaj podjetja povezujejo vodenje projektov in ERP#

Podjetja povezujejo projektno vodenje in ERP, ker se brez povezave podatki o delu in podatki o denarju ločijo na dva vzporedna sveta, ki ju je treba ročno usklajevati pred vsakim poročilom vodstvu. V podjetjih z več milijoni evrov prihodka in več projekti hkrati takšno ročno usklajevanje hitro postane delo za več ljudi, ne le administrativna opomba. Integracija zato ni le tehnična nadgradnja, temveč sprememba, ki razbremeni projektne vodje in finančno službo.

Drug razlog je natančnost podatkov o stroških posameznega projekta. Ko so ure, material in zunanje storitve povezane neposredno s projektom v ERP, lahko vodstvo vidi dejansko donosnost projekta brez čakanja na mesečno zapiranje knjig. To je še posebej pomembno v proizvodnji, kjer se stroški dela in materiala spremljajo vzporedno z naročili, in v javnih zavodih, kjer je treba stroške projekta izkazati ločeno za namene poročanja financerju.

Tretji razlog je usklajeno planiranje virov med oddelki, saj projektno orodje pokaže, kdo je zaseden na projektih, ERP pa pokaže, kdo je na voljo glede na kadrovske in nabavne omejitve. Kadar ti dve sliki obstajata ločeno, nastajajo konflikti pri razporejanju ljudi in opreme, ki jih vodstvo opazi šele, ko je rok že ogrožen. Povezan sistem take konflikte pokaže prej, še preden postanejo vidni navzven.

• Odpravljeno dvojno vnašanje ur, nalog in stroškov
• Sprotni vpogled v dejanske stroške posameznega projekta
• Usklajeno planiranje virov med projektnimi in drugimi oddelki
• Hitrejše fakturiranje na podlagi statusa projekta
• Enotno poročanje vodstvu brez ročnega usklajevanja podatkov

Kateri podatki se izmenjujejo med projektnim orodjem in ERP?#

Med sistemom za vodenje projektov in ERP se najpogosteje izmenjujejo podatki o nalogah in mejnikih, opravljenih urah, stroških materiala in storitev ter o stanju naročil, ki vplivajo na fakturiranje in zaloge. Katere podatke je smiselno povezati, je odvisno od tega, kako podjetje organizira projekte in kateri oddelki na podlagi teh podatkov sprejemajo odločitve. Ni nujno, da se povežejo vsa polja obeh sistemov, temveč le tista, ki dejansko vplivajo na poslovne odločitve ali na obveznosti do strank in zaposlenih.

Pri podjetjih, ki izvajajo projekte za zunanje naročnike, je ključna povezava med opravljenimi urami in fakturiranjem, saj mora biti vsaka ura, ki jo projektna ekipa potrdi, vidna tudi v ERP kot osnova za račun. Pri proizvodnih podjetjih je pogosto pomembnejša povezava med projektom in zalogo materiala, saj projekt porablja material, ki ga je treba naročiti in umakniti iz skladišča. V javnem sektorju je dodatno pomembna sledljivost, kdo je kdaj spremenil kateri podatek.

Odločitev o obsegu izmenjave podatkov je zato prva stopnja projekta integracije, ne tehnična podrobnost, ki se reši med razvojem. Naročnik mora skupaj z izvajalcem pregledati, kateri podatki danes že obstajajo v obeh sistemih, kateri so podvojeni in kateri manjkajo, preden se določi, kaj se bo prenašalo samodejno. Ta korak pogosto pokaže, da je treba najprej urediti podatke v obstoječih sistemih, šele nato jih povezati.

• Naloge in mejniki projekta
• Opravljene ure in razpoložljivost zaposlenih
• Stroški materiala in zunanjih storitev
• Stanje naročil in zalog
• Podlage za fakturiranje
• Kadrovski podatki o razpoložljivosti virov

Kako poteka digitalna integracija sistema za upravljanje projektov v praksi?#

Digitalna integracija sistema za upravljanje projektov v praksi poteka po korakih: najprej pregled obstoječih sistemov in njihovih vmesnikov, nato določitev smeri in pogostosti prenosa podatkov, sledi razvoj povezave prek API-ja, testiranje v ločenem okolju in šele nazadnje postopen prehod v produkcijo. Pri tem je pomembno, da se najprej poveže en jasno omejen del, na primer prenos opravljenih ur, preden se obseg širi na fakturiranje, zaloge ali kadrovske podatke.

Pred razvojem je treba pregledati, kakšne vmesnike obstoječi ERP in projektno orodje že ponujata, saj to določa, ali gre za povezavo v realnem času ali za periodično sinhronizacijo, na primer enkrat na dan. Pri starejših ali prilagojenih sistemih je pregled izvorne kode, arhitekture in podatkov pogosto nujen korak, še preden se oceni, kaj je sploh mogoče povezati brez poseganja v obstoječe delovanje sistema.

Spremembe se nato testirajo v ločenem razvojnem in testnem okolju, pri čemer se v teh okoljih ne uporabljajo pravi osebni podatki zaposlenih ali strank. Vsaka sprememba gre skozi pregled in testiranje, preden se objavi v produkcijsko okolje, kjer dejansko delata projektna ekipa in finančna služba. Pri večjih projektih se uvedba razdeli v sklope, tako da se vsak sklop potrdi ločeno in se napake odkrijejo prej, preden vplivajo na celoten sistem.

Katere tehnične odločitve je treba sprejeti pred integracijo#

Pred začetkom integracije je treba določiti, kateri sistem je primaren vir resnice za posamezen podatek, na primer ali so opravljene ure najprej potrjene v projektnem orodju ali v ERP, saj od tega odgovora odvisi celotna arhitektura povezave. Enako velja za stroške in naročila, kjer mora biti vnaprej jasno, kateri sistem sme podatek spremeniti in kateri ga le prikazuje. Brez te odločitve lahko pride do nasprotujočih si zapisov, ki jih je težko pozneje razvozlati.

Druga odločitev je način povezave: ali gre za sinhronizacijo v realnem času prek API-ja ali za periodično izmenjavo datotek, kar je pogosto dovolj za podatke, ki se ne spreminjajo vsak dan, na primer kadrovske razpoložljivosti. Tretja odločitev zadeva obstoječe podatke, saj je treba presoditi, ali jih je smiselno prenesti v povezan sistem v celoti, delno ali šele od določenega datuma dalje, kar vpliva na obseg migracije podatkov.

Kadar ERP ali projektno orodje nista dokončana ali sta bila razvita pri drugem izvajalcu, je mogoče prevzeti obstoječ sistem po pregledu izvorne kode, arhitekture, infrastrukture in podatkov, preden se nadaljuje z integracijo. Ta pregled pokaže, ali obstoječa rešitev sploh prenese dodatno povezavo brez posegov v jedro sistema, ali pa je najprej potrebna manjša prenova posameznega modula, še preden se vzpostavi redna izmenjava podatkov z drugim sistemom.

• Vir resnice za posamezen podatek (projektno orodje ali ERP)
• Način povezave: API v realnem času ali periodična sinhronizacija
• Obravnava podvojenih ali nasprotujočih si zapisov
• Obseg in način migracije obstoječih podatkov
• Ločena razvojna, testna in produkcijska okolja
• Dokumentacija povezave in dostopov

Kaj je treba urediti glede varnosti in dostopov pri integraciji#

Pri integraciji projektnega orodja in ERP je treba vnaprej urediti, kdo ima dostop do povezanih podatkov in kdo lahko spremeni nastavitve same povezave, saj gre pri obeh sistemih pogosto za občutljive podatke o strankah, zaposlenih in financah. Izvorna koda in podatki ostajajo last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta, kar naročniku omogoča, da pozneje zamenja izvajalca brez izgube nadzora nad sistemom.

V razvojnem in testnem okolju se ne uporabljajo pravi osebni podatki zaposlenih ali strank, kar zmanjša tveganje, da bi se občutljivi podatki znašli zunaj produkcijskega okolja med testiranjem povezave. To je še posebej pomembno v panogah, kjer veljajo stroge zahteve glede varstva podatkov in revizijske sledi, na primer v javnem sektorju, financah ali zdravstvu, kjer mora biti razvidno, kdo je kdaj dostopal do katerega podatka.

Znotraj Epixa in njegove specialistične partnerske mreže so na voljo profili za varnostno arhitekturo, upravljanje dostopov in utrjevanje infrastrukture, ki jih je smiselno vključiti, kadar integracija povezuje regulirane sisteme ali sisteme s podatki, ki zahtevajo posebno zaščito. Pri takih projektih je priporočljivo že na začetku določiti, kateri varnostni pregledi so potrebni pred vzpostavitvijo povezave in kateri po njej, med rednim delovanjem sistema.

Kako integracija vpliva na zaposlene in uvedbo sistema?#

Integracija vpliva na zaposlene predvsem tako, da ukine dvojno vnašanje podatkov in spremeni, kje posamezni zaposleni vnaša katero informacijo, kar zahteva usposabljanje in jasno komunikacijo pred prehodom v novo delovanje. Projektni vodje, ki so prej ure in stroške vnašali ločeno v dve orodji, po integraciji delajo samo v enem, medtem ko se drugi podatki prenesejo samodejno, kar pomeni, da se spremenijo tudi njihove delovne navade in pričakovanja do sistema.

Pri večjih projektih se zato že pred uvedbo določi projektni vodja na strani izvajalca, odgovornosti posameznih ekip, roki in način komunikacije ter poročanja, kar naročniku omogoča, da spremlja potek dela in sprotno preverja, ali uvedba sledi dogovorjenemu obsegu. Zaposleni, ki bodo sistem uporabljali, naj bodo vključeni že v fazo preverjanja, kateri podatki se morajo prenašati, saj najbolje poznajo izjeme, ki jih splošen opis procesa pogosto spregleda.

Pred prehodom v redno delovanje je smiselno izvesti prevzemno testiranje, pri katerem zaposleni iz projektnih in finančnih vlog preverijo, ali povezani podatki na obeh straneh ustrezajo dejanskemu stanju. Šele ko ta preizkus potrdijo ljudje, ki bodo sistem dnevno uporabljali, se integracija objavi v produkcijsko okolje, s čimer se zmanjša tveganje, da bi se napaka pokazala šele pri prvem resničnem fakturiranju ali poročilu vodstvu.

Kako izbrati izvajalca za integracijo vodenja projektov z ERP?#

Izvajalca za integracijo vodenja projektov z ERP izberete tako, da preverite, ali je sposoben pred ponudbo pregledati vaše obstoječe sisteme, ne le ponuditi vnaprej pripravljene rešitve, saj se vsaka integracija razlikuje glede na to, kateri sistemi so že v uporabi in kako so bili zgrajeni. Dober pokazatelj je, da izvajalec ponudi pregled izvorne kode, arhitekture, infrastrukture in podatkov še pred določitvijo obsega dela, namesto da obseg oceni le na podlagi splošnega opisa.

Pomembno je tudi, kako izvajalec vodi sam projekt: ali določi enega projektnega vodjo, jasno razmeji odgovornosti ekip in se vnaprej dogovori o načinu poročanja, ali pa se komunikacija med razvojem in naročnikom odvija neformalno. Pri integraciji, ki posega v več oddelkov hkrati, je formalno vodenje projekta pogoj za to, da se spremembe v projektnem orodju in ERP uvajajo usklajeno in da ima naročnik ves čas pregled nad stanjem dela.

Preverite tudi, ali lahko izvajalec prevzame projekt v celoti ali le posamezen sklop, na primer samo povezavo ur in stroškov, ter ali po uvedbi ponuja nadaljnjo podporo, odpravo napak in tehnične posodobitve prek dogovorjenih odzivnih razredov. To je pomembno zato, ker integracija z ERP ni enkratni projekt, temveč del sistema, ki ga je treba vzdrževati skozi celotno obdobje uporabe obeh povezanih rešitev.

• Pregled obstoječe kode, arhitekture in podatkov pred ponudbo
• Določen projektni vodja in jasne odgovornosti ekip
• Dogovorjen način poročanja in komunikacije med razvojem
• Zmožnost prevzema celotnega projekta ali posameznega sklopa
• Ločena testna faza pred objavo v produkcijo
• Podpora in odzivni razredi po uvedbi

Kaj se zgodi po uvedbi integracije vodenja projektov z ERP?#

Po uvedbi integracije sledi obdobje rednega delovanja, v katerem se napake razvrščajo po vnaprej dogovorjenih razredih nujnosti, od popolnega izpada do manjših zahtev za spremembe, kar obema stranema omogoča, da ve, kaj lahko pričakuje in v kakšnem vrstnem redu se bodo težave reševale. Brez takšne razvrstitve se lahko manjša kozmetična napaka obravnava enako nujno kot izpad fakturiranja, kar po nepotrebnem obremeni ekipo za podporo.

Razred 1 pomeni izpad, ko sistem ali ključna povezava med projektnim orodjem in ERP ne deluje, razred 2 motnjo, ko sistem deluje, a posamezna funkcija ne, razred 3 manjšo napako brez vpliva na poslovanje, ki se uvrsti v naslednjo objavo, in razred 4 zahtevo za spremembo ali nadgradnjo povezave, za katero se obseg in termin šele uskladita. Odzivni časi za vsak razred se določijo v pogodbi o podpori.

Poleg odprave napak po uvedbi pogosto sledi tudi nadaljnji razvoj povezave, na primer razširitev na dodatne podatke ali dodaten oddelek, ki se v prvem koraku ni vključil. Zato je smiselno že ob podpisu pogodbe o podpori dogovoriti, kako se obravnavajo tehnične in varnostne posodobitve obeh povezanih sistemov, saj spremembe na strani ERP ali projektnega orodja lahko vplivajo tudi na delovanje same povezave.

• Razred 1 – izpad: sistem ali ključna povezava ne deluje
• Razred 2 – motnja: sistem deluje, posamezna funkcija ne
• Razred 3 – napaka: manjša napaka brez vpliva na poslovanje
• Razred 4 – zahteva: sprememba ali nadgradnja povezave

Koliko stane integracija vodenja projektov z ERP?#

Cene integracije vodenja projektov z ERP ne objavljamo, saj je odvisna od obsega funkcionalnosti, števila povezanih sistemov in stanja podatkov, ki jih je treba prenesti, zato vsak projekt obravnavamo posebej. Namesto splošne cenovne tabele je bolj uporabno razumeti, od česa je obseg dela sploh odvisen, saj to naročniku pomaga oceniti velikost projekta še preden pridobi konkretno ponudbo. Dve na videz podobni integraciji se lahko po obsegu dela močno razlikujeta, odvisno od tega, koliko sistemov je treba povezati in kako zahtevna je migracija podatkov.

Na obseg dela vpliva predvsem število uporabniških vlog in funkcionalnosti, ki jih je treba povezati, ter to, ali gre za povsem nov sistem ali za prevzem in nadgradnjo obstoječega. Pomembna je tudi količina in stanje podatkov, ki jih je treba prenesti, saj urejeni podatki zahtevajo bistveno manj dela kot podatki, ki so leta nastajali v različnih razpredelnicah in ločenih sistemih brez skupnih pravil vnosa.

Na ceno dodatno vplivajo zahteve glede varnosti in revizijske sledi, zlasti v javnem sektorju in reguliranih panogah, ter obseg testiranja, ki ga projekt zahteva, vključno s tem, ali je potreben neodvisen QA, ločen od razvojne ekipe. Priporočamo, da se pred ponudbo izvede krajša analiza, ki obseg razdeli na posamezne sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno, namesto da se cena projekta oceni kot ena nedeljiva številka.