Issuu on Google+

BOOKINGLØSNING Dokumentasjon av arbeidsprosessen

G O

E R

O W

K R

IN

R P

S S


Dette arbeidet er pågått i perioden januar 2016 - mars 2017 Prosjekteier er dSTAB i Drammen kommune Tjenestedesigner og prosjektleder har vært Kristin Svendsen Bookinløsningen er levert av Skalar AS


Bakgrunn Drammen kommune har vedtatt en frivillighetspolitisk platform. I punkt 4.2. a) står det at:

”Kommunen stiller skolelokaler vederlagsfritt til rådighet for frivillige organisasjoner og andre ikke-kommersielle tiltak i nærmiljøet” I forbindelse med dette har det blitt bestilt en digital løsning for håndtering av utlån. Til nå har betjeningen av utlån på skoler vært en manuell rutine. Man må selv kontakte skolene for å bestille lokaler. Og man må opp til skolen i forkant (i skolen åpningstid) for å signere kontrakt og hente nøkler. Det er heller ikke alle som vet at det kan låne lokaler.

Formål Formålet med prosjektet er å lage en digital bookingløsning for utlån av skolelokaler. Løsningen skal også kunne ekspanderes til å brukes på andre lokaler ved behov. Prosjektet skal kartlegge behov og designe en ny løsning ut fra disse. Målet er en digital bookingløsning som dekker behovene både hos frivillige og hos skoler. For Drammen kommune, vil prosjektet være en del av digitaliseringsstrategien som skal sørge for og selvbetjeningsløsninger for innbyggerne. Løsningen skal kunne ekspanderes etter behov. Dette kan være både at flere typer lokaler/ressurser (ikke bare skoler) kan integreres, og at det kan åpnes opp for at den også skal brukes på lokaler som har leiepris m.m. Kildekoden skal også være åpen, slik at andre kommuner kan bruke og/eller bygge på samme løsning hos seg selv. Gjennom innovasjon i tankesett, arbeidsmetodikk og gjennomføring, samt prosjektets størrelse, vil det være et referanseprosjekt ikke bare for kommunen, men også nasjonalt. Prosjektet vil belyse viktigheten av behovsdrevet innovasjon/tjenestedesign og bidra til å digitalisere booking og saksbehandling av ledige lokaler. Det vil også gi en mer rettferdig/demokratisk tilgang på lokaler. Erfaringene vil kunne danne grunnlag for videre utvikling av bookingløsninger av andre lokaler. Det vil også gi nyttige erfaringer rundt utvikling og bruk av selvbetjeningsløsninger. Videre i digitaliseringsstrategien står det blant annet: “Målsetningen er å definere en modell hvor Drammen både har kontroll over utviklingen og etablerer klare bestillerfunksjoner, samtidig som man har fleksibilitet på valg av utfører.” Derfor må vi starte med innsikt og behov før vi går på løsning. Vi må lage anbudsutlysninger basert på behov som skal løses; en behovspec - ikke en kravspec. Beslutninger tas på bakgrunn av reelle behov og ikke antakelse.


Design thinking Hele dette arbeidet er bygd på en designmetodikk. I stedet for tradisjonell fossefallsmetode, har man et mer fleksibelt utviklingsforløp med jevnlige iterasjoner og uttestinger. Gode løsninger ikke kommer av seg selv. De kommer når man har fokus på brukerne og jobber tverrfaglig, samt at man tester ut ideer og konsepter underveis - helt fra et tidlig stadie i prosessen.

Prosessen Fase 1 - Innsiktsarbeid Innsiktsarbeidet består av de to første boksene; Empathy og Define. Det er gjennomført gjennom intervjuer med enkeltpersoner - både skoler og frivillige organisasjoner, samt andre ansatte i kommunen som har innsikt om utlån av lokaler. Dette har gitt et godt grunnlag for videre arbeid, og forståelsen av hvordan prosessen er i dag, og hva som er utfordringene med den. I analysen av intervjuene ser man at det er mange forbedringspotensialer rundt bestilling og utlån av skolelokaler. Dette er visualisert opp i en brukerreise og et business model canvas (BMC)


Fase 2 - Prototype og valg av leverandør I neste fase, gikk vi videre med Ideate, Protype og Test. Her ble det på bakgrunn av innsiktsarbeidet laget en prototype, som ble testet og justert. På bakgrunn av dette ble det gått i dialog med mulige leverandører, og det ble lagd en utlysning.

Fase 3 - MVP Her har vi valgt leverandør, og vi startet et felles arbeid med å definere en MVP. Denne ble utviklet og testet av undertegnede og ute på 3 skoler.

Fase 4 - Beta Her vil det lanseres en betaversjon, basert på resultater fra fase 3. Denne vil så testes på 3 av skolene, og med reelle brukere. Her vil det foreta brukertester som vil gi grunnlag for videre justeringer, før den slippes i endelig versjon som er fase 5

Fase 5 - Lansere Her vil vi lansere ferdig løsning som rulles ut på alle skoler.

Fase 6 - Evaluere Hva gikk bra? Hva fungerte ikke så bra? Hva har vi lært? Hva kan vi gjøre annerledes neste gang?


Plan Planen er å lage en betaversjon med noen skoler først. Da får man testet ut hvordan det funker i praksis og mulighet til å gjøre nødvendige endringer. Da sikrer man at alle skolene ikke bruker mye tid på å legge inn mye data som kanskje ikke er riktig eller nødvendig. På sikt skal det lages en fulldigitalisert løsning. Før vi starter må vi snakke med berørte parter, for å avdekke behov, muligheter og begrensninger. I første omgang må vi snakke med rektorer, skolesekretærer, andre ansatte i kommunen og frivillige organisasjoner. Deretter må funnene analyseres, slik at man finner hvilke behov som finnes. Med utgangspunkt i dette ser vi på muligheter og løsninger. Det er også viktig å kartlegge kostnader og tekniske muligheter og begrensninger. Her må man sjekke med: · Drammen eiendom. (kostnader ved evt utskiftning av låser/nøkler) · D-IKT (systemer og arkitektur. Hva må vi ta hensyn til?) · Episerver (hvordan få til best mulig løsning på Episerver? Hva vil det koste?) · Snakke med andre leverandører/se på andre løsninger enn Episerver. Når leverandør er valgt: Skissere opp løsning sammen med leverandør. Lage en pilot/MVP og teste ut på tre skoler Lansere betaversjon

Mål:

Lage en selvbetjeningsløsning for booking av ledige skolelokaler.


Fase 1 - Innsiktsfase Trinn 1 For å skaffe innsikt, ble det gjennomført intervjuer med de som skal være brukere av løsningen. Det vil si både representanter for de frivillige, administrativt ansatte, virksomhetsledere og skolesekretærer. Hensikten var å få en forståelse av hvordan brukergruppa opplever sitt behov, sine muligheter og begrensninger. Angående de frivillige, så var det viktig å snakke med både de som allerede låner skolelokaler og de som ikke har benyttet denne muligheten. De som ikke har lånt lokalene har ikke de samme rutinene og reglene i bakhodet som de som allerede benytter seg av dette. Angående skoler, var det viktig å få representert ulike typer skoler. Det ble derfor valgt ut disse tre skolene: - en sentrumsnær og stor skole med mye pågang: Marienlyst - en stor skole som ligger et stykke utenfor sentrum: Gulskogen - en liten skole som ligger utenfor sentrum: Vestbygda.

Trinn 2: Kartlegge ulike bookingløsninger som brukes i andre kommuner både i Norge, Sverige og Danmark. Konklusjon: brukergrensesnittet er gammeldags, og lite intuitivt og brukervennlig. Er også usikker på om det tilfredsstiller kravene til Universell Utforming. Risiko ved å implementere en slik løsning, vil være at brukerne ikke får gjort den jobben de skal gjøre, de gjør feil, de ringer til skolene isteden, også må skolene drive support og/eller legge inn for dem likevel.

Trinn 3: Analyse av funn.

Trinn 4: Visualisere opp brukerreise, business model canvas og lage en prototype.


Canvaset er for ĂĽ illustrere helheten i hva vi skal levere, til hvem, gjennom hvilke kanaler, i samarbeid med hvem og hvor kostnader og inntekter ligger.


Viktige funn fra fase 1: · · · · · · · · · · · · ·

Sikre personvern og rydde rommene. Sikre teknisk utstyr. Hva kan låses og hva kan ikke låses? Sikre at lokalene er pene og i stand til elevene kommer om morgenen. (ikke alltid det blir vaska bra nok selv om de som låner er ansvarlige for det). De trenger en person som kan levere ut og hente inn nøkler. Andre kostnader som toalettpapir, såpe, mm Skolen må dokumentere alt som skjer og alle kostnader de har. (Reelle kostnader.) Er de så høye at det lønner seg med tilsynsvakt? Vil en kostnad ved eventuell utbytting av låser og nøkler lønne seg? I tillegg må man tenke på skoler som har SFO Hvilke lokaler trenger de som skal låne? Forskjell på de som skal ha dansekurs og de som skal ha sjakk-kurs. Hvor mange mennesker kommer? Hvilke andre fasiliteter trengs?

Regelverk å forholde seg til: · D-IKT (systemer, løsninger, integrasjon, drift mm) · Har vi rammeavtale på utvikling av slike løsninger? · Regel om 3 ukers klagefrist. (de som får nei på søknaden har rett til å klage innen 3 uker) · 15 dagers fristen ved booking. (skolene må være forberedt og vite om det kommer noen. Ferie, fridager, foreldremøte, rydde mm)


Fase 2 - prototype og valg av leverandør Trinn 5- Lage og teste prototype På bakgrunn av innsiktsarbeidet ble det lagd en prototype. Innsiktsarbeidet ga blant annet innspill på type kategorier, behov, og viktighetsgrad. Dette ble skisset opp, og testet ut for å se om det fungerte i praksis. Testingen ble foretatt på gata (gueriljatesting) og vist frem på frivilligkveld.

Trinn 6 - Markedsundersøkelse Hva finnes av potensielle leverandører? Vi fortalte markedet at vi skulle lage en bookingløsning, og ba om tips til hvem som kunne være potensielle leverandører. Vi snakket med flere ulike leverandører og presenterte vår tilnærming til løsningen.

Trinn 7 - Workshop Her inviterte vi alle de vi hadde snakket med i forrige trinn til en halvdags workshop. I forkant av workshopen fikk alle tilsendt innsiktsarbeidet. På selve workshopen presenterte vi innsiktsarbeid og andre behov vi hadde. Deretter kom deltakerne med innspill og tips til hva man bør tenke på, da spesielt når det kom til tekniske funksjonaliteter. Vi ba også om tips til hva som er viktig å få med i en utlysning for at tilbudsforespørselen skal være forståelig og god, og for at den skal kunne svares ut på best mulig måte. Vi åpnet også opp for at leverandørene kunne snakke seg imellom.

Trinn 8 - Legge ut anbud På bakgrunn av innsiktsarbeid, testing av prototype og markedsundersøkelse, ble det lagd en behovspec. Det vil si at man ikke tok utgangspunkt i tekniske spesifikasjoner, men behov som løsningen skal dekke. I en designprosess er det som sagt viktig å teste ut og justere underveis, så det var også skrevet opp krav til arbeidsmetodikk. Tilbudsforespørselen ble skrevet med god hjelp fra innkøpsavdelingen og ble sendt ut til alle vi hadde snakket med i markedsfasen.

Trinn 9 - Velge leverandør Da tilbudene kom inn, ble disse lest nøye gjennom og vurdert opp mot kriteriene som vi hadde satt i tilbudsforespørselen. Vi valgte så den leverandøren som hadde høyest score.


Viktige erfaringer i fase 2: · Det er nyttig å ha dialog med leverandører underveis. De kan mye om tekniske løsninger som ikke vi har forutsetninger for å kunne noe om. Leverandørene var også veldig fornøyd med at vi hadde gjort et så grundig innsiktsarbeid på forhånd. På den måten var det enklere for dem å kunne beskrive en løsning de kunne levere. · Det er også viktig å ha innsiktsarbeidet på forhånd slik at man lager en behovspec og ikke en kravspec. Da sikrer man at man ikke bestiller en løsning ut fra tekniske krav, men en løsning som dekker behov og utfordringer som reelle brukere har. · Det er også lurt å sette opp krav til arbeidsmetodikk i en utlysning. Dersom man skal jobbe med en designprosess, fungerer det dårlig å velge noen som jobber etter fossefallsmetoden. I en designprosess er det viktig at man er åpen for testing og justeringer underveis, og at man ikke på forhånd vet nøyaktig hvordan sluttproduktet blir. · Det tar lang tid å skrive en tilbudsforespørsel. Spesielt når man ikke har gjort det før. Det er mye juridisk som må avklares.


Fase 3 - MVP Trinn 10 - Oppstart av prosjektet Etter vi hadde valgt leverandør, signerte vi kontrakt og starta prosjektet, Vi hadde en oppstartsworkshop med hele teamet hvor vi sammen gikk gjennom innsiktsarbeid og tilbudet. Vi hadde også en forventningsavklaring og sammen definerte vi hva en MVP (Minimum viable product - minste levedyktige produkt) skulle være. Hensikten med å starte med en MVP er at det er en løsning som kan fungere alene, samtidig som den enkelt lar seg bygge ut med flere og flere funksjoner. Vi lagde også følgende milepæler: · MVP ferdig til testing i august. · Beta klar til lansering i oktober · Ferdig versjon ferdig i januar.

Trinn 11 - Testing av MVP MVP ble testa på skolene i september. . Vi testa på Marienlyst, Vestbygda og Åskollen. Denne gangen testa vi funksjonen for skolene (utlåner). Grunnen til at vi startet med dette, var at informasjon om lokalene må på plass før det er noe for lånetaker å teste. Skolene registrerte 1-2 lokaler hver. Vi fikk tilbakemeldinger på hva som funket bra og hva som var utfordringer. Det ble også foretatt jevnlig test av funksjoner og layout underveis i prosessen. For å registrere og følge opp feil og mangler ble det brukt GitHub. Dette gir en enkel oversikt over alle oppgaver som skal gjøres og hvor man er i prosessen. Samt at det er enkelt å legge inn kommentarer og tagge andre. Det kom også igjen opp andre utfordringer som må løses utenom den digitale løsningen. Dette gjaldt blant annet hvordan man skal håndtere rydding, nøkler, tyveri mm.

Trinn 12 De andre utfordringene som må tas tak i ble presentert på styringsgruppemøte.


Viktig erfaring og læring fra fase 3 · Det er veldig nyttig å ha et arbeidsmøte med hele prosjektgruppa med en gang. Hvor man presenterer innsikt, og går gjennom tilbudet, og sammen definerer hvordan prosessen skal være, og definer en MVP, slik at alle har en felles forståelse av hva som skal løses. + at alle er med å bidrar med sine innspill og sin kunnskap inn i hvordan vi kan lage en best mulig løsning. · Det er også fint å ha med en fra teamet hos leverandør ut på brukertest, slik at de får førstehåndskunnskap med hvordan løsningen fungere for brukerne. · Det er viktig å ha forankra hvem som skal være med på testingen, slik at skolene forplikter seg til å delta og følger opp. · Det at skolene/brukerne involveres gjør også at de føler seg hørt og får komme med sine innspill og at vi lager noe som gjør deres arbeidsdag enklere. · Det er viktig å ha noen som er ansvarlig for å følge opp og løse andre utfordringer som dukker opp ved en slik løsning. Å ha en direktekontakt her ville vært fordelaktig. Å gå linja hver gang, kan by på utfordringer i form av hviskeleken; informasjon blir borte på veien. Det anbefales å ha jevnlige, faste møter hvor man får gått gjennom og fulgt opp utfordringer fortløpende.


Fase 4 - Betaversjon Trinn 13. Utvikle og lansere Betaversjon. Planen var at denne skulle lanseres i oktober Den ble utsatt pĂĽ grunn av utfordringer med ĂĽ koble opp mot ID-porten og kontakt og reservasjonsregisteret. Testingen av betaversjonen starter derfor i februar. 4 skoler vil vĂŚre med ĂĽ teste i denne perioden.


Viktig erfaring og læring fra fase 4 · Det er lurt å starte tidlig når man skal implementere noe fra en 3. part. Selv om man har lagt opp tid til utvikling, er det ikke sikkert 3. parten har tid eller kapasitet til å følge opp akkurat da. Det kan også dukke opp andre utfordringer som det tar tid å finne ut av. Læringen er at man heller starter noen uker for tidlig neste gang.


Fase 5 - Lansere Trinn 14 Ferdig versjon ferdig i januar. Blir utsatt. Mü rekke ü teste betaversjonen før vi lager den ferdig.


Viktig erfaring og lĂŚring fra fase 5


Fase 6 - Evaluere


Viktig erfaring og lĂŚring fra fase 6


Vedlegg



Booking work in progress