Možemo reći da većina BI sistema svakog dana preuzima nove podatke iz ERP-a.

Ali poslovni podaci nisu uvek konačni onog trenutka kada su prvi put obrađeni.

Dokument može danas biti knjižen sa datumom od pre nekoliko dana. Tada ERP menja istorijsko stanje, dok skladište podataka može da nastavi da čuva staru verziju istog perioda.

U ovom tekstu objašnjavamo kako projektovati podatkovni proces koji može bezbedno da ponovo obradi istorijski datum, zameni zastareli rezultat i pritom ne napravi duplikate.

Skladište podataka je centralni analitički sloj u kome se podaci iz ERP-a i drugih sistema pripremaju za izveštavanje i analitiku.

Njegov zadatak nije samo da kopira podatke.

Potrebno je da obezbedi da podaci budu:

– povezani
– istorijski uporedivi
– obrađeni prema istim pravilima
– spremni za BI izveštaje
– ponovljivo izračunati kada se izvor promeni

Tipičan tok izgleda ovako:

ERP → ETL proces → skladište podataka → BI model → dashboard

Problem nastaje kada ERP naknadno promeni podatak koji je ETL već obradio.

Tada analitički sistem mora da zna kako da uskladi istoriju.

Drugim rečima: skladište podataka ne treba samo da pamti prošlost. Mora da zna kako da je bezbedno ispravi.

Uzmimo konkretan primer.

BI proces 1. septembra obrađuje podatke za:

31.08.2026.

Iz ERP-a preuzima sve dokumente koji postoje u tom trenutku i izračunava:

Stanje zaliha artikla A: 120 komada

Rezultat se upisuje u analitički sloj.

Sve je ispravno.

Dva dana kasnije neko u ERP-u knjiži dokument:

Datum dokumenta: 31.08.2026.

Taj dokument menja stanje zaliha za 31. avgust.

ERP sada kaže:

Stanje: 105 komada

Ali BI i dalje može da pokazuje:

Stanje: 120 komada

Imamo:

isti datum → dva različita rezultata

Nijedan sistem nije nužno tehnički pokvaren.

Problem je u podatkovnom procesu.

Ako ETL svakog dana obrađuje samo jučerašnje podatke, više se nikada neće vratiti na 31. avgust.

Stari rezultat ostaje u skladištu podataka.

Ovo može da utiče na:

– zalihe
– prodaju
– nabavne cene
– maržu
– finansijska knjiženja
– istorijske KPI-jeve

Glavni problem zato nije dashboard.

Problem je pretpostavka da se jednom obrađen istorijski period više nikada neće promeniti.

Podatak koji je juče bio tačan ne mora danas da predstavlja tačno istorijsko stanje.

Razlog je kombinacija načina rada poslovnih sistema i dizajna ETL procesa.

U praksi se događaju:

– naknadna knjiženja
– storniranja dokumenata
– korekcije količina
– promene nabavnih cena
– zakašneli ulazni dokumenti
– ispravke pogrešnih knjiženja

ERP zato može danas promeniti poslovno stanje koje pripada prethodnoj nedelji.

Sa druge strane, jednostavan ETL često radi po pravilu:

Danas je 3. septembar → učitaj 2. septembar.

To je brzo.

Ali nije dovoljno.

Ako je 2. septembra promenjen dokument iz 31. avgusta, sama obrada 2. septembra možda neće ponovo izračunati stanje za 31. avgust.

Zato je važno čitaocu i korisniku sistema jasno pokazati razliku između dva datuma:

Datum knjiženja: kada je promena evidentirana u sistemu
Poslovni datum: na koji period promena utiče

Ta razlika deluje mala.

Za analitički sistem je ključna.

Rešenje nije da se svake noći ponovo obrađuje kompletna istorija.

Kod velikih baza to bi bilo sporo i nepotrebno.

Potrebno je projektovati kontrolisanu ponovnu obradu.

To podrazumeva:

1. Prepoznati podatke koji mogu naknadno da se promene

Nisu svi podaci jednako promenljivi.

Na primer, poslednjih 30 ili 60 dana može predstavljati period u kome su naknadna knjiženja očekivana.

2. Uvesti rolling refresh period

Pored novih podataka, sistem periodično ponovo obrađuje i deo prethodnog perioda.

Na primer:

svake noći → novi datum + prethodnih 60 dana

Tako se naknadne izmene automatski preuzimaju.

3. Omogućiti obradu jednog konkretnog datuma

Ako se utvrdi da postoji problem za 31. avgust, treba moći pokrenuti samo:

Reprocess 2026-08-31

bez brisanja ostatka istorije.

4. Napraviti proces koji može bezbedno da se ponovi

Ako isti datum obradimo dva puta, ne smeju nastati dva ista rezultata.

Postojeći rezultat treba kontrolisano zameniti novim.

5. Validirati ponovnu obradu

Nije dovoljno da proces završi bez greške.

Potrebno je proveriti:

– koliko zapisa je obrađeno
– koji je maksimalni datum podataka
– da li su svi koraci završeni
– da li rezultat odgovara izvornom sistemu

6. Voditi evidenciju izvršavanja

Za svaku obradu treba znati:

– koji period je obrađen
– kada je proces pokrenut
– da li je uspeo
– koliko je zapisa promenjeno
– da li je obrada bila redovna ili korektivna

Na ovaj način skladište podataka ostaje usklađeno sa ERP-om i kada se izvorna istorija promeni.

Pretpostavimo da BI sistem čuva dnevno stanje zaliha.

Originalna obrada daje:

31.08. → 120 komada

Dva dana kasnije ERP dobija naknadni dokument koji utiče na isti datum.

Nova očekivana vrednost je:

31.08. → 105 komada

Umesto kompletne ponovne izgradnje skladišta podataka, pokreće se obrada samo potrebnog perioda.

Proces radi sledeće:

1. preuzima trenutno stanje izvora za 31.08.
2. ponovo primenjuje poslovna pravila
3. uklanja ili ažurira prethodni analitički rezultat
4. upisuje novu vrednost
5. proverava kompletnost obrade
6. evidentira uspešno izvršavanje

Rezultat nije:

120 + 105 = 225

već:

stara verzija: 120 → nova verzija: 105

Istovremeno, redovna noćna obrada može ponovo osvežavati poslednjih nekoliko nedelja kako bi slične promene bile uhvaćene automatski.

Najveća prednost nije samo tačniji dashboard.

Prednost je što je korekcija ponovljiva, ograničena na potreban period i tehnički kontrolisana.

Najčešće greške kod ovakvih podatkovnih procesa su:

– učitavanje samo novih datuma
– pretpostavka da je istorijski podatak zauvek konačan
– ručno brisanje tabela pre svake korekcije
– ponovno učitavanje koje proizvodi duplikate
– obrada kompletne istorije zbog promene jednog dana
– korekcija bez validacije rezultata
– nepostojanje evidencije šta je ponovo obrađeno

Posebno je opasan pristup:

„Obriši podatke i pokreni sve ponovo.“

Može rešiti jedan incident, ali uvodi novi rizik.

Kod produkcionog sistema potrebno je tačno znati:

koji period popravljamo → zašto → kojim procesom → sa kojim rezultatom

To je mnogo bezbednije od ručnih intervencija nad celom istorijom.

Pouzdano skladište podataka nije samo mesto na kome se čuva kopija ERP podataka.

To je sistem koji mora da:

– prepozna naknadne izmene
– ponovo obradi istorijski period
– zameni prethodni rezultat bez dupliranja
– proveri kompletnost nove obrade
– sačuva trag izvršavanja
– održava BI i izvorni sistem usklađenim

Naknadno knjiženje nije neobičan incident koji treba ignorisati.

Ono je normalna karakteristika mnogih poslovnih procesa i zato mora biti deo dizajna podatkovnog sistema.

Ako ERP može da promeni istoriju, analitički sistem mora da zna kako da je bezbedno uskladi.

---

Ako se ERP i BI povremeno razlikuju za istorijske periode, problem ne mora biti u samom izveštaju.

Možemo tehnički pregledati ETL tok, način obrade istorijskih podataka, pravila ponovnog izvršavanja i validacije kako bi korekcije iz izvornog sistema bezbedno stigle do analitičkog sloja.

Prvi razgovor je tehnički i bez obaveza.