Så kravställer du rätt inför byte av medlemssystem

En kravinsamling är det underlag som både organisationen och leverantören behöver ha samsyn kring. Uppnår man detta ökar förutsättningarna för att det framtida medlemssystemet också innehåller det organisationen faktiskt behöver.

Arbetet med kravinsamling hos en medlems- och/eller insamlingsorganisation innebär ofta en hel del förankringsarbete och förändring av processer. Detta behöver man vara medveten om när arbetet påbörjas och avsätta både projektledning och arbetstid för.

För många organisationer är ett systembyte ett stort ingrepp i verksamheten och det är lätt att vilja få med så mycket som möjligt ”när man nu ändå investerar”. Risken är att kravbilden växer och att resultatet blir ett system som blir dyrbart i längden, mindre användarvänligt och svårare att vidareutveckla.

Datamodellen är grunden i medlemssystemet

En felaktig datamodell skapar fel systemlösning. Datamodellen är en viktig länk mellan verksamheten och ett verksamhetssystem.

Om datamodellen inte avspeglar verksamhetens begrepp, relationer och information kommer inte heller systemet att göra det. Det påverkar bland annat hur användaren kan göra sina sökningar, se relaterad information eller följa upp transaktioner.

Tänk på medlemssystemet som ett hus

För att beskriva vad en datamodell är kan man jämföra med grunden till ett hus. Grunden ger både möjligheter och begränsningar till vilken typ av hus man kan bygga.

Medlems- och insamlingsorganisationer är beroende av att datamodellen beskriver verkligheten. Man arbetar mycket med analyser av data och det innebär att datamodellen måste vara lätt att förstå och användbar.

En väl strukturerad datamodell är också en förutsättning för att kunna få ut rätt statistik ur medlemssystemet. Har ni någon gång haft problem med att få ut rätt statistik kan en förklaring vara att datamodellen inte är utformad på rätt sätt eller att organisationen inte förstår hur systemets datamodell fungerar.

En bra datamodell ger dessutom organisationen bättre möjligheter att vidareutveckla medlemssystemet. Det innebär att ni inte behöver försöka kravställa alla tänkbara framtida funktioner redan vid införandet.

Det är få organisationer som själva har kunskapen att översätta hela verksamheten till en datamodell. Det kan därför vara något som görs tillsammans med den valda leverantören. Men se till att få information om hur datamodellen för det system som erbjuds ser ut.

Beskriv hur medlemssystemet faktiskt ska användas

En kravinsamling slutar ofta med en lång lista på funktionella krav. Det innebär dock inte nödvändigtvis att man har besvarat frågan om hur medlemssystemet faktiskt ska användas. Därmed ökar också risken för att organisationen betalar för onödig funktionalitet.

Det kan tyckas vara en given grundförutsättning, men om du inte beskriver vad systemet ska användas till finns det en risk att du får ett system där era flöden inte hänger ihop och där användarna behöver göra onödigt många moment.

Att beskriva användandet görs enklast med enkla processbeskrivningar med kompletterande text.

Ett exempel från medlemsservice

Medlemsservice registrerar och kvalitetssäkrar nya medlemmar som kommer in via flera kanaler, både förskotts- och efterskottsbetalningar.

• Filer för välkomstbrev exporteras till betalande medlemmar veckovis.
• Filer för avier exporteras till ej betalda medlemmar dagligen.

Poängen är inte bara att beskriva vilken funktionalitet som ska finnas, utan också hur den ska användas i verksamheten.

Prioritera med hjälp av en frekvensanalys

Ett annat bra sätt att beskriva sin verksamhet för en leverantör är att göra en frekvensanalys. I en frekvensanalys beskriver man vilka moment som utförs, hur ofta de görs och av hur många.

Det ger en vägledning till vad som ska kravställas med större noggrannhet och var användarvänlighet måste vara i fokus.

Funktionella krav beskriver i många fall krav utan någon tydlig värdering. I bästa fall finns en gradering i bör- och skallkrav. Bör-krav är ofta svåra att kravställa eftersom de kan spegla en vision om ett arbetssätt som ännu inte har implementerats i organisationen.

Det kan därför vara värt att fundera på om vissa bör-krav kan vänta tills det nya medlemssystemet är på plats och organisationen vet när funktionaliteten faktiskt kan realiseras.

Kombinationen av funktionella krav, processbeskrivning och frekvensanalys ger leverantören en betydligt bättre bild av organisationens verksamhet.

Börja med varför ni behöver ett nytt medlemssystem

Alla som tar del av en kravspecifikation behöver förstå sammanhanget:

• Varför har initiativet startats?
• Vad är målbilden när allt är klart?

Det finns också ett värde i att inleda respektive verksamhetsprocess med en kort introduktion kring om den nya lösningen förändrar det befintliga arbetssättet eller inte. Ibland behövs bara ett nytt system. I andra fall innebär det nya medlemssystemet också ett nytt sätt att arbeta.

Det första som behöver dokumenteras är alltså varför.

Frågan behöver inte vara ”varför ska ni ha ett nytt system?” utan kan i stället formuleras som:

• Vilket högre syfte fyller systemet?
• Vilka effekter eller värden hoppas ni kunna uppnå?

Koppla kraven till verksamhetens mål

Det finns många metoder för att kartlägga värden och effekter. Ett sätt är att använda en behovstrappa.

Syftet är inte bara att komma överens om verksamhetens behov, utan också att kunna kommunicera dessa till alla berörda parter i projektet. Det ger en gemensam grund inför de många små beslut som behöver fattas under ett systeminförande.

Den högsta nivån i behovstrappan handlar om att stödja organisationens mission, vision och strategi. Längre ned blir kraven successivt mer detaljerade.

Genom att ställa frågan ”varför?” kan ett detaljerat krav kopplas tillbaka till ett större verksamhetsbehov. Åt andra hållet kan frågan ”hur?” användas för att gå från ett övergripande mål mot mer konkreta krav.

Dokumentationen behöver förankras med projektets intressenter för att skapa en gemensam syn innan kravarbetet går vidare.

Genom att arbeta på det sättet blir det också lättare att tänka nytt kring krav och lösningar, i stället för att utgå från invanda arbetssätt och resonemanget ”så har vi alltid gjort”.

En viktig fråga blir då:

Vilket värde är det som den här funktionen ska stödja?

Se medlemssystemet i tre dimensioner

Ett IT-system kan i många hänseenden liknas vid ett hus. Därför passar det också ganska bra att kravställa i flera dimensioner.

Tre viktiga dimensioner är:

• information
• process
• integration

Informationsmodellen kan liknas vid husets konstruktionsverk: grunden, stommen och stammarna, samt en översiktlig plan över vilka rum som finns.

Processerna beskriver hur huset är tänkt att användas och vilka behov som finns från slutanvändarna: laga mat, tvätta kläder, umgås med familjen och så vidare.

Det viktiga är att korsa dessa två dimensioner. Det innebär att man måste beskriva vilket stöd processerna behöver från informationsmodellen.

Att laga mat kräver till exempel ett kök, att tvätta kläder kräver en tvättstuga och att umgås med familjen kräver kanske ett vardagsrum. Eller kanske räcker köket? Det är enkla exempel, men även där är det inte alltid självklart vilken lösning som bäst stödjer behovet.

I IT-kravens värld är det ofta användarna eller verksamheten som kommer med processkraven, medan IT-avdelningen eller leverantören kommer med informationsmodellen.

Ofta möts inte dessa två perspektiv. Genom att korsa dem kan verksamheten och IT kopplas samman.

Integrationer är en del av verksamheten

Integrationerna syftar till att ställa krav på allt som inte hämtas eller matas in i ett system manuellt.

Inget framgångsrikt IT-stöd är en isolerad ö, och det kommer allt mindre att vara det i framtiden.

Även här fungerar husjämförelsen. Ett hus är beroende av anslutningar till omvärlden, exempelvis el, vatten, avlopp, vägnät och inkommande kommunikation. På samma sätt behöver ett medlemssystem fungera tillsammans med andra system och informationsflöden.

Välj rätt detaljeringsnivå

Beroende på var i kravställnings- eller upphandlingsprocessen ni befinner er är det rimligt att välja detaljeringsnivå därefter.

Nivå 1 passar bra för att göra en första helikopteröversikt och kan exempelvis användas för att skapa en RFI eller ett annat översiktligt förfrågningsunderlag.

Nivå 2 är ofta det som krävs för att verkligen förstå hur något ska lösas och den nivå som vanligtvis behövs för att kunna estimera projektet.

Nivå 3 är den detaljeringsnivå som krävs för att börja utveckla funktionalitet. Den är sällan nödvändig redan i kravhanteringsfasen och kan ofta lämnas till utvecklingsfasen.

Informationsmodell, datamodell och databasmodell

Informationsmodell, datamodell och databasmodell är begrepp som ligger nära varandra, men de betyder inte riktigt samma sak.

• Informationsmodellen ligger närmast verksamheten och beskriver, oberoende av systemstöd, hur olika informationsobjekt förhåller sig till varandra i verksamheten.
• Datamodellen tar informationsmodellen, placerar den i ett systemperspektiv och gör vissa justeringar baserat på hur lösningen ser ut.
• Databasmodellen bygger på datamodellen och implementerar den praktiskt i den databas som ska stödja lösningen.

Informationsmodellen och datamodellen är relevanta ur ett kravperspektiv. Databasmodellen är det betydligt mer sällan.

Beskriv verksamhetsbehovet, inte bara dagens arbetssätt

Processer, användningsfall, scenarier och user stories är olika sätt att beskriva behov och krav, men de handlar alla om samma grundläggande dimension:

Användarens behov för att kunna sköta sitt verksamhetsansvar.

Utmaningen är att beskriva det faktiska verksamhetsbehovet och inte bara hur arbetet görs i dag.

Det är sällan lönt att börja kravställa specifika gränssnittsbeteenden direkt. I många fall är det verksamhetens natur som styr i vilken ordning saker måste ske, och det finns ofta fördelar med att först tänka ur ett helikopterperspektiv innan man går in på detaljer som fältplacering och interaktioner.

Använd frekvensanalysen för att prioritera

Även här kan en frekvensanalys vara användbar. För varje användningsfall eller aktivitet kan man exempelvis summera:

• antal användare
• antal gånger aktiviteten utförs per år

Genom att jämföra dessa kan ni få en tydligare bild av vilka processer som användarna kommer att uppleva som viktigast och som därför bör få extra uppmärksamhet.

Se integrationer som dataflöden, inte bara teknik

Ett vanligt feltänk kring integrationer är att de betraktas som en teknikfråga som teknikerna får lösa.

Tekniken går ofta att lösa på ett eller annat sätt. Det viktiga är förståelsen för dataflödet och själva handskakningen mellan de två kommunicerande systemen.

Innan frågor om exempelvis XML-scheman och protokoll tas upp behöver ni därför förstå vad integrationen faktiskt ska åstadkomma.

Ett XML-schema beskriver hur information som skickas i XML-format ska vara strukturerad. Det kan till exempel ange vilka uppgifter som ska finnas med, vad de ska heta och vilken typ av information varje fält får innehålla.

Ett protokoll beskriver reglerna för hur två system kommunicerar med varandra, alltså hur information skickas och tas emot. Det kan exempelvis handla om hur systemen etablerar kontakt, skickar data och hanterar svar eller fel.

Det är tekniska frågor som behöver lösas, men först behöver verksamheten och leverantören vara överens om vilken information som ska flyttas, varför den ska flyttas och vad som ska hända när den kommer fram.

Innan man går ned på den tekniska nivån behöver ni därför bland annat kunna svara på:

• Vad är syftet?
• Vad triggar integrationen?
• Vem ansvarar för respektive system?
• Vem initierar anropet?
• Vilken data ska skickas?
• Vad kan det ena systemet anta vara sant om informationen från det andra?
• Vilket svar kan det andra systemet förvänta sig?
• Behövs någon efterbehandling?
• Vilket tekniskt gränssnitt används?
• Finns integrationen redan hos motparten?

Det kan vid första anblick se ut som många detaljer, men svaren gör det betydligt tydligare hur processen i det nya medlemssystemet ska fungera.

Korsa information, process och integration

Genom att korsa de olika dimensionerna får ni också ett ramverk som gör det möjligt att kontrollera kravbilden.

Hur informationen modelleras ger värdefull vägledning kring vilka processer användarna behöver tillfrågas om. Genom att beskriva processerna får ni samtidigt en checklista att stämma av datamodellen mot.

Det ger också ett konkret stöd för att prioritera och dela upp medlemssystemet i flera leveranser.

Var tydlig med vad som inte ingår

Det som inte ingår i kravspecifikationen kan ofta uppfattas som naturligt avgränsat. Därför är det viktigt att vara extra tydlig när delar som skulle kunna uppfattas som en naturlig del av verksamheten faktiskt har exkluderats.

Det kan exempelvis handla om specialhantering i en viss process eller processer som inom kort ska tas bort.

En bättre kravbild ger bättre förutsättningar

Genom att beskriva verksamheten, bakgrunden, syftet och de olika kravdimensionerna skapar ni en jämnare kravbild med en inbyggd kvalitetskontroll.

För att göra detta bra krävs erfarenhet, verksamhetskunskap och vana vid att modellera olika typer av krav. Men med ett tydligt ramverk blir det enklare att börja med det som redan är känt och identifiera var organisationen behöver ytterligare stöd.