Podatki in analitika: od poročil do odločanja

Od poročil do odločanja: kaj to pomeni za podjetje#

Poslovna analitika v podjetju pomeni, da podatki iz različnih sistemov ne ostanejo le zapisi za nazaj, temveč postanejo podlaga za tekoče odločanje. Poročilo pove, kaj se je zgodilo v preteklem obdobju: koliko je bilo prodaje, kakšna je bila zasedenost proizvodnje, koliko reklamacij je prišlo v podporo. Odločanje potrebuje več kot to – potrebuje podatke, ki so sveži, primerljivi med oddelki in dostopni takrat, ko jih odgovorna oseba potrebuje. Prehod od poročil k odločanju je zato v prvi vrsti organizacijski premik, šele nato tehnični.

Razlika med poročanjem in odločanjem je v času in kontekstu. Poročilo praviloma nastane po zaključku obdobja, ko je za ukrepanje pogosto prepozno. Odločanje zahteva, da vodja proizvodnje, financ ali nabave vidi odstopanje, ko se zgodi, in ne šele na mesečnem sestanku. To pomeni, da mora biti podatek iz proizvodnje, zalog, naročil in financ na voljo v enem pogledu, ne v ločenih izvozih iz posameznih sistemov, ki jih nekdo ročno združuje v preglednici.

Ker podatki v srednje velikem in velikem podjetju nastajajo v ERP, CRM, proizvodnih sistemih, dokumentnih rešitvah in kadrovskih orodjih, projekt analitike skoraj vedno zadeva več oddelkov hkrati. Vodja IT mora zagotoviti povezljivost sistemov, vodja financ mora potrditi, kateri podatek je merodajen, vodja proizvodnje pa mora podatke iz strojev in senzorjev pripeljati v isto sliko kot poslovne kazalnike. Brez usklajenega dogovora med oddelki analitika ostane le še eno dodatno poročilo, ne pa orodje za odločanje.

Kje v podjetju nastajajo podatki, ki jih je treba povezati#

Preden se podjetje loti analitike, je smiselno popisati, kje vsi podatki dejansko nastajajo. V praksi to niso le finančni in prodajni podatki iz ERP-ja, temveč tudi podatki iz proizvodnje, dokumentni zapisi, komunikacija s strankami in kadrovski sistemi. Vsak od teh virov ima svojo strukturo, svojo pogostost osveževanja in svojega lastnika znotraj podjetja. Popis virov je prvi korak, ker pokaže, kje so podatki popolni in ažurni ter kje bo treba vzpostaviti dodatno zajemanje ali povezavo.

Vsak od naštetih virov v podjetju že obstaja, redko pa je med seboj povezan. Prodajni podatki iz CRM sistema pogosto ne govorijo z zalogami v ERP-ju, podatki iz proizvodnje pa ostanejo v ločenem nadzornem sistemu, do katerega poslovna stran nima dostopa. Posledica je, da vodje odločajo na podlagi delne slike, saj celotnega vpogleda nihče ročno ne sestavlja dovolj pogosto. Povezovanje virov zato ni le tehnično vprašanje, temveč vpliva na to, kako hitro in kako zanesljivo se v podjetju sprejemajo odločitve.

Pri popisu virov je treba določiti tudi, kateri podatek je merodajen, kadar se isti kazalnik pojavi v dveh sistemih. Če se na primer število naročil razlikuje med CRM-jem in ERP-jem, mora biti vnaprej jasno, kateri sistem je vir resnice. To odločitev sprejme poslovna stran, ne razvijalec, saj gre za vsebinsko in ne tehnično vprašanje. Šele ko je to dogovorjeno, ima smisel graditi povezave in poročila nad podatki.

• ERP sistemi: naročila, zaloge, finančni podatki, nabava
• CRM sistemi: stranke, prodajne priložnosti, komunikacija
• Proizvodni in senzorski sistemi: izmene, zastoji, kakovost
• Dokumentni sistemi: pogodbe, poročila, interna dokumentacija
• Kadrovski sistemi: prisotnost, usposabljanja, organizacijska struktura
• Spletne in mobilne aplikacije: naročila strank, uporabniška aktivnost

Zakaj klasična poročila ne zadostujejo za tekoče odločanje#

Klasično poročilo nastane po zaključenem obdobju in je pogosto rezultat ročnega izvoza iz enega ali več sistemov. Nekdo v financah ali kontrolingu podatke prenese v preglednico, jih uredi in pošlje naprej. Postopek je razumljiv, dokler je poročilo namenjeno pregledu preteklega stanja, denimo mesečnemu zaključku. Težava nastane, ko isto poročilo uporabljajo tudi za sprotne odločitve, na primer o nabavi surovin ali razporeditvi proizvodnih kapacitet, kjer je informacija stara že takrat, ko pride do odločevalca.

Ročno sestavljanje poročil ima še eno posledico: vsak dodaten vir podatkov pomeni dodatno delo in dodaten prostor za napako. Če podjetje širi ponudbo, odpira nove lokacije ali uvaja nov prodajni kanal, se ročni postopek podaljšuje, namesto da bi se poenostavil. Posledično poročila zamujajo ali pa jih pripravljavci poenostavijo do te mere, da izgubijo del vrednosti. Vodstvo tako dobi pregleden, a nepopoln pogled na stanje, kar poveča tveganje pri odločitvah z večjim vplivom.

Odločanje v realnem času ne pomeni, da je vsak podatek treba spremljati vsako sekundo, temveč da je podatek na voljo takrat, ko je odločitev na vrsti. Za nabavo je to lahko dnevni pregled zalog, za proizvodnjo pregled izmene, za vodstvo pa teden ali mesec, glede na naravo odločitve. Ključno je, da frekvenco osveževanja določi poslovna potreba, ne tehnične zmožnosti posameznega sistema, in da je ta frekvenca za vsak kazalnik eksplicitno dogovorjena.

Kaj je treba določiti pred uvedbo analitike#

Preden se začne razvoj analitičnega sistema, mora podjetje določiti nekaj organizacijskih vprašanj, ki jih tehnologija sama ne reši. Prvo je lastništvo podatkov: kdo je odgovoren, da so podatki o strankah, zalogah ali proizvodnji točni in ažurni. Brez jasnega lastnika se napake nabirajo, saj jih nihče sistematično ne popravlja. Drugo vprašanje je vir resnice – kadar se isti kazalnik izračunava v ERP-ju in v ločenem poročilu, mora biti vnaprej jasno, kateri vir velja kot merodajen za odločanje.

Enako pomembne so enotne definicije kazalnikov. Če prodaja v enem oddelku šteje naročilo od datuma vnosa, finance pa od datuma izstavitve računa, bo isti izraz v dveh poročilih pomenil različno število. Tovrstna razhajanja spodkopljejo zaupanje v analitiko že v prvih tednih uporabe, zato jih je smiselno razrešiti pred razvojem, ne med njim. Dogovor o definicijah je poslovna, ne razvojna naloga, in ga mora potrditi vodstvo posameznih oddelkov.

Dostopne pravice do podatkov je treba določiti glede na vlogo, ne glede na oddelek kot celoto. Vodja proizvodnje na primer ne potrebuje vpogleda v osebne podatke zaposlenih v drugih enotah, prodajna ekipa pa ne potrebuje dostopa do celotne finančne slike podjetja. Jasna razmejitev dostopov zmanjša tveganje pri delu z osebnimi in poslovno občutljivimi podatki ter je pogoj za to, da analitiko lahko uporablja širši krog zaposlenih, ne le ozek krog administratorjev.

• lastništvo posameznega podatka in odgovornost za njegovo točnost
• vir resnice za vsak ključni kazalnik, kadar se pojavlja v več sistemih
• pravice dostopa do podatkov po vlogah in oddelkih
• enotne definicije kazalnikov, da isto številko vsi razumejo enako
• pogostost osveževanja podatkov glede na namen uporabe
• postopek za popravek napačnih ali manjkajočih podatkov

Vloga povezovanja sistemov in API-jev#

Ko so organizacijska vprašanja razjasnjena, sledi tehnično povezovanje sistemov. V praksi to pomeni, da ERP, CRM, proizvodni in dokumentni sistemi med seboj izmenjujejo podatke prek API-jev, namesto da bi zaposleni podatke ročno prepisovali iz enega sistema v drugega. Ročno prepisovanje je počasno in je eden glavnih virov napak v poročilih, saj se pri vsakem prepisu poveča možnost, da se številka izgubi ali spremeni.

Povezovanje sistemov prek API-jev omogoča, da se podatek vnese enkrat, na izvoru, nato pa se avtomatsko pojavi povsod, kjer je potreben – v poročilu za vodstvo, v nadzorni plošči za proizvodnjo ali v obvestilu za nabavo. To ne pomeni, da se vsi sistemi zamenjajo, temveč da se obstoječi sistemi povežejo tako, da delujejo kot celota. Pri podjetjih, ki že imajo uveljavljen ERP ali CRM, je to pogosto hitrejša in cenejša pot kot zamenjava celotnega sistema.

Pri povezovanju je treba posebej urediti primere, ko sistem nima urejenega API-ja ali kadar gre za starejšo, prilagojeno rešitev. V takih primerih je pred integracijo potreben pregled izvorne kode, arhitekture in podatkov obstoječega sistema, da se ugotovi, kaj je mogoče povezati neposredno in kje je potrebna dodatna plast za izmenjavo podatkov. Ta korak je pogosto podcenjen, čeprav je od njega največ odvisno, ali bo projekt analitike sledil realnemu stanju sistemov ali le teoretičnemu.

AI in napredna analitika kot podpora odločanju#

Ko so podatki povezani in urejeni, se odpre prostor za napredno analitiko in AI. AI agenti lahko spremljajo dogovorjene kazalnike in opozorijo odgovorno osebo, ko pride do odstopanja, namesto da bi vodja čakal na naslednje redno poročilo. RAG sistemi omogočajo iskanje po interni dokumentaciji, pogodbah in pretekli komunikaciji v naravnem jeziku, kar skrajša čas, ki ga zaposleni porabijo za iskanje informacij po razpršenih virih.

Obdelava dokumentov in ekstrakcija podatkov sta pomembni tam, kjer podjetje še vedno prejema račune, dobavnice ali pogodbe v obliki, ki ni strukturirana – po pošti, e-pošti ali kot sken. AI rešitve lahko take dokumente preberejo, izluščijo ključne podatke in jih vnesejo v ustrezen sistem, s čimer se zmanjša ročno prepisovanje, ki je sicer eden pogostejših virov napak in zamud v poslovnih procesih.

Napovedna analitika pomaga tam, kjer odločitev ne temelji le na preteklih podatkih, temveč na oceni prihodnjega povpraševanja, zasedenosti ali potrebne zaloge. Taka analitika ne nadomesti odločevalca, temveč mu da oceno tveganja in razpon možnih izidov, na podlagi katerih lažje presodi, kako ukrepati. Ključno je, da je jasno, na katerih podatkih napoved temelji in kako pogosto se osvežuje, sicer vodstvo hitro izgubi zaupanje v njene rezultate.

• AI agenti, ki spremljajo odstopanja in opozarjajo odgovorne osebe
• RAG sistemi za iskanje po interni dokumentaciji in poročilih
• obdelava dokumentov in ekstrakcija podatkov iz pogodb, računov, dobavnic
• napovedna analitika za oceno povpraševanja, zasedenosti ali zalog
• avtomatizacija rednega poročanja in obveščanja

Varnost podatkov in odgovornosti pri analitiki#

Analitika pogosto združuje podatke, ki so bili prej razpršeni po ločenih sistemih z ločenimi dostopnimi pravicami. Ko se ti podatki povežejo na enem mestu, se poveča tudi posledica morebitnega nepooblaščenega dostopa, zato je varnostna arhitektura del projekta, ne naknadna nadgradnja. To pomeni dosledno ločevanje pravic po vlogah, beleženje, kdo je do katerega podatka dostopal, in jasen postopek za odvzem dostopa, ko zaposleni zamenja vlogo ali zapusti podjetje.

Razvojno, testno in produkcijsko okolje morajo biti ločena, v testnem okolju pa se ne uporabljajo pravi osebni podatki. To je pomembno predvsem takrat, ko se analitika razvija ali dopolnjuje postopoma, saj se v nasprotnem primeru občutljivi podatki strank ali zaposlenih znajdejo v okolju, ki nima enake ravni zaščite kot produkcija. Ločitev okolij je standardna praksa, ki jo je treba dogovoriti pred začetkom razvoja, ne med njim.

Odgovornost za varnost podatkov ni le tehnično vprašanje izvajalca, temveč skupna odgovornost naročnika in izvajalca. Naročnik ostane lastnik izvorne kode in podatkov, dokumentacija, dostopi in gesla pa so del vsake primopredaje. Jasna razmejitev, kdo je odgovoren za kaj po uvedbi sistema, je še posebej pomembna v javnem sektorju in reguliranih panogah, kjer revizijska sled in sledljivost dostopov nista le dobra praksa, temveč pogosto tudi zahteva.

Vpliv na zaposlene in spremembo načina dela#

Prehod od ročnih poročil k povezani analitiki spremeni tudi delo zaposlenih, ki so poročila doslej pripravljali ročno. Del njihovega časa, ki je šel za zbiranje in urejanje podatkov, se sprosti za analizo in interpretacijo, kar je za podjetje dodana vrednost, za posameznika pa pomeni spremembo vloge. To spremembo je smiselno komunicirati vnaprej, saj se zaposleni sicer lahko počutijo ogrožene, čeprav gre za premik k bolj analitičnemu, ne manj pomembnemu delu.

Uvedba novih orodij zahteva tudi usposabljanje – ne le tehnično, temveč predvsem razumevanje, kaj posamezen kazalnik pomeni in od kod prihaja. Če zaposleni ne razumejo, kako je številka izračunana, ji ne bodo zaupali, ne glede na to, kako natančno je bila izračunana. Usposabljanje zato ni enkraten dogodek ob zagonu sistema, temveč del uvedbe, ki traja toliko časa, kolikor traja tudi sprememba delovnih navad.

Pri projektih, ki zadevajo več oddelkov, je koristno določiti kontaktno osebo v vsakem oddelku, ki razume tako poslovno kot tehnično stran projekta. Ta oseba pomaga pri prevajanju zahtev med vodstvom, izvajalcem in zaposlenimi, ki bodo sistem uporabljali vsak dan. Brez take vmesne vloge se pogosto zgodi, da sistem tehnično deluje, a ga zaposleni ne uporabljajo v polni meri, ker se jim zdi tuj ali nerazumljiv.

Kako izbrati izvajalca za podatkovne projekte#

Pri izbiri izvajalca za projekt analitike je smiselno preveriti, ali zna prevzeti tudi obstoječ ali delno dokončan sistem, ne le graditi na novo. V srednje velikih in velikih podjetjih redko obstaja povsem prazen prostor za nov sistem – vedno je treba upoštevati ERP, CRM ali proizvodne sisteme, ki že delujejo. Izvajalec mora zato pred ponudbo pregledati izvorno kodo, arhitekturo, infrastrukturo in stanje podatkov obstoječega sistema, ne le prisluhniti željam naročnika.

Drugo merilo je pristop k dogovoru o lastništvu in kakovosti podatkov. Izvajalec, ki predlaga, naj se najprej dogovori vir resnice za vsak kazalnik in lastništvo posameznega podatka, gradi na trdnejših temeljih kot tisti, ki takoj preide na razvoj nadzornih plošč. Prav tako je koristno preveriti, kakšen je proces testiranja: ali gre za ročno in avtomatizirano testiranje, testiranje v okviru razvojnega procesa in prevzemno testiranje po vnaprej dogovorjenih merilih.

Za projekte, ki zadevajo več oddelkov ali daljše obdobje, je pomembno tudi, kako je organizirano vodenje. Pri večjih projektih je smiselno določiti projektnega vodjo, jasno razmejiti odgovornosti posameznih ekip, roke in način poročanja naročniku. Po uvedbi je pomembno vprašanje modela podpore – ali izvajalec prevzame nadzor delovanja, odpravo napak in nadaljnji razvoj ter kako so napake razvrščene po nujnosti, tako da je jasno, katera zahteva takojšnjo obravnavo in katera počaka na naslednjo objavo.

• ali izvajalec zna prevzeti in nadgraditi obstoječ, delno dokončan sistem
• kako pristopa k dogovoru o lastništvu in kakovosti podatkov
• kakšen je pristop k testiranju pred objavo sprememb v produkcijo
• kakšna je ločitev razvojnega, testnega in produkcijskega okolja
• kakšen model podpore ponuja po uvedbi in kako so razvrščene napake po nujnosti
• ali projekt vodi določen projektni vodja z jasnimi odgovornostmi

Kako pristopamo v Epixu#

V Epixu projekt analitike lahko prevzamemo v celoti, od popisa virov podatkov do uvedbe in podpore, ali kot posamezen sklop, na primer povezovanje ERP-ja in CRM-ja prek API-jev. Pri večjih projektih določimo projektnega vodjo, odgovornosti posameznih ekip, roke in način komunikacije z naročnikom, tako da je ves čas jasno, kdo je odgovoren za kateri del sistema in kdaj lahko naročnik pričakuje naslednji korak.

Prav tako lahko prevzamemo obstoječ ali nedokončan sistem, potem ko pregledamo izvorno kodo, arhitekturo, infrastrukturo in stanje podatkov. Razvojno, testno in produkcijsko okolje ločimo, v testnem okolju pa ne uporabljamo pravih osebnih podatkov. Spremembe gredo pred objavo v produkcijo vedno skozi pregled in testiranje, kar velja tudi za manjše popravke in dopolnitve, ne le za večje nadgradnje sistema.

Po uvedbi lahko prevzamemo nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj sistema. Napake razvrščamo po nujnosti – od izpada, ki zahteva najvišjo prednost, prek motenj v delovanju posamezne funkcije, do manjših napak, ki počakajo na naslednjo redno objavo, in zahtev za spremembe, za katere ocenimo obseg in uskladimo termin. Izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del vsake primopredaje.