NYHED
DCX

7 nyttige råd til offentlige organisationer, der skal udvikle et nyt website

Skal din organisation have en ny hjemmeside? Så har du her 7 konkrete og brugbare råd, som kan hjælpe jer med at komme sikkert igennem processen og yde borgerservice i topkvalitet. Lidt læsning, der kan spare jer for ærgrelser, forsinkelser og unødvendigt kostbare fejltagelser.

Af Adam Osbirk Moe, Capgemini Sogeti

Jeg er ikke it-indkøber. Men efter at have læst hundredevis af kravspecifikationer og deltaget i udvikling af løsninger gennem 18 år, har jeg gjort nogle observationer, som kan være relevante for virksomheder, der køber it-løsninger. I dette tilfælde offentlige organisationer, der vil anskaffe et nyt website. Så her er nogle udviklingstrin, som jeg mener, at man med god grund kan tage.

1)    Hvad er visionen?

Skal man virkelig udvikle en decideret vision for et website? Det er svært at svare entydigt på, fordi der både er fordele og potentielle ulemper. 

  • Hvad tæller FOR en vision?

Der er brug for enighed om, hvad endemålet er, fordi mange valg afhænger af dette perspektiv. Det sker desværre ofte, at virksomheder eller organisationer går i markedet for at få udviklet et nyt website uden at være afklaret internt. Det gør det svært for folk internt at lave et godt udbud, og det gør det tilsvarende svært for potentielle samarbejdspartnere at dimensionere tilbuddet rigtigt. Og her taler jeg ikke om penge. Jeg taler om valg af arkitektur, fremtidssikring, udvikling af funktioner etc.

Men hvad er en god vision? Vision kommer som bekendt af ”video”, som betyder ”jeg ser”. Det er en god tommelfingerregel at gøre visionen så konkret og synlig som muligt. Så det står klart for enhver, hvad man skal gå efter, og ikke mindst om man har nået den eller ej. Hvis den ikke kan være direkte synlig for én, kan man bruge SMART-modellen og gøre visionen: 

  • Specifik
  • Målbar
  • Accepteret
  • Realistisk
  • Tidsbegrænset

Bare for eksemplets skyld, kunne en vision være: ”Alle digitale henvendelser fra borgere til kommunen i 2020 skal være besvaret af den rigtige medarbejdere inden for 24 timer, og nye pas, kørekørt og sygesikringsbeviser skal være udstedt eller afvist i løbet af 48 timer”. 

  • Hvad tæller IMOD en vision?

Der er især to faktorer, man skal være opmærksom på. Den ene er, at visioner, der faktisk har indflydelse på organisationers måde at arbejde på, ofte kræver forandringsledelse og organisatoriske tilpasninger og kan ende med at blive meget omfattende.

Den anden faktor, du skal være opmærksom på, er, at visionen ikke kommer til at stå i vejen for de løsninger, I skal bruge på kort sigt. Det kan ske, hvis visionen er stor, flot og langsigtet, så man selv bliver forblændet af den. Hvis man f.eks. har en vision om at udvikle en portal, der løser alle problemer for alle borgere i hele verden, kan det stå i vejen for at udvikle den funktion, som gør, at borgere i kommunen lige om lidt kan skifte læge ved at gå igennem højst 3 skærmbilleder.

Så skal I udvikle en vision? Tjah. Måske ikke en stor forkromet forretningsplan med Vision, Mission og målbare objectives, men du skal være afklaret om, hvad det det primære formål med den digitale platform er. Og hold øje med, at I ikke mister fokus på at få udviklet den funktionalitet og de forretningsgange, der opfylder konkrete behov og løser konkrete problemer – dem der i private virksomheder får business casen til at hænge sammen

2)    Identificer de tekniske (non-funktionelle) krav

Krav kan med fordel deles op i henholdsvis funktionelle og non-funktionelle krav. Hvor de funktionelle krav handler om, hvad brugeren skal kunne gøre, og hvordan. Mens de non-funktionelle er krav til systemerne, der leverer brugeroplevelsen. Ofte objektive krav, som eventuelle leverandører under alle omstændigheder skal forholde sig til. Det er vigtigt, at man internt identificerer disse krav fra start. Fordi det næsten er umuligt at sammenligne forslag uden et overblik over non-funktionelle krav. Det kan være krav som: 

  • .NET baseret teknologi
  • Skal kunne køre på seneste versioner af Chrome, Firefox og Safari
  • Løsningen skal have høj sikkerhed (f.eks. alle formularer sikret mod cross site scripting)
  • Krav til svartider og performance
  • Redaktøren skal kunne publicere en artikel på 5 minutter
  • Redaktøren skal kunne previewe indhold, og se hvordan det fremtræder på forskellige skærmopløsninger og devices

Dette er tekniske mindstekrav, der sikrer jer, at løsningen er korrekt dimensioneret. Det vil sige, at løsningen kan håndtere det antal brugere, som I forventer, og at løsningen er udført teknisk korrekt i forhold til at kunne skalere, når I får succes med jeres digitale platform. 

3)    Identificer de features (funktionelle krav) I ønsker  – med user stories

Når det gælder om, hvad websitet skal kunne, kan jeg ikke anbefale stærkt nok, at man som hovedværktøj bruger user stories. I stedet for en detaljeret beskrivelse af nøjagtige funktioner, der skal leveres. Og det er der flere grunde til: 

                 I.          Beskriver man funktionerne, risikerer man at gå glip af smartere måder at gøre ting på. Og endnu værre ser man ofte såkaldte ”Herreløse krav” fremsat. Som hvis man næsten pr. refleks kræver, at der bliver udskrevet en PDF, når der indgår en forespørgsel fra en borger. Selv om ingen i organisationen længere bruger den PDF til noget som helst. 

               II.          Ved at bruge user cases udnytter man den eventuelle leverandørers ekspertise. Forestil dig, at man skal bygge en bro. Men i stedet for at definere broens størrelse, definerer man, at 10.000 biler skal kunne komme fra A til B på 2 timer. Og så kommer der en potentiel leverandør og fortæller, at han kan nedsænke en tunnel, som kun vil koste 1/10 af en bro … Så har man brugt en user story til at udnytte den fulde ekspertise, som leverandøren kan byde ind med. 

              III.          User stories er ’synlige’ for organisationen selv. Mens definitioner af funktioner hurtigt kan få folk til at sænke øjenlågene undervejs i processen, er der anderledes attention, når du arbejder med user stories. Lad os sige, at man beskriver, hvordan en bruger skal bestille et nyt pas eller tage stilling til en vaccinering på nettet. Så kan alle være med, og alle vil synes, at det er interessant. 

             IV.          En user story beskriver en forretningsproces fra første kontakt til gennemført handling. Dermed undgår man at stille krav om, at standardløsninger skal indrette sig efter organisationers ad hoc arbejdsgange i stedet for at udnytte standarder og workflows på systemet. Ved at beskrive de forretningsmæssige krav kan man få mere solide løsninger, der udnytter standarder, så der oftere vil være tale om konfiguration fremfor skræddersyet udvikling. 

4)    Vælg på baggrund af dine tekniske og forretningsmæssige krav

Udbudsmateriale til potentielle leverandører skal naturligvis også indeholde organisationens overordnede målsætninger. 

Det kan f.eks. være at organisationen har som målsætning, at der skal være personalisering på løsningen, eller at man gerne vil tilkøbe en e-commerce funktionalitet senere, så man kan sælge services, produkter eller ydelser.

Eller at man har en plan om at lave fora for grupper af interessenter, som kan samarbejde i projektrum. Selv om det ikke er en del af det første scope, ved man dermed, at det kommer senere.

Sammen med de non-funktionelle krav kan I nu opstille en matrix, som både indeholder tekniske krav til den kommende løsning og giver mulighed for at tilvælge system på baggrund af organisatoriske og forretningsmæssige målsætninger. 

Tilvalgskriterier

CMS A

(Eks. Episerver) 

 

CMS B

(Eks. Umbraco)

 

CMS C

(Eks. Sitecore) 

 CMS D

(Eks. Drupal)  

Open Source

 

 

 

 

Mulighed for ekstranet/projektrum

 

 

 

 

Understøtter responsiveness

 

 

 

 

Osv.

 

 

 

 

Vægtet sum

 

 

 

 

5)    Send din tilvalgsmatrix til højst 4 software leverandører

Lad os et øjeblik se bort fra offentlige udbudsregler. Og lad os alene beskæftige os med, hvad der vil være optimalt.

Det ER fristende, at man inviterer nogle, som har udviklet en god hjemmeside for en bekendt. Og man kan ikke afvise, at det kunne være den rigtige leverandør. Men jeg vil til enhver tid anbefale, at man udvælger sin leverandør struktureret og i to trin: 

  1. a.     Vælg først system

Umbraco, Episerver, Sitecore eller hvilket system det nu må være, som passer bedst til din organisations krav. De fire systemleverandører man ønsker at sammenligne med sin tilvalgsmatrix bør være de fire på markedet, der har flest softwareleverandører. På den måde kan man som kunde undgå at blive bundet til et system, der er ved at blive udfaset, og man er ikke bundet til en implementeringspartner, men kan skifte ud, hvis der skulle opstå problemer. Med tildelingsmatrixen kan du ud fra kriterier, der er vigtige for din digitale strategi, vælge det system, der passer bedst til din organisation og dit digitale Road-map.

Bed de fire software leverandører om at udfylde din matrix, så du får deres svar på, om de kan levere på de tildelingskriterier, du har listet med standard-løsninger og -moduler. Med den vægtede score vil du kunne skære feltet ned til to systemer, som du gerne vil se præsenteret. Præsentationen bør softwareleverandøren stå for, da det er deres software, du skal vurdere og ikke implementeringspartnerens evne til at levere. Når du således har besluttet dig for det system, du gerne vil have din nye løsning baseret på, er det tid til at finde den rigtige implementeringspartner. 

  1. b.     Vælg derefter din implementeringspartner

Når du har zoomet ind på det system, du ønsker, kan du finde den implementeringsparter, der både har erfaring med systemet, og som kan forstå og leve op til jeres krav og ønsker. I denne fase ville jeg fokusere på, hvor stor erfaring implementeringspartneren har med systemet, hvor mange certificerede udviklere, der er ansat, og selvfølgelig hvor tilfredse deres kunder er med dem. 

6)    Udnyt præsentationsmødet til en god dialog

Måske tager jeg fejl. Men jeg oplever det ind imellem, som om især offentlige organisationer er for tilbageholdende under præsentations-møderne med implementeringspartnere. Måske fordi de ønsker at være så fair som muligt ved at behandle alle lige. Hvilket så ender med, at man ikke tør sige noget.

Men min påstand er, at jo mere diskussion og spørgsmål/svar man kan få frem under en præstation, jo bedre beslutningsgrundlag får man. For det viser sig næsten altid, at: 

  • Uanset om det måtte forekomme logisk, at en implementeringspartner vil være motiveret af at tjene penge, så vil jeg mene, at man ikke skal undervurdere værdien af at skabe god stemning og motivere implementeringspartneren ud over indtjeningen. Lige som en god træner eller sportsdirektør kan motivere gode fodboldspillere til at skifte til hans klub. Sørg for at gøre det vigtigt, sjovt og spændende at udvikle løsningen. Penge er ikke alt. 
  • Implementeringspartneren ved mere, end du får ud af en énvejs-samtale. Så skab en dialog i møderne. Og tag ikke fejl. Det er faktisk det mest fair, man kan gøre over for potentielle implementeringspartnere. Fordi det giver dem mulighed for virkelig at sandsynliggøre, at de kan løse opgaven. Husk på, at løsningen ikke bliver bedre end samarbejdet, og samarbejdet er fortrinsvis baseret på dialog.

Væk med berøringsangsten. Læg låg på frygten for at komme til at sige noget, som kan vise, at du ikke er ekspert. Jo bedre en potentiel samarbejdspartner forstår din tekniske indsigt, din måde at udtrykke dig på og din vision, jo bedre rådgivning får du at vælge ud fra. 

7)    Brug referencebesøg – men brug dem rigtigt

Er du på nogen måde i tvivl om, hvilken implementeringspartner, du skal vælge, vil jeg anbefale dig at bruge referencebesøg hos en af implementeringspartnerens kunder. Alt for få gør det, og hvorfor ved jeg ikke. Men det er vigtigt, at man bruger et referencebesøg rigtigt. Som nogen engang har sagt, så kan en dårlig implementeringspartner lave et kaos ud af en god platform, og en dygtig partner kan få en dårlig platform til at virke nogenlunde fornuftigt.

Så lad ikke referencebesøget drive dig fra en platform til en anden. For platformen har du allerede valgt, så objektivt som muligt med din tilvalgsmatrix. Brug referencebesøget til at vurdere implementeringspartnerens evne til at forstå og imødekomme organisationens krav og ønsker, og deres evne til at levere i dagligdagen. Og spørg om alt. Det er utroligt, hvad folk vil fortælle, hvis man blot spørger dem.

De 7 råd blev lidt længere, end jeg havde forestillet mig. Men forhåbentlig har jeg ikke fået det til at se mere kompliceret ud, end det er. For mit ærinde er faktisk det modsatte. Man kommer langt ved at bruge sin sunde fornuft og så i øvrigt bruge verdens bedste og vigtigste værktøj til al problemløsning: Dialogen. God fornøjelse!

todo todo
Kontakt
  • Adam Osbirk Moe
    Adam Osbirk Moe
    Web & Portal Lead
    +45 52189557