Netočan podatak u webshop katalogu može postati dio upita, ponude i narudžbe. Kontrola prije objave zato ne počinje pregledom teksta na stranici, nego definicijom prodajne stavke: koji su podaci obvezni, tko stručno potvrđuje njihovu točnost, koje iznimke smiju proći i kako povući već objavljenu pogrešku. Tehnička ograničenja baze korisna su kontrola strukture, ali poslovna pravila zahtijevaju zasebnu odluku.
Katalog je ulaz u prodajni proces. Kupac prema njemu uspoređuje artikle, šalje upit ili očekuje uvjete iz ponude. Ako katalog prikazuje pogrešnu jedinicu mjere, neusklađenu varijantu, zastarjelu kompatibilnost ili nedostupno obilježje, prodaja može prenijeti isti podatak dalje.
Rizik nije samo pogrešna objava. Problem nastaje kada nema jasnog odgovora na četiri pitanja:
Kontrola podataka webshop kataloga mora zato povezati katalog, stručnu odgovornost i prodajni proces. Sustav može spriječiti dio formalnih pogrešaka, ali ne može sam odlučiti je li opis primjeren stvarnoj primjeni proizvoda ili je li određena iznimka poslovno prihvatljiva.
Marketinški opis objašnjava namjenu i korist. Primjerice, može opisati proizvod kao rješenje za određeni radni zadatak. Takav sadržaj treba biti jasan, ali ne smije zamijeniti specifikaciju.
Mjerljiva specifikacija je podatak koji se može provjeriti prema dogovorenom izvoru. To mogu biti šifra artikla, proizvođačka oznaka, jedinica mjere, dimenzija, materijal, tehnički raspon, kompatibilnost, pakiranje ili uvjet isporuke - kada je taj podatak relevantan za prodajnu odluku.
Za svako polje odredite:
Nije svako polje obvezno za svaku vrstu artikla. Ipak, kategorija mora imati unaprijed određen minimalni skup. Potpunost prodajne stavke nije isto što i velik broj popunjenih polja. Stavka je potpuna kada sadrži podatke potrebne za ispravnu identifikaciju, usporedbu i prodajnu odluku unutar svoje kategorije.
Vlasnik ulaznog podatka odgovara za pravodobnu dostavu i održavanje podatka iz odobrenog izvora. To može biti nabava za dobavljačku oznaku, proizvodnja za sastav ili tehnička služba za tehničku specifikaciju. Uloga ne mora unositi podatak u katalog, ali mora biti jasno odgovorna za njegov sadržaj.
Vlasnik stručne potvrde odgovara za odluku smije li podatak biti objavljen za određenu namjenu. Ta odgovornost je važna kada opis ili kompatibilnost mogu utjecati na izbor artikla. Marketinški urednik može oblikovati tekst, ali ne bi trebao sam potvrđivati stručnu tvrdnju bez određenog stručnog vlasnika.
Praktična podjela može izgledati ovako:
Jedna osoba može imati više uloga u manjoj organizaciji, ali odgovornosti i odluke ipak trebaju ostati vidljive u postupku.
Objava ne mora biti jedini mogući status stavke. Jasni statusi smanjuju potrebu za usmenim provjerama i olakšavaju rad prodaji.
Koristan tijek može sadržavati sljedeće korake:
Za objavu definirajte i blokirajuća pravila. Primjer: artikl iz tehničke kategorije ne može prijeći u status „spremno za objavu” bez identifikatora, prodajne jedinice, kategorije, izvora specifikacije i evidentirane stručne potvrde. Konkretna obilježja moraju proizaći iz vaše ponude i načina prodaje.
Ograničenja podataka mogu provjeravati jedinstvenost, obvezna polja i veze među zapisima. Dokumentacija za PostgreSQL opisuje ograničenja kao što su NOT NULL , UNIQUE , primarni i strani ključevi te provjere vrijednosti: PostgreSQL Constraints .
Takve kontrole imaju jasnu vrijednost. Mogu spriječiti duplikat šifre, praznu obveznu vrijednost ili vezu na nepostojeću kategoriju. Ipak, sama struktura baze ne definira poslovnu odluku. Primjerice, sustav ne može bez zasebno definiranog pravila zaključiti:
Poslovna pravila treba zapisati izvan tehničkog ograničenja, zatim ih povezati sa statusima, ulogama i dokazom potvrde. Tek nakon toga dio pravila ima smisla automatizirati.
Pretpostavimo da nova stavka ima šifru, naziv, cijenu i marketinški opis, ali nema potvrđenu kompatibilnost. Katalog tim ne bi trebao popuniti polje pretpostavkom niti objaviti općenitu tvrdnju koja može navesti kupca na pogrešan izbor.
Odluka ovisi o unaprijed postavljenom pravilu kategorije:
Ovo je hipotetski scenarij. Njegova je svrha pokazati redoslijed odluke, ne propisati univerzalni skup polja.
Pogreška otkrivena nakon objave traži brz, ali kontroliran postupak. Nemojte prvo mijenjati samo vidljivi tekst, a zatim tražiti uzrok. Sačuvajte trag odluke i provjerite gdje je podatak već upotrijebljen.
Postupak može imati ove korake:
Povlačenje ima cijenu: privremeno smanjuje vidljivost stavke i povećava operativni posao. Alternativa je ostaviti neprovjeren podatak dostupnim kupcima. Odluku treba vezati uz stvarni utjecaj pogreške, a ne uz neformalnu procjenu pojedinca.
Prije uvođenja ili izmjene procesa prođite ovaj popis.
Ako katalog, ERP i prodajni tijek danas koriste različite definicije stavke, prvi korak nije nužno nova tehnologija. Screening poslovnog procesa može pomoći mapirati izvore, odluke, prijenose i točke na kojima netočan podatak putuje do ponude. Nakon toga pravila imaju jasniji temelj za rad u svakodnevnom procesu.