Vad bör ingå i en kravspecifikation för affärssystem?

Syfte och utgångspunkt: varför en kravspecifikation för affärssystem?

En kravspecifikation har två uppgifter: att tvinga verksamheten att enas om vad som faktiskt ska lösas, och att ge leverantörer ett underlag som går att svara på och jämföra. SIS beskriver standarders syfte som att skapa enhetliga och transparenta rutiner som parterna kan enas kring; de underlättar upphandling och avtalsskrivning eftersom köpare och leverantörer talar samma språk. Samma logik gäller kravspecifikationen – den låser begrepp, avgränsningar och förväntningar innan avtal tecknas.

Utgångspunkten är en strukturerad förstudie. Enligt xperitus lägger en förstudie med tydliga affärsmål grunden för hela upphandlingen och minskar risken för kostsamma misstag. Rätt lösning kan effektivisera processer och ge bättre beslutsunderlag; ett felaktigt val kan i stället leda till höga kostnader och begränsad flexibilitet. Kravspecifikationen är dokumentet där förstudiens slutsatser blir prövbara – den dokumenterar funktionella och icke-funktionella krav.

I praktiken ska kravspecifikationen kunna användas av tre parter samtidigt: verksamheten som beställare, upphandlingsfunktionen som prövar anbud och leverantören som ska realisera kraven – utan att någon av dem behöver tolka om innebörden sinsemellan.

Från behov och processer till krav

Arbetet börjar i verksamheten, inte i leverantörernas produktkataloger. Kartlägg affärsmål, processer och intressenter: vilka flöden som finns, vilka roller som utför dem, vilka volymer som hanteras, var fel och manuella arbetsmoment uppstår, och vilka beslut som i dag fattas på bristfälligt underlag. I svensk kravterminologi kopplas verbet tillgodose till behov – krav formuleras för att tillgodose ett identifierat behov, inte för att beskriva en på förhand vald produkt.

Omvandlingen från behov till krav görs med dokumenterade metoder: intervjuer och workshops med processägare, nulägesanalys, genomgång av avvikelserapporter och manuella stöddokument, samt volymmätningar för de flöden som ska dimensionera lösningen. Registrera varje kandidatkrav med sin källa – vilket behov, vilken process och vilken intressent som ligger bakom – eftersom källan behövs senare vid prioritering och ändringar.

En vanlig fallgrop är att kraven skrivs som beskrivningar av en färdig lösning. Kravterminologin skiljer på lösningsoberoende krav och begränsningar, och begränsningarna bör redovisas separat. Bindande förutsättningar som befintlig systemmiljö, ingångna avtal eller tvingande regelverk ska alltså framgå som just begränsningar – inte blandas in bland de krav leverantören förväntas uppfylla på valfritt sätt.

Struktur, begrepp och prioritering av krav

En kravspecifikation blir hanterbar först när den har en struktur. Svensk kravterminologi omfattar kravhierarkier och krav på olika abstraktionsnivåer, kategorisering och klassificering av krav, kravtyper, kravattribut och kravmängdsattribut samt kravschabloner och kravmönster. Den gemensamma begreppsapparaten är själva poängen – gemensamt språk ger bättre krav.

Kravattribut gör kraven spårbara och styrbara. Sätt attribut per krav: unikt id, benämning, källa till behovet, kravägare i verksamheten, prioritet, status och verifieringsmetod. Prioriteringen bör följa en fast skala som alla parter känner, till exempel ska-krav, bör-krav och kan-krav, så att leverantören kan bedöma vad som är bindande och vad som är önskvärt vid en given budget.

Kraven som helhet har också egenskaper att hantera: fullständighet, konsistens och avgränsning mot det som inte ingår. Funktionella och icke-funktionella krav beskrivs i kravterminologin som de problematiska kravtyperna. Praktisk konsekvens: bestäm i förväg vilken kategori ett krav hör till och vilken struktur det ska följa, i stället för att låta kategorin avgöra om kravet blir formulerat.

Prioritering av krav: ska, bör, kan

Funktionella krav: processer och funktioner

Ett affärssystem beskrivs som en integrerad plattform som samlar och automatiserar centrala affärsprocesser, där ekonomi, inköp, produktion, lager, försäljning och kundhantering knyts ihop i ett gemensamt system med en delad databas. Kravspecifikationen bör spegla samma processområden och beskriva vad systemet ska göra i varje flöde.

För varje process behöver specifikationen besvara: vad som utlöser processen, vilka in- och utdata som används, vilka roller och behörigheter som är inblandade, vilka beslut och atteststeg som krävs, hur avvikelser och undantag hanteras samt vilka gränssnitt processen har mot angränsande flöden. Typiska kravområden är order till kassa, inköp till betalning, prognos till produktion, lagerpåfyllnad och retur- och reklamationshantering inom kundservice.

Formulera kraven som aktiviteter och resultat – vad som ska kunna utföras och vilket utfall det ska ge – snarare än som skärmbilder eller menyval. Skärmnivåbeskrivningar binder lösningen i förtid och gör anbuden svårare att jämföra, medan process- och resultatkrav går att verifiera oberoende av vilket gränssnitt leverantören erbjuder.

Icke-funktionella krav: prestanda, användbarhet, gränssnitt och säkerhet

De icke-funktionella kraven kompletterar de funktionella och avgör om lösningen är användbar i praktiken. Fyra områden hör till de vanligaste: prestanda, användbarhet, gränssnitt och säkerhet.

Varje sådant krav måste vara mätbart och verifierbart. I stället för "snabb" och "användarvänlig" anges ett mått, en betingelse och en verifieringsmetod: svarstid vid ett angivet antal samtidiga användare och en angiven datamängd, tillgänglighet uttryckt i procent av avtalad drifttid, maximal överföringstid för integrationer, andel lyckade transaktioner samt hur måttet ska mätas och när. Användbarhetskrav bör kopplas till konkreta uppgifter som ska kunna utföras av en viss roll inom en angiven tidsram.

Säkerhetskraven bör omfatta autentisering, behörigheter per roll och enhet, loggning av ändringar, kryptering och spårbarhet i affärskritiska transaktioner. SIS listar SS-EN ISO/IEC 27002:2022, informationssäkerhet, cybersäkerhet och integritetsskydd – informationssäkerhetsåtgärder, som en standard att utgå från. Om certifiering av IT-säkerhet ska krävas i upphandlingen måste specifikationen också ange vem som får utfärda den: Swedacs föreskrifter tillämpas på certifieringsorgan som är eller ansöker om att bli ackrediterade för certifiering av IT-säkerhet hos IT-produkter, IT-system samt skyddsprofiler, och den tidigare föreskriften STAFS 2007:21 är upphävd genom STAFS 2019:3.

Integrations-, data- och informationskrav

Integrationskraven avgör ofta om affärssystemet ersätter de isolerade system som inte kommunicerar med varandra. Den integrerade plattformen med delad databas ger aktuell affärsdata från hela verksamheten, vilket i sin tur möjliggör snabbare och mer välgrundade beslut. Lista varje system som ska integreras och ange per integration: syfte, dataobjekt, riktning, frekvens, format, ansvar vid fel och hur avvikelser larmas och hanteras.

Datakraven hör ihop med integrationerna: vilket dataobjekt som ägs och förvaltas var, vilka fält som är obligatoriska, vilka valideringar som ska ske vid källan, hur dubbletter förhindras, hur historik och arkivering hanteras samt hur data kan lämnas ut vid avtalets slut. Bestäm också vilket system som är auktoritativt källsystem per dataobjekt, och vad som ska hända när två system innehåller motstridiga uppgifter.

Krav på datakvalitet blir verkningslösa om ingen äger dem. Knyt därför varje datakrav till en roll i verksamheten med ansvar för innehåll, kvalitet och behörigheter, och kräv att leverantörens föreslagna lösning kan visa avvikelser mot uppsatta kvalitetsmått.

Driftform, moln, skalbarhet och tillgänglighet

Molnbaserade affärssystem ger svenska företag flexibilitet, skalbarhet och tillgång till realtidsdata oavsett var verksamheten bedrivs. Driftformen är därför ett kravområde, inte en teknisk detalj: specifikationen bör ange om molndrift förutsätts, hur tillgänglighet mäts och följs upp, hur tjänsten skalas vid ökade volymer eller fler användare, hur ofta uppgraderingar sker och när underhållsfönster får ligga.

Komplettera med krav på supporttider och kanaler, åtkomst från mobil och distansarbetsplats, prestanda vid hög belastning, rutiner för säkerhetskopiering och återställning samt villkor för datalagring och utlämning av data om avtalet upphör. Tillgänglighetskrav utan avtalad mätmetod och konsekvens vid avvikelse går inte att följa upp i efterhand.

Internationella och koncernspecifika krav

Svenska företag med internationell verksamhet har särskilda behov kring flervaluta, koncernredovisning och lokala regelverk, och ett modernt affärssystem förutsätts hantera dessa krav. Specifikationen bör därför omfatta redovisnings- och transaktionsvalutor, kurshantering vid transaktionstillfälle och bokslut, enhetshierarkier och behörigheter per enhet, elimineringar mellan enheter samt rapportpaket för konsolidering.

Beskriv också hur gemensam kontoplan och gemensamma kodplaner förhåller sig till lokala variationer, hur lokala rapporteringskrav och fakturaformat hanteras och på vilket språk och med vilka enheter gränssnitt och rapporter ska vara tillgängliga. Utgå från den rapporteringsstruktur koncernen faktiskt använder, så att systemet kan producera underlaget utan manuella mellanled.

Krav på leverantör, implementeringspartner och stöd

Valet av implementeringspartner är lika viktigt som valet av system – erfarenhet, branschkunskap och långsiktigt stöd avgör framgången. Kravspecifikationen bör därför ställa krav på partnern och inte bara på programvaran: dokumenterad erfarenhet från liknande verksamhet och bransch, referensuppdrag som går att kontakta, vilka nyckelresurser som avses arbeta i projektet, hur kompetens säkerställs och hur support och vidareutveckling organiseras.

En lyckad implementation kräver förankring hos ledningen, engagerade projektteam och realistiska tidsplaner. Det omsätts i krav på projektmodell, milstolpar, acceptanskriterier per fas, bemanning från båda parter, utbildning och kunskapsöverföring till den egna organisationen, samt villkor för supportavtal med svarstider och former för ändringsbegäran efter driftsättning.

Verifiering, validering och spårbarhet

Varje krav ska gå att följa upp. Ange därför redan i specifikationen vilken verifieringsmetod som gäller för respektive krav – granskning av dokumentation, demonstration i systemet, test med egna data eller analys – och när verifieringen ska ske. Kravterminologin behandlar validering och verifiering av krav respektive system, vilket ger begreppen för att hålla isär två frågor: att rätt krav har ställts (validering) och att systemet uppfyller dem (verifiering).

Spårbarhet innebär att varje krav kan följas från behov via krav till testfall och acceptans, och vidare till ändringsloggen. Kravterminologin omfattar både spårbarhet och kravglidning samt kravallokering, det vill säga hur krav fördelas mellan systemets delar. Utan spårbarhet går det inte att vid leverans visa vad som är uppfyllt, delvis uppfyllt eller inte uppfyllt.

Kravglidning – att kraven ändras successivt under projektet – påverkar både tid och kostnad. Möt den med en formell ändringsrutin: nya och ändrade krav registreras, värderas mot prioritet, versionshanteras och prissätts innan de arbetas in, så att kopplingen mellan ändrat innehåll och ändrade förutsättningar blir dokumenterad.

Kravspecifikationen som underlag för upphandling och utvärdering

En anbudsinbjudan delas i praktiken in i kapitel där administrativa förutsättningar och krav beskriver bland annat hur man lämnar anbud, medan kapitlet prövning och utvärdering redogör för hur anbuden prövas. Kravspecifikationen för ett affärssystem bör följa samma logik: tydliga administrativa förutsättningar, krav på anbudets form och innehåll samt utvärderingskriterier som är kända i förväg.

Kräv att anbudsgivaren svarar krav för krav i ett fast svarsformat – uppfyllt, delvis uppfyllt eller ej uppfyllt – med motivering och hänvisning till hur kravet löses, samt en prisbilaga där kostnaderna redovisas var för sig: licens eller prenumeration, implementation, drift och support, utbildning och vidareutveckling. Då blir anbuden jämförbara och prövningen transparent.

Standarder säkerställer kompatibilitet och ger trovärdighet både lokalt och globalt. Genom att hänvisa till etablerade standarder inom de områden där de finns – till exempel informationssäkerhet – får kravspecifikationen en referensram som båda parter känner igen, vilket minskar utrymmet för egna tolkningar i anbudsprövningen.