En viktig komponent för att lyckas med ett IT system är fokus på användbarheten. Ett Agilt kontrakt är ett sätt att formalisera detta. Oavsett kontraktsform kan man ställa sig frågan: kan jag kravställa användbarhet? Svaret är ja – både i offentlig och privat upphandling. Vi har intervjuat Clas Thorén, som berättar vad man bör tänka på.
Clas har arbetat som upphandlare i många år och är användbarhetsspecialist vid upphandlingar. Clas är medförfattare till ”Att beställa användbara it-system” som beskriver ett antal upphandlingscase som haft användbarhet i fokus, bland annat Ekonomistyrningsverket (ESV) .
Varför är det viktigt med användbarhet i upphandlingar?
Clas: Effekten uppstår ju hos användaren. Därför är det viktigt att kunna förstå, beskriva och följa upp användbarhetsmål vid upphandling av IT system, i både offentlig och privat sektor. Låt oss kika på steget genom en upphandling och vad man bör tänka på ang. användbarhet genom alla steg:
- Effektmål
- Behovsanalys (verksamhetens och slutanvändarnas behov)
- Marknadsanalys
- Upphandlingsunderlag
- Anbud
- Förhandling
- Kontraktskrivning
- Uppföljning
1. Effektmål
Det viktigast i att börja med är att beskriva effektmålet, vad det är man vill åstadkomma. Den teknik vi implementerar skall ju användas av någon, och det är deras nytta vi vill åt. Utmaningen i detta steg är att undvika bli lösnings och teknikfokuserad, dvs att att sätta som mål att ”implementera lösning X”.
Exempel på effektmål:
- ”90% av anställda skall klara av uppgiften inom 3 minuter.”
- ”Medborgare skall kunna sköta 80% av sina åläggande själva på internet , utan direkt involvering av myndighetens personal ”
Effektmålet är med fördel mätbart.
2. Behovsanalys
I i behovsanalysen (kallas ofta förstudie) försöker vi förstå
a) Vad användarnas behov, och,
b) Vad behöver vi förändra i verksamheten, för att nå effektmålet
Utmaningen i förstudien är att öppna upp för att vi kan behöva förändra processer och rutiner i verksamheten likväl som lösningen för att nå vårt mål. Kanske behövs speciell träning för att användarna skall kunna bruka lösningen. En central skillnad mellan en upphandling som vänder sig till medborgare och anställda är att vi inte råder över medborgarna. Vi kan tex. inte skicka dem på utbildning. Det betyder att vi måste vara än mer nogrannare för att se till att den tjänst vi utvecklar verkligen är lättanvänd och tillgänglig för flera olika målgrupper.
Förstudien är ett samarbete mellan upphandlingansvarig och verksamheten. Exempel på metoder som är användbara i denna fas är:
- Intervjuer
- Enkäter
- Fokusgrupper
- Observationer av användare i deras naturliga miljö
Tips: Du måste inte vara en expert för att klara detta. Hur du kan samla in behov finns beskrivet i standarden ISO 9241-210.
3. Marknadsanalys
Målet med marknadsanalysen är att titta utåt. Vad finns det för tjänster och produkter som kan passa?
En jämförelse är om du skall köpa kläder, tex. byxor. Efter att ha hittat några alternativ, scannat dem i Råd och Rön är det dags att prova. Det är först då du får en indikation om de kan passa.
OBS: Du bryter inte mot någon lag när du gör en marknadsanalys. Du får prata med aktörer på marknaden för att förstå vad som finns. Att, under ordnade former, få en uppfattning om leverantörernas erbjudanden är kompatibelt med LOU. Nyckeln är att det sker objektivt och att leverantörerna behandlas likvärdigt. Kammarkollegiet är ett exempel. Inför ramavtalsupphandlingar frågar man:
- Berörda myndigheter (era erfarenheter från förra ramavtalet, vad fungerade?)
- Leverantörer ( vilka tjänster använde kunderna?)
Informationen görs sedan transparent till alla intresserade parter genom publikation på kammarkollegiets webbplats.
Det finns ett antal enkla indikatorer som kan användas för att syna leverantörernas användbarhetsmognad. Tex. har leverantörerna har någon policy om användbarhet, har de en organisatorisk enhet som ansvarar för användarvänlighet i sina produkter och tjänster, alternativt – har de relation till ett konsultföretag som hjälper dem i de fall de inte besitter egen expertkunskap.
4. Upphandlingsunderlag
När den regelrätta upphandlingen påbörjas är det viktigt att tänka på två saker. Det ena är att formulera användbarhetsbehoven som krav i upphandlingssunderlaget, dvs som ”skall” eller ”bör” krav. Dessa ska avspegla de behov som kommit fram i förstudien. Det andra är att beskriva processen för utvärderingen av användbarhet, hur den kommer att göras. Pss kan leverantörerna se att metoden är transparent, likabehandlande och objektiv. Leverantörerna kan använda denna för att ”testa sig själva” innan de svarar på upphandlingen.
En viktig notis om du önskar hänvisa till standarder i din upphandling, så måste standardens beteckning åtföljas av orden ”eller likvärdig”. När det gäller hänvisning till specifikationer som inte är regelrätta standarder såsom tex miljömärkning eller en TCO bildskärmscertifiering – får du inte ställa ett direkt krav ”produkten ska vara TCO-certifierad” . Vad du kan göra är att räkna upp de kraven i specifikationen som är relevanta för dig. Men i samband med att dessa beskrivs kan du påpeka att ”om du är (TCO certifierad) uppfyller du dessa”. Syftet är att möjliggöra för leverantörer som är kompatibla dina önskemål , men ännu inte gjort certifieringen, att kunna delta.
Exempel på betygssättning från Ekonomistyrningsverket (ESV). Ref. ”Att beställare användbara it-system”.
5. Anbud
Eftersom vi redan har beskrivet de användarmässiga kraven samt utvärdringsmetoden är allt vi behöver gör att kontrollera att skallkraven uppfyllts i anbuden och utvärdera hur börkraven uppfylls. Med fördel görs det senare med riktiga användare involverade. Det finns en grupp av standarder som är under utveckling och som beskriver hur man formulerar användbarhetskrav, hur man utvärderar användbarhet och hur man dokumenterar utvärderingen. Standardernas gemensamma gruppnamn är SQuaRE.
6. Förhandling
Enligt LOU får man förhandla endast under vissa omständigheter. Före LOU var detta ett naturligt inslag i en upphandling.
7. Kontrakt
Här vill vi att de användarvänliga kraven blir en del av kontraktet. Det är också viktigt att i kontrakten referera till det leverantören sagt sig uppfylla i sitt anbud.
Ett tips som förenklar uppföljningen är att i kontraktet att beskriva mätetal som leverantören åläggs följa upp och rapportera. Tex. tiden det tar att diarieföra ärenden. Pss kan användbarheten följas upp pss. som ett SLA (service level agreement) för en driftstjänst.
8. Uppföljning
Uppföljning är en löpande kontroll att kraven uppfylls. Det är vanligt att upphandlaren får ta på sig det arbetet men det bör hellre göras av en annan person, en avtalsansvarig (verksamhetsperson). Använd samma utvärderingsmetod som stipulerats i upphandlingsunderlaget.
Om uppföljning är svårt att få till pga att verksamhetspersonerna är upptagna kan detta ske med hjälp av extern expertis.
Standarder är din vän
Jag har valt att peka på ett antal standarder i respektive steg som är hjälpsamma. Du väljer såklart om du vill använda dem. Fördelen är att de representerar internationella överenskommelser och visar hur du kan göra respektive steg objektivt. De hjälper dig att komma igång även om du inte är expert på ämnet. En standard gör att vi kan fokusera på rätt sak genom att beskriver vad vi inte väljer att konkurrera om.
Några slutgiltiga råd?
Två saker:
- Glöm inte effektmålen
- Var inte rädd för att utveckla dessa, och dina behov iterativt.
Där stannar vi denna gång. Tack Clas för att vi får ta del dina tips och dina råd.
Referenser
ISO 9241-210 ”Human-centred design for interactive systems”
Provides requirements and recommendations for human-centred design principles and activities throughout the life cycle of computer-based interactive systems. It is intended to be used by those managing design processes, and is concerned with ways in which both hardware and software components of interactive systems can enhance human–system interaction.
Software product Quality Requirements and Evaluation (SQuaRE)” – en familj som infattar bla. ISO/IEC 25062:2006
Provides a standard method for reporting usability test findings. The format is designed for reporting results of formal usability tests in which quantitative measurements were collected, and is particularly appropriate for summative/comparative testing.