Case: ESS (Employee Self Service)

1. Case: ESS (Employee Self Service) SAP for statsansatte Her vurdert i forhold til det vi har lært om IT systemer

2. Et system der • Den ansatte skal selv holde orden på sine persondata • Lønnsmeldinger skal presenteres her istedenfor på papir • Arbeidstidregistreringer utføres her • Reiseregninger skal registreres og behandles i dette systemet • m.m. • Et Web-basert system • En modul i SAP

3. FEIL: Ingen mål for systemet • Ingen mål er oppgitt for systemet, det holder ikke å si at de ansatte skal administrere seg selv. • Vi vil altså vite hva en vil oppnå med systemet. • En kan spørre seg om utviklerne bare har ITfisert et system uten å tenke på hva de skal oppnå • Dessverre er dette ofte eneste målsetting staten har med nye systemer – å vise hvor moderne eller ”cool” de er. Det er i hvert fall en rimelig konklusjon når noe annet mål ikke er oppgitt. • eller at en tror at IT er så effektivt, og at det i utgangspunktet vil være en forbedring • Men av alle burde ikke staten tenke slik

4. Evaluering • Vi skal her gi en kort uformell evaluering av systemet • Siden dette skal benyttes av vanlige ansatte til sekundære gjøremål forventer vi et intuitivt system • Det kan gå lang tid mellom hver gang den ansatte bruker systemet – også en grunn for et enkelt system

5. Feil: Opplæring • Systemet krever to timers opplæringskurs fpr alle ansatte (mer for de som jobber i administrasjonen) • Dette vil innebære en betydelig kostnad og betydelige problemer • Greit nok å gi alle et startkurs, men hva med nyansatte? Skal en gi fortløpende kurs? Hva med de som ikke bruker systemet på lang tid – skal de få oppfriskingskurts? • Systemet brukes for enkle administrative oppgaver og burde vært intuitivt i bruk

6. FEIL: Tungvindt innlogging • Vi velger først ESS i hovedmenyen på intranettsiden • Må så klikke pålogging her • Kommentar: Et lite unødvendig mellomsteg

7. FEIL: Uklare begreper • Her heter systemet SAP, ikke ESS (kan skape forvirring). Et tredje ord som brukes er ”ansattportalen”. • Klient burde vært utfylt (er rettet nå), men forsvinner om du skriver galt passord første gang • ”Tjeneste PZM3” sier ingenting til en bruker

8. FEIL: Bare Internet Explorer • Et system må understøtte den nettleseren som kunden har valgt å bruke • Det er både praktiske og prinsipielle grunner til dette

9. FEIL: Ikke tilgjengelig via nett • Det er rimelig å forvente at systemet kan benyttes fra hvor som helst i verden • ESS kan bare brukes fra Høgskolen, eller om en er logget inn på Høgskolen via VPN

10. FEIL: Misoppfatning mellom bruker og system • Velger ”avslutt” knappen (med rødt kryss) • Men vi er fortsatt ikke utlogget (det er mulig å komme tilbake) • Tungvindt og risikofylt at du må logge av og lukke nettleser

11. FEIL: Nok et brukernavn • Hver ansatt har fått et eget brukernavn i dette systemet. • Vi har allerede et brukernavn for Høgskolens datasystem, så dette er unødvendig • Siden klient (Høgskolen) er oppgitt kunne brukernavnet vært lokalt, og dermed enklere • Dette kan bli bedre med et nytt innloggingssystem som er på trappene

12. FEIL: Tungvindt passordsystem • Passord må være på 8 tegn • Det skal inneholde bokstaver, tall og spesialtegn • Det må skiftes hver 120 dag • Dette gjør det umulig å huske passordet. • Brukerne vil da skrive det opp • Dette reduserer sikkerheten • og effektiviteten (bruker du dette en gang i kvartalet må du legge inn et nytt passord hver gang)

13. FEIL: Svak sikkerhet • Inngangspassord sendes på e-post • Også om brukeren har glemt passord • Det medfører at systemet uansett ikke blir sikrere enn Høgskolens vanlige innloggingsrutiner • Dette kan være farlig. • Om en ansatt glemmer å logge ut, f.eks. i et undervisningsrom, kan andre få adgang til passord • Dette er normalt ikke noe stort problem, siden de fleste ikke har konfidensielle data i Høgskolens system • Men i ESS kan en endre bankkontonr for lønn. • Da blir risikoen større.

14. I ESS • ESS har et relativt standardisert grensesnitt • Meny til venstre • Detaljer til høyre • Dette er oversiktlig

15. FEIL: Ulogisk struktur • Skille mellom kontor og persondata er ikke klart • F.eks. ligger e-postadresse og bilde (!) under ”kontor”, mens det kanskje var mer naturlig å forvente dette under persondata • I det hele tatt er ”kontor” en underlig kategori?

16. FEIL: Terminologi • Lønnsavregninger ligger under ”Betaling”, ferie under ”fravær” • Ikke intuitivt • God terminologi er av vesentlig betydning om en skal lage intuitive systemer

17. Eksempel 1: Lønn • Med ESS er ideen at papirskjemaene vi i dag får i posthyllen skal gis gjennom systemet • Det er gjort, men helt bokstavelig • Her har de flyttet papiret til datamaskinen

18. FEIL: Fast format • For å se lønnsavregningen i normal skriftstørrelse må vi skrolle både vertikalt og horisontalt • Dette gir dårlig oversikt • Som bildet viser er verken skjerm- eller vinduet utnyttet • Godtar vi mindre fonter kan skjemaet tilpasses vinduet

19. FEIL: Ikke utnyttet muligheter • Det hadde kanskje vært mer naturlig å glemme papiret, og å presentere lønnsdata slik at brukeren kunne utnytte dette også elektronisk • Som data ville brukeren kunne få de ”view” hun måtte ønske: • som lønnsavregning • i tabellform • men også summere opp det hun hadde tjent i sommer, overtid siste kvartal, skatt av diett, etc. • Denne type feil ser vi ofte. Utviklerne blir for opptatt av det eksisterende (papirformatet) og glemmer å utnytte de nye mulighetene som datamaskinen gir.

20. Feil: Intet varsel om lønn • Tidligere fikk vi en lønnsslip i posthyllen • Denne varslet at lønn var kommet og ga data • I dag får vi intet varsel.

21. Feil: Systemet dekker ikke alle • En undervisningsinstitusjon har mange deltidsansatte og timeansatte • Disse får ikke konto i ESS • og må da få lønnsslipp på papir • En bedre ide ville vært å bruke epost

22. Eksempel 2: Reiseregning • Vi skal her velge ut en funksjon – utfylling av reiseregning • Utgangspunkt: • Vi har vært på seminar i USA • Alle utgiftene skal registreres her • Slik at vi får refusjon • Merk at staten lar oss betale utgiftene selv først

23. FEIL: Uklare kommandoer • Vi velger ”oppretting av reiseregning” • Ordet ”oppretting” kan misforstås • ”Ny reiseregning” ville vært klarere og mer i tråd med hva vi er vant til fra andre systemer

24. Feil: Overlappende menyalternativer • Vi får nå velge type reise • Rekkefølgen (og valg av ord) er ikke smart her – hvorfor? • Velger utenlandsreise • Og får fram et skjema som de fleste statsansatte vil kjenne seg igjen i

26. FEIL: Fast utfyllingsrekkefølge • Systemet krever at vi fyller ut skjemaet i den rekkefølgen det har definert • Men dette er ikke oppgitt • Det er heller ikke lagt inn begrensninger, dvs. det er fullt mulig å starte med å legge inn utgifter – selv om systemet ikke håndterer dette • Et mer brukervennlig system ville latt brukeren bestemme rekkefølge

27. Feil: Skjulte feilmeldinger • Eksempel: • Jeg pleier å glemme parkeringsgebyret og velger å fylle ut dette først • Velger ”parkering” i feltet for utgifter • Det går greit, men når jeg skal fylle ut beløpet stopper det hele opp • Hva skjer?

28. FEIL: Lite robust system • Systemet stopper opp • Jeg går ut av reiseregningen, og inn igjen • Og får den kryptiske meldingen under

29. Feil: Lite synlige feilmeldinger • Når jeg fyller ut reiseregningen i min rekkefølge kommer følgende melding nederst på skjermen med liten skrift: • ”Fyll ut all obligatoriske felt først” • Feilmelding varsler brudd i sekvensen å må da vises meget synlig

30. Feil: Lang responstid • Som en erfaren bruker fyller vi ut systemet slik vi har lært at SAP forventer • Starter med dato øverst • Fyller ut reisemål (Pittsburgh) • Klikker for å fram ”reiseland” (og i mitt tilfelle må jeg vente 90 sek for at listen skal komme fram) • (systemet går raskere nå)

31. FEIL: Kun valg, ikke inntasting • Finner ikke USA i listen og trykker pilen øverst til høyre • Får samme liste på nytt • Innser at vi må taste inn et nr i feltet • Endrer 1 til 101 og trykker så pilen på nytt • Først da får vi listen med USA (US)

32. Feil: Krav om å bruke listboks • Listbokser, der vi velger fra en liste, er greit alternativ • Men vi må også få lov å taste inn, siden dette ofte er raskere • En Kombo-boks er den ideelle løsning, her velger vi i listen etter hvert som vi taster.

33. FEIL: Terminologi • Skriver ”seminar” • Det går bra • ”Reiseårsak” er for øvrig et underlig ord. • På papirskjemaet heter det ”Reiseformål”, et langt bedre ord.

34. FEIL: Ikke intuitiv utfylling • Vi fyller ut: • Flyreise 8670 kr – ok • Må trykke ”overfør” for å dette inn i skjemaet. • Siden data allerede er tastet inn er det lett å overse denne kommandoen

35. Refusjon: Hotell • Hotellet kostet $320 for 3 netter • Vi legger inn dette • Blir nå bedt om å gi tilleggsinformasjon • Fyller ut og trykker ”Overfør”

36. FEIL: Manglende forståelse av oppgaven • Utlegget blir lagt inn med en kurs på 5,37310 • Dette er dagens offisielle valutakurs • Men ikke den som blir brukt på kredittkortet (her er det et påslag mellom 1,5 og 2%) • I praksis vil den ”offisielle” kursen aldri være aktuell! • Løsningen er å oppgi alle beløp i NOK, men da er det ikke lengre direkte samsvar mellom kvitteringen (f.eks. $320) og beløpet (1.824,32). Det kan gjøre godkjenning mer komplisert.

37. FEIL: Feilmelding istedenfor advarsel • Vi forsøker å legge inn seminaravgift ($1000) • Men dette er ikke et valg i utgiftsmenyen • Må legge inn under ”Annet” • Nå får vi se kursen (det fikk jeg ikke i hotelleksempelet?). • Vi betalte avgiften 01.06, og fikk da rabatt for tidligregistrering. På dette tidspunktet var kursen 6,05. Legger inn dette og trykker ”Overfør” • Vi får feilmelding: 01.06 ligger ikke innenfor reisetiden. Endrer dato til 22.10. • Får ny feilmelding: Kursavvik på 10% er for høyt.

38. FEIL: Håndterer ikke feilsituasjoner • Til tross for at systemet ikke aksepterte kursen ble beløpet lagt inn, men nå med kurs 1 (dette skjer ikke alltid) • Dette krever oppegående brukere. • Vi legger inn dette på nytt, nå som 6050 norske kroner. • Ulempen er at de som skal kontrollere må kople ”Annet 6050” til kvitteringen for ”Seminaravgift $1000”. Det kan bli komplisert.

39. FEIL: Systemet er ikke tilpasset arbeidssituasjonen • Jeg får nå en telefon fra en kompis som spør om mitt nye kontonummer • Det husker jeg ikke, men tenker at dette ligger jo i ESS • Går til ”persondata” for å hente fram dette, leser det opp for kompisen, og går så tilbake til reiseregningen… • Men der ligger ingen reiseregning!

40. FEIL: Misforståelser • I et annet tilfelle fikk jeg innloggingsskjemaet opp da jeg skulle gjenskape denne situasjonen • Inntrykket er at vi er logget ut • Reiseregningen var fortsatt tapt • Men det alvorlige her var at en bruker kunne tro at hun var logget ut – det var ikke tilfelle!

41. FEIL: Aksepterer ikke multitasking • En av grunnprinsippene i moderne databehandling er at vi aksepterer at brukeren gjør flere ting samtidig • Derfor tillater (nesten) alle system i dag at vi går ut og inn i operasjoner • I det minste burde vi her fått en advarsel • Men hvorfor kan en ikke mellomlagre automatisk – det er en enkel løsning?

42. FEIL: Timeout! • Reiseregningen er tapt • Feilmeldingen er uforståelig for den vanlige bruker • Timeout var opprinnelig på 2 minutter, nå er det 10 • I tillegg: En uerfaren bruker kan igjen tro hun er logget ut – det er hun ikke. Det er bare ”session”, den aktuelle jobben, som er terminert.

43. FEIL: Ferdig? • Denne meldingen kan vi få midt i en prosess • En uerfaren bruker kan tro at han må starte på nytt • Men vi er fortsatt innlogget

44. FEIL: Manglende kommandoer • Om du får lagret reiseregningen • Og sender denne videre til godkjenning • Kan du ikke se på denne • Du må velge ”endre” • Det betyr at regningen stoppes i godkjenningsprosessen • Og forblir stoppet om du ikke igjen sender den videre • Det er viktig å skille mellom lese (se) og skrive (endre) operasjoner, siden de første vanligvis ikke har noen andre konsekvenser.

45. Uakseptabelt: Tap av data • Vi må kanskje akseptere at et system går sakte av og til • Men vi kan ikke akseptere at inntastede data går tapt • I den lille testen jeg utførte mistet jeg data to ganger • For øvrig skjedde det samme også ved tre andre anledninger

46. Uakseptabelt: Sikkerhet • Det er helt uakseptabelt at systemet gir inntrykk av at en bruker er logget ut, mens systemet fortsatt er oppegående • ESS bør derfor ikke benyttes i laboratorium, undervisningslokaler, internett kafeer, m.m.

47. Uakseptabelt: Hastighet • Systemet kan til tider gå ualminnelig tregt • Det kan ta minutter (2-3 under denne testen) å komme inn, eller å skifte i menyen • Med en timesats på 700 kroner (lønn + administrativt overhead) kan det bli kostbart for staten å bruke ESS • Skal IT systemer virke må det gå raskt. Blir totaltiden større enn med papirskjema blir vinningen diskutabel. • Bedre med nyere versjoner

48. Uakseptabelt: Ikke robust • Det er åpenbart feil i systemet • Det er lite robust, og kan låse seg om brukeren ikke gjør akkurat det systemet forventer. • Dette skaper frustrasjon og forvirring

49. FEIL: Uforståelige meldinger • Slike meldinger får vi på mail når systemet er nede Klientkopi 603 – 403 pågår fortsatt og dette medfører at TOA 403 ikke er tilgjengelig ennå. Det blir sendt ut melding når TOA 403 er oppe.

50. Feil: Forskudd er ikke håndtert • Blir derfor lagt inn som en egen reiseregning • Når du så kommer tilbake og velger ”opprett” reiseregning, får du fylle ut land, by m.m. Men når du legger inn dato får du beskjed: • Det ligger allerede en reiseregning på denne dato (altså forskuddet). Du må da få administrasjonen til å slette dette og starte på nytt. • Uansett må en da kunne forvente to reiseregninger på samme dag? Jonas Gar Støre, Hillary Clinton og andre har jo mange reiser på samme dag (men kanskje de ikke skriver reiseregning – i hvert fall ikke i ESS)