Power BI kontrolne table za trgovačke kompanije

Trgovačkoj kompaniji potrebno je nekoliko kontrolnih tabli zasnovanih na usaglašenim definicijama KPI pokazatelja i pouzdanim ERP podacima: prodaji i marži, zalihama, potraživanjima i pošiljkama. Power BI, Tableau i Looker Studio mogu da ih obezbede, pa izbor alata treba da prati vaše izvore podataka, korisnike i način upravljanja podacima, a ne spisak funkcija.

Koje kontrolne table su potrebne trgovačkoj kompaniji?

Trgovačka preduzeća imaju nekoliko ponavljajućih upravljačkih pitanja na koja se odgovara svake nedelje; za svako od njih potrebna je kontrolna tabla, a ne samo izveštaj:

• Prodaja i marža. Šta je prodato, kome i uz koju maržu, po proizvodu, kupcu, tržištu i mesecu. Pregled marže menja ponašanje: trgovačka kompanija može da poveća prihod, a da joj se dobit smanji u istom kvartalu; to pokazuje tek analiza marže.


• Zalihe. Šta se drži na zalihama, gde, koliko dugo i koja roba više ne cirkuliše. Za distributere je ovo kontrolna tabla novčanih sredstava: broj dana zaliha i sporoobrtna roba vezuju obrtni kapital potreban za sledeću porudžbinu.


• Potraživanja. Ko duguje, koliko dugo i koja su dugovanja dospela. Starosne kategorije odmah pokazuju razliku između uobičajenog stanja i problema.


• Pošiljke. Šta je otpremljeno na vreme, šta kasni i šta je zastalo zbog dokumentacije ili carinskog postupka. Za izvoznike je ovo i kontrolna tabla kvaliteta usluge, jer kupac kašnjenje doživljava kao događaj u vezi s pošiljkom, a ne s fakturom.


• Otvorene porudžbine. Šta je ugovoreno, šta je na čekanju, a šta blokirano: operativni pregled koji određuje planove proizvodnje, nabavke i kontejnera za ovu nedelju.

Definicije KPI pokazatelja i izvori podataka

Tabela je operativna osnova projekta: svaki KPI treba da ima jednu definiciju, jednog vlasnika i jedan izvor, a kolona o čestim zamkama ukazuje na uzroke većine neslaganja oko kontrolnih tabli:

Tabela A: KPI | definicija | izvor podataka | česta zamka

Dve prakse održavaju ovu tabelu aktuelnom. Definicije se pišu jednostavnim poslovnim jezikom, a ne formulama: formula pripada modelu podataka, dok rečenica pripada rečniku definicija i upravo oko nje komercijalni tim može da se usaglasi. Uz svaku definiciju navode se datum i vlasnik: definicije se menjaju kako se menja poslovanje, pa kontrolna tabla koja koristi prošlogodišnju definiciju nije samo zastarela već i neprimetno pogrešna. Šire pitanje da li ovaj sloj treba da bude u novom sistemu ili postojećem ERP rešenju obrađeno je na stranici o prilagođenom ili gotovom ERP-u, a stranica o BI i analitici podataka pokriva širu oblast.

Izvori podataka i integracija

Podaci koji predstavljaju stvarno stanje u trgovačkoj kompaniji rasuti su po pet sistema; zadatak BI sloja je da ih poveže bez izmišljanja podataka:

• ERP. Fakture, porudžbine, zalihe, plaćanja i matični podaci. Primarni izvor, obično jedini s integritetom transakcija.


• Tabele. Ciljevi, budžeti, ručna usklađivanja i pomoćni brojevi koji postoje samo u nečijem fajlu. Treba ih shvatiti ozbiljno: budžet koji postoji samo u tabeli i dalje je stvaran budžet. Uvozite ih kao podatke s vlasnikom, a ne kao priloge u imejlu.


• E-trgovina i platforme. Porudžbine i posećenost za kompanije koje prodaju na internetu; podaci po kanalima retko se poklapaju s ERP podacima jedan prema jedan, pa pravila mapiranja (šta se računa kao prodaja i kada) postaju deo rečnika definicija.


• Logistika. Otpremnice, brojevi za praćenje i status prevoznika: izvor za KPI blagovremene otpreme i kontrolnu tablu pošiljki, koji najčešće zahteva ručne ključeve ili podatke partnera.


• Banka. Naplate i plaćanja upareni s otvorenim stavkama: veza između kontrolne table potraživanja i stvarnog stanja gotovine.

Osnove modela podataka

Ne morate postati inženjer podataka da biste ovo dobro postavili, ali tri koncepta određuju da li će projekat opstati i u drugoj godini:

• Činjenice i dimenzije. Činjenice su događaji, kao što su stavke faktura, otpreme i plaćanja, s količinama i vrednostima. Dimenzije su kontekst: proizvod, kupac, tržište, datum i skladište, uz atribute po kojima filtrirate i grupišete podatke. Svaki KPI iz gornje tabele predstavlja agregaciju činjenica po dimenzijama, pa jedan model može da podrži pet kontrolnih tabli.


• Namerno korišćena zvezdasta šema. Činjenice su u centru, a dimenzije oko njih, bez domišljatih prečica tipa „više prema više“. Tako mere ostaju aditivne: zbir prodaje po regionu jednak je zbiru prodaje po mesecu i ukupnoj prodaji. Modeli koji preskaču ovu strukturu rade u demonstraciji, a pucaju pri trećem izveštaju.


• Jedinstven izvor istine. Isti kod proizvoda, kupca i valute u svakoj tabeli činjenica, preuzet iz istih matičnih podataka. Duplirane dimenzije koje se razilaze dovode do toga da dve kontrolne table prikazuju različite ukupne iznose za isti mesec; rasprava koja sledi košta više nego što je model ikada uštedeo.

Power BI, Tableau i Looker Studio: poređenje

Sva tri alata mogu da obezbede navedene kontrolne table; razlike se svode na to koliko odgovaraju vašim potrebama. Poređenje je namerno kvalitativno: uslovi licenciranja i skupovi funkcija na ovom tržištu često se menjaju, zato pre odluke proverite aktuelne informacije dobavljača, a svaki podatak stariji od trenutnog ciklusa izdanja smatrajte smernicom, a ne činjenicom:

Tabela B: kriterijum | Power BI | Tableau | Looker Studio

Ispravan način odlučivanja jeste da u prvoj koloni navedete sopstvena ograničenja, a ne da proizvode stavljate u redove: gde se podaci nalaze (okruženje zasnovano na Microsoft tehnologijama daje prednost Power BI-ju zbog povezivanja i identiteta), ko su svakodnevni korisnici i ko će upravljati modelom za dve godine. Nabavka koja ocenjuje ove redove prema pisanim zahtevima, po metodi iz kontrolne liste za RFP dobavljača, daje obrazložen izbor; demonstracija koja poredi tri početne stranice ne daje ga.

Kontrola pristupa i upravljanje podacima

Kontrolne table za trgovinu prikazuju marže, imena kupaca i ponašanje pri plaćanju, zato je pristup prvo poslovno, a tek onda tehničko pitanje:

• Bezbednost na nivou redova. Regionalni menadžer vidi svoj region, komercijalista svoje kupce, a uprava sve; ograničenja se sprovode u modelu podataka, a ne kroz zasebne kopije kontrolne table. Upravo zasebne kopije ponovo dovode do „dve različite brojke za isti mesec“.


• Uloge umesto izveštaja. Pristup se dodeljuje prema radnim ulogama, odobrava jednom i periodično proverava. Ukidanje pristupa zaposlenom koji odlazi deo je rutinskog upravljanja, a ne projekta.


• Osetljiva polja. Za kolone s maržom i troškovima potrebne su izričite odluke: ko ih uopšte vidi i da li postoji kontrolna tabla bez njih za širu distribuciju.


• Zaštita podataka. Lični podaci kupaca na kontrolnoj tabli podležu istim obavezama koje kompanija već ima: KVKK za poslovanje u Turskoj i GDPR za podatke evropskih kupaca, uključujući pravni osnov, čuvanje izvezenih podataka i evidenciju pristupa. Obaveze su iste kao za sisteme iz kojih podaci potiču; kontrolna tabla nije izuzeta samo zato što podatke čita. Širi ugovorni kontekst, uključujući hosting i pristup dobavljača, obrađen je na stranici o IT autsorsingu.


• Osvežavanje i kontrola izmena. Promena definicije kontrolne table treba da bude vidljiva kroz napomenu o verziji, datum i vlasnika. Tiha promena definicije KPI-ja dovodi do toga da odeljenja prestanu da veruju međusobnim brojkama.

Koraci uvođenja

Redosled koji daje rezultate:

1. Najpre definišite pokazatelje. Rečnik KPI pokazatelja odobravaju rukovodioci komercijale, finansija i logistike. Dovoljne su jedna ili dve stranice; rizik od neuspeha celog projekta zavisi od toga da li je ovaj korak dobro urađen.


2. Jedan izvor podataka i jedna probna kontrolna tabla. Obično su to ERP fakture i kontrolna tabla prodaje i marže: pitanje koje uprava najčešće postavlja i podaci koji su obično najčistiji. Probna verzija istovremeno proverava tok podataka, model i definiciju.


3. Testirajte s korisnicima i stvarnim pitanjima. Dajte probnu verziju troje stvarnih korisnika na dve nedelje i zamolite ih da postavljaju svoja uobičajena nedeljna pitanja; pratite na koja ne mogu da odgovore. Spisak nedostataka iz tog perioda čini važan zaostatak zadataka, a zahtevi za funkcijama koji iz njega proisteknu obično su manji od straha koji izazivaju.


4. Ispravite probleme, pa proširite obuhvat. Probleme s kvalitetom podataka otkrivene u probnoj verziji rešavajte na izvoru, a ne na kontrolnoj tabli. Proračunata ispravka u izveštaju prikriva neuredne ERP podatke koji bi pokvarili sve kasnije kontrolne table.


5. Uvodite kontrolnu tablu po kontrolnu tablu, a ne korisnika po korisnika. Objavite pet dogovorenih kontrolnih tabli jednu po jednu, svaku s vlasnikom i datumom definicije, umesto da odmah otvorite alat svima. Drugi deo usvajanja zavisi od toga šta ljudi zaista pregledaju; pet kontrolnih tabli s jasno određenim vlasnicima bolje je od praznog platna.


6. Uspostavite redovan rad. Pratite osvežavanje, imenujte vlasnika svake kontrolne table i jednom kvartalno pregledajte definicije. BI projekat koji se završava puštanjem u rad postaje hobi za izveštavanje u roku od godinu dana; redovna operativa pretvara ga u upravljačku infrastrukturu.

Često postavljana pitanja

Da li nam je potrebno skladište podataka?

Ne za početak. Direktna veza s ERP sistemom i nekoliko dimenzionih tabela dovoljni su za prvih pet kontrolnih tabli u većini trgovačkih kompanija. Skladište podataka opravdano je kada se umnože izvorni sistemi, kada istorijske podatke treba čuvati duže nego što ih ERP zadržava ili kada performanse oslabe. Pouzdan znak je ponavljanje: ako stalno iznova pravite ista zaobilazna rešenja za izdvajanje podataka, vreme je za razgovor o skladištu podataka i dilemi između razvoja po meri i podešavanja gotovog ERP rešenja.

Koliko često treba osvežavati podatke?

Učestalost prilagodite ciklusu odlučivanja za svaki izvor: prodaja i otvorene porudžbine opravdavaju dnevno ili skoro dnevno osvežavanje; zalihe i potraživanja obično se osvežavaju dnevno; podaci s platformi i iz banke osvežavaju se onoliko često koliko se pouzdano ažuriraju. Češće osvežavanje od stvarnih promena podataka povećava trošak bez novih informacija. Neuspešna osvežavanja treba da budu vidljiva korisnicima, a ne prećutana: kontrolna tabla koja jučerašnje podatke prikazuje kao današnje gora je od one koja jasno kaže da kasni.

Možemo li koristiti izvezene Excel tabele?

Da, one su legitiman izvor podataka. Mnoge prve kontrolne table zasnivaju se na rutinskom planiranom izvozu, a budžeti često postoje samo u tabelama. Važno je da se izvoz tretira kao izvor podataka s vlasnikom, rasporedom i formatom koji se proverava. Problem nastaje kada fajl poslat imejlom stiže neredovno, a zatim neprimetno prestane da stiže i sa sobom povuče KPI.

Ko definiše KPI pokazatelje?

Vlasnici poslovnih rezultata: rukovodioci komercijale za prodaju i maržu, operacije za zalihe i pošiljke, a finansije za potraživanja. BI tim pretvara usaglašene formulacije u mere. Ako KPI definiše samo BI tim, kontrolne table mere nešto što niko nije tražio: tehnički je tačno, ali se u organizaciji ne koristi.

Da li je Power BI besplatan?

Uslovi licenci na ovom tržištu često se menjaju, zato pre planiranja budžeta proverite aktuelne informacije kompanije Microsoft umesto da se oslanjate na podatke koji možda potiču iz ranijeg ciklusa izdanja. Suština odluke ostaje ista: pretplate po korisniku s ulogama, sloj za modelovanje kojim treba upravljati i trošak koji je obično skroman u poređenju s vrednošću odluka koje kontrolne table unapređuju. Ipak, odlučujte na osnovu aktuelnih uslova i zabeležite ih u pisanom obliku.

Kako da zaštitimo podatke kupaca?

U modelu primenite bezbednost na nivou redova kako bi korisnici videli samo ono što njihova uloga dozvoljava; izričito odredite pristup poljima s maržom i troškovima; pristup dodeljujte po ulogama i periodično ga proveravajte; a obaveze prema KVKK/GDPR-u primenite i na sloj kontrolnih tabli, uključujući pravni osnov, čuvanje izvezenih podataka i evidenciju pristupa, isto kao za izvorne sisteme. Pitanja hostinga i pristupa dobavljača obrađena su na stranici o IT autsorsingu i treba ih rešiti ugovorom pre puštanja u rad.

Izvori i standardi

• Skup KPI pokazatelja, mapiranje izvora podataka, koncepti modelovanja (činjenice, dimenzije, zvezdasta šema i jedinstven izvor istine), teme upravljanja (bezbednost na nivou redova, vidljivost osvežavanja i kontrola izmena) i redosled uvođenja prate opštu praksu poslovne inteligencije za trgovačke i logističke kompanije; ova stranica ne navodi statistiku korišćenja, podatke o usvajanju ni merene rezultate.
• Poređenje tri alata namerno je kvalitativno i ne navodi cene licenci, ograničenja ni tvrdnje o funkcijama koje se menjaju između ciklusa izdanja; u svakom redu o licenciranju čitaocu se savetuje da proveri aktuelne informacije dobavljača, a ne tvrdi se postojanje partnerstva s kompanijama Microsoft, Tableau ili Google.
• Procesne napomene prate stranice ovog sajta: BI i analitika podataka, prilagođeni ili gotovi ERP (gde pripada sloj podataka) i IT autsorsing iz Turske (obaveze prema KVKK i GDPR-u, pristup dobavljača i ugovorna pitanja).
• Obaveze u vezi sa zaštitom podataka samo su navedene, ne i tumačene: KVKK za poslovanje u Turskoj i GDPR za podatke evropskih kupaca primenjuju se u skladu sa okolnostima kompanije; odgovarajući režim proverite sa kvalifikovanim savetnikom.

Povezane stranice

BI i analitika podataka · Prilagođeni ili gotovi ERP · Razvoj softvera · Kontrolna lista za RFP dobavljača · Automatizacija pomoću veštačke inteligencije · Zatražite ponudu