Så kallade standardsystem, som exempelvis SAP R3 eller Oracle Applications, blir allt vanligare när det gäller IT för stödprocesser som exempelvis ekonomi. Ett standardsystem är ett slags halvfabrikat, en låda med byggklossar, med hjälp av vilka en leverantör kan sätta ihop en produkt som kunden kan använda.
På ett releaseparty för boken Användbarhet i praktiken fick vi frågan om inte det faktum att standardsystem blir allt vanligare innebär döden för användbarhetsområdet. Tyvärr kom vi inte på något riktigt bra svar förrän tillställningen var över. Det korta svaret är "Nej, tvärtom". Det långa svaret hittar du nedan.
"Standardsystem, de måste väl innebära döden för användbarhet?"
Frågan visar på två felaktiga uppfattningar om användbarhet:
- att användbarhet endast handlar om det visuella, exempelvis placering av knappar och val av färger i användargränssnittet.
- att standardsystemen bygger på "best practice" inom sitt område och det innebär att de kommer fungera bra i vilken ekonomiverksamhet som helst.
"Vårt system är användarvänligt"
Kanske är det så att det är användarvänligt. Det beror ju på hur man definierar begreppet användarvänligt. Det man bör fråga sig är om systemet går att använda, är det användbart? En produkt har hög användbarhet om den uppfyller kundens och användarnas syften. En produkts användbarhet visar sig i samspelet mellan produkten och dess användare och över en tidsperiod – kort sagt: i användning. Användbarhet är således en kvalitetsegenskap hos interaktiva produkter.
Detta innebär också att användbarhet inte är en objektivt observerbar, inneboende produktegenskap, så som en färg eller en funktion. Användbarhet är istället en egenskap som uppstår när den används. Ingen produkt, inte ens SAP R3, har "hög användbarhet" (eller "är användarvänlig" som är det ord som används oftast i sälj-jargongen). Däremot kan det mycket väl finnas installationer av SAP R3 som har hög användbarhet, trots att det kan vara svårt att tro när man läser exempelvis Computer Sweden.
"Vårt system passar alla"
Både tillverkare och leverantörer av standardsystem framhåller argument som "alla ekonomifunktioner liknar varandra, därför kan vi ekonomiverksamheten också hos er". Detta är helt naturligt eftersom det är en av grundidéerna med standardsystem: att finna det som är generellt och återanvändbart. Däremot blir det lite farligt då tillverkaren slår sig för bröstet och kallar det sätt på vilket ekonomiprocesserna implementerats i just deras produkt för "best practice"*. Inte nog med att det är förmätet, det förmedlar dessutom ett budskap till kunden att om inte standardsystemet passar så följer företaget inte ett vedertaget arbetssätt.
Naturligtvis har ekonomifunktioner på olika företag stora likheter med varandra genom att vissa av deras arbetsuppgifter är reglerade i lag (t.ex. bokföringslagen), men för att uppnå de syften som kunden har med sin investering, och för att säkerställa att användaren faktiskt kan arbeta på ett effektivt sätt krävs ett större mått av respekt mot användarnas arbetssätt och arbetssituation. Kommer systemet att fungera bra i praktiken?
Exempel från modul för fakturaregistrering
på ett medelstort företag:
Registreringen av en faktura gjordes i en dialogbild där ett femtiotal olika kolumner fanns upplagda horisontellt, ungefär som ett par rader ur ett kalkylark. På grund av rådande begränsningar i skärmstorlek och upplösning visades endast ett 10-tal av dessa kolumner på skärmen samtidigt. Problemet var att de kolumner som användaren var tvungen att fylla i när hon registrerar en faktura finns på position 1, 2, 7, 37, 38, 39, 16, och 41. Detta innebär att användaren får fylla i tre av de fält som visas. Därefter måste hon scrolla i horisontal-led och fylla i 37, 38 och 39. Sedan måste hon gå tillbaka och fylla i kolumn 16, för att slutligen förflytta sig till kolumn 41 och mata in den sista uppgiften.
Trots den lätt bisarra situationen i exemplet ovan är det i högsta grad ett litet och oansenligt exempel på problem som kan orsakas om standardsystem installeras utan anpassning till företagets arbetssätt, men det visar ändå på vilka besparingar som är möjliga att göra. Om leverantören brytt sig om att göra en kartläggning av hur de som registrerade fakturorna faktiskt arbetar och därefter ändrat ordningen på inmatningsfälten hade den tid som går åt för att registrera en faktura halverats, och det utan extra utvecklingskostnad.
Så... vad innebär detta för användbarhetsområdet?
Standardsystem blir allt vanligare, men de innebär inte döden för användbarhet. Bilden av att man bara kan "skruva in" ett standardsystem utan att göra någon kartläggning över hur användarna arbetar, och anpassa systemet därefter, är en grov förenkling av verkligheten.
För den som är intresserad av att fortsätta arbeta med användbarhet på samma sätt som tidigare innebär förskjutningen mot standardsystem ingenting. Det krävs fortfarande ordentliga kartläggningar av både kundens syften med sin investering och användarnas arbetssätt och situation. Likaså krävs det ordentliga specifikationer i form av en interaktionsdesign.
För den som är intresserad av att hitta nya sätt att arbeta med användbarhet innebär förskjutningen en hel del. Behovet av användbarhetskompetens på kundens sida blir allt tydligare. Genom att ta in användbarhetskompetens får hon hjälp med att ställa de krav som är nödvändiga för att investeringen skall få avsedd effekt.
Sluligen: användbarhetsexperter behövs hos dem som tillverkar standardsystem, hos dem som levererar dem, och, kanske viktigast, hos dem som beställer dem. Standardsystem innebär inte döden för användbarhet, utan en fantastisk möjlighet i vilken många användbarhetsexperter kommer att byta sida och sätta sig hos kunden istället för hos leverantören.
Dags att byta sida?
Johan Berndtsson, inUse AB
johan.berndtsson@inuse.se
Är det dags att byta sida? Kommentera kolumnen
Utvikning om Best Practice
Vid en närmare undersökning finns det dock sällan mer än luft bakom detta begrepp. Naturligtvis är det så att en "best practice" måste vara hämtad från installationer med snarlika förhållanden för att den skall säga något - och så är sällan fallet. Skillnader som att en sekreterare i Estland endast tjänar en femtedel av vad en i Sverige tjänar kan ha stor påverkan på var man lägger resurserna i ett utvecklingsprojekt. Om kostnaden för att genomföra tidsbesparande förbättringar av systemet överstiger kostnaden för den extra lön som arbetsgivaren behöver betala ut på grund av verktygets ineffektivitet finns det ingen anledning att genomföra förbättringarna. Hur hittar man en "best practice" för ekonomisystem när de referensinstallationer som ingår i undersökningen spänner över exempelvis länder eller branscher med stora skillnader?
© Johan Berndtsson & Design after Thought 2002.
Publicerad 2002-11-20, uppdaterad
2006-11-12
|
|
Johan Berndtsson är konsult på inUse AB och en av författarna till boken Användbarhet i praktiken
Läs också
Anvandbar.nu Webbplats om boken Användbarhet i praktiken
Köp boken från Adlibris eller Bokus
Myter om användbarhet
Flera designeftertankar
Designeftertankar är texter om interaktionsdesign, användbarhetsarbete och närliggande
områden.
Vill du veta när nya designeftertankar publiceras?
Ja tack!
Nja, berätta mer först.
Vill du skriva en gästeftertanke?
Hör av dig
|