ERP UX olakšava usvajanje ERP sustava kada korisnik za svoj zadatak vidi relevantne informacije, prepoznaje sljedeći korak i ne mora pamtiti putanju kroz sustav. Polazište nije početna stranica ni katalog funkcija, nego radna uloga, učestalost zadatka i posljedica pogreške. Takav dizajn poslovnih aplikacija povezuje ekran, obrazac i navigaciju sa stvarnim radnim tijekom, a provjerava se radom s korisnicima prije šireg uvođenja.
ERP sustav često koristi više timova, ali ne koriste ga svi na isti način. Skladištar može više puta tijekom smjene potvrđivati primitak ili izdavanje robe. Voditelj proizvodnje može pratiti odstupanja i rješavati iznimke. Računovodstvo može pregledavati dokumente, konta i statuse knjiženja. Uprava može povremeno tražiti pregled stanja i otvorenih odluka.
Jedan širok početni ekran za sve korisnike obično skriva te razlike. Korisnik tada mora sam filtrirati podatke, pronalaziti funkciju i tumačiti polja koja nisu važna za trenutačni posao. To povećava kognitivno opterećenje, osobito u prvim tjednima rada.
Koristan početak UX rada nije pitanje "koje module sustav ima?", nego nekoliko konkretnijih pitanja:
Odgovori stvaraju osnovu za prikaze po ulozi. To ne znači izraditi zasebnu aplikaciju za svakoga. Znači odrediti prioritete: što je vidljivo odmah, što se nalazi jedan korak dublje, a što ostaje dostupno samo korisnicima kojima je potrebno.
U okviru ERP i procesnog screeninga tim može najprije mapirati uloge, ključne zadatke, iznimke i prijelaze između procesa. ERP i procesni screening posebno je koristan kada organizacija još utvrđuje opseg promjene ili želi razlikovati stvarne potrebe od navika iz postojećeg sustava.
Učestalost rada pomaže odrediti koliko izravan mora biti put do radnje. Zadatak koji se ponavlja mnogo puta dnevno traži manje koraka, jasnije zadane vrijednosti i brzu provjeru unosa. Rijetki, ali osjetljivi zadaci mogu opravdati dodatne provjere, objašnjenja i pregled prije potvrde.
Praktično je podijeliti zadatke u tri skupine.
To su ponavljajući unosi i potvrde, primjerice evidentiranje primitka, izrada radnog naloga, unos stavke dokumenta ili potvrda faze proizvodnje. Na takvim obrascima korisniku najčešće trebaju:
Brzina nije jedino mjerilo. Previše prečaca može sakriti važnu provjeru ili potaknuti unos bez razumijevanja. Zato svaku zadanu vrijednost treba moći prepoznati i po potrebi promijeniti, uz jasnu vidljivost posljedice.
Voditelji, planeri i kontrolori često ne unose velik broj transakcija. Njihov posao uključuje prepoznavanje odstupanja, usporedbu prioriteta i pokretanje sljedeće aktivnosti. Prikaz za tu ulogu može naglasiti otvorene stavke, rokove, zastoje, iznimke i poveznice prema detalju.
Sažetak ne bi smio glumiti odgovor na svako pitanje. Dobar prikaz jasno razlikuje pregled od izvornog zapisa i omogućuje prelazak prema dokumentu, nalogu ili stavci koja stoji iza statusa. Korisnik tada može provjeriti kontekst prije odluke.
Zatvaranje razdoblja, promjena matičnih podataka, storniranje dokumenta ili ručna korekcija mogu se događati rijetko, ali nose veću posljedicu. Za takve radnje korisniji su vođeni koraci, provjera prije potvrde, razumljive poruke i mogućnost pregleda povezanih zapisa.
Dizajn ne mora otežavati svaku radnju radi opreza. Treba razlikovati normalan tijek od postupaka s većim rizikom. Ta razlika je važna za povjerenje korisnika: sustav treba biti brz gdje je posao rutinski i pažljiv gdje je posljedica veća.
Nazivi modula često slijede internu strukturu sustava: nabava, prodaja, proizvodnja, financije ili skladište. Korisniku su ti nazivi korisni kao orijentir, ali radni zadatak često prelazi preko više područja. Primjerice, rješavanje manjka materijala može uključiti stanje zaliha, zahtjev za nabavu, proizvodni nalog i komunikaciju s odgovornom osobom.
Predvidiva navigacija gradi se oko nekoliko pravila:
Navigacija također treba pokazati gdje se korisnik nalazi. To je osobito važno u procesima s mnogo sličnih dokumenata, verzija ili statusa. Jasni nazivi ekrana, vidljivi identifikator zapisa i razumljiv status smanjuju rizik rada nad pogrešnim objektom.
Povezani poslovni moduli povezani s ERP-om mogu se promatrati kroz taj isti princip: korisnik ne treba učiti strukturu samo zato što je sustav tehnički podijeljen na module. Treba razumjeti kako njegov posao prelazi iz jednog dijela procesa u drugi.
Obrazac nije samo popis polja. On korisniku govori koje informacije sustav očekuje, kojim redoslijedom i pod kojim uvjetima. Loš obrazac može prenijeti pravila procesa u korisnikovu memoriju. Dobar obrazac dio tih pravila čini vidljivim u trenutku rada.
Pri oblikovanju obrasca korisno je provjeriti sljedeće:
Razmotrimo pojednostavljen primjer prijave utroška materijala u proizvodnji. Operateru za rutinski unos mogu biti važni radni nalog, materijal, količina, jedinica mjere i vrijeme evidentiranja. Podaci o planu, dobavljaču ili računovodstvenom tretmanu mogu biti dostupni u detalju, ali ne moraju zauzimati glavno mjesto na svakom unosu.
Ako količina odstupa od očekivane ili materijal nije raspoloživ, obrazac ne bi trebao samo odbiti unos nejasnom porukom. Trebao bi pokazati problem, zadržati unesene podatke gdje je to prikladno i usmjeriti korisnika prema mogućoj sljedećoj radnji. To može biti provjera stanja, izbor drugog materijala ili upućivanje odgovornoj ulozi. Točan tijek ovisi o pravilima organizacije, pa ga treba dogovoriti prije izrade sučelja.
Projektni tim ne može pouzdano procijeniti jasnoću sučelja samo pregledom specifikacije ili demonstracijom. Korisničko testiranje otkriva gdje osoba zastaje, koje pojmove tumači drukčije i kojim se neformalnim postupcima služi kako bi dovršila zadatak.
Test ne mora biti složen. Za svaku važnu ulogu može se pripremiti nekoliko realnih scenarija, primjerice:
Tijekom testiranja korisnik treba izvesti zadatak, ne samo komentirati ekran. Promatrač bilježi gdje se pojavljuje nejasnoća, koji podatak nedostaje, koji naziv zbunjuje i kada korisnik očekuje drukčiju povratnu informaciju. Nalaze je korisno razdvojiti na probleme procesa, podatkovne probleme, pitanja ovlasti i čiste probleme sučelja. Jedan ekran ne može riješiti nejasno vlasništvo nad zadatkom ili nedogovoreno poslovno pravilo.
Široko puštanje svih procesa i svih uloga odjednom može otežati učenje i podršku. Postupno uvođenje daje priliku provjeriti radne scenarije u ograničenom opsegu, doraditi upute i pripremiti podršku za sljedeću skupinu korisnika.
Redoslijed ne mora uvijek pratiti organizacijsku hijerarhiju. Može slijediti stabilnost procesa, spremnost podataka, povezanosti s drugim timovima i dostupnost ključnih korisnika za povratnu informaciju. U nekim slučajevima smislen je početak s jasno omeđenim procesom. U drugima je važnije prvo pripremiti zajedničke matične podatke i pravila rada.
Postupno uvođenje nije samo tehničko pitanje. Potrebno je odrediti tko odgovara na pitanja, kako se prijavljuje problem, kada se mijenja uputa i kako se razlikuje greška u radu od potrebe za promjenom procesa ili sučelja. Kratke upute uz konkretan zadatak često su korisnije od opsežnog priručnika koji korisnik otvara tek nakon problema.
ERP UX ne može ukloniti svu složenost poslovanja. Ako proces zahtijeva više provjera, odobrenja ili povezanih podataka, sučelje ne smije stvoriti privid jednostavnosti koji skriva važnu odluku. S druge strane, svako polje i upozorenje ne treba prikazati svakom korisniku u svakom trenutku.
Nekoliko kompromisa traži svjesnu odluku:
Zato ERP UX treba promatrati kao niz odluka koje se povremeno preispituju na temelju stvarnih zadataka, promjena procesa i povratnih informacija korisnika.
Projektni tim može početi bez velikog redizajna. Odaberite nekoliko zadataka s velikom učestalošću, velikom posljedicom pogreške ili čestim pitanjima korisnika. Za svaki zapišite ulogu, početni događaj, potrebne podatke, odluku, iznimke i završni status. Zatim provjerite može li korisnik taj put prepoznati i dovršiti bez oslanjanja na usmeno objašnjenje.
Ako je potreban strukturiran razgovor o ulogama, procesima i opsegu promjene, razgovarajte s ORKA timom . Dobra polazna točka nije popis ekrana, nego konkretan radni scenarij koji korisnik mora sigurno razumjeti.