Hvordan skaber man et it-udbud, der både understøtter de lovmæssige og funktionelle rammer og samtidig holder brugerbehovet i centrum? Det spørgsmål var omdrejningspunktet, da Region Syddanmark i 2023 startede arbejdet med at udvikle en ny fællesoffentlig behandlingsplatform (FOB).
Mange oplever it-udbud i det offentlige som en kedelig og omstændig pligthandling for at komme til ”det sjove” – det der munder ud i udvikling af den egentlige it-løsning. Men når it-udbud fungerer bedst, kan processen blive en dynamo for etablering af en holdbar vision og sikre, at beslutninger kan træffes rettidigt med afsæt i det egentlige brugerbehov. Her er brugerinddragelse en central aktivitet for at opnå denne synergi. Som sidegevinst sikres samtidig en sund konkurrence mellem leverandører og kan give en kontrakt, der efterfølgende giver fornuftige styringshåndtag. I casen nedenfor beskriver vi, hvordan det i et projekt er lykkedes at få tænkt brugerinddragelse ind både før, under og efter it-udbud.
Opgaven
I slutningen af 2023 blev vi kontaktet af Center for Digital Psykiatri i Region Syddanmark. Ønsket var at få hjælp til at etablere et it-udbud, der kunne danne fundamentet for en ny digital løsning i kampen mod mentale lidelser og mistrivsel. Visionen var at muliggøre udbredelsen af digitale terapitilbud til flere behandlingsgrupper og bygge ovenpå Fælles Udbredelse af Telemedicinsk infrastruktur (FUT).
Udover udarbejdelse af de formelle udbudsdokumenter, havde kunden fra start et ønske om, at løbende brugerinddragelse og brugerafdækning blev en integreret del af det fremtidige leverandørsamarbejde. Derudover havde kunden et ønske om at udvikle løsning, som nu skulle genopbygges, der kunne bruges i alle regioner og kommuner på tværs af Danmark.
Brugerinddragelse – en definition
Men først lige en definitions ting. For hvad betyder brugerinddragelse i praksis? Grundlæggende ser vi tre niveauer af brugerinddragelse:
- Brugercentreret design, hvor brugerne involveres sådan at designerne opnår en bedre og mere korrekt forståelse af brugernes behov
- Brugerinvolverende design, hvor brugerne indgår på lige fod med designerne fra idéfase til implementering
- Brugerinnoverende, hvor brugerne selv er designere og udvikler løsningen
Når virkeligheden rammer, er definitionerne selvfølgelig ikke helt så firkantede. I denne case brugte vi fx en ‘product owner’, der havde beslutningskompetencen og vurderede, hvad der var vigtigst på tværs af de opsamlede brugerbehov – blandt andet for at undgå bias ved enkeltpersoner. En rolle som formentlig vil kategorisere sig som et brugercentreret design.
Samtidig definerede vi en fast brugergruppe og et brugerpanel, der fik en central rolle. De skal løbende evaluere kontraktens prøver og vurdere prototyper under udarbejdelsen af udbudsmaterialet. En rolle som man typisk vil kategorisere som et brugerinvolverende design.
Når vi snakker brugerinddragelse i denne case, refererer vi altså primært til de første to niveauer i en balanceret anvendelse.
Vores bidrag: et fælles afsæt
Sammen påbegyndte vi opgaven med at etablere et fælles afsæt. Vores erfaring er, at vellykket og rettidig brugerinddragelse hviler på evnen til at definere et fælles afsæt inden et it-udbud. Når det rammesættende ’hvorfor’, ’hvad’ og ’hvordan’ er konceptuelt afklaret, skaber det en fælles referenceramme, der giver de bedste forudsætninger for den efterfølgende brugerinddragelse og samarbejdet med leverandørens udviklingsteam.
Vi brugte her Fælles Offentlig Digital Arkitektur (FDA) som metode for at komme hele vejen rundt på konceptuelt niveau til en samlet behovsopgørelse. Alt fra styring, strategi, jura og sikkerhed til information, applikation og infrastruktur. Alle elementer i forretningen skal berøres inden udbuddet, og skal grundlæggende give svar på ’hvorfor’, ’hvad’ og ’hvordan.’ Udarbejdelsen var resultatet af inddragelse af brugerrepræsentanter til indsamling og kvalificering på et såvel strategisk, forvaltningsmæssigt og løsningsnært niveau.
- Hvorfor: Hvad er visionen for løsningen? Hvilke gevinster forventes og hvad skal den være svar på?
- Værktøj: Brugerinddragelse ved brug af gevinstrealisering
- Hvad: Hvilke funktionelle og ikke-funktionelle behov skal løsningen dække? Og hvilke data og procesmæssige behov er der?
- Værktøj: Brugerinddragelse ved brug af tema/epic overblik, roadmap og aktør/kontekst diagram
- Hvordan: Hvordan kan behovene understøttes i relationen til brugerne?
- Værktøj: Brugerinddragelse ved brug af procesdiagrammer, scenarier og prototyper
Med afsæt i ovenstående er spørgsmålet altid: Hvilket detaljeniveau og hvilken rammesætning skal kravene have, før opgaven udbudsættes? Det handler om, i hvilket omfang leverandøren ønsker at indgå som den innovative part – særligt i afprøvningsdelen. Udfordringen er ofte, at måden hvorpå brugeren understøttes ofte er tæt forbundet med, hvordan selve it-løsningen designes – fx i forhold til løsningsarkitektur, teknologi og lignende – hvilket i sidste ende kan få stor betydning for brugerunderstøttelsen. Hvor dybt kunden går, er altså afgørende for, hvordan en kommende leverandør kan sættes i spil i den efterfølgende kontraktperiode.
For kunden var ambitionen at bruge udbuddet på at finde en relevant samarbejdspartner, hvor den løbende brugerinddragelse indgår som en dynamik, der både understøttes i kontrakten og skaber rum for fælles innovation mellem kunde og leverandør. Opgaven blev derfor at formulere ’hvad’ og ’hvordan’ på en måde, der gav plads til, at en kommende leverandør kunne være ”med på rejsen” sammen med de relevante brugere.
Sammen med kunden formulerede vi behovene på både konceptuelt og funktionelt niveau fordelt på tema, epic og feature. Det blev løbende afstemt med udvalgte brugerrepræsentanter og prioriteret af den tilknyttede projektleder og product owner for at sikre en meningsfuld rammesætning.
Afdækningen skete gennem en række workshops, hvor vi brugte scenarier og procestegninger (fx. svømmebaner og service blueprints) og gennem iterationer kom tættere på det konkrete funktionelle behov. Prototyping af centrale brugergrænseflader (wireframes) var med til at eksemplificere og kvalificere ønskerne til brugerunderstøttelsen.
Udover den indledende brugerinddragelse, som blev brugt til at afdække de funktionelle behov og besvare ’hvorfor’, ’hvad’ og ’hvordan’ FOB-løsningen skal, bør eller kan udmøntes, blev der i udbudsmaterialet indarbejdet en række mekanismer for at sikre løbende brugerinddragelse.
Vores bidrag: krav til samarbejdsorganisation og udviklingsmetode med brugerinddragelse
Vi arbejdede med at etablere en samarbejdsorganisation, der afspejlede de brugere, som var centrale repræsentanter for brugen af it-løsningen. Organiseringen blev dels opdelt i styringsorganer, med udelukkende kunderepræsentation, og dels i styringsorganer, hvor både kunde og leverandør var repræsenteret for at sikre samarbejde.
Følgende styringsorganer blev etableret i FOB-regi for at sikre brugerinvolvering og tydelig ansvarsfordeling:
- En forretningsstyregruppe der primært varetager det strategiske perspektiv og består af ledelsesrepræsentanter på forretningsstrategisk niveau.
- Et anvenderforum der primært skal varetage det forvaltningsmæssige perspektiv og består af personer med forvaltnings– og forretningsprocesmæssige ansvar i de enkelte anvenderorganisationer.
- Et brugerpanel der primært skal varetage det løsningsmæssige perspektiv og består af brugerrepræsentanter fra anvenderorganisationerne.
Figur 1: Skitser over leveranceorganisationens samarbejdsorganisation
Særligt brugerpanelet forventes løbende blive ”bruger-involveret” i både evaluering, test og afprøvning af skitserede løsningsforslag – herunder vurdering af brugergrænseflade, proces- og dataunderstøttelse. Dermed får brugerpanelet en afgørende rolle i beslutning om, hvorvidt det producerede er tilstrækkeligt.
Krav til kompetencer
I udbudsmaterialet lagde vi vægt på at identificere relevante nøglepersoner og deres tilhørende kompetencer. Her var strategien at fremhæve og vægte erfaring med brugerinddragende designmetoder positivt – særligt for roller som it-arkitekt, product owner, test manager og UX-konsulent.
Krav til udviklingsmetode
Udviklingsmetoden blev rammesat som en proces med plads til brugerinddragelse i alle faser med inddragelse af repræsentanter fra brugerpanelet. Det blev vægtet positivt at leverandøren skulle redegøre for, hvordan denne ramme kunne udfyldes, især med fokus på både brugercentreret og brugerinvolverende design.
Følgende iterative proces dannede rammen for brugerinddragelsen og relaterede sig til både aktørerne i samarbejdsorganisation og it-løsningen:
- Fase 1: Udforskning skulle sikre prioritering af backlog og funktionsønsker samt foranalyseaktiviteter med inddragelse af brugerpanelets repræsentanter.
- Fase 2: Planlægning skulle sikre validering af systemdesign i forhold til forventninger med inddragelse af brugerpanelets repræsentanter.
- Fase 3: Udvikling skulle sikres gennem iterativ test og evaluering af forslag til brugergrænseflader, processer og datastøtte med inddragelse af brugerpanelets repræsentanter.
- Fase 4: Godkendelse skulle sikre at kvaliteten var som aftalt med afprøvning med brugerinddragende prøver.