Polje nije razumljivo zato što postoji u ERP-u, tablici ili obrascu. Njegovo značenje mora imati zapisanu definiciju, vlasnika, izvor i pravilo ažuriranja. U maloj tvrtki katalog poslovnih podataka ne mora biti velik dokument. Treba početi s poljima koja utječu na odluke ili stalno izazivaju pitanja: koji je kupac aktivan, kada je narudžba potvrđena, što je raspoloživo za isporuku i koji je status računa.
Bez tog dogovora dva korisnika mogu gledati isto polje i donositi različite zaključke. Problem tada nije samo kvaliteta podatka. Problem je nejasna odgovornost za njegovo poslovno značenje.
Katalog poslovnih podataka je radni rječnik važnih poslovnih pojmova i polja. Njegova je svrha uskladiti ljude, proces i sustav oko istog pitanja: što podatak predstavlja, odakle dolazi, tko ga održava i kada se smije koristiti za odluku.
Za malu tvrtku nije praktično dokumentirati svako tehničko polje. Početni katalog može obuhvatiti deset do dvadeset polja s najvećim operativnim učinkom. Dobar kriterij odabira je jednostavan: uvrstiti polje ako utječe na novac, rok, obvezu prema kupcu, zalihu, izvještaj ili redovitu raspravu između funkcija.
Tipični početni kandidati su:
Nije potrebno krenuti od strukture baze. Krenite od odluka. Ako voditelj proizvodnje planira rad prema raspoloživosti materijala, definicija raspoložive količine ima prednost pred rijetko korištenim administrativnim poljem. Ako računovodstvo i prodaja različito čitaju status računa, upravo taj status zaslužuje mjesto u prvom izdanju kataloga.
Za svako polje katalog treba dati kratak odgovor na najmanje četiri pitanja.
Definicija treba opisati poslovni smisao, a ne samo naziv ekrana ili stupca. Primjerice, „potvrđeni datum isporuke” može značiti datum koji je tvrtka obvezna isporučiti kupcu nakon potvrde narudžbe. Ako organizacija koristi drugačije značenje, ono mora stajati u definiciji.
Uz definiciju zabilježite i što polje nije. To je često najbrži način za uklanjanje nesporazuma. „Datum narudžbe” nije nužno datum kada je narudžba postala obvezujuća. Može biti datum unosa, primitka ili dokumenta. Katalog mora imenovati točno odabrano značenje.
Izvor je sustav, transakcija, obrazac ili odobreni dokument iz kojeg podatak nastaje ili se službeno održava. U ERP procesu korisno je navesti i službenu transakciju, ne samo naziv modula.
Primjer zapisa može glasiti: izvor je potvrđena prodajna narudžba u ERP-u; polje se unosi u prodajnoj transakciji; izvještaj samo prikazuje vrijednost. Takav zapis sprječava ručno ispravljanje iznosa u lokalnoj tablici bez promjene izvornog zapisa.
Ako podatak dolazi iz integracije, navedite izvorni sustav, smjer prijenosa i trenutak kada ERP preuzima odgovornost. Integracija nije sama po sebi definicija poslovnog izvora. Potrebno je utvrditi koji zapis ima prednost kada se vrijednosti razlikuju.
Vlasnik definicije podatka odgovara za poslovno značenje, dopuštene uporabe i pravila promjene. Ta uloga ne mora unositi svaki zapis. Prodaja može unositi rok isporuke, dok voditelj prodaje ili imenovana procesna uloga održava definiciju statusa narudžbe i pravila njegova prijelaza.
Odvojite najmanje četiri vrste odgovornosti:
Jedna osoba može imati više uloga, osobito u maloj tvrtki. Važno je zapisati ih, ne stvarati složen organizacijski model.
Pravilo ažuriranja treba obuhvatiti okidač, ovlaštenu ulogu, dopuštenu promjenu i trag odluke. Primjer: prodajni referent unosi potvrđeni datum isporuke pri potvrdi narudžbe; nakon slanja potvrde kupcu promjenu odobrava odgovorna prodajna uloga; razlog promjene ostaje u zapisu ili povezanom dokumentu.
Pravilo ne mora automatski značiti tehničku zabranu. Može biti procesna kontrola. Međutim, kada sustav podržava ograničenja, korisno je razlikovati što provjerava baza ili aplikacija, a što ostaje poslovno pravilo.
Sljedeći format dovoljan je za prvo izdanje kataloga. Svaki zapis može stati u nekoliko redaka u zajedničkom dokumentu ili alatu za upravljanje radom.
Polje: Status prodajne narudžbe
Polje: Raspoloživa količina artikla
Polje: Datum dospijeća ulaznog računa
Ovi primjeri nisu univerzalne definicije. Tvrtka ih mora uskladiti s vlastitim ugovorima, procesima, konfiguracijom ERP-a i računovodstvenom praksom.
Tehničke kontrole mogu spriječiti dio grešaka. Ograničenja podataka mogu, primjerice, provjeravati jedinstvenost vrijednosti, obvezna polja i veze među zapisima. PostgreSQL dokumentacija opisuje ograničenja kao što su UNIQUE , NOT NULL , primarni i strani ključevi: PostgreSQL Constraints .
Takve kontrole odgovaraju na pitanja poput: postoji li već isti identifikator, nedostaje li obvezna vrijednost ili pokazuje li zapis na postojeći povezani zapis. One ne odlučuju same smije li prodaja obećati rok kupcu, kada se status smije promijeniti ili tko odobrava odstupanje. Ta poslovna pravila treba definirati zasebno u katalogu i procesu.
Ova razlika smanjuje dvije česte pogreške. Prva je očekivanje da će validacija baze riješiti nejasan proces. Druga je vođenje važnog poslovnog pravila samo u usmenom dogovoru zato što ga nije moguće izraziti jednim tehničkim ograničenjem.
Rad započnite kratkom radionicom s osobama koje unose podatke i osobama koje prema njima odlučuju. Za svako kandidatno polje postavite ova pitanja:
Hipotetski scenarij: prodaja označava narudžbu kao „spremnu”, skladište taj status čita kao nalog za otpremu, a računovodstvo kao uvjet za izdavanje računa. Katalog ne mora odmah mijenjati sustav. Najprije može razdvojiti značenja: „spremno za otpremu”, „otpremljeno” i „spremno za fakturiranje”, zatim dodijeliti vlasnike i pravila prijelaza. Tek nakon toga ima smisla procijeniti treba li promijeniti polja, statuse ili integraciju.
Ako se nesporazumi protežu kroz više funkcija, Screening poslovnog procesa može dati strukturiran početak: identificirati odluke, službene transakcije, prijenose i točke odgovornosti prije većih promjena u ERP-u.
Katalog stvara obvezu održavanja. Definicija bez vlasnika brzo zastari, a prevelik katalog gubi uporabu. Zato je bolje početi s malim brojem polja i utvrditi pregled pri promjeni procesa, obrasca, integracije ili izvještaja koji služi za važnu odluku.
Također, jedan pojam ponekad opravdano ima više vrijednosti. „Kupac” može označavati ugovornu stranu, primatelja robe i platitelja. Umjesto prisilnog spajanja tih uloga, katalog treba navesti svaku ulogu, povezano polje i dopuštenu uporabu.
Katalog nije zamjena za ovlasti, računovodstvene politike, ugovore ili kvalitetu osnovnih podataka. On je zajedničko mjesto na kojem se vidi gdje te teme dodiruju konkretno polje.
Prije objave prvog kataloga provjerite svaki zapis prema ovom popisu:
Kada prvi katalog prođe ovu provjeru na nekoliko važnih polja, koristite ga u svakodnevnoj suradnji, uz službene ERP transakcije i promjene procesa. Za povezivanje kataloga s odgovornostima, procesnim koracima i operativnim pravilima pogledajte ORKA operativni sustav .