Kap. 21 – Bad Systems

1. Kap. 21 –Bad Systems How Information Technology Is Conquering the World: Workplace, Private Life, and Society Professor Kai A. Olsen, Universitetet i Bergen og Høgskolen i Molde

2. Case 1: Inntasting i nettbank Hvem skal ta ansvaret når kunden taster feil nettbanken?

3. Tapte 500.000 Tapte en halv million etter tastefeil Tastefeil: Ett fem-tall for mye kostet Grete Fossbakk en halv million. Hun tastet feil kontonummer i nettbanken. Stakk av: Kunden i DnB Nor som fikk beløpet tok umiddelbart ut pengene - og gamblet bort det meste.

4. Hva skjedde • Fossbakk skulle taste: • 70581555022 • Men tastet: • 705815555022 • Dvs. et femtall for mye • Banksystemet aksepterte bare 11 siffer • Overføringen gikk til • 70581555502

5. Uheldig (1) • Det siste sifferet er et kontrollsiffer, men uheldigvis er også 70581555502 et gyldig kontonummer • Kontrollsifferet tar alle feil i ett siffer og alle ombyttinger av to etterfølgende siffer. • Gjør vi flere feil stopper denne kontrollen i snitt bare 92% av alle gale kontonummer. • Fossbakks feiltasting resulterte derfor i et gyldig kontonummer

6. Kontrollsiffer? • Vi har kontrollsiffer i kontonummer, i KID-koder, ISBN- og varenummer, og i personnummer (de to siste sifrene her). • Hva er poenget med disse? • Trenger vi kontrollsiffer i dag?

7. Uheldig (2) • Det er 10 siffer i kontonummeret, pluss kontrollsiffer • Dette gir 10 milliarder mulige kontonummer • Bare en liten del er i bruk • Derfor er det lite sannsynlig at et feil nummer gir en eksisterende konto (noe avhengig hvor i kontonummeret feilen gjøres) • I Fossbakk’s tilfelle resulterte feiltastingen i et kontonummer som var i bruk

8. Uheldig (3) • Pengene gikk til en uføretrygdet person • Som brukte opp nesten 400.000 på spill i løpet av en uke • Ikke praktisk mulig å få noe tilbake her • Men personen som bruke pengene fikk fengselsstraff • Du er uheldig om du treffer på en kontoeier som dette i et land som Norge

9. Problem • Banken hevdet at dette er Fossbakk’s feil • De ville ikke erstatte tapet

10. Hva gjør en bankkunde nå? • Aksepterer tapet – 400.000 kroner er mange penger for de fleste • Men en kan klage til bankklagenemda • Denne skal ta seg av konflikter mellom forbrukere og banker • Her sitter 5 representanter: • To som representerer bankene • To som representerer forbrukerne • En formann

11. Hva skjedde her • Fossbakk tapte • Hun fikk to stemmer fra forbrukerrepresentantene • Hun fikk to stemmer imot fra bankrepresentantene • Formannen, en professor i jus, stemte med bankene • Derfor tapte hun

12. Begrunnelse • Leder jusprofessor Viggo Hagstrøm mener Bankklagenemnda ikke hadde noen annen mulighet, etter som lovverket ikke sier noe om ansvarsbegrensning når bankkunder gjøre feil i nettbanken. • ”Det er vanskelig å se at det er noe feil med systemet. Det er like feil å slå inn feil nummer som et nummer for mye. Det gjorde ikke noe fra eller til for avgjørelsen”, sier Hagstrøm • Det burde vært en grense for hvor stort ansvar forbrukeren skal ta for egne feil, men lovgiveren har altså ikke sagt noe om det, og da kan ikke vi endre det, sier Hagstrøm.

13. Flertallet • Fokuserer altså på erstatningsdelen av jussen • Ikke på hvilken feil brukeren eller eventuelt banken har gjort

14. Stor mediaomtale

15. Rettssak • Fossbakk med støtte av Forbrukerrådet gikk til sak mot banken (Sparebank 1 Nord-Norge) • Forbrukerrådet er viktig her. I Norge kan en risikere å måtte betale saksaomkostninger om en taper – også motpartens! Derfor er det stor risiko for privatpersoner å gå til sak. • Saken skulle opp våren 2008 • Undertegnede ble bedt av Forbrukerrådet om å stille som ekspertvitne • Det store spørsmålet blir

16. Hvem har ansvaret? • Banken eller • Kunden

17. Banken hevdet at • At det ikke er bevis for at hun tastet et siffer for mye • At hun godkjente den endelige giroen • Fossbakk må ta konsekvensen av egne feil (og banken har altså fått støtte av dette i klagenemnda)

18. Skal Fossbakk vinne fram • Må vi plukke fra hverandre bankens argumentasjon • For å få til dette kan vi argumentere • Men helst bør vi ha håndfaste data • La oss se på argumentene igjen:

19. Banken hevder at • At det ikke er bevis for at hun tastet et siffer for mye • At hun godkjente den endelige giroen • Fossbakk må ta konsekvensen av egne feil (og banken har altså fått støtte av dette i klagenemnda)

20. Et siffer for mye (1) • Fossbakk tastet 705815555022, men systemet registrerte kun 70581555502 • Kan vi bevise at hun tastet 12 siffer? • I grensesnittet ble alle siffer ut over 11 ignorert. Det eksisterer derfor ingen logg-informasjon. • (Kanskje litt frekt av banken å komme med dette argumentet, når deres system ikke har logget det som skjedde) • Dette er av vesentlig betydning, har hun tastet 11 siffer er det åpenbart hun som har gjort feil, har hun tastet 12 er saken etter min mening helt annerledes (lederen for klagenemnda mener derimot ikke det)

21. Sannsynlighet (1) • Hun har gjort en feil om hun tastet et siffer for mye (et ekstra 5-tall) • Men må ha gjort to feil om hun likevel tastet 11 siffer (et 5 tall for mye, utelatt et 2-tall på slutten) • Det er åpenbart lettere å gjøre en feil enn to • Men det er vanskelig å regne på sannsynligheter her • Men en test kan gi interessante data

22. En banksimulator • Vi utviklet et datasystem som simulerte bankens Web-system • Men dette registrerte også alt som ble gjort, inntasting, feil, tider brukt, m.m. • Vi hentet inn: • En skoleklasse fra Molde Videregående • En fra Romsdal Videregående (også i Molde) • Studenter fra Høgskolen • i alt 69 personer

23. Inndata • Datasettet ble presentert på papir, i alt 30 giroer. • Hver testperson tastet inn alle disse. Det ble 1778 giroer tilsammen (etter at vi fjernet noen “outlayers”) • Hver giro besto av kontonummer, KID eller melding, dato og beløp. • Siden vi var spesielt interessert i kontonummer med flere like siffer i sekvens, hadde vi mange av disse i datagrunnlaget.

24. Simulatoren • Identisk til det Grete Fossbakk brukte (Sparebank 1 og mange andre banker)

25. Resultater *) Vi har ekskludert feil der det ble tastet fra galt datasett

26. Feiltype - kontonummer

27. Forkortning er farlig • Når et for langt kontonummer blir kortet ned til 11 siffer vil dette bli det riktige kontonummeret i 2 av 3 tilfeller (en gjør ofte feil på slutten) • Modulo 11 testen (kontrollsiffer) tar de fleste av de resterende • Men i testen slapp 3 giroer (0.2%) forbi denne testen

28. Testen viser at • Dersom en taster et siffer for mye i en sekvens • Ender en nesten alltid opp med et kontonummer som er for langt • Vi kan da vise, med meget stor sannsynlighet, at Fossbakk har tastet et 12 sifret kontonummer • Sannsynligheten for at hun i stedet gjorde to feil er marginal

29. Banken hevder at • At det ikke er bevis for at hun tastet et siffer for mye • At hun godkjente den endelige giroen • Fossbakk må ta konsekvensen av egne feil (og banken har fått støtte av dette i klagenemda)

30. Godkjenning 97101112345

31. Godkjenning • 88 studenter godkjente transaksjonen – til tross for at de hadde tastet galt kontonummer • I tillegg, for tre transaksjoner av de tretti, fikset (den sleipe) simulatoren det inntastede kontonummeret til ett som lignet – selv om det var tastet rett! • Dette ble gjort i 178 tilfeller • I bare 5 av disse 178 tilfellene (3 %) ble dette oppdaget av brukeren

32. Testen viser at • Godkjenning er ingen sikkerhet mot feil • Vi ”godkjenner” det vi har tastet inn • Også annen forskning understøtter dette.

33. Banken hevdet at • At det ikke er bevis for at hun tastet et siffer for mye • At hun godkjente den endelige giroen • Fossbakk må ta konsekvensen av egne feil (og banken har fått støtte av dette i klagenemnda)

34. Hvem har gjort feil (3) • Fossbakk har åpenbart gjort en feil • Hun har tastet 12 siffer • …og må ta ansvaret for det! • Men banken har også gjort en feil • De har endret det inntastede kontonummeret, fra 12 til 11 siffer • …og må ta ansvaret for det!

35. Konsekvensen av feil (3) • Fossbakks feil skulle medføre at hun skulle få en feilmelding • Konsekvensen av det skulle være at hun måtte rette opp nummeret

36. Konsekvensen av feil (3) • Bankens feil, å endre et 12 sifret nummer til et 11 sifret, medfører at 500.000 kroner gikk til feil konto • Det er da rimelig at banken tar konsekvensen av dette, og erstatte beløpet • Vi ser dette klart om vi overfører problemstillingen til den fysiske verden: Vi skriver et brev til banken og ber de overføre 500.000 kroner til et ugyldig 12-sifret kontonummer. Hva gjør funksjonæren?

37. I tillegg - Grov uaktsomhet? • Banken har aldri brukertestet det grensesnittet de brukte (og som hele Sparebank 1 gruppen og andre banker benyttet) • De visste ikke engang hva en brukertest er • Da vi spurte om brukertester svarte de at de hadde gjennomført en spørreundersøkelse • Ja visst, vi finner spørreundersøkelser under brukertesting på Wikipedia – men da under kapittelet om hva brukertester ikke er!

38. Hva skjedde? • Banken kastet inn håndkleet to dager før saken skulle opp i retten • Fossbakk fikk erstatning for det tapte beløpet, inklusive renter • Fossbakk, Forbrukerrådet og Sparebank 1 Nord-Norge gjorde en avtale • Men som professor er jeg ikke bundet av denne (som dere ser i dag)

39. Er dette viktig? • 500.000 kroner er et stort beløp. • Men saken gjelder langt mer enn dette! • Hva når dårlige systemer fører til at: • Pasienten får dobbel dose av smertestillende på sykehuset og dør av det • Flygelederen misoppfatter situasjonen og fly kolliderer • Banksystemet, strømnettet eller mobilnettet faller ut fordi noen utfører en gal operasjon • … • Derfor er denne Fossbakk-saken en viktig prinsippsak

40. Mer informasjon • Inntasting i nettbank, arbeidsrapport, Høgskolen i Molde, 28.02.2008 • A $100,000 Keying Error, IEEE Computer, April 2008 • Kronikk/debatt i Aftenposten (08.04.08)

41. Hva kan vi lære? Ha respekt for brukerne, se systemene fra deres synspunkt. Bruk gode metoder for å utvikle bruker-grensesnitt (feilen her er velkjent og burde vært unngått) Test systemene på vanlige brukere (feilen her ville en oppdaget svært fort i en test) Gi gode muligheter for feedback (helst til en ”ombudsmann” for brukerne, ikke til IT avdelingen)

42. Case 2: ESS (Employee Self Service) SAP for statsansatte

43. ESS

44. 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 • ESS brukes av mange – her ser vi altså på den tilpassningen som er gjort av Direktoratet for Økonomistyring

45. Idé • Ansatte skal gjøre noe av det administrasjonen gjør i dag • Dette kan være effektiviserende – bedre effisient (vi kan gjøre jobben med færre ressurser) • . Forutsetningen er: • Tidsbesparelse: Ansatte bruker mindre tid på å gjøre dette selv enn hva administrasjonen brukte (ellers er det bare snakk om å flytte oppgaver mellom personer). Vi kan fjerne mellommenn. • og/eller • Kvalitetsheving: Ansatte kan få enklere tilgang til viktig informasjon enn det de hadde tidligere

46. Evaluering • Vi skal her gi en kort uformell evaluering av ESS • 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 • NB! Noen av feilene påpekt her er forsøkt rettet opp i senere versjoner – uten at dette påvirker helheten. • I tillegg: Første versjon av et system er kritisk! • Hvorfor?

47. Første 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

48. Feil: Opplæring • Systemet krever to timers opplæringskurs for 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å oppfriskingskurs? • Systemet brukes for enkle administrative oppgaver og burde vært intuitivt i bruk

49. 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

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