På kornet - texter om användbarhet, interaktionsdesign, informationsarkitektur på webb och Internet
Korn av sanning
Artiklar
och essäer
Guldkorn
Böcker,
musik, sajter
Blind höna

Webblogg
Skrot & korn
Portfolio
och passioner
Väderkorn
Sakregister
och sökning

 

Så mycket kostar en användbarhetsmiss

Dålig mjukvara kostar pengar - till exempel genom att arbetsuppgifter tar onödigt lång tid, eller genom onödigt höga utbildningskostnader.

Men bara sällan går det - som i det här fallet - att exakt säga vilka kostnader ett visst program har orsakat genom missar i funktion eller användbarhet:

En konsultfirma använder ett kombinerat system för tidsredovisning och fakturering. Det är ett stort, databasdrivet system, som kostar gott och väl över en miljon kronor.

Konsulterna för in sin arbetade tid i systemet, lägger till ett projekt-ID, och systemet sammanställer kundernas fakturor.

Nu finns det förstås också andra saker företaget gör för sina kunders räkning. Köper in mjukvara och ibland hårdvara. Betalar flygbiljetter och andra resekostnader. Tar in underkonsulter. Alla sådana kostnader ska matas in i systemet och till slut hamna på kundens faktura.

Projektledaren som har ett kvitto, en biljett eller en faktura skriver projektets ID-nummer på den och lämnar den till ekonomiavdelningen. Ekonomiavdelningen skriver in den i systemet under rubriken "Projektkostnader" tillsammans med ID-numret. Det antas nu att beloppet därför också förs upp på nästa projektfakturan, när den skapas.

Efter att systemet använts i nästan ett år visar sig detta vara fel.

   
På denna sida:
Gå till Extrakostnad: en kvarts miljon
Gå till Fel utvecklings- modell ger problem
Gå till Kunniga användare blev lurade
Gå till Relaterade länkar

 

Extrakostnad: en kvarts miljon
När en kostnad skrivs in som projektkostnad, förs den bara in i bokföringen som en leverantörsskuld. Det finns inget sätt att få faktureringsdelen av programmet att registrera samma belopp och ID-nummer. Varje faktura, och dess data, måste därför skrivas in två gånger: en gång för bokföringen, en gång för kundfaktureringen.

En konsultfirma kan visserligen ha en del kostnader, som en kund inte ska betala. Men i princip ska ju kunden alltid betala, när kostnaden är en del av ett projekt. (Andra kostnader tas upp på andra ställen, inte som projekt.) Något så enkelt som en kryssruta i inmatnings-gränssnittet skulle ha löst problemet: "Lägg till i projektfakturering: Ja/Nej" (med Ja som det förvalda alternativet).

Vad var då kostnaden? När det upptäcktes att projektkostnaderna inte registrerades i projekten, började man leta i systemet. Efter en första genomgång hittade man ackumulerade kostnader, som inte fakturerats på kund, på cirka en kvarts miljon - en rätt stor kostnad i förhållande till omsättningen. Den exakta summan är inte känd; den kan vara högre. Eftersom en del av kostnaderna är ganska gamla, och projekten avslutade, kan det bli svårt att få in pengarna.

Till det exakta beloppet kan man förstås också lägga de mer svårbestämda kostnaderna för sämre kundrelationer och minskat förtroende för företaget.

    Gå tillSidans topp

 

Fel utvecklingsmodell ger problem
Det förefaller mig, som om programmets utformning kan bero på att det utvecklats med en uppgifts-styrd (engelska task-driven) utvecklingsmodell.

I en sådan försöker man identifiera de minsta, logiskt skilda arbetsuppgifter, som ett datasystem ska kunna utföra eller hjälpa till med. Utvecklarna kan sedan få i uppdrag att skapa sådana avgränsade moduler. Indelningen i uppgifter kan man hämta från en lärobok, manual eller teoretisk analys av området.

Det är en praktisk metod - för den som ska skriva kod. Men den är en av de möjliga orsakerna bakom dåligt fungerande datorsystem.

Det är två saker som man riskerar att glömma bort i en sådan process.
  1. För det första helheten: hur olika uppgifter hänger ihop, hur de förutsätter, utesluter eller kompletterar varandra, och vilka som är vanliga och vilka som är sällsynta.
  2. För det andra: att det sätt verkliga människor utför ett arbete mycket sällan stämmer med hur det står i manualer, läroböcker eller teoretiska analyser att de ska eller borde göras.
Att skapa en faktura är ur ett logiskt perspektiv givetvis en helt annan uppgift än att föra in en kostnad i bokföringen.

Men med en utvecklingsmodell där man med dels etnografiska metoder försöker kartlägga vad användarna verkligen gör, när de jobbar; dels fokuserar på helheten, vad människor har för övergripande mål med sitt arbete - (det som Alan Cooper kallar "mål-styrd design) är chansen stor att man tidigt skulle upptäckt hur nära besläktade dessa uppgifter var.

    Gå tillSidans topp

 

Kunniga användare blev lurade
Borde inte någon mycket tidigare ha märkt att utlägg och kostnader inte fanns med på fakturorna? Det kan man förstås tycka, men två saker tror jag förhindrade deta.

Dels är fakturaspecifikationerna mycket svårlästa. Layouten är komplicerad, och en normal specifikation kan innehålla många hundra rader med belopp, tider och koder.

Men dels - och viktigast - tror jag det är att de som handskas med systemet är mycket datorvana. De vet mycket väl att en av de främsta poängerna med databaslösningar är att man ska slippa skriva in samma data flera gånger. Därför verkar det så orimligt att man måste göra det i detta system. Varför då lusläsa de krångliga specifikationerna för att hitta något man var övertygad om fanns där?

Hade användarna varit mindre vana - och mer skeptiska - hade de förmodligen inte tagit för givet att kostnaderna också fakturerades ut "automatiskt". Någon hade långt tidigare faktiskt granskat en faktura och upptäckt att t.ex. inga resekostnader fanns med.
   
Relaterade artiklar
på kornet:
Gå tillNågon på Åhléns
bör söka till Stjärnflottan


Gå tillKlibbighet - eller hur man får en flygresenär att känna sig som en idiot

Andra webbplatser:
Gå tillwww.
cooper.com


Gå tillLO:s rapport om IT-användningen (pdf)

 

Jonas Söderström

9 oktober 2001

   

 

Gå tillSidans topp
     
>> Synpunkter? Skicka ett mail med länken ovan.<<
     

 


På kornet  |  Korn av sanning  |  Guldkorn  |  Blind höna  |  Skrot och korn  |  Väderkorn