Utvärderingsmodell för programvara: så väger ni kriterier mot varandra

Syftet med utvärderingen bestämmer vikterna

Vikter är inte neutrala. De visar vad ni anser vara viktigast och bör därför härledas ur utvärderingens syfte, inte sättas efter vad som är enkelt att mäta. Myndigheten för samhällsskydd och beredskap (MSB) beskriver att utvärderingar inom myndigheten utförs med ett lärande och förbättrande syfte – en hållning som fungerar även när ni utvärderar programvara.

I offentlig verksamhet samsas ofta flera syften: att lära och förbättra, att välja mellan alternativ, att följa upp en upphandling eller att visa resultat för en politisk nivå. Att ansatsen behöver anpassas till det som ska utvärderas illustreras av Regeringsuppdraget till Statens skolverk, där myndigheten bland annat ska föreslå vilken typ av utvärdering som bäst lämpar sig för olika reformer och föreslå lämpliga aktörer för genomförandet. Samma logik gäller programvara: är syftet lärande blir vikterna ett sätt att rikta uppmärksamheten mot det ni vill utveckla, medan ett renodlat urvalssyfte kräver vikter som skiljer alternativen åt.

Skriv därför ned syftet med utvärderingen i en eller ett par meningar innan ni börjar vikta, och låt varje vikt kunna kopplas till det syftet. En vikt som inte går att motivera utifrån syftet är sannolikt ett uttryck för tradition eller tyckande snarare än för behov.

Vilken typ av programvara är det egentligen?

Alla programvaror bör inte viktas på samma sätt. Ett medicinskt beslutsstöd styrs av andra krav än ett ärendehanteringssystem eller ett internt statistikverktyg. Kunskapsstyrning i vård och omsorg har tagit fram en vägledning om beslutsstöd i regionala och nationella kvalitetsregister som tydliggör vilka programvaror som utgör medicinska beslutsstöd eller annan programvara. En sådan avgränsning är en rimlig första övning även lokalt.

Läkemedelsverket beskriver att medicinteknisk programvara till exempel ska vara CE-märkt, om den inte egentillverkas inom en hälso- och sjukvårdsinstitution. Sådana egenskaper väger ni inte mot andra egenskaper – de är krav som måste vara uppfyllda för att alternativet ska vara aktuellt över huvud taget.

För leverantörer av samhällsviktiga och digitala tjänster finns dessutom krav på säkerhetsåtgärder och incidentrapportering. I lagrådsremissen om informationssäkerhet för samhällsviktiga och digitala tjänster, som genomför NIS-direktivet, anges sektorerna energi, transport, bankverksamhet, finansmarknadsinfrastruktur, hälso- och sjukvård, leverans och distribution av dricksvatten samt digital infrastruktur. Används programvaran i en sådan tjänst påverkar det vilka kriterier som blir trösklar och vilka som kan betygsättas.

Klargör därför tidigt: användningsområde, vilka som använder programvaran, vilken information den hanterar, vilka regelverk som är tillämpliga och vem som äger frågan i organisationen. Det avgör vilka kriterier som är relevanta – innan ni diskuterar hur tungt de ska väga.

Relevanta regelverk för programvara i svensk offentlig sektor

Helhetsbild och samverkan motverkar stuprörsviktning

En viktning som bara utgår från den egna förvaltningens behov riskerar att bli ett stuprör. Digg rekommenderar svenskt ramverk för digital samverkan och lyfter att en offentlig aktör behöver stärka sin förmåga att se och agera utifrån ett helhetsperspektiv och skapa större samlad samhällsnytta – att göra rätt saker på rätt sätt, oavsett om det sker enskilt eller i samverkan med andra.

Omsätt det i kriterier. Exempel på samverkansrelaterade kriterier är förmåga till informationsutbyte och interoperabilitet, stöd för gemensamma begrepp och standarder, möjlighet att dela tjänster eller komponenter med andra aktörer samt långsiktig förvaltning och dokumenterad exitstrategi. Sådana kriterier blir sällan tunga om ingen aktivt för dem in i modellen.

En praktisk tumregel är att avsätta en uttalad andel av vikten åt samverkansrelaterade kriterier och att redovisa den andelen separat, så att den inte tystas ned av verksamhetsspecifika önskemål. Andelen bör motiveras utifrån utvärderingens syfte och hur beroende er verksamhet är av andra aktörer.

Samverkansrelaterade kriterier i programvaruutvärdering

Fördela vikter mellan kriterier i praktiken

Arbeta i tydliga steg. Börja med att skilja ut tröskelkriterierna: krav som måste vara uppfyllda för att alternativet ska komma i fråga, till exempel lagkrav, grundläggande informationssäkerhet, tillgänglighetskrav, nödvändiga integrationer mot befintliga system eller krav på support och avtal. Trösklar betygsätts inte och ges ingen vikt – de är antingen uppfyllda eller inte.

Betygsätt därefter de kriterier som kan variera i kvalitet mellan alternativen. Bestäm en betygsskala och vad varje nivå betyder, så att bedömarna tolkar skalan likadant. Slå ihop eller stryk kriterier som mäter ungefär samma sak; en lång lista gör vikterna svåra att tolka och ökar risken för dubbelräkning.

Sätt sedan relativa vikter som summerar till 100 procent över de betygsatta kriterierna. Bestäm också hur kriterierna får kompensera varandra: får ett högt betyg på ett kriterium väga upp ett lågt på ett annat, eller finns kriterier där ett svagt resultat inte kan kompenseras? Ett vanligt grepp är att sätta ett minimikrav per kriterium vid sidan av vikterna. Beräkningen blir då vikt multiplicerat med betyg, summerat över kriterierna.

Dokumentera motiveringen bakom varje vikt: vilket syfte vikten tjänar, vilket behov den speglar och vem som företräder behovet. Det är den dokumentationen som gör viktningen granskningsbar i efterhand.

Förankra vikterna hos dem som berörs

Vikter som satts av en enskild grupp blir sällan accepterade och speglar sällan hela verksamheten. Ett offentligt exempel på hur förankring beskrivs finns i regeringsuppdraget till Statens skolverk: myndigheten ska i samtliga delar av uppdraget aktivt involvera arbetsgivarorganisationer, huvudmannaorganisationer, fackliga organisationer, elevorganisationer samt andra relevanta aktörer i syfte att säkerställa den förankring som krävs, och berörda aktörers erfarenheter och perspektiv ska tas om hand i arbetet.

Översatt till programvaruutvärdering innebär det att involvera dem som använder programvaran dagligen, de som ansvarar för drift och förvaltning, informationssäkerhet, upphandling och juridik samt den verksamhet som finansierar lösningen. Låt grupperna lämna förslag på vikter och jämför dem. Stora skillnader är värdefull information som bör hanteras öppet, inte jämnas ut i tysthet.

Välj metod efter situation: gemensam workshop, parvisa jämförelser, enkät eller strukturerad hearing. Förankringen gäller både kriterierna och vikterna. Att bjuda in först när modellen är färdig ger skenbar delaktighet och brukar märkas när resultatet ska användas.

Pröva, följ upp och justera modellen

Pröva viktningen mot alternativ vars egenskaper redan är kända innan modellen används skarpt. Ge deltagarna samma underlag och se om viktningen leder till ett utfall som stämmer med den samlade bedömningen. Om det inte gör det, undersök om det är kriterierna, betygsskalan eller vikterna som behöver justeras – inte vilket svar ni helst vill ha.

Följ upp efter införandet. Gav de kriterier som vägde tyngst den effekt ni förväntade? Om inte är det en signal att revidera kriterier eller vikter. Ett lärande och förbättrande syfte, som MSB beskriver för sina utvärderingar, förutsätter att modellen ses som en levande artefakt som ändras när kunskapen ökar.

Dokumentera tillräckligt för att viktningen ska kunna granskas och återanvändas: syfte och avgränsning, kriterielista med definitioner och betygsskalor, vikter med motivering, vem som beslutat och när, samt datum och skäl för varje ändring. Versionera modellen så att det går att se vad som låg till grund för ett tidigare beslut, och återanvänd den i nästa utvärdering i stället för att börja om från noll.