ERP može da bude potpuno tačan, a BI izveštaj potpuno pogrešan.

Dovoljna je jedna pogrešna veza između tabela.

U praksi to znači da promet može biti dupliran, trošak višestruko uvećan ili marža pogrešno izračunata, iako nijedan izvorni dokument nije netačan.

U ovom tekstu objašnjavamo kako BI sistemi koriste data model da bi sprečili da tačni podaci proizvedu pogrešne poslovne rezultate.

BI sistemi povezuju podatke iz ERP-a i drugih izvora, obrađuju ih prema definisanim pravilima i pripremaju za izveštavanje i analitiku.

Dashboard je samo poslednji sloj.

Pre njega postoje:

• izvorni podaci
• tabele i transformacije
• veze između tabela
• pravila računanja
• KPI-jevi
• kontrole kvaliteta podataka

Jedan od najvažnijih delova tog lanca je data model.

Data model određuje šta svaki red predstavlja i kako različiti skupovi podataka mogu da se povežu.

Na primer:

• jedan red može predstavljati fakturu
• jedan red može predstavljati stavku fakture
• jedan red može predstavljati artikal
• jedan red može predstavljati prodavnicu

Drugim rečima: BI sistem mora da zna šta podatak predstavlja pre nego što počne da ga sabira.

Uzmimo jednostavan primer.

Postoji faktura:

Faktura 1001 = 30.000 RSD

Na fakturi se nalaze tri artikla.

Tabela faktura izgleda ovako:

1 red = 1 faktura

Faktura	Ukupna vrednost
1001	30.000 RSD

Druga tabela sadrži stavke:

Faktura	Artikal
1001	Artikal A
1001	Artikal B
1001	Artikal C

Ovde imamo tri reda jer faktura ima tri stavke.

Ako ukupnu vrednost fakture od 30.000 RSD povežemo direktno sa svakom stavkom, model može da proizvede:

30.000 + 30.000 + 30.000 = 90.000 RSD

ERP i dalje sadrži tačnih 30.000 RSD.

Sabiranje takođe radi ispravno.

Dashboard se otvara bez greške.

Ali rezultat je tri puta veći od stvarnog prometa.

Glavni problem nije u Power BI-ju, ERP-u ili formuli.

Problem je u tome što su podaci povezani na različitim nivoima detalja.

Tačan podatak + pogrešna veza = pogrešan poslovni rezultat.

Razlog obično nije jedna velika greška.

Češće je u pitanju nekoliko malih odluka u modelu:

• nije definisano šta predstavlja jedan red
• podatak sa nivoa dokumenta koristi se na nivou stavke
• tabele se povezuju preko pogrešnog ključa
• veza između tabela ima pogrešan smer ili kardinalnost
• ista poslovna vrednost postoji na više mesta
• rezultat nije proveravan prema izvornom sistemu

Tehnički termin za pitanje „šta predstavlja jedan red“ je granularnost.

Ali njegovo praktično značenje je jednostavno.

Ako jedan red u prvoj tabeli predstavlja celu fakturu, a jedan red u drugoj predstavlja samo jedan artikal na toj fakturi, te dve vrednosti ne mogu automatski da se tretiraju kao da se nalaze na istom nivou.

To je posebno opasno zato što rezultat često izgleda uverljivo.

Grafikon je uredan.

Broj ima pravi format.

Filteri rade.

Korisnik nema vizuelni signal da nešto nije u redu.

Zato informacije u BI sistemu treba da budu jednostavne za proveru. Umesto komplikovane tehničke terminologije, korisniku treba omogućiti da lako razume:

Promet po dokumentima: 30.000 RSD
Broj faktura: 1
Broj stavki: 3

Ako isti model zatim pokaže promet od 90.000 RSD, problem postaje odmah vidljiv.

Jasnoća nije samo pitanje dizajna.

Ona olakšava otkrivanje grešaka.

Rešenje nije dodavanje još jednog grafikona.

Potrebno je pravilno projektovati i testirati data model.

To podrazumeva:

1. Definisati šta predstavlja jedan red

Za svaku tabelu mora postojati jasan odgovor.

Na primer:

– FactInvoice → jedna faktura
– FactInvoiceLine → jedna stavka fakture
– DimArticle → jedan artikal

Ako ovo nije jasno, model ne treba dalje razvijati.

2. Odrediti nivo svake poslovne mere

Ukupna vrednost fakture pripada dokumentu.

Količina artikla pripada stavci.

Cena artikla takođe pripada stavci.

Ne treba istu vrednost automatski prenositi sa jednog nivoa na drugi.

3. Koristiti jasne ključeve između tabela

Veza treba da se zasniva na stabilnom identifikatoru, na primer InvoiceId, ArticleId ili StoreId.

Naziv artikla ili opis dokumenta nisu pouzdani ključevi.

4. Definisati očekivanu vezu

Ako jedna faktura ima više stavki, odnos je:

1 faktura → više stavki

Model mora to da predstavlja upravo tako.

5. Meru računati na mestu gde podatak nastaje

Ako želimo promet po artiklu, potrebno je koristiti vrednost prodajne stavke.

Ne ukupnu vrednost fakture kopiranu na svaku stavku.

6. Uvesti kontrolne testove

Pre objavljivanja dashboarda treba proveriti:

– ukupan promet u ERP-u
– ukupan promet u BI modelu
– broj dokumenata
– broj stavki
– nekoliko konkretnih faktura

Razlika mora imati objašnjenje.

7. Automatizovati kontrole

Kod produkcionih BI sistema validacija ne treba da zavisi samo od ručnog pregleda.

Mogu se implementirati kontrole koje prijavljuju neočekivana odstupanja između izvornog sistema i analitičkog sloja.

Na ovaj način BI sistemi ne oslanjaju pouzdanost samo na to da SQL upit ili dashboard tehnički rade.

Pouzdanost postaje deo arhitekture sistema.

Kod izrade analitičkog sistema praktična provera može da počne sa samo jednom fakturom.

Uzmemo dokument za koji unapred znamo:

– broj fakture
– ukupan iznos
– broj stavki
– količine
– pojedinačne vrednosti stavki

Zatim pratimo isti dokument kroz ceo tok:

ERP → učitavanje → data model → BI mera → dashboard

Ako ERP pokazuje:

30.000 RSD

a model nakon povezivanja tabela pokazuje:

90.000 RSD

ne popravljamo grafikon.

Vraćamo se na model.

Proveravamo:

– koji je nivo tabele
– kojim ključem je povezana
– koliko redova nastaje nakon veze
– koja vrednost se sabira

Tek kada pojedinačni dokument daje očekivani rezultat, proverava se ceo skup podataka.

Ovakav pristup je jednostavan, ali veoma efikasan.

Umesto pokušaja da se greška pronađe među milionima redova, počinje se od jednog poznatog poslovnog događaja.

Najčešće greške u BI modelima su:

– povezivanje tabela bez definisane granularnosti
– korišćenje ukupne vrednosti dokumenta na nivou stavke
– many-to-many veze bez jasnog razloga
– sabiranje vrednosti koje nisu aditivne
– korišćenje opisnih polja umesto stabilnih ključeva
– testiranje samo ukupnog dashboarda
– pretpostavka da tačan ERP automatski znači tačan BI rezultat

Posebno je opasna poslednja pretpostavka.

BI može da koristi potpuno tačne izvorne podatke i da ipak proizvede netačan rezultat.

Greška nastaje između izvora i prikaza.

Zato tehničko testiranje ne treba da proverava samo:

„Da li se dashboard otvorio?“

Već i:

„Da li model predstavlja poslovni događaj onako kako se stvarno dogodio?“

ouzdani BI sistemi ne počinju od grafikona.

Počinju od pravilno strukturisanih podataka.

Dobar data model omogućava firmi da:

– povezuje dokumente i stavke bez dupliranja
– koristi iste poslovne definicije kroz sve izveštaje
– proveri poreklo svake važne brojke
– spreči pogrešno sabiranje podataka
– donosi odluke na osnovu rezultata kojima može da veruje

Data model zato nije samo dijagram tabela namenjen developerima.

On predstavlja kontrolni sloj između izvornog podatka i poslovne odluke.

Tačni podaci nisu dovoljni. I način na koji su povezani mora biti tačan.

---

Ako BI izveštaji daju različite rezultate od ERP-a ili nije jasno kako određena brojka nastaje, možemo tehnički analizirati postojeći data model, veze između tabela i KPI logiku.

Cilj je da pronađemo gde nastaje razlika i da brojka može da se prati od dashboarda nazad do izvornog podatka.

Prvi razgovor je tehnički i bez obaveza.