Najviše pogrešaka unosa podataka nastaje kada korisnik mora pamtiti pravila, tražiti polja ili nagađati sljedeći korak. UX poslovnog softvera može znatno smanjiti takav rizik kroz dobar raspored polja, razumne zadane vrijednosti, pravodobne validacije i jasan status procesa. Ipak, sučelje ne može nadomjestiti nejasna procesna pravila, loše matične podatke ni edukaciju korisnika.
Pogrešan unos rijetko je samo pitanje nepažnje. U poslovnom sustavu korisnik često radi pod vremenskim pritiskom, prekida rad zbog poziva ili upita kolega te obrađuje velik broj sličnih dokumenata. Ako ekran ne pokazuje što je obvezno, koja je vrijednost očekivana ili u kojoj je fazi dokument, korisnik traži prečace.
Ti prečaci mogu izgledati bezazleno: kopiranje starog dokumenta bez provjere, upis slobodnog teksta umjesto odabira šifre, odgoda unosa ili vođenje pomoćne evidencije izvan ERP-a. Posljedice se kasnije pojavljuju u nabavi, proizvodnji, računovodstvu, skladištu i izvještavanju. Jedan pogrešan partner, artikl, konto, datum ili status može stvoriti dodatni posao za više timova.
ERP korisničko iskustvo zato nije samo pitanje urednog izgleda ekrana. Ono određuje koliko sustav korisniku pomaže donijeti ispravnu odluku u trenutku unosa. Dobar UX smanjuje nepotrebno razmišljanje, ali ne skriva poslovnu logiku koja je važna za kontrolu procesa.
Prije promjene ekrana korisno je utvrditi gdje i zašto nastaju pogreške. Umjesto općenitog zahtjeva poput "pojednostaviti unos", procesni tim može proći kroz konkretan slučaj:
Ovakav pregled razlikuje problem sučelja od problema procesa. Ako dva odjela različito tumače trenutak prijenosa robe u proizvodnju, dodatna boja na obrascu neće riješiti nesporazum. Potrebno je prvo dogovoriti pravilo, odgovornost i iznimke. Tek tada UX može pravilo prikazati na jasan način.
Kod složenijih tokova koristan početak može biti ERP i procesni screening . Svrha screeninga nije samo popis funkcija, nego razumijevanje stvarnog rada, odluka i mjesta na kojima podaci gube kvalitetu.
Polja trebaju slijediti redoslijed kojim korisnik prikuplja i provjerava informacije. Podaci o partneru, dokumentu, artiklu, količini, roku i odgovornoj osobi ne moraju uvijek biti istim redom, ali redoslijed treba odgovarati poslovnoj radnji.
Najvažnija polja vrijedi grupirati i vizualno odvojiti od pomoćnih podataka. Polja koja ovise jedno o drugome trebaju stajati blizu. Ako izbor skladišta određuje dostupne lokacije ili artikle, korisnik to treba razumjeti prije sljedećeg odabira.
Dug obrazac nije nužno loš. Problem nastaje kada su sva polja jednako istaknuta, kada se važne informacije skrivaju u karticama bez jasnog naziva ili kada korisnik mora pomicati ekran gore-dolje radi jedne odluke. Dobro strukturiran obrazac može imati više podataka, ali korisniku pokazuje samo ono što je relevantno u toj fazi.
Zadana vrijednost je korisna kada dolazi iz pouzdanog konteksta: prijavljene organizacijske jedinice, odabranog skladišta, vrste dokumenta ili unaprijed dogovorenog pravila. Time se smanjuje broj ručnih unosa i rizik tipfelera.
No zadane vrijednosti nose rizik tihog pogrešnog unosa. Ako sustav automatski postavi konto, porezni tretman ili lokaciju samo zato što je korisnik zadnji put radio s tom vrijednošću, pogreška može proći bez ikakvog upozorenja. Zato treba razlikovati:
Dobra praksa nije maknuti svu automatiku, nego jasno pokazati izvor prijedloga i omogućiti jednostavnu provjeru prije spremanja.
Validacija može biti obvezno polje, dopušteni raspon količine, provjera formata, kontrola povezanosti podataka ili upozorenje na neuobičajenu kombinaciju. Njezina vrijednost ovisi o vremenu i poruci.
Prekasna validacija, primjerice tek nakon slanja dokumenta, korisniku stvara frustraciju jer mora ponovno tražiti uzrok. Prerano upozorenje može prekinuti rad prije nego što je korisnik unio sve potrebne podatke. Najkorisnije je provjeriti podatak čim sustav ima dovoljno konteksta za pouzdanu odluku.
Treba izbjegavati i pretjeranu validaciju. Sustav s velikim brojem blokada potiče korisnike na traženje zaobilaznih rješenja ili dijeljenje tuđih pristupnih podataka. Kritične kontrole trebaju blokirati nastavak rada. Manje rizične situacije mogu prikazati upozorenje, razlog i dopušten način postupanja s iznimkom.
Poruka poput "Neispravan unos" ne govori korisniku ništa korisno. Razumljiva poruka navodi što nije u redu, gdje je problem i što korisnik može učiniti dalje.
Primjerice, umjesto opće poruke o neuspješnom spremanju, korisnije je navesti: "Datum isporuke ne može biti prije datuma narudžbe. Ispravite datum isporuke ili provjerite vrstu dokumenta." Takva poruka ne otkriva internu tehničku logiku, ali korisniku daje jasnu sljedeću radnju.
Poruke trebaju koristiti rječnik procesa koji korisnici poznaju. Tehničke šifre, nazivi tablica i interne oznake mogu pomoći podršci, ali ne pripadaju glavnom tekstu poruke za krajnjeg korisnika.
Korisnik može ispravno popuniti dokument, a ipak pogriješiti ako ne zna je li dokument spremljen, poslan na odobrenje, knjižen, odbijen ili čeka dopunu. Nejasan status potiče dvostruki unos, slanje e-pošte radi provjere i paralelne evidencije.
Status treba biti vidljiv bez otvaranja više ekrana. Uz naziv statusa korisna je i informacija o sljedećem koraku: tko treba reagirati, što nedostaje ili može li korisnik još izmijeniti dokument. Povijest važnih promjena dodatno pomaže pri rješavanju nesporazuma, posebno kada više osoba radi na istom predmetu.
Zamislimo unos utroška materijala u proizvodnji. Operater odabire radni nalog, artikl, količinu, skladište i datum. Ako sustav najprije prikaže sve artikle, sva skladišta i velik broj tehničkih polja, povećava se mogućnost pogrešnog odabira.
Bolji slijed može biti sljedeći:
Takav obrazac ne određuje sam poslovno pravilo o dopuštenom odstupanju. To pravilo trebaju definirati odgovorne osobe iz proizvodnje, skladišta i financija. Sučelje zatim provodi dogovoreno pravilo na mjestu rada.
Povezani procesi često traže pregled dostupnih funkcionalnih cjelina, poput Poslovnih modula povezanih s ERP-om , ali svaka promjena treba krenuti od konkretnog toka podataka i odgovornosti.
UX poslovnog softvera ne može riješiti loše matične podatke, neusklađene šifrarnike, nejasne ovlasti ni kontradiktorne upute. Ne može ni zamijeniti edukaciju za rijetke, rizične ili složene postupke. Korisnik treba razumjeti zašto unosi podatak, kakav poslovni učinak unos ima i kada treba zatražiti pomoć.
Postoji i kompromis između brzine i kontrole. Previše koraka usporava svakodnevni rad. Premalo provjera povećava trošak kasnijeg ispravljanja. Pravi omjer ovisi o učestalosti zadatka, riziku pogreške, iskustvu korisnika i mogućnosti naknadne korekcije.
Zato promjene vrijedi testirati s korisnicima koji stvarno obavljaju posao. Test ne mora biti velik projekt: nekoliko stvarnih scenarija može otkriti nerazumljiva polja, loš redoslijed, nejasne poruke i nepotrebne blokade prije šire primjene.
Za početak odaberite jedan obrazac s čestim pogreškama ili zaobilaženjem sustava. Zabilježite stvarni tijek rada, odluke, iznimke i podatke koji se naknadno ispravljaju. Zatim odredite koje će pravilo ostati procesna odgovornost, koje će upozorenje pripadati sučelju, a koje će podatke sustav moći sigurno predložiti.
Ako organizacija treba strukturirati takav pregled kroz ERP, proizvodnju, računovodstvo ili integracije, sljedeći razgovor može početi s konkretnim primjerom procesa. Razgovarajte s ORKA timom .