Zna li AI što znače podaci u vašem ERP-u? Zašto bez semantičkog opisa podataka nema pouzdane poslovne analitike

AI agent može pročitati tisuće tablica u vašem ERP-u, a ipak ne znati odgovoriti na pitanje koje je upravi najvažnije: koliko nam je pala marža i na kojim artiklima?

ERP sustavi godinama prikupljaju podatke o prodaji, nabavi, zalihama, troškovima, kupcima i financijskim rezultatima. Ti podaci predstavljaju jednu od najvrjednijih imovina poduzeća. Međutim, njihova dostupnost ne znači automatski da ih umjetna inteligencija može ispravno protumačiti.

Kada poduzeće poveže AI agenta s ERP bazom podataka, često se pretpostavlja da će agent moći razumjeti poslovanje na isti način kao iskusan financijski analitičar ili voditelj prodaje.

U praksi to nije tako jednostavno.

AI može prepoznati nazive tablica, pročitati strukturu baze i izvršavati upite. No, ako ne zna što pojedino polje predstavlja, kako se njegova vrijednost izračunava, kojem poslovnom procesu pripada i kako se povezuje s drugim podacima, rezultat može biti nepotpun, pogrešno protumačen ili poslovno beskoristan.

Upravo zato semantički opis podataka postaje jedan od ključnih preduvjeta za uspješnu primjenu AI agenata u poslovnoj analitici.

1. ERP baza zna gdje je podatak, ali ne nužno i što on znači

Zamislimo tipičnu ERP bazu podataka koja sadrži tablice i polja poput:

• OINV, INV1, OITM i OCRD
• ItemCode, Quantity, Price, LineTotal
• GrossProfit, DiscPrcnt, DocDate, DocTotal

Iskusnom ERP konzultantu ti nazivi mogu biti poznati. Međutim, ni poznavanje naziva nije dovoljno za svaku poslovnu analizu.

AI agent mora znati, primjerice:

• Predstavlja li Price nabavnu ili prodajnu cijenu?
• Je li LineTotal iznos prije ili nakon popusta?
• Je li GrossProfit izračunat prema trenutačnoj ili povijesnoj nabavnoj cijeni?
• Označava li DocDate datum izdavanja dokumenta, datum knjiženja ili datum drugog poslovnog događaja?
• Predstavlja li negativna količina povrat robe, storno ili neki drugi događaj?
• Sadrži li tablica samo knjižene račune ili i dokumente koji još nisu konačno potvrđeni?

Bez tih informacija AI može izraditi tehnički ispravan SQL upit koji daje poslovno pogrešan odgovor.

Drugim riječima, nije dovoljno da AI zna pročitati podatak. Mora razumjeti njegovo značenje.

2. Što je semantički opis ERP polja?

Semantički opis nije samo dodatni tekst uz naziv stupca. To je strukturirano objašnjenje poslovnog značenja podatka i načina na koji ga treba koristiti.

Za kvalitetan opis pojedinog polja potrebno je, ovisno o njegovoj ulozi, definirati:

• Poslovno značenje: što polje predstavlja u stvarnom poslovanju.
• Mjernu jedinicu i tip vrijednosti: iznos u eurima, količinu, postotak, datum ili identifikator.
• Pravila izračuna: kako je vrijednost nastala i što uključuje ili isključuje.
• Poslovni proces: sudjeluje li u nabavi, prodaji, skladištu, računovodstvu ili financijskom izvještavanju.
• Povezanost s drugim poljima: s kojim tablicama, dokumentima i šifrarnicima se povezuje.
• Vremensku dimenziju: na koji datum se podatak odnosi i kako se uspoređuje s prethodnim razdobljima.
• Ograničenja i iznimke: kako tretirati povrate, storna, odobrenja, neknjižene dokumente i druge posebne slučajeve.

Nije svakom polju potreban jednako opsežan opis. Identifikator artikla zahtijeva drugačiji opis od izračunate bruto marže. Ključno je da su svi podaci važni za poslovne odluke dovoljno jasno definirani.

Tako nastaje poslovni rječnik podataka, odnosno semantički sloj koji povezuje tehničku strukturu ERP-a s jezikom kojim uprava i zaposlenici opisuju poslovanje.

3. Primjer: AI treba odgovoriti na pitanje „Koliko nam je pala marža?”

Pretpostavimo da direktor prodaje pita AI agenta:

„Usporedi maržu za prvih devet mjeseci 2026. s istim razdobljem 2025. i pokaži na kojim je artiklima najviše pala.”

Na prvi pogled, riječ je o jednostavnom analitičkom zadatku. U stvarnosti, agent mora donijeti niz ispravnih interpretacijskih odluka.

Prvo mora utvrditi što u poduzeću znači marža. Zatim mora pronaći odgovarajuće prodajne transakcije, povezati ih s artiklima, pravilno obraditi popuste i povrate, odabrati usporediva razdoblja te primijeniti odgovarajuću definiciju troška.

Ako različiti dijelovi organizacije pod maržom podrazumijevaju različite pokazatelje, agent mora znati koji je pokazatelj službeni za konkretno pitanje.

Primjerice, bruto marža na prodaji može se računati kao razlika između neto prihoda od prodaje i pripadajućeg troška prodane robe. Međutim, točan izračun ovisi o pravilima poduzeća i načinu na koji ERP evidentira troškove, rabate, povrate i naknadna odobrenja.

Za usporedbu promjene marže potrebno je razlikovati i dvije stvari:

• Promjenu marže u postotnim bodovima: primjerice, pad s 30 % na 26 % iznosi 4 postotna boda.
• Relativni pad marže: isti pad iznosi približno 13,3 % u odnosu na početnu maržu.

To nisu isti pokazatelji i ne smiju se međusobno zamjenjivati.

Kvalitetan AI agent mora znati koja se definicija koristi, kako se izračunava i kako objasniti rezultat korisniku.

4. Primjer semantičkog opisa podataka

Pogledajmo kako bi se tehnički podatak mogao pretvoriti u informaciju koju AI može poslovno koristiti.

Ovo je samo početak. AI mora razumjeti i odnose između polja i tablica. Primjerice, kako se stavka računa povezuje s artiklom, kako se dokument povezuje s kupcem i kako se artikl povezuje s njegovom kategorijom.

Također, stvarna struktura i značenje polja ovise o ERP sustavu, verziji, konfiguraciji i prilagodbama koje je poduzeće implementiralo. Naziv stupca sam po sebi nije dovoljan dokaz njegova poslovnog značenja.

5. Nije dovoljno opisati polja — treba opisati i poslovna pravila

Čak i kada su sva polja jasno opisana, AI može pogriješiti ako ne poznaje poslovna pravila.

Primjerice, zamislimo da poduzeće prodaje isti artikl po različitim nabavnim cijenama tijekom godine.

Ako se marža za 2026. računa prema jednoj vrsti troška, a za 2025. prema drugoj, usporedba može pokazati promjenu koja nije posljedica stvarne promjene prodajne profitabilnosti, nego razlike u metodologiji izračuna.

Sličan problem nastaje kada se ne definiraju:

• tretman povrata i odobrenja;
• razlika između prihoda s PDV-om i prihoda bez PDV-a;
• korištenje standardnog, prosječnog ili stvarnog troška;
• uključivanje samo knjiženih i relevantnih dokumenata;
• usporedba jednakih vremenskih razdoblja;
• način agregiranja marže na razini artikla, brenda ili kategorije.

Posebno je važno razumjeti da se marža u postotku ne dobiva nužno zbrajanjem ili jednostavnim prosjekom marži pojedinih stavki. Za ukupnu maržu u pravilu se koristi odnos ukupne bruto dobiti i ukupnog neto prihoda, prema odobrenoj poslovnoj definiciji.

Zato AI-ju nije dovoljno objasniti što je GrossProfit. Potrebno mu je definirati i što organizacija smatra bruto dobiti, kako se ona računa te koja pravila vrijede za agregaciju i usporedbu.

6. Od ERP polja do poslovnog odgovora: kako radi pouzdan AI agent

Pouzdano rješenje povezuje nekoliko slojeva.

Prvi sloj — izvorni podaci. ERP sadrži transakcije, artikle, kupce, nabavne cijene, prodajne dokumente i druge poslovne događaje.

Drugi sloj — poslovno značenje. Opisi tablica i polja, poslovni rječnik, odnosi između entiteta i definicije ključnih pokazatelja objašnjavaju što podaci predstavljaju.

Treći sloj — semantički model. Definiraju se pouzdane mjere, veze između tablica, vremenske dimenzije, hijerarhije i pravila agregiranja. U Microsoftovu okruženju važnu ulogu može imati Power BI semantički model.

Četvrti sloj — AI agent. Agent tumači pitanje, odabire relevantne podatke, primjenjuje odobrene definicije i izrađuje upit.

Peti sloj — provjera i objašnjenje. Rezultat se uspoređuje s provjerenim poslovnim pravilima i poznatim izvještajima, a korisnik dobiva objašnjenje rezultata i korištene metodologije.

Microsoftova dokumentacija za Power BI naglašava upravo važnost jasno definiranih mjera, odnosa, poslovnih opisa i pripreme semantičkog modela za Copilot i AI agente. Dobro pripremljen model povećava mogućnost dobivanja dosljednih i točnih odgovora, dok pogrešni odnosi i nejasne definicije mogu proizvesti pogrešne rezultate čak i kada su dodatne AI upute dobro napisane.

7. Kako bi trebao izgledati odgovor AI agenta upravi?

Kada su podaci i poslovna pravila pravilno opisani, pitanje direktora ne mora završiti na tablici s nekoliko desetaka redaka.

AI agent može pripremiti odgovor koji sadrži:

1. Ukupnu maržu u usporedivim razdobljima.
2. Promjenu marže u postotnim bodovima i relativno.
3. Artikle s najvećim padom marže, prema unaprijed definiranom kriteriju.
4. Usporedbu prodajnih cijena i troškova gdje su podaci dostupni.
5. Učinak promjene prodajnog miksa, količina i cijena, ako model sadrži potrebne podatke.
6. Rezultate po brendu, proizvođaču, kategoriji, kupcu ili prodajnom kanalu.
7. Objašnjenje metodologije, razdoblja i isključenja korištenih u analizi.

Važno je pritom razlikovati činjenicu od pretpostavke. Agent može utvrditi da je marža na određenom artiklu pala. Međutim, da bi zaključio zašto je pala, mora imati podatke koji omogućuju analizu uzroka.

Ako poduzeće nema povijesne nabavne cijene, podatke o rabatima ili dovoljno detaljne transakcije, agent to mora jasno navesti umjesto da izmisli objašnjenje.

Takav pristup pretvara AI iz alata koji samo prikazuje podatke u poslovnog analitičkog pomoćnika koji upravi omogućuje brže donošenje informiranih odluka.

8. Odakle početi? Ne treba opisivati cijeli ERP odjednom

Veliki ERP sustavi mogu sadržavati tisuće tablica i desetke tisuća polja. Pokušaj da se sve dokumentira odjednom često je skup, dugotrajan i teško održiv.

Bolji pristup počinje od konkretnih poslovnih pitanja.

Ako je cilj razumjeti profitabilnost prodaje, prvo treba obraditi podatke koji sudjeluju u izračunu prihoda, troškova, bruto dobiti i marže. Nakon toga treba dokumentirati artikle, kategorije, kupce, datume, status dokumenta i pravila za povrate i odobrenja.

Praktičan redoslijed implementacije može izgledati ovako:

1. Odabrati poslovni scenarij. Primjerice, analiza pada marže po artiklu.
2. Mapirati potrebne podatke. Utvrditi tablice, polja, veze i izvore troškova.
3. Definirati poslovni rječnik. Opisati značenje, jedinice, pravila i iznimke.
4. Izraditi pouzdane mjere. Standardizirati izračune prihoda, bruto dobiti i marže.
5. Povezati AI agenta. Omogućiti mu pristup odgovarajućem semantičkom modelu i definirati granice njegove primjene.
6. Testirati odgovore. Usporediti rezultate AI agenta s provjerenim izvještajima i testnim poslovnim scenarijima.
7. Održavati opise i pravila. Svaka promjena ERP-a, poslovnog procesa ili metodologije mora se odraziti u dokumentaciji i modelu.

Na taj način semantički sloj postaje trajna poslovna imovina, a ne jednokratni projekt dokumentiranja baze podataka.

Zaključak: AI ne treba samo pristup podacima — treba razumjeti poslovanje

Uvođenje AI agenata u poslovnu analitiku nije samo tehničko povezivanje jezičnog modela s ERP bazom podataka.

Stvarna vrijednost nastaje kada AI može povezati tehničke podatke s poslovnim značenjem, razumjeti pravila izračuna i koristiti provjerene definicije ključnih pokazatelja.

Bez toga, pitanje „Koliko nam je pala marža i na kojim artiklima?” može rezultirati uvjerljivim, ali pogrešnim odgovorom.

Uz kvalitetan semantički opis podataka, pouzdan model i provjerene poslovne mjere, isto pitanje može postati početak konkretne analize: gdje gubimo profitabilnost, koji artikli zahtijevaju pažnju i koje odluke trebamo razmotriti.

Uspješna primjena AI-ja u poslovanju zato ne počinje samo od izbora modela umjetne inteligencije. Počinje od razumijevanja vlastitih podataka.