Kravspecifikation som styr systemvalet: från behov till kravlista

Utgå från verksamhetsbehovet – inte från systemet

Ordningen spelar roll: kravspecifikationen tas fram innan systemen jämförs, inte efteråt. Enligt Upphandlingsmyndigheten har en upphandlande organisation stor frihet att själv formulera kraven på det som ska upphandlas, och hur kraven formuleras beror på vad som ska upphandlas och syftet med upphandlingen. I upphandlingsdokumenten kallas avsnittet där kraven ställs på upphandlingsföremålet – varan, tjänsten eller byggentreprenaden – ofta kravspecifikation eller teknisk specifikation. Sidan avser upphandlingar enligt lagen om offentlig upphandling (LOU) och lagen om upphandling inom försörjningssektorerna (LUF).

I praktiken börjar arbetet i verksamheten, inte i en produktdemo. Kartlägg vilka processer som ska stödjas, vilka roller som arbetar i dem, vilka beslut som fattas och vilken information som behövs. Formulera sedan vad lösningen ska åstadkomma och översätt först i ett senare steg till en kravlista. Risken med att utgå från ett färdigt system är att kraven anpassas efter det system man redan fastnat för, vilket gör att jämförelsen mellan alternativ tappar sitt värde.

Anskaffningens syfte fungerar som ett filter för vilka krav som blir relevanta. Att ersätta ett föråldrat system ställer andra krav än att effektivisera en process, införa självbetjäning för medborgare eller stärka informationssäkerheten. Skriv därför ned syftet i några meningar tidigt och pröva varje krav mot det: bidrar kravet till att uppfylla syftet, eller är det en önskan som hör hemma någon annanstans? Krav som inte kan kopplas till verksamhetsbehovet blir svåra att prioritera och ännu svårare att verifiera.

Behovsanalys och marknadsanalys som första kravfilter

Innan kravlistan skrivs finns två analyser som underlättar arbetet: behovsanalys och marknadsanalys. Upphandlingsmyndigheten lyfter fram båda som stöd i kravställningen. Behovsanalysen beskriver vad verksamheten faktiskt behöver; marknadsanalysen beskriver vad som är rimligt att efterfråga och hur marknaden ser ut. Tillsammans ringar de in vilka krav som är realistiska, relevanta och möjliga att ställa.

En behovsanalys består typiskt av att dokumentera nuvarande arbetssätt och dess brister, vilka volymer och ärendetyper som hanteras, vilka befintliga system och avtal som berörs, vilka integrationer som krävs och vilka beroenden som finns till andra verksamheter. Den ger också underlag för att skilja på egentliga behov och på önskemål som egentligen handlar om vana vid ett visst gränssnitt.

En marknadsanalys handlar om att ta reda på vilka typer av lösningar och leverantörer som finns, vilka lösningsmodeller som är vanliga, vilka standarder som används i branschen och vilka krav marknaden rimligen kan uppfylla. Dialog med marknaden tidigt i processen är ett vanligt sätt att skaffa den kunskapen, utan att binda sig vid en viss leverantör. Resultatet blir färre krav som ingen kan uppfylla, och färre krav som är så snävt formulerade att de i praktiken pekar ut en enda lösning.

Detaljkrav, funktionskrav eller standarder – välj kravtyp medvetet

Upphandlingsmyndigheten beskriver tre sätt att formulera krav. Detaljkrav anger detaljerade krav på varans egenskaper eller hur tjänsten ska utföras. Funktionskrav beskriver krav på funktionen, det vill säga vad som ska uppnås i stället för hur något ska uppnås. Standarder kan användas för att göra det enhetligt och tydligt för både upphandlande organisation och leverantör vad en vara eller tjänst innehåller.

Detaljkrav kräver att den upphandlande organisationen har djup kunskap om det som ska köpas för att uppnå ett lyckat slutresultat. De passar när verksamheten själv vet exakt vilken lösning som behövs, eller när kraven följer av interna beslut och en befintlig teknikmiljö som inte kan ändras. Nackdelen är att de låser lösningen och minskar utrymmet för leverantören att föreslå något bättre.

Funktionskrav ger leverantören större utrymme att använda sin yrkeskunskap och kreativitet. Även om tillvägagångssättet inte beskrivs i detalj bör organisationen precisera vilket resultat som ska uppnås, eftersom funktionskrav ofta kopplas till mål och mäts som önskade effekter och resultat. Det gör dem särskilt användbara när flera tekniska lösningar kan nå samma nytta, men de ställer högre krav på att målet är mätbart och på att uppföljningen fungerar.

Standarder kan underlätta och effektivisera vid inköp och upphandling och hjälper organisationer och leverantörer att arbeta strukturerat och enhetligt. Om standarder används måste kravet följas av orden "eller likvärdigt", och det bör framgå av upphandlingsdokumenten att bevis som styrker likvärdighet ska bifogas anbudet. Enligt ett ställningstagande från Konkurrensverket som publicerades i juli 2024 är det inte tillåtet att hänvisa till standarder som inte finns att tillgå kostnadsfritt för leverantören; ställningstagandet är i sig inte rättsligt bindande. Ett vanligt arbetssätt är att kombinera kravtyperna: funktionskrav där verksamheten vill ha handlingsfrihet, detaljkrav där gränssnitt eller tekniska förutsättningar måste vara exakt bestämda, och standarder där branschen redan har etablerade referenser.

Obligatoriska krav och önskemål i två nivåer

Upphandlingsmyndigheten tar upp frågan om kraven ska formuleras som obligatoriska krav eller som tilldelningskriterier. Det är en avgörande uppdelning i kravarbetet. Obligatoriska krav är sådana som anbudet måste uppfylla för att komma ifråga över huvud taget. Tilldelningskriterier används i stället för att jämföra, vikta och prioritera mellan de anbud som klarar de obligatoriska kraven.

För systemvalets skull innebär två nivåer att kraven delas i två listor. Den ena listan innehåller det som måste vara uppfyllt, till exempel krav som följer av verksamhetens lagbundna uppgifter, av befintlig teknisk miljö eller av organisationens säkerhetskrav. Den andra listan innehåller sådant som är önskvärt och som kan vägas mot pris och andra faktorer.

En vanlig fallgrop är att blanda nivåerna, så att önskemål formuleras som absoluta krav. Det ger ofta få anbud och gör det svårare att argumentera för varför ett visst system valdes. En annan fallgrop är motsatsen: att göra nästan allt till önskemål, vilket gör jämförelsen godtycklig. Nyckeln är att varje obligatoriskt krav ska kunna motiveras med ett verksamhetsbehov, och att varje önskemål ska vara formulerat så att det går att bedöma och vikta på ett någorlunda enhetligt sätt.

Kravområden som ofta avgör systemvalet

Vissa kravområden återkommer nästan oavsett vilken typ av system som ska anskaffas, och de är ofta de som avgör valet i slutändan.

Funktion. Beskriv de processer och ärendetyper systemet ska stödja, vilka roller som ska kunna arbeta i det och vilka arbetsflöden som ska kunna genomföras. Här passar funktionskrav bra, eftersom de beskriver vad som ska uppnås och mäts som effekter och resultat.

Integration. Kartlägg vilka system lösningen ska utbyta information med, vilken information som ska utbytas, i vilken riktning och med vilken frekvens. Krav på gränssnitt och format hör ofta till de mest konkreta och mest avgörande delarna av kravlistan.

Informationssäkerhet och datahantering. Beskriv vilken information som hanteras, hur känslig den är, vem som ska komma åt den och hur den ska lagras och gallras. För offentlig sektor är säker digital kommunikation ett område där kraven behöver preciseras. DIGG har haft regeringsuppdrag att utveckla och tillhandahålla infrastruktur för säker digital kommunikation inom offentlig sektor och delredovisade uppdraget i september 2022. Upphandlingsmyndigheten hänvisar också till DIGG:s stöd för kravställning vid upphandling av data. Aktörer som bygger lösningar på DIGG:s ramverk för säker digital kommunikation framhåller att säkerhet är en grundförutsättning snarare än en eftertanke, eftersom myndigheter, kommuner och regioner dagligen utbyter stora mängder information. För den egna kravlistan blir frågan vilka kanaler och vilken spårbarhet som verksamheten behöver, och hur det ska kunna verifieras.

Tillgänglighet och användbarhet. Kraven bör handla om att medarbetare och medborgare med olika förutsättningar ska kunna använda lösningen, och om hur det ska kontrolleras. Formulera kraven så att de går att testa snarare än som allmänna omdömen.

Drift, förvaltning och livscykel. Beskriv krav på tillgänglighet, support, uppdateringar, dokumentation, utbildning och vad som händer vid avtalets slut. Även om dessa krav inte handlar om funktioner i systemet är de ofta avgörande för totalkostnaden över tid.

Krav som bör finnas i en fullständig kravspecifikation

Formulera verifierbara krav och acceptanskriterier

Ett krav som inte går att verifiera går heller inte att följa upp och blir därmed en källa till tvist i ett senare skede. Utgångspunkten är att varje krav ska kunna besvaras med ett tydligt ja eller nej, eller mätas mot ett angivet värde.

Undvik formuleringar som "användarvänligt", "modernt", "flexibelt" och "hög prestanda" utan att precisera vad de betyder i den här verksamheten. Ersätt dem med beskrivningar av en situation: vilken uppgift ska kunna utföras, av vem, med vilket resultat och inom vilken tid. Om ett värde anges bör det också framgå hur det ska mätas och i vilken miljö.

Koppla varje krav till ett eller flera acceptanskriterier som beskriver vad som ska vara uppfyllt för att kravet ska anses uppfyllt. Kriterierna blir underlag för acceptanstester vid införandet och för regressionstester när systemet förändras över tid. I systemnära utvecklings- och verifieringsarbete är just systemövergripande verifiering, acceptans- och regressionstester samt analys av avvikelser återkommande arbetsuppgifter, vilket speglar att verifieringen måste planeras redan när kraven skrivs.

Bestäm också i förväg vem som verifierar, med vilken metod och med vilket underlag. Vissa krav verifieras genom tester i en testmiljö, andra genom granskning av dokumentation, certifikat eller genom referenser. Att tidigt bestämma verifieringsmetod tvingar fram krav som är tillräckligt konkreta – och synliggör krav som egentligen inte går att kontrollera.

Använd kravlistan som beslutsunderlag

När kraven är framtagna, uppdelade i obligatoriska krav och önskemål samt försedda med acceptanskriterier, fungerar listan som det underlag som systemvalet vilar på. Den gör det möjligt att jämföra alternativ på samma grunder i stället för att jämföra demonstrationer och intryck.

Ett praktiskt arbetssätt är att bygga en matris där varje krav är en rad och varje kandidat är en kolumn. Obligatoriska krav besvaras med uppfyllt eller inte uppfyllt, och önskemålen ges poäng enligt en viktning som bestämts i förväg. Viktningen bör sättas innan anbuden eller systemdemonstrationerna utvärderas, annars är risken stor att den anpassas efter det alternativ man redan föredrar.

Spårbarhet är en del av beslutsunderlaget. Varje krav bör kunna härledas till ett verksamhetsbehov eller ett syfte, och varje avvägning bör dokumenteras: varför ett krav blev obligatoriskt, varför ett annat blev ett önskemål, och vad man valde bort. Det gör beslutet begripligt för dem som inte deltog i arbetet och hållbart när någon frågar varför just detta system upphandlades.

Slutligen: håll kravlistan levande under upphandlingens gång. Om förutsättningarna ändras bör det framgå av dokumentationen vad som ändrades och varför. En prioriterad, spårbar och verifierbar kravlista är inte bara ett underlag för att välja system – den är också grunden för att senare avgöra om det valda systemet faktiskt levererar det verksamheten behöver.