ERP rešitve za analitiko podatkov v podjetju

Kaj so ERP rešitve za analitiko podatkov in čemu služijo?#

ERP rešitve za analitiko podatkov so nadgradnja obstoječega poslovnega informacijskega sistema, ki podatke iz financ, nabave, proizvodnje in prodaje združi v enotno sliko, primerno za poročanje in odločanje. Namesto da vodja oddelka podatke ročno prenaša v preglednice, jih sistem pripravi samodejno, v obliki, ki je pripravljena za nadaljnjo obdelavo. Tak pristop je smiseln predvsem takrat, ko podjetje raste prek enega oddelka ali ene lokacije in potrebuje pregled, ki povezuje več virov hkrati.

V praksi to pomeni, da ERP sistem ni le evidenca transakcij, temveč tudi vir podatkov za nadaljnjo analitiko, poročanje in napovedovanje. Podjetja z več kot milijon evrov letnih prihodkov imajo običajno že vzpostavljen ERP, poleg njega pa pogosto tečejo še ločeni sistemi za kadre, dokumente ali proizvodnjo. Analitična rešitev mora te vire povezati, ne da bi podvajala vnos podatkov ali ustvarila novo evidenco, ki je nihče ne vzdržuje.

Odločitev o tem, kako zasnovati analitiko nad ERP podatki, zato ni le tehnično vprašanje, temveč organizacijsko. Določiti je treba, kdo je lastnik posameznega podatkovnega vira, kateri podatki morajo biti dostopni v realnem času in kateri zadostujejo v dnevnih ali tedenskih povzetkih. Te odločitve kasneje vplivajo na arhitekturo rešitve in na to, koliko dela zahteva njeno vzdrževanje.

Kje najpogosteje nastanejo težave pri povezovanju ERP podatkov z analitiko#

Največ težav pri analitiki ERP podatkov ne izvira iz same analitične plasti, temveč iz stanja podatkov v osnovnem sistemu. Če so šifranti izdelkov, strank ali stroškovnih mest v različnih oddelkih vodeni različno, poročilo, ki jih združuje, pokaže napačno sliko, čeprav je tehnično pravilno izdelano. Zato se vsak resen projekt ERP analitike začne s pregledom stanja podatkov, ne s postavitvijo poročil.

Druga pogosta težava je omejen ali slabo dokumentiran dostop do podatkov znotraj ERP sistema. Nekateri sistemi ponujajo odprt API, drugi zahtevajo izvoz prek vmesnih datotek ali ročno pripravo poročil. V obeh primerih je treba pred začetkom dela preveriti, kaj sistem dejansko omogoča, in to preveriti na dejanskem okolju naročnika, ne le na podlagi dokumentacije proizvajalca.

Težave se v praksi skoraj vedno pojavijo na presečišču med oddelki, ne znotraj enega samega modula ERP sistema. Prodaja vodi svoje šifrante, proizvodnja svoje, nabava pa pogosto tretje, in analitika, ki jih poskuša združiti, mora te razlike najprej odpraviti ali vsaj preslikati. Enak problem se pojavi pri zgodovinskih podatkih, ki so bili leta nazaj vneseni po drugačnih pravilih kot danes. Preden se lotimo postavitve poročil, zato popišemo okoliščine, ki najpogosteje upočasnijo projekt:

Vsaka od teh okoliščin pomeni dodatno delo pred postavitvijo analitike, zato jih popišemo že v fazi analize in jih razčlenimo na posamezne sklope. Naročnik tako dobi realno sliko obsega dela, preden se odloči za nadaljevanje, izvajalec pa jasno izhodišče za arhitekturo rešitve. Brez tega koraka se analitična plast pogosto gradi na podatkih, ki niso zanesljivi, kar se pokaže šele, ko vodstvo poročilom preneha zaupati.

• Podatki so razpršeni po več modulih in bazah
• Šifranti in matične evidence niso usklajeni med oddelki
• Zgodovinski podatki so nepopolni ali neenotno vneseni
• API dostop do ERP sistema je omejen ali slabo dokumentiran
• Poročila se pripravljajo ročno v preglednicah
• Ni jasne lastnine nad podatkovnim modelom

Kako izbrati pravi pristop k analitiki ERP podatkov?#

Pravi pristop k analitiki ERP podatkov izberete glede na to, koliko virov podatkov povezujete, kako hitro potrebujete sveže podatke in kdo bo poročila uporabljal. Ni ene rešitve, ki bi ustrezala vsem; manjše podjetje z enim ERP sistemom potrebuje drugačno arhitekturo kot organizacija, ki povezuje ERP, CRM in sisteme za upravljanje dokumentov hkrati. Odločitev o pristopu zato sledi šele po analizi obstoječih sistemov, ne pred njo.

Pri izbiri pristopa je treba ločiti med poročanjem, ki povzema pretekle podatke, in analitiko, ki podpira odločanje v realnem času. Finančno poročanje praviloma zadostuje v dnevnih ali tedenskih povzetkih, medtem ko nadzor zalog ali proizvodnih linij pogosto zahteva sprotne podatke. Mešanje teh dveh potreb v eno samo rešitev brez razmisleka vodi v sistem, ki je za eno uporabo premočan, za drugo pa prepočasen.

Preden izberemo tehnično arhitekturo, skupaj z naročnikom razčlenimo nekaj izhodiščnih vprašanj, ki jih je treba razjasniti, še preden se lotimo zasnove rešitve. Od odgovorov nanje je namreč odvisno, ali bo rešitev temeljila na obstoječem poročevalskem modulu znotraj ERP sistema, na ločeni analitični plasti, ali na kombinaciji obeh pristopov. Vprašanja, ki jih v tej fazi najpogosteje postavimo naročniku, so naslednja:

Odgovori na ta vprašanja določijo, ali se splača nadgraditi obstoječi ERP modul za poročanje ali postaviti ločeno analitično plast, ki podatke zajema iz več virov hkrati. Pri reguliranih panogah, kot je javni sektor, k temu dodamo tudi vprašanje revizijske sledi in nadzora dostopa do podatkov. Šele ko so ta izhodišča jasna, ima smisel govoriti o konkretni arhitekturi in o tem, kateri del sistema prevzamemo v celoti in kateri kot posamezen sklop.

• Katere oddelke in sisteme je treba povezati
• Kako pogosto se podatki spreminjajo in kako hitro jih potrebujemo
• Kdo bo poročila uporabljal in na kateri napravi
• Ali je potrebna revizijska sled za regulirane podatke
• Ali gre za nov sistem ali nadgradnjo obstoječega
• Kakšna je pričakovana rast obsega podatkov

Kateri podatki iz ERP sistema so najbolj uporabni za analitiko?#

Najbolj uporabni so podatki, ki se v ERP sistemu že vodijo dnevno in neposredno odražajo stanje poslovanja: finance, zaloge, naročila in stroški dela. To so podatki, ki jih podjetje že zbira zaradi same narave poslovanja, zato jih ni treba na novo vzpostavljati, temveč jih je treba le ustrezno povezati in prikazati v obliki, primerni za odločanje vodstva.

Poleg teh osnovnih sklopov je vredno vključiti tudi podatke o dobaviteljih, rokih dostave in kakovosti, saj ti pogosto pojasnijo vzrok za odstopanja, ki jih finančni ali prodajni podatki sami po sebi ne pokažejo. Proizvodna podjetja k temu dodajo še podatke o kapacitetah strojev in izmenah, javni zavodi pa podatke o izvajanju storitev in rokih, ki jih morajo spremljati zaradi poročanja nadzornim organom.

Ne glede na panogo se pri zasnovi ERP analitike v podjetju pogosto izkaže, da je smiselno začeti z omejenim naborom podatkovnih sklopov in ga širiti šele, ko je prvi del analitike zanesljiv in v uporabi. V prvo fazo najpogosteje uvrstimo naslednje sklope podatkov, saj dajo vodstvu najhitrejši pregled nad poslovanjem:

Ko je ta prvi nabor vzpostavljen in se vodstvo nanj zanese, ga širimo s podatki, ki so specifični za panogo ali oddelek, na primer s podatki o kakovosti v proizvodnji ali o izvajanju storitev v javnem zavodu. Postopno širjenje je bolj obvladljivo kot poskus, da bi v enem koraku povezali vse razpoložljive podatkovne vire, saj se napake pri šifrantih in matičnih podatkih pri manjšem obsegu lažje odkrijejo in popravijo.

• Finančni podatki: prihodki, stroški, likvidnost
• Podatki o zalogah in nabavi
• Podatki o proizvodnji in kapacitetah
• Podatki o prodaji in naročilih
• Podatki o kadrih in stroških dela
• Podatki o dobaviteljih in rokih dostave

Vloga AI in avtomatizacije pri analitiki ERP podatkov#

AI in avtomatizacija v ERP analitiki prevzamejo naloge, ki so doslej zahtevale ročno pripravo poročil, na primer izločanje podatkov iz dokumentov, zaznavanje odstopanj in pošiljanje obvestil, ko vrednost preseže dogovorjeno mejo. Namesto da zaposleni vsak teden pripravijo isto poročilo v preglednici, sistem podatke pripravi samodejno in opozori le, kadar se pojavi odstopanje, ki si ga je vredno ogledati.

Pri podjetjih, ki prejemajo veliko število dokumentov, kot so računi, dobavnice ali pogodbe, se AI uporablja tudi za ekstrakcijo podatkov iz teh dokumentov in njihov prenos v ERP sistem brez ročnega vnosa. To zmanjša število ročnih vnosov in s tem tudi število napak, ki sicer kasneje otežijo analitiko, saj se napačno vneseni podatki v poročilih pokažejo kot nepojasnjena odstopanja.

Druga pogosta uporaba je semantično iskanje po internih dokumentih in evidencah, ki zaposlenim omogoča, da hitro najdejo odgovor na vprašanje, ne da bi morali brskati po več sistemih hkrati. Pri tem je pomembno, da AI komponenta deluje nad podatki, ki so že urejeni in dostopni prek API-ja, saj v nasprotnem primeru samo podeduje obstoječe napake v matičnih podatkih in jih ne odpravi.

Avtomatizacijo poročanja in obveščanja je smiselno nadgraditi šele, ko je osnovna analitika stabilna in podatki zanesljivi. Če se AI komponenta vgradi prehitro, v okolje s slabo urejenimi šifranti, rezultat ni hitrejše odločanje, temveč hitrejše širjenje napačnih sklepov. Zato AI del projekta praviloma sledi ureditvi podatkov, ne obratno.

Varnost podatkov in skladnost pri ERP analitiki#

Varnost podatkov pri ERP analitiki je vprašanje nadzora dostopa, saj analitična plast pogosto združuje podatke, ki so bili prej razpršeni po ločenih sistemih in dostopni le omejenemu krogu zaposlenih. Ko se finančni, kadrovski in proizvodni podatki znajdejo v enem poročilu, je treba na novo določiti, kdo ga lahko vidi v celoti in kdo le del, ki se nanaša na njegov oddelek.

Pri javnem sektorju in reguliranih panogah to vprašanje dodatno zaostri zahteva po revizijski sledi: vedeti je treba, kdo je podatek spremenil, kdaj in zakaj. Razvojno, testno in produkcijsko okolje zato ločimo, v testnem okolju pa ne uporabljamo pravih osebnih podatkov, saj bi s tem nepotrebno povečali tveganje za uhajanje podatkov zunaj produkcijskega sistema, kjer je nadzor dosleden.

Vsaka sprememba analitične rešitve gre skozi pregled in testiranje, preden pride v produkcijsko okolje, kar velja tudi za spremembe, ki vplivajo na to, kateri podatki so vidni kateri uporabniški vlogi. To je še posebej pomembno pri ERP sistemih, kjer napačno nastavljena pravica dostopa lahko izpostavi finančne ali kadrovske podatke zaposlenim, ki do njih ne bi smeli imeti dostopa.

Izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta ali posameznega sklopa. S tem naročnik ohrani nadzor nad tem, kdo ima dostop do analitičnega okolja tudi po koncu sodelovanja z izvajalcem, kar je pri podatkih, ki vključujejo finančne ali osebne informacije, ključno vprašanje.

Kako poteka uvedba ERP analitične rešitve?#

Uvedba ERP analitične rešitve poteka po korakih, od analize obstoječih podatkov in sistemov do primopredaje dokumentacije in dogovora o nadaljnji podpori. Projekt lahko prevzamemo v celoti ali le kot posamezen sklop, na primer samo povezavo ERP sistema z enim analitičnim poročilom, odvisno od tega, kaj naročnik že ima vzpostavljeno in kaj mu manjka.

Pri večjih projektih na začetku določimo projektnega vodjo, odgovornosti posameznih ekip, način komunikacije in poročanja o napredku. To je pomembno zlasti takrat, ko je v projekt vključenih več oddelkov naročnika, saj mora vsak vedeti, kdo je odgovoren za kateri del podatkov in kdo potrjuje, da je posamezen sklop pripravljen za naslednjo fazo.

Kadar naročnik že ima delno zgrajen ali nedokončan analitični sistem, ga lahko prevzamemo po pregledu izvorne kode, arhitekture, infrastrukture in obstoječih podatkov. To je pogosto hitrejša pot kot gradnja na novo, saj ohrani že opravljeno delo, hkrati pa zahteva natančen pregled, da se napake iz prejšnje faze ne prenesejo naprej v novo analitično plast.

Ne glede na to, ali gre za nov projekt ali za prevzem obstoječega, delno zgrajenega sistema, potek dela sledi podobnemu zaporedju korakov, ki zagotavlja, da nobena faza ne steče mimo nadzora naročnika in da je vsak korak mogoče preveriti, preden se nadaljuje na naslednjega. Celoten potek uvedbe ERP analitične rešitve lahko strnemo v naslednje korake:

Po primopredaji naročnik prejme vso dokumentacijo, dostope in gesla, tako da ni odvisen od enega izvajalca za nadaljnje spremembe sistema. S tem je zagotovljeno, da lahko podatke in izvorno kodo, ki so last naročnika, po potrebi prenese tudi k drugemu izvajalcu, brez izgube že vloženega dela.

• Analiza obstoječih sistemov in podatkov
• Določitev projektnega vodje in odgovornosti ekip
• Ločena razvojna, testna in produkcijska okolja
• Testiranje in prevzemno preverjanje pred objavo v produkcijo
• Primopredaja dokumentacije, dostopov in gesel
• Dogovor o nadaljnji podpori in vzdrževanju

Vzdrževanje in podpora po uvedbi ERP analitike#

Po uvedbi ERP analitične rešitve je smiselno dogovoriti se o nadaljnji podpori, saj se potrebe po spremembah pokažejo šele, ko sistem dejansko začne uporabljati širši krog zaposlenih. Lahko prevzamemo nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj, obseg pa se določi glede na to, kako kritičen je sistem za vsakodnevno poslovanje naročnika.

Napake in zahteve po spremembah razvrščamo po razredih, kar omogoča, da se najprej obravnava tisto, kar dejansko ustavi delo, in šele nato manjše izboljšave. Izpad celotnega sistema ali ključnega dela analitike ima najvišjo prednost, motnja pri posamezni funkciji nižjo, manjša napaka brez vpliva na poslovanje pa se uvrsti v naslednjo redno objavo sprememb.

Pri podpori po uvedbi je koristno že vnaprej določiti, v kateri razred spada posamezna težava, saj se s tem izogne razpravam o prednosti obravnave v trenutku, ko je sistem že moten in vodstvo čaka na poročilo. Razvrstitev, ki jo uporabljamo pri podpori ERP analitičnih rešitev, vključuje naslednje štiri razrede zahtevkov:

Odzivni čas za vsak razred se dogovori v pogodbi o podpori in je odvisen od tega, kako kritičen je sistem za poslovanje naročnika, zato ga na tem mestu ne posplošujemo. Pomembno je, da je razvrstitev znana vnaprej, tako da ob prijavi težave ni treba najprej razpravljati o tem, kako nujna je, temveč se lahko takoj preide k reševanju.

• Izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Motnja: sistem deluje, posamezna funkcija ne
• Napaka: manjša napaka brez vpliva na poslovanje, uvrščena v naslednjo objavo
• Zahteva: sprememba ali nadgradnja, obseg ocenimo in uskladimo termin

Kako izbrati izvajalca za analitiko ERP podatkov?#

Izvajalca za analitiko ERP podatkov izberete po tem, ali zna delati z obstoječim sistemom naročnika, ne le postaviti novega, ter po tem, kako jasno opredeli odgovornosti, roke in način poročanja še pred začetkom dela. Pri projektih, ki posegajo v več oddelkov, je enako pomembno, da izvajalec razume organizacijske posledice projekta, ne le tehnične.

Preverite, ali izvajalec loči razvojno, testno in produkcijsko okolje ter ali v testnem okolju uporablja prave osebne podatke, kar je pri finančnih in kadrovskih podatkih nesprejemljivo tveganje. Enako velja za vprašanje, kdo je po zaključku projekta lastnik izvorne kode in podatkov; pri resnem izvajalcu je odgovor vedno naročnik, dokumentacija in dostopi pa so del primopredaje.

Pri izbiri izvajalca za projekt ERP analitike podatkov se splača iti skozi nekaj konkretnih vprašanj, saj odgovori pokažejo, ali izvajalec razume obseg dela, ki ga tak projekt dejansko zahteva, in ne le obljublja hitre rezultate brez vpogleda v obstoječe sisteme. Preden se odločite za sodelovanje, je smiselno preveriti naslednje točke:

Odgovori na ta vprašanja povedo več kot splošne predstavitve referenc, saj projekt ERP analitike podatkov v veliki meri sloni na tem, kako urejeno izvajalec dela z obstoječimi sistemi naročnika. Izvajalec, ki teh vprašanj ne zna jasno odgovoriti, verjetno tudi med projektom ne bo imel jasnega odgovora na vprašanja, ki se pojavijo sproti.

• Ali izvajalec pred ponudbo pregleda obstoječe sisteme in podatke
• Kako določa odgovornosti, roke in način poročanja o napredku
• Ali ločuje razvojno, testno in produkcijsko okolje
• Kaj se zgodi z izvorno kodo in podatki po zaključku projekta
• Ali ponuja podporo in SLA po uvedbi rešitve

Od česa je odvisna cena ERP rešitve za analitiko podatkov?#

Cena ERP rešitve za analitiko podatkov ni fiksna, saj je odvisna od obsega funkcionalnosti, števila povezanih sistemov in stanja podatkov, ki jih je treba urediti pred postavitvijo analitike. Zato cen in cenovnih razponov ne navajamo vnaprej, temveč predlagamo krajšo analizo, ki obseg razčleni na sklope, tako da je vsak sklop ocenljiv in izvedljiv ločeno od drugih.

Na obseg dela najbolj vpliva to, koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji, ter ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega. Prevzem obstoječega, delno zgrajenega sistema zahteva poseben pregled izvorne kode in arhitekture, preden je mogoče oceniti, koliko dela je potrebnega za nadaljnjo analitiko.

Pri ocenjevanju obsega projekta analitike ERP podatkov upoštevamo več dejavnikov hkrati, saj se šele iz njihove kombinacije pokaže, kako zahteven je posamezen projekt in koliko časa bo zahtevala priprava podatkov pred samo postavitvijo poročil. Med dejavniki, ki jih pri tem upoštevamo, so naslednji:

Šele po takšni analizi je mogoče podati realno oceno obsega dela in časovnega okvira, zato cene objavljamo le po pregledu konkretnih zahtev posameznega naročnika. S tem se izognemo tako podcenjenim ponudbam, ki kasneje privedejo do dodatnih stroškov, kot tudi pavšalnim ocenam, ki ne upoštevajo dejanskega stanja obstoječih sistemov in podatkov.

• Obseg funkcionalnosti in število uporabniških vlog
• 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
• Količina in stanje podatkov, ki jih je treba urediti ali prenesti
• Zahteve glede varnosti, revizijske sledi in skladnosti
• Obseg testiranja in raven podpore po uvedbi