Kennisbank

Kada se registar za više poslovnih jedinica smatra gotovim

Registar za jednu poslovnu jedinicu u jednom trenutku dovedete do kraja. Datapointovi su u njemu, svaki s izvorom i vlasnikom, a definicije su provjerene. Kod više poslovnih jedinica pitanje se mijenja. Više nije riječ o tome je li jedan popis potpun, nego o tome zbrajaju li se popisi međusobno u jednu sliku organizacije.

To je druga vrsta posla od dodavanja još redaka. Zamka je misliti da je registar gotov onog trenutka kad je svaka jedinica popunila svoju tablicu. Četiri popunjene tablice s četiri različite definicije istog datapointa ne daju registar, nego četiri registra koji se slučajno nalaze jedan pored drugog.

Što po poslovnoj jedinici mora stajati u registru

Po jedinici se ponavlja isti temeljni posao: koji su datapointovi potrebni, odakle dolaze i tko je za njih odgovoran. To počinje s pitanjem koje datapointove zapravo trebate, jer jedinica koja registrira previše datapointova prije svega prikuplja teret održavanja bez da izvještavanje postaje bolje.

Za svaki datapoint koji preostane, mora se postaviti isto pitanje: postoji li to već u nekom sustavu, ili se to još mora pribaviti upitom. Stranica o tome gdje datapoint već postoji opisuje tu potragu. Kod više poslovnih jedinica odgovor je često različit: jedinica A već ima potrošnju energije u sustavu za upravljanje objektima, jedinica B to još vodi u proračunskoj tablici koju upravlja jedan kontroler. Ta razlika mora biti vidljiva u registru, a ne skrivena iza jednoobraznog stupca koji svugdje kaže 'prisutno'.

Gdje najčešće ide krivo: isti naziv, druga definicija

Najveći rizik kod više jedinica nije da datapointovi nedostaju, nego da postoje pod istim nazivom dok mjere nešto drugo. 'Potrošnja vode' može kod jedne jedinice obuhvaćati samo glavni ured, a kod druge i proizvodnu halu. 'Broj FTE-a' može biti brojan s ili bez ustupljenih radnika. Sve dok se ta razlika ne imenuje, nitko ne zbraja problem sve do trenutka kad se brojke moraju objediniti za konsolidirano izvješće.

Registar koji to rješava utvrđuje po datapointu definiciju na razini organizacije, a zatim prikazuje po jedinici je li ta definicija tako i primijenjena. Gdje to nije slučaj, to stoji u registru kao otvorena stavka, a ne kao tiha pretpostavka. Struktura te izgradnje opisana je u kako izraditi registar podataka, a taj redoslijed se ne mijenja kad postoji više jedinica: prvo se datapointovi i njihove definicije utvrđuju na razini organizacije, zatim se po jedinici popunjava što već postoji i što nedostaje.

Nedostajući izvori postoje svugdje, ne samo kod najmanje jedinice

Pretpostavka da samo manje ili manje razvijene jedinice imaju rupe u svojim izvorima rijetko je točna. Velika jedinica s razvijenim ERP sustavom može za određene podatke o okolišu isto tako ovisiti o ručnom brojanju kao mala poslovnica. Udio datapointova bez čvrstog izvora ovisi o temi i o tome koliko dugo jedinica već radi s tim brojkama, a ne o veličini jedinice. Koliko vaših datapointova ima izvor stoga je pitanje na koje se mora odgovoriti po jedinici zasebno, pogledajte koliko vaših datapointova ima izvor. Samo kad je to po jedinici jasno, može se nešto reći o cjelini.

Datapointovi bez izvora ne ispadaju iz registra zato što su neugodni. Dobivaju status i sljedeći korak, opisano pod što učiniti s datapointom bez izvora. Kod više poslovnih jedinica pametno je usporediti taj status između jedinica: ako tri od četiri jedinice imaju izvor za neki datapoint a četvrta nema, rješenje se najčešće nalazi nadohvat ruke kod te tri jedinice, umjesto da četvrta jedinica ponovno izmišlja kotač.

Kada je registar točan

Registar za više poslovnih jedinica nije točan zato što izgleda potpuno, nego zato što su tri stvari istovremeno istinite. Prvo: svaki datapoint ima na razini organizacije jednu definiciju, a ta je definicija kod svake jedinice jednako primijenjena ili je razlika izričito zabilježena. Drugo: za svaki datapoint je po jedinici jasno postoji li izvor, a ako ne postoji, koji je status. Treće: vlasništvo je dodijeljeno na razini gdje se znanje zapravo i nalazi, a ne automatski kod najvišeg rukovoditelja jedinice.

Koliko taj posao traje ovisi o broju jedinica, broju tema i stanju temeljnih sustava; procjena toga opisana je u koliko dugo traje da se tema dovede u red. To nije fiksno trajanje, nego zbroj posla koji po jedinici i po datapointu još treba obaviti.

Spajanje ovih registara, izvođenje definicija i usporedba izvora po jedinici velikim je dijelom posao koji se ponavlja: ista pitanja, iznova primijenjena na drugi odjel ili drugi datapoint. Koji se dio toga može prepustiti AI-u a koji dio ostaje ljudski posao, upravo je za to izrađen radni sken tvrtke FTE TO AI: on po zadatku izračunava koliko prostora postoji da se ovakav posao oko registra ubrza, bez da rezultat ovisi o pretpostavkama koje nitko nije provjerio.