Guide til udvikling af mobile løsninger i det offentlige

3 - Behovsafklaring

Forretningsmæssige behov er grundelementet i alle it-projekter. De står dog sjældent alene og skal ses i sammenhæng med hvilken funktionalitet der er mulig med aktuel teknologi samt tilgængelige ressourcer (økonomi, tid og personale). Dette afsnit vil beskrive nogle af de elementer, der indgår i en behovsopgørelse for et mobilprojekt, mens de følgende afsnit vil belyse afklaring af funktionalitet og indhold (afsnit 4), hvilke overordnede løsningsplatforme der findes (afsnit 5), samt afklaring omkring sikkerhed (afsnit 6).

Nedenfor gennemgås først modenheden på området,og herefter den egentlige behovsafklaring i form af væsentlige elementer til en analyse.

Behovsafklaringen er den første del af et mobilprojekt og sker, inden det egentlige anskaffelsesprojekt starter. Modellen er baseret på den fællesoffentlige it-projektmodel fra Ministeriernes projektkontor i Økonomistyrelsen.http://www.digst.dk/Styring/Statens-projektmodel/IT-projektmodellen

3.1 - Modenhed på mobile platforme

Teknologien

Udviklingen på området sker meget hurtigt og antallet af nye muligheder er ligeledes voksende. Nogle teknologier er udbredte på de fleste mobile platforme og kan derfor udnyttes, når man udvikler sin løsning. Eksempelvis er GPS og anden lokationsbestemmelse relativt udbredt, antallet af velgennemprøvede løsninger er højt, og der findes standardiserede metoder til at benytte teknologien. Desuden findes der gode alternativer, man kan falde tilbage på, hvis ikke GPS understøttes.

Omvendt er eksempelvis kun få mobile enheder i stand til at læse såkaldt NFC-chips, selvom man forventer, at teknologien vil få stor succes de kommende år. Behov for at benytte umodne teknologier og risikoen ved dette, samt hvilke alternativer man kan tilbyde, bør derfor være et opmærksomhedspunkt i behovsafklaringen.

Brugerne

Modenhed er heller ikke en entydig størrelse hos brugerne, da nogle teknologiske muligheder anvendes betydeligt mere end andre. Langt de fleste af brugerne har eksempelvis sendt og modtaget en SMS, mens betydeligt færre har installeret en applikation på en mobil enhed eller benyttet en mobil enheds GPS til navigere på et kort.

Det er forventeligt, at modenheden inden for brug af mobile teknologier fortsat vil stige hos brugerne. Tilsvarende vil modenheden også stige hos leverandørerne samt de offentlige myndigheder, der får udviklet og tilbyder mobile services. Bred anvendelse af mobile teknologier og løsninger er dog stadig nyt og ikke udbredt til alle brugerne, og set i det lys bør det betragtes som et umodent felt.

Myndigheden

Mobile løsninger har stadig nyhedens interesse. Alene det, at en myndighed vælger at levere en mobil løsning til brugerne, kan således stadig skabe opmærksomhed og omtale. Det er naturligvis positivt, hvis formålet med projektet alene er at skabe opmærksomhed og øge brandingværdien af et produkt eller en organisation. Derfor kan en mobil løsning være et muligt reklame-/markedsføringsinitiativ, som kan give værdi for en myndighed.

Som udgangspunkt bør opmærksomheden dog som oftest være rettet mod ikke at blive grebet alene af teknologisk interesse eller nyhedsværdi, men i stedet være på den forretningsmæssige værdi, som den tiltænkte anvendelse giver - nøjagtigt ligesom for andre it-projekter.

Det første af de fem principper for gennemførelse af it-projekterhttp://www.fm.dk/publikationer/2010/1969_professionalisering-af-arbejdet-med-it_projekter-i-staten/beskriver netop, at alle muligheder skal anvendes med et forbehold for modenhed:

Staten skal være ambitiøs i forhold til digitalisering af den offentlige sektor, men skal kun gå forrest i anvendelsen af umodne tekniske løsninger, såfremt der er særlige perspektiver ved at foretage en sådan satsning.

Mens det tredje princip fastslår, at:

Kun projekter med klart beskrevne omkostninger, gevinster og effekter bør gennemføres.

Et mobilprojekt bør derfor, som andre offentlige it-projekter, have fokus business casen for løsningen. Ved udarbejdelse af business cases bør (og i visse tilfælde skal) offentlige myndigheder benytte Statens Business Case-model.http://www.digst.dk/Styring/Statens-projektmodel/Statens-Business-Casemodel I vejledningen til Business Case-modellen kan følgende udsagn være særligt relevant:

For det første bliver det med nærværende business case-model obligatorisk at beskrive institutionens fremtidige driftsudgifter – både med og uden projektets gennemførelse. Dette skal være med til at sikre, at der i forbindelse med effektiviseringsprojektet kan dokumenteres en reel forbedring af driften. Det bliver således forudsat, at projektejeren kan dokumentere overfor beslutningstagere, at projektet vil bidrage positivt på de samlede driftsudgifter.

For det andet skelnes der i den reviderede business case-model for it-projekter mellem økonomiske gevinster, der har en direkte effekt på en institutions budget og de effekter, der generelt forbedrer mulighederne for erhvervslivet, borgerne, etc. I den nærværende business case-model kan kun medregnes gevinster, der kan indbudgetteres og henføres til en specifik institution.

For det tredje skal ikke-økonomiske gevinster opgøres langt mere detaljeret og ikke mindst kvantificeres. Det vil således være nødvendigt at dokumentere ikke-økonomiske effekter systematisk og vurdere risikoen for, at det potentielt ikke er muligt at realisere disse.Vejledning til Business Case-modellen s.7

Typisk kræver det et vist kendskab til de teknologiske muligheder at kunne øjne innovative løsningsmodeller. Derfor bør nysgerrigheden anspores ved at holde sig orienteret i forhold til teknologier og andres erfaringer samt om muligt opbygge egne erfaringer og ikke mindst lydhørhed over for brugernes egne ideer og forslag.

Det anbefales derfor, at myndigheder starter med mindre og billige mobile løsninger, da erfaringerne fra de første projekter vil skabe en meget bedre forståelse for muligheder og udfordringer ved sådanne løsninger og ikke mindst de særegenskaber, der findes for anskaffelsesprojekter af mobile løsninger.

Behovsanalyse

Der findes flere veldokumenterede metoder til at lave en behovsanalyse. En hyppigt benyttet metode er at foretage en såkaldt GAP-analyse, hvor man beskriver en nuværende status og sammenligner denne med en ønsket status for en given situation. Forskellen mellem disse beskriver netop, hvad der skal til for at opfylde behovet - og om det derfor er investeringen værd.http://ea.oio.dk/arkitekturmetode/trin/gap/d3-gap-analyse

Hvad enten man vælger at foretage en GAP-analyse eller benytter en anden metode, bør analysen dog adressere de punkter, som er nævnt i det følgende.

Idéfasen

Alle projekter starter med en idé - nogle ideer vil være nye og innovative måder at løse en opgave på, andre vil være muligheden for at få en større anvendelse af allerede eksisterende løsninger, mens nogle ideer vil være affødt alene af nysgerrighed efter at udforske de nye teknologiske muligheder.

Den egentlige idefase starter først, efter at en ide er opstået (nogle gange fanget i et par centrale slides eller formelt skrevet i et kommissorium). I idefasen sker den første modning, hvor potentielle gevinster vejes op imod et overslag på omkostningerne. Dette udmøntes i et udkast til en projektplan, som beskriver, hvordan projektet kan kvalificeres yderligere i analysefasen samt hvilke ressourcer, dette vil kræve.

Arbejdet med behovsafklaringen vil i praksis have et forløb med en vekselvirkning mellem at beskrive den nuværende ide og mulige alternativer - eventuelt baseret på teknologiske løsningsmodeller som fx om løsningen skal være et mobilt optimeret netsted eller en applikation.

Afklaring af ydre og indre omstændigheder

Formålet med analysen er at fastlægge, om ideen vil give den forretningsmæssige gevinst, som ligger til grund for den. Såfremt det er tilfældet, bør analysen indgå i projektets projektinitieringsdokument eller tilsvarende, som vil danne baggrund for det egentlige anskaffelsesprojekt.

Trends i anvendelsen af mobile løsninger i forretningsdomænet

Mængden af mobile løsninger eksploderer i disse år. I takt med, at smartphones og tablets vinder udbredelse, er mobile applikationer blevet et stort marked, og der findes et stort antal applikationer til de mest udbredte mobile platforme. Dertil skal lægges mobile netapplikationer og mobiloptimerede netsteder.

Myndigheden bør overveje og argumentere for, at denne tendens også kan omsættes til det forretningsområde, som myndigheden beskæftiger sig med. I den forbindelse kan det være nyttigt at besvare følgende spørgsmål:

  • Kan lignende myndigheder vise eksempler på velfungerende mobile services?
  • Findes der tilsvarende eksempler i udlandet på velfungerende mobile services?

Dette punkt kan være med til på et tidligt tidspunkt at afklare, hvorvidt myndigheden er en first mover på området, eller om der er erfaringer fra andre løsninger, som myndigheden kan drage nytte af.

Ligeledes kan punktet give input til platformsafklaringen, da man allerede på dette tidspunkt vil kunne få en indikation af, om der findes standardløsninger på området, eller om løsningen eventuelt skal udvikles fra bunden.

Udbydes løsningen allerede i en anden form?

I forlængelse af ovenstående er det ligeledes vigtigt at overveje, om en eksisterende løsning kan benyttes frem for at bygge en helt ny.

Hvis en eksisterende løsning rent faktisk virker tilfredsstillende, bør man som udgangspunkt ikke bygge en ny, med mindre man kan påvise effektiviseringsgevinster eller værdiskabelse, der overstiger omkostningerne ved den nye mobile løsning.

Er der mulighed for partnerskaber med andre myndigheder?

Meget funktionalitet i mobile løsninger er generisk og kan benyttes indenfor flere forretningsdomæner. Det kan eksempelvis dreje sig om at vise data på kort eller formidle nyheder. Det kan af samme årsag være en god idé at undersøge muligheden for at indgå partnerskaber med andre myndigheder om den funktionalitet, der overlapper.

Det bør også afklares om en mobilløsning kan beriges med data fra en anden myndighed for at forbedre løsningen.

Er løsningens målgruppe mobil?

Selvom den generelle udbredelse af mobile løsninger stiger, er det vigtigt for en myndighed at afklare, om målgruppen inden for det konkrete forretningsområde, som den mobile løsning er tiltænkt, også har behov for løsningen og forventes at ville benytte løsningen.

Der findes mange metoder til målgruppeanalyse. Disse vil ikke blive gennemgået her, men overordnet bør de først og fremmest fastlægge, hvem den relevante målgruppe er for den mobile løsning. Herefter bør det afklares, om den tiltænkte målgruppe rent faktisk findes og er i stand til at benytte servicen, herunder mere specifikt:

  • Hvad er målgruppens behov i forhold til den mobile løsning?
  • Hvad er målgruppens motiv til at benytte den mobile løsning?
  • Hvad er løsningens relevans for målgruppen?
  • Hvad er målgruppens forventninger til den mobile løsning?
  • Hvad er målgruppens erfarings- og kompetenceniveau som bruger af mobile løsninger?
  • Og vigtigst: har målgruppen overhovedet mobile enheder i et omfang, der kan retfærdiggøre udviklingen af en mobil løsning?

Man bør ligeledes supplere med at besvare nedenstående spørgsmål:

  • Hvor ofte vil målgruppen have brug for løsningen? Kan den i bedste fald blive benyttet hyppigt, som eksempelvis en daglig vejrudsigt, eller har den en karakter, der gør, at den kun vil blive benyttet enkelte gange - eksempelvis fordi den udfører handlinger, som typisk udføres yderst sjældent af brugeren?
  • Er der omstændigheder ved konteksten, der kan påvirke, om løsningen vil blive brugt? Vil funktionaliteten eksempelvis typisk skulle bruges i mørke, under kørsel eller i stressede situationer, og har det indvirkning på, om den overhovedet vil blive benyttet?

I forlængelsen heraf kan målgruppeanalysen også give oplysninger om, hvordan løsningen skal udformes og dermed give input til funktionalitetsafklaringen.

Målgruppeanalysen vil også give værdifuld input til projektets kommunikationsplan. En kommunikationsstrategi er yderst vigtig i forhold til at opnå den ønskede udbredelse af en mobil løsning. Udarbejdelsen af en sådan vil dog ikke blive behandlet i denne guide, da der i forvejen findes litteratur om emnet.

Tilgængelighed

Krav om tilgængelighed gælder også for mobile digitale tjenester. Der findes i dag veludviklede og omfattende standarder og best practices for, hvordan digitale og webbaserede tjenester kan gøres tilgængelige, så også brugere med forskellige handikap kan anvende tjenesterne. En stor del af de standarder og best practices kan anvendes direkte på mobile tjenester, men der er specielle forhold omkring mobile enheder, som kræver særlige overvejelser. Eksempelvis er de mobile enheder begrænsede i forhold til tilslutning af eksterne apparater, der kan øge tilgængeligheden for brugere med fx kraftige synshandikap eller andre fysiske handikap.

Afklaringen vedrørende tilgængelighed bør tage udgangspunkt i aktuelle retningslinjer for, hvordan tjenester til mobile enheder bedst muligt kan gøres tilgængelige. W3C (The World Wide Web Consortium) har fx publiceret nogle retningslinjer på http://www.w3.org/WAI/mobile/ og nærmere diskussion af tilgængelige mobile løsninger kan finde på http://www.w3.org/TR/mwbp-wcag/.

3.3 - Udbud og mobile løsninger

Offentlige myndigheder skal overholde udbudsreglerne. Det er særligt relevant i forhold til mobile løsninger, for selvom selve udviklingen af løsningen er under udbudsgrænsen, vil vedligehold, videreudvikling og drift af mobilløsningen ofte over tid medføre, at udbudsgrænsen overskrides, hvorfor der skal foretages et udbud.

Dette kan være vigtigt at holde sig for øje i de tilfælde, hvor det kræves, at en applikation opdateres for at understøtte en nyere version af et mobilstyresystem. For det første vil det være hensigtsmæssigt for brugeroplevelsen at få foretaget opdateringen hurtigt. For det andet risikerer en myndighed at stå i en situation, hvor myndigheden er tvunget til at gennemføre et udbud for at få foretaget en relativ lille tilpasning af en eksisterende løsning, fordi man har overskredet udbudsgrænsen og ikke har taget højde for dette, da man indgik den oprindelige aftale. Den yderste konsekvens af dette er, at det kan være vanskeligt at finde en leverandør, der vil byde på opgaven.

Det er hensigtsmæssigt at drøfte sådanne problemstillinger med en udbudsjurist, inden projektet igangsættes. Ligeledes bør man med udgangspunkt i den øvrige behovsafklaring tage højde for fremtidige udgaver og krav til løsningen, fordi dette har indflydelse på, hvilken type aftale der skal indgås.

3.4 - Udviklingsmodeller og mobile løsninger

Der gælder de samme tommelfingerregler for projekter vedrørende mobile løsninger som for andre it-projekter: jo større usikkerhed der er om den optimale funktionalitet, desto mere egnet vil det være at køre hele projektet agilt"Agile metoder i it-baserede forretningsprojekter - Vejledning om agil udvikling i den offentlige sektor", http://digitaliser.dk/news/454078, sådan at erfaringer, der fremkommer i selve udviklingsforløbet, kan anvendes til at skabe det bedst mulige slutprodukt.

Ved it-projekter med kendt og veldefineret funktionalitet anvendes typisk den traditionelle udviklingsmetode med først at specificere hele løsningen, som derefter konkurrenceudsættes, og vinderen implementerer løsningen, som endeligt overdrages til opdragsgiveren.

For mobile løsninger kan der være stor usikkerhed om mobile teknologier, og hvordan de bedst kan bruges i forhold til et forretningsområde. Dertil kommer, at den teknologiske udvikling sker meget hurtigt og et på bare ét år kan der ske utroligt meget på området.

Ved at dele projektet op i flere ret korte iterationer, kan der med udgangspunkt i den aktuelle iteration og de erfaringer, der findes, tilføjes eller ændres i prioriteringen. Dette styrer projektet mod det bedste resultat, dog forudsat at parterne i det agile projekt er klædt på til det med hensyn til tid og kompetencer. Den høje grad af involvering vil også give en god fornemmelse af, hvordan mobile løsninger som sådan kan indgå i en større sammenhæng og dermed kan der høstes erfaringer, der vil være brugbare fremover ved andre projekter.