Prosjektsrapport, Fase 1

Prosjektsrapport, Fase 1 Muligheter og barrierer for en nasjonal kommersiell samkjøringstjeneste 1. Januar 2012 1

Innhold Introduksjon s. 3 Forarbeid og aktiviteter s. 3 Løsningen s. 4-7 Analyse og resultat s. 7 Konklusjon s. 9 Planer fremover s. 9 Prosjektregnskap s. 10 Potensiale s. 10 Oppsummering s. 11 Vedlegg s. 12-35 2

Introduksjon Sharepool har i løpet av det siste året jobbet med utviklingen av en samkjøringstjeneste hvor hovedmålet har vært å utvikle og teste tjenesten i et avgrenset geografisk område. Prosjektet har fått støtte fra Transnova og består av to faser. Denne rapporten gir informasjon om resultater, utfordringer, potensiale og videre planer fremover fra den første fasen. Forarbeid og aktiviteter Arbeidet med å lage en samkjøringstjenste startet allerede høsten 2010. I samarbeid med TØI (Transportøkonomisk institutt) ble det gjennomført en markedsundersøkelse hos noen utvalgte bedrifter i Lysaker/ Fornebu området for å undersøke interessen rundt en samkjøringstjeneste. Totalt deltok 720 personer i undersøkelsen fra 7 bedrifter. Aker Solutions, Sweco, Bærum kommune, Microsoft og Storebrand var blant disse bedriftene. Omtrent halvparten av de som deltok i undersøkelsen var positive eller interessert i en samkjøringstjeneste. Over halvparten ønsket også å bli kontaktet når tjenesten var klar. Designprosess For å kartlegge bruksmønster og behov ble det ved oppstart av prosjektet startet med å jobbe frem ulike bruksscenarioer, se vedlegg 1-7. De ulike scenariene dannet grunnlaget for videre design av brukergrensesnittet for løsningen. Videre ble det jobbet med utvikling av logo, profil, hjemmeside og innloggede sider på nett. I april ble brukergrensesnittet for mobilapplikasjonen og internettdelen fullført og utviklerne ble involvert i prosjektet. Når hjemmesidene var lansert ble det også mulig for ansatte i de deltagende bedriftene å melde seg på. Ved påmelding oppgav deltageren hvilket operativsystem man brukte (iphone, Android eller annet). Dette var for å kartlegge hvilket operativsystem som skulle brukes til tjenesten i denne første fasen. Bedrifter Fra begynnelsen av mars begynte jobben med å opprette kontakt med bedrifter i det utvalgte området. Vår strategi var å få bedriftene til å støtte prosjektet og markedsføre prosjektet internt til sine ansatte. Det ble etterhvert opprettet kontakt og avholdt møter med 15 av de største bedriftene i området. Blant disse var Telenor, Storebrand, IF, Aker Solution, Sweco og Wilhemsen. Bedriftene var generellt veldig positive til tjenesten. Noen av bedriftene ønsket å være med fra start, mens andre ville vente til neste fase i prosjektet. Mange av disse bedriftene har markedsført tjenesten internt på sine intranett-sider. Flere av bedriftene har sagt seg villig til å vurdere belønningsordninger som f. eks mulighet for fast parkeringsplass for aktive samkjørere til neste fase. Andre kontakter og relasjoner Prosjektet ble presentert for Asker kommune og Bærum kommune som valgte å støtte prosjektet med kr 50.000,- hver. Det ble også opprettet kontakt med organisasjoner som NAF, Grønn Hverdag, Miljøverndepartementet og Abelia for å få råd og støtte. Prosjektet har blitt presenteret for miljøverndepartementet og samferdselsdepartementet. Flere media har også fattet positiv interesse for prosjektet og gitt det gode omtaler (se vedlegg 8-13). Et av Sharepools mål var å se på muligheten for omgjøring av kollektivfelt til samkjøringsfelt på enkelte strekninger. Det ble derfor avtalt et møte med Staten Vegvesen hvor vi presenterte Sharepool. I møtet la vi også frem ønsket om å få teste omgjøringen av kollektivfeltet til samkjøringsfelt på strekingen E18 fra Asker til Oslo, for biler med 3 eller 3

flere personer. Denne strekningen har tidligere vært oppe til diskusjon i forbindelse med bruk av samkjøringsfelt. Vårt ønske var å teste dette i en 4 til 6 måneders periode. En slik type ordning vil kunne bidra til at flere velger å kjøre sammen og at antall peroner i hver bil vil øke. Asker kommune, Bærum kommune og NAF støttet søknaden. Desseverre valgte Vegdirektoretatet å avslå søknaden på bakgrunn av tidligere analyser gjort på den gitte strekningen. I møtet ble det også diskutert muligheten for bruk av holdeplasser som av- og påstigningsoner. Det ble ikke jobbet videre med dette i fase 1, men det er noe vi kommer til å jobbe videre med i neste fase. Andre markedsføringstiltak Andre tiltak for å verve deltakere og markedsføre prosjektet har vært vervekonkurranse, stand hos de ulike bedriftene, utdeling av flyers, markedsføring gjennom media og sosiale medier som facebook og twitter. Løsningen Etter noen måneder med designprosess og konseptutvikling ble tjenestens brukergrensesnitt klart. Brukergrensesnittet som ble benyttet i prøveprosjektet er svært enkelt. På grunn av begrensede ressurser ble det fjernet en del funksjonalitet som i utgangspunktet var medtenkt. Dette medførte blandt annet at funksjonaliteter som å kunne se reiseruten i kart måtte utelates. Her følger en beskrivelse av løsningen i fase 1, samt hvordan den er videre tenkt i fase 2: Løsningen for fase 1 som brukeren laster ned til sin telefon, den andre delen er en internettside hvor brukeren oppretter en profil og logger seg inn. Mobilapplikasjonen har i fase 1 blitt benyttet for å legge til nye reiser og å holde oversikt over reisenes status og mottatte forslag. De innloggede sidene på nett er der brukeren oppretter eller endrer på sin brukerprofil. Det er her all informasjon som navn, bilde, registreringsnummer, adresser, tider osv blir lagt til. Via disse sidene skal brukeren også definere en standardrute som er den ruten som blir benyttet i applikasjonen (se vedlegg 14 for nærmere beskrivelse av hva en rute og en reise er). Man vil kunne lage flere ulike ruter, men i løsningen for fase 1, vil man bare kunne opprette/redigere disse rutene på de innloggede internettsidene. Som beskrevet i beskrivelsen av fase 2 (s. 6) vil man senere få tilgang til alle sine ruter også på mobilapplikasjonen i fase 2. Selve applikasjonsløsningen kan enkelt beskrives med tre ulike steg: Steg 1: Planlegg reiser (vedlegg 18) Det første steget består i å planlegge og legge inn reiser for ønskede dager innenfor maksimalt to uker frem i tid (nåværende og førstkommende uke). Fra skjermbilde Mine reiser (fig. 2) kan man legge til nye reiser. Ved planlegging av en reise vil det alltid være standardruten som brukeren har definert på de innloggede sidene på nett som benyttes i mobilapplikasjonen. Det er disse adressene og tidsvinduene som automatisk kommer opp, men det er mulig å endre på tidene dersom det skulle være nødvendig. Hele førstkommende uke vil også automatisk komme opp. Dersom brukeren bare ønsker å benytte tjenesten noen dager i uken, kan han/hun fjerne uaktuelle dager. Brukeren kan også endre på sine tidsvinduer i applikasjonen (tidligst ønsket avreise og senest ønsket ankomst). Løsningen består av to deler. Den ene delen er en mobilapplikasjon 4

Steg 2: Koblingen (vedlegg 19) For å gjøre selve koblingen, har Sharepool benyttet seg av en høyteknologisk allerede utviklet tjeneste fra SINTEF. Denne tjenesten heter Spider Solution og benyttes i dag av blant annet Bakers, Diplom is og Posten for å optimalisere og effektivisere rutedistribusjonen deres. Spider har ikke blitt benyttet i denne form for persontransport tidligere, så det krevdes en del tilpassning og oppstod noen utfordringer i starten. Hvert 5. minutt gjøres en ruteoptimalisering med Spider Solution. Ved en Fig. 1 ruteoptimalisering søker Spider Solution gjennom alle reiser som er lagt inn på det nåværende tidspunkt. På grunnlag av alle adresser, tidsvinduer og andre preferanser brukeren har registrert i sin profil, vil Spider sette sammen ulike ruter. Disse rutene inneholder 1 sjåfør og minst 1 passasjer og disse vil aldri motta et forslag som ikke passer med de kravene som er satt. Dersom Spider har opprettet en rute (to eller flere er blitt koblet sammen og mottatt forslag på applikasjonen), vil denne være låst inntill alle parter har akseptert eller avvist. Dersom både sjåfør og minst 1 passasjer har akseptert forslaget, går reisens status over fra rød/gul til grønn. For en nærmere beskrivelse av statusfarger, se vedlegg 17. Steg 3: Selve reisen (vedlegg 20-21) Ved 1 time igjen til avreise er reisen fryst og ruteoptimaliseringen for denne reisen stoppes. Dette vil si at det ikke lenger kan komme til nye samkjørere på reiseruten. Når sjåfør starter reisen trykker han/hun på Start -knappen i reiseruten (fig. 1). Da vil passasjerene på reisen motta en SMS som forteller at sjåfør har startet reisen og er på vei. Mine reiser og status (vedlegg 17) I skjermbildet Mine reiser (fig. 2), som også er applikasjonens startside, vil man få en oversikt over alle planlagte reiser og deres status. Se vedlegg 17 for nærmere beskrivelse av de ulike statusene og deres funksjoner. Kostnader Det er gratis å laste ned applikasjonen og å være medlem av Sharepool. Brukeren vil bare betale for de reisene som faktisk gjennomføres. Kostnadene er basert på en deling av driftskostnader pr. km hvor alle kostnadene fordeles på antall personer i bilen. I tillegg kommer Sharepools honorar som vil ligge på alt fra fra 0.12,- til 0.25,- pr km pr person avhengig av hvor mange personer som sitter i bilen. Se vedlegg 15-16 for nærmere beskrivelse av driftskostnadene og Sharepools honorar. Løsningen registerer hvor reisen starter og slutter, og regner automatisk ut antall km. De som er sjåfør på sin standardrute må legge inn sitt kontonummer for å motta de månedelige innbetalingene fra passasjerene. Likeledes må alle passasjerer legge inn kortinformasjon. Sharepool benytter betalingstjenesten PayEx for håndtering av kostnadsflyten. Det trekkes automatisk penger fra registrert kredittkort når sjåfør starter reisen. Sjåfør får utbetalt sine penger fra passasjerene en gang i måneden. Fig. 2 5

Personvern og sikkerhet I følge markedsundersøkelsen som ble gjennomført i samarbeid med TØI, var sikkerhet en av de faktorene som brukeren fokuserte på i forhold til om man ville benytte tjenesten eller ikke. Sharepool har derfor kommet frem til noen løsninger som vil være med på å øke brukerens trygghetsfølelse: Det er ikke tillatt å bruke anonyme mailadresser som hotmail, gmail, yahoo osv. Alle brukere må registrere seg med Fig. 3 sin jobbadresse, noe som vil sikre rett personalia. Man kan velge om man vil kjøre med f. bare kvnner eller bare andre kolleger. Dersom brukeren legger inn dette i sin profil vil han/hun aldri få opp forslag som avviker fra disse kravene/innstillingene. Alle reiser blir registrert. Brukeren må taste inn en PIN-kode vertifikasjon som blir sendt til det oppgitte mobilnummeret når han/hun registrerer seg som Sharepool-bruker. Fig. 4 Se under Løsningen fase 2 for beskrivelse av flere tiltak som kan gjøres for å øke brukerens trygghetsfølelse. Fysiske rammebetingelser knyttet til av- og påstigning Passasjer vil kunne se sjåførens registreringsnr på sin mobil når reisen har statusen reise avtalt. Passasjeren kan identifisere riktig bil ved å se på bilens registreringsnummer. I tillegg vil begge parter kunne se både navn, arbeidssted og bilde. Sjåfør vil selvfølgelig også ha tilgang til passasjerens adresser. Det vil også være mulig å både ringe eller sende SMS for å kontakte samkjøreren dersom dette skulle være nødvendig. Løsningen for fase 2: Mye av designet for fase 2 er allerede ferdigstilt i fase 1. Det vil i løsningen for fase 2 fokuseres på å få inn funksjonalitet som vil gjøre tjenesten lettere å bruke og mer fleksibel. Under kommer en beskrivelse for de tre stegene med tilhørende forbedringer som er planlagt for fase 2: Planlegg reiser (vedlegg 22) Fig. 5 Det vil i fase 2 også bli mulig for brukeren å velge mellom flere ruter i selve applikasjonen fremfor å være avhengig av å gå inn på nett. I tillegg vil det bli mulig å endre adresser, tider og om man er sjåfør eller passajer på de aktuelle rutene via applikasjonen når man legger inn en ny reise. Det vil også bli mulig å velge reisevei (èn vei eller tur/retur). Disse nye funksjonalitetene vil gjøre det mye lettere for brukeren å planlegge sine reiser slik at brukeren får mer fleksibilitet. Mens man i dagens løsning bare kan legge inn tidsvinduer for tidligst avreise 6

og senest ankomst, vil man i fase 2 også kunne legge inn maks ønsket tid i bilen (fig. 3). Dette er en ny funksjonalitet som Spider Solution nylig lanserte og som vil gjøre tjenesten mer fleksibel. Koblingen (vedlegg 23) Til neste fase vil dette skjermbildet og denne prosessen være ganske så lik. Det er i lagt opp til at man kan få opp mer info om den foreslåtte personen (om personen er en favoritt eller hvor mange tommelen opp eller tommelen ned den foreslåtte personen har (se fig. 5)), men det er ikke helt avklart om dette skal gjennomføres i fase 2 enda. Det vil kunne gi brukeren ytterligere trygghet ved å se andres og sin egens oppfattning av personen. I fase 2 vil det også bli lagt til en push- funksjonalitet som vil gi brukeren beskjed på mobiltelefonen når det kommer inn nye forslag på passasjer/sjåfør, fremfor dagens løsning hvor brukeren må gå inn i applikasjonen for å se om det er mottatt noen forslag. Selve reisen (vedlegg 24) Dette steget vil få tilført en kartfunksjonalitet som gjør det mulig for sjåfør å se reiseruten i kart og for passasjer å følge sjåføren i kartet. Dette vil gjøre det mye lettere for begge parter å forholde seg til den foreslåtte reiseruten. Som passasjer vil man i tillegg til å se sjåførens registreringsnummer i skjermbilde Reiseruten (fig. 4) også kunne se bilmerke og farge for den bilen som skal hente slik, at det blir enda lettere å få øye på riktig bil. Analyse og resultat av prøveprosjektet Målet med prøveprosjektet var å teste løsningen på et lite utvalg. Det var ønskelig å se hvordan den tekniske løsningen fungerte, i tillegg til å se på bruksmønsteret til brukerne. Deltagerne ble gjort oppmerksom på at de deltok i et prøveprosjekt og at forventningene måtte stilles deretter. Underveis var det en tett dialog med deltakerene og det ble mottatt mange tilbakemeldinger. Prosjektet ble dessverre utsatt i stor grad i forhold til planlagt oppstart i aug/sept. En av hovedårsakene til dette var kapasitetsmangler hos utvikleren, slik at arbeidet ble utsatt og tok lengre tid enn tidligere estimert. Mot slutten av utviklingen ble det også oppdaget noen kritiske feil som gjorde prosjektet ytterligere forsinket. I tillegg tok godkjenningsprosessen hos Apple uventet lang tid. Selve prøveprosjektet ble gjennomført i desember. Totalt hadde 180 personer meldt seg på Sharepool. Fordi løsningen for fase 1 ble utviklet for iphone var det ca 80 personer av de totalt 180 som hadde riktig mobil og bor/jobbet i riktig område, som derfor ble aktuelle som testbrukere. Av disse 80, registrerte 60 personer en brukerprofil på nett når denne ble tilgjengelig. Utfordringer Den største utfordringen for prøveprosjektet var å få alle med en registrert brukerprofil til faktisk å gå inn og planlegge reiser på applikasjonen. Under er det satt opp flere teorier om hvorfor dette antallet ble lavere enn forventet: 1. Testperioden kom for nærme jul. Vi har fått tilbakemelding fra flere som sa de ikke fikk tid til å gjennomføre reiser nå, men at de var veldig positiv til tjenesten og ville teste den senere. Noen av argumentene har gått på private gjøremål som måtte gjøres både før og etter jobb. Eks; julefrokost i barnehagen, julegaveshopping rett etter jobb osv. 2. Ikke mulig å planlegge for nåværende uke fra første dag: På grunn av en feil under utvikling var brukeren nødt til å legge inn reiser in- 7

nen utgangen av mandagen i den nåværende uke. Noen brukere ønsket å legge inn reiser, men ble hindret da det ikke lenger var mulig etter mandag kl 24. Denne feilen ble rettet opp. 3. Optimaliseringsverktøyet Spider Solution har aldri vært brukt på persontransport tidligere, så det tok litt tid å forstå hvordan denne fungerte i praksis. Det oppstod derfor noe problemer i starten. Dessverre opplevde noen av de første som registrerte reisene sine at Spider feilet ved ruteoptimaliseringen, noe som resulterte i at de første planlagte reisene som ble lagt inn ble slettet. 4. Vanskelig å få folk til å legge inn riktige tidsvinduer slik at de fant riktig samkjører. Dette løser vi i neste fase da vi blant annet får inn en «maks tid i bil» funksjon. I tillegg er dette noe som brukeren må læres opp til å bruke på riktig måte. 5. Tjenesten måtte grunnet økonomiske begrensninger kutte noe funksjonalitet som medførte at løsningen ikke var så fleksibel som ønsket. 6. Det tar tid å få hjulene til å rulle. Mange var trege til å komme i gang. Etter flere purremail ble det observert en økning i antall registrerte reiser. Andre utfordringer De første to ukene var antall sjåfører i forhold til passasjerer omtrent 80% sjåfører til 20% passasjerer. Hver enkelt registrerte bruker ble derfor kontaktet og informert om denne skjeve fordelingen. Dette resulterte i en økning av antall passasjerer utover i uke de neste ukene i prøveprosjektet. Et annet problem som gjorde det vanskeligere å gjøre gode koblinger var rushtids innstillingene i Spider som ikke fungerte som ønsket. Dette førte til at en tur som f.eks. skulle ta 10 min ble anslått til å ta 20 min i Spider. Dette førte igjen til at noen ikke fikk match da reisen tar lengre tid enn antatt. Dette problemet vil bli lett å rette på til neste fase. mange passasjerer i forhold til sjåfører i Oslo sentrum. Sistnevnte utfordring antas å være grunnet mange kollektivreisende i sentrumsområdet og flere som vanligvis bruker bil i utkantstrøkende. En mulig løsning på disse utfordringene vil være å integrere en funksjonalitet som vil gi aktive brukere en mulighet for å se andre potensielle samkjørere, uavhengig av om disse er sjåfør eller passasjer eller tidsvinduer. Da vil en ny bruker kunne finjustere sitt søk ut ifra dette. Dette vil evt. kunne integreres på lengre sikt. På kort sikt vil denne utfordringen også kunne håndteres ved en høyere andel brukere i fase 2 som igjen vil gjøre det lettere å koble reiser med optimal person. Mange brukere fortsatte å legge inn reiser, til tross for få forslag. Dette hentyder til et sterkt enasjement, som viser at løsningen kan fungere bra ved implementering i en større skala. Totalt antall reiser i prøveprosjektet: Tilbudte reiser 135 Etterspurte reiser 118 Gjennomførte reiser 37 Her følger en analyse for hvert scenario for mobilapplikasjonsløsningen. Opprettelse av nye reiser: Denne funksjonaliteten fungerte bra. Den første uken ble det oppdaget en feil som ikke gjorde det mulig å planlegge reiser for den nåværende uken. Dette la begrensninger på fleksibiliteten ved at man måtte planlegge alle sine reiser for hele den førstkommende uken. I uke to var denne feilen rettet opp og det ble også mulig å planlegge dag for dag. Det ble observert en liten oppgang i antall registrerte reiser etter dette. En annen utfordring som oppstod utover i prøveprosjektet var en for høy andel sjåfører i forhold til passasjerer i utkantstrøkene og for 8

Koblingen: Med unntak av problemene den første uken fungerte selve koblingen med den integrerte løsningen til Spider veldig bra. Særlig med tanke på at denne løsningen aldri var brukt i denne form for persontransport tidligere. Det ble gjort flere forsøk på å finne en samkjører og i alle tilfeller hvor både tidsvinduer og adresser passet, fikk de involverte personene treff på hverandre. Denne funksjonaliteten er på mange måter den viktigste delen av tjenesten, men det var også den mest usikre i forhold til om det ville fungere eller ikke. Det er derfor meget bra at dette fungerte så bra som det gjorde, med så lite testing i forkant av prøveprosjektets start. Selve reisen: Denne delen av tjenesten fungerte også fint. På grunn av økonomiske begrensninger var funksjonalitet som f. eks. kartskjermbildet utelatt i fase 1. Dette gjorde det naturligvis vanskeligere for sjåfører å finne frem til adresser osv. Vi fikk noen tilbakemeldinger på dette. Ellers var tidene i reiseruten ganske så nøyaktige. Det oppstod noen problemer med start -knappen noen ganger som innebar en feilmelding når sjåfør prøvde å trykke på knappen. Grunnet slutt på økonomiske ressurser, var det ikke mulig å rette denne feilen under prøveperioden. Avbestille reise Det ble gjort utprøvninger på å avbestille opprettede reiser med grå, rød, gul og grønn status. Denne funksjonaliteten fungerte fint. Ved avbestilling på grønn status mottok motparten en SMS som varslet om avbestillingen. Endre tid Brukeren kunne i fase 1 endre sine tidsvinduer etter at reisen er opprettet. På grunn av en feil fra utviklernes side virket ikke denne funksjonaliteten under prøveprosjektet. Dette er en feil som ikke krever mye ressurser for å rette på. Konklusjon Målet med prøveprosjektet var som tidligere nevnt å teste ut tjenesten på et lite utvalg for blant annet å studere brukerens bruksmønster. På bakrunn av de reisene som er gjennomført er de fleste scenarioer blitt testet. Disse ukene har vært meget lærerike. Det er blitt rettet opp feil i løsningen, sett på bruksmønteret, fått tilbakemeling fra brukerne, media og bedrifter, fått testet ut Spider Solution mot Sharepools løsning og ikke minst sett at dette er en løsning som kan bidra til å få ned antall biler på veien. I testperioden ble det oppdaget noen feil, som ble rettet underveis. Pga lang ventetid hos Apple og begrensede ressurser var det også noen feil som ikke lot seg rette i denne første fasen. Planer fremover I løpet av fase 1 ble det gjort mange erfaringer på bruksmønster, kommunikasjon mot brukeren, hvilke utfordringer og fordeler tjenesten har og testing av tjenesten som vil bli veldig nyttig når vi nå går over i fase 2. Det vil bli startet med utvikling av ny funksjonalitet så fort som mulig. Mye av denne funksjonaliteten er allerede ferdig eller delvis ferdig designet og kan dermed sendes til utviklerne ganske raskt. Feil oppdaget i fase 1 vil også rettes opp. I tillegg vil tjenesten også utvikles for Android. Målet vil være å få tjenesten ferdig utviklet og deretter gjøre grundigere testing internt. Så vil tjenesten lanseres og markedsføres på nytt i Lysaker/Fornebu og flere andre geografiske områder som Skøyen, Nydalen og Oslo sentrum. Prosessen med å opparbeide gode samar- 9

beidspartnere i disse områdene er allerede i gang. Denne markedsføringen vil starte umiddelbart etter lansering. I tillegg til disse områdene, vil det også satses på en mer nasjonal markedsføring gjennom f. eks. media. Løsningen kan i prinsippet benyttes i hele landet. Det vil derfor ikke legges føringer i forhold til hvem som kan benytte seg av applikasjonsløsningen. I fase 2 vil det jobbes for et nærmere samarbeid med bedriftene. Blant annet kan det være aktuelt å få med noen bedrifter til å markedsføre seg selv som Sharepool-brukere i media og på denne måten engasjere nye og eksisterende brukere. Disse bedriftene kan tilrettelegge for sine ansatte ved å tilby egne parkeringsplasser for Sharepool-brukere. På grunn av tjenestens mangler i forhold til funksjonalitet samt at tjenesten ikke har vært ferdig utviklet før helt mot fasens slutt, har det i fase 1 blitt holdt igjen i forhold til markedsføring i media. Så fort den nødvendige funksjonalitet er på plass, vil det bli laget en mediaplan for å markedsføre tjenesten mer nasjonalt. Prosjektregnskap for fase 1 Regnskapet for 2011 (fig. 6) viser at det er i hovedsak lønn og utvikling som har vært kostnadene. Det at prøveprosjektet ble utsatt har medført at lønnskostnadene for denne fasen har blitt høyere enn antatt. Potensiale Det ut i fra både tilbakemeldinger, erfaringer og utprøvninger i fase 1 registrert et stort potensiale i løsningen. Stor interesse fra bedrifter, interesseorg. og mydigheter. En del av disse instansenene har gitt uttrykk for stor interesse, men ønsket å vente med intern markedsføring til tjenesten var klar. Det var totalt 180 påmeldte til fase 1. I fase 2 vil alle androidbrukere også kunne benytte seg av løsnigen. Det er mulig å markedsføre fase 2 for ytteligere 5 000-10 000 arbeidstakere i Lysaker/Fornebu. Da noen bedrifter ønsket å vente til fase 2 (blant annet Telenor med sine 5000 ansatte),vil potensialet fortsatt være stor i dette området. Tjenesten vil kunne markedsføres mot flere geografiske områder som Nydalen, Skøyen, Vækerø og Oslo sentrum. Har kontakter i Danmark som er interessert i tjenesten. Kommuner; Oslo, Drammen, Lier. I tillegg til Asker og Bærum som allerede har støttet oss. Potensialet ift. kommersialisering er stort. Det vil være mest utgifter i starten for å få systemet opp å gå, men det kreves ikke mye ressurser for å holde tjenesten i gang. Muligheter for være med å få ned trafikken på Norges mest trafikerte strekninger. Meget stor interesse fra media. Det er blitt holdt igjen fra både Sharepools og medias side da tjenesten ikke har vært ferdig utviklet. Det vil derfor markedsføres mye bredere i media i fase 2, så fort løsningen er ferdig. 10

På tross av noe lavere deltagelse enn foventet, fikk vi mange positive tilbakemeldinger fra brukere. Ved mer mediaoppmersomhet vil det bli lettere å generere nye brukere, samt at eksisterende brukere vil bli mer engasjert. Designet for fase to av prosjektet er grundig gjennomarbeidet og klart til å utvikles for implementering. Dette ønskes å gjennomføres så raskt som mulig for å bygge videre på det opparbeidede momentumet hos de eksisterende brukerne og alle som har vist interesse for tjenesten, som aktuelle nye brukere, bedrifter, interesseorganisasjoner og media. Sharepool ønsker derfor å kunne fortsette arbeidet så raskt som mulig. Ved å få bedriftene enda mer delaktig i prosjektet, vil det også være med på å skape mer engasjement og interesse hos de ansatte. Samkjøring er den minst ressurskrevende måten å få ned antall biler på veien, da det gjennomsnittlig er 3-4 ledige seter i biler i forbindelse med jobbreisen. Sharepool er medsøker sammen med TØI (Transportøkonomisk Institutt) på en søknad sendt til Regionale Forskningsfond Hovedstaden. Sharepool er med som demonstrasjonspart i søknaden sammen med TØI. Forventet svar på denne søknaden er i begynnelsen av februar 2012 og søknadsbeløpet er på 2 millioner til Sharepool for 2012. Oppsummering Sharepool har jobbet frem en løsning som vil gjøre det mulig for mange å kjøre sammen til og fra jobben, noe som vil effektivisere veitransporten og gi et miljøvennlig utfall. Løsningen har blitt testet i et prøveprosjekt på ansatte i Lysaker/Fornebu- området. Det har før prøveprosjektet blitt gjort et grundig forarbeid for å sikre en best mulig brukeropplevelse og skape en enkel og lettanvendelig tjeneste. Grunnet manglende ressurser har en del av funksjonaliteten blitt utelatt i prøveprosjektet. 11

Vedlegg 1 Bestille ny reise PLANLAGT -Sjåfør Bestille ny tur Planlagt -Sjåfør Christine har alltid likt å bruke bil for det gir hun forutsigbarhet og trygghet. Hun skal på jobb til samme tid hver dag og har registrert samme adresser og tidspunkter for en hel uke noen dager i forveien, unntatt på onsdag for da har hun en time hos tannlegen. Fordi hun ikke vet hvor lang tid det vil ta hos tannlegen unnlater hun å legge ut en ny registrering for reiseveien inn til jobb, men legger inn hjemreisetid. 1: Sjåfør 2a 1a Den faste jobbadressen og tidspunkter ligger allerede inne. Man kan endre om ønskelig Bekrefte adresse og tidspunkter Kopiere kjøremønster og tidspunkter for flere dager X minutter senere... Får beskjed om match foresåørsel 1a 1a 2a Her må det muligens lages en egen for sjåfør 2b3 Info om match: Navn, kart, adresser, tidsberegning osv Bestiller 2a (oversikt over tider og adresser) Avviser match Ikke svart innen timeoute-tiden 2: Passasjer velger match 3b Får beskjed at ny sjåfør aksepterer/ avviser 2a 2a (oversikt over tider og adresser) 12

Vedlegg 2 Bestille ny reise PLANLAGT Bestille ny tur Planlagt Pål liker å ha faste rutiner om morgenen både for å spare tid, men også for å unngå unødvenige stressende situasjoner. Han foretrekkr å bestille planlagte turer. Fordi han stort sett alltid skal på jobb på samme tid og sted hver dag booker han gjerne for en hel uke av gangen. Han pleier å være passasjer. 1: Passasjer Logge inn Kalender/liste over turer Bestille ny tur Den faste jobbadressen ligger allerede inne. Man kan endre om ønskelig Bekrefte adresse og tidspunkter Kopiere kjøremønster og tidspunkter for flere dager Hvert 15 min Søker etter match... Finnes ingen hensiktsmessige matcher Gjenta søket P Liste over matcher (per planlagt tur) X timer senere... Først mandag, så tirsdag, så onsdag osv.. Får beskjed når en ny match melder seg Velger match X minutter senere... Dersom avviser eller over TIMEOUTE-tiden Får beskjed at ny sjåfør aksepterer/ avviser /avvist (oversikt over tider og adresser) 30 minutters TIMEOUTE Lyd/melding på mobilen 2: Sjåfør Får beskjed om match foresåørsel Aksepterer match (oversikt over tider og adresser) Skrive inn endrede adresser og tidspunkter Valg som gjøres innen samme skjermbilde for Passasjer og Sjåfør Liste med matcher for Passasjer Liste med match forespørsler for Sjåfør 13

Vedlegg 3 Bestille ny tur Uplanlagt Passasjer (+ endre fra passasjer til sjåfør) Bestille ny reise UPLANLAGT passasjer (+ endre fra passasjer til sjåfør) Hanne har en jobb som gjør at hun stadig må endre både jobbtider og også reisevei, ofte på på ganske kort varsel. Noen dager jobber hun i bedriftens kontorlokaler, men hun er også ute på møter ulike steder i Oslo-området. Dette gjør at det ikke er hensiktsmessig å planlegge reisemønsteret så langt frem i tid. For å forsikre seg om at hun kommer seg til destinasjonsstedet prøver hun å bestille så tidlig som mulig. Som oftest vil dette si dagen/kvelden i forveien eller rett før avreise. X minutter senere... 1: Passasjer Den faste jobbadressen endres til det evt. nye kjøremønsteret Match ikke funnet Endre til sjåfør for å sjekke etter matcher Får beskjed om match forespørsel S Aksepterer match Logge inn S&P Kalender/liste over turer Bestille ny tur S&P Bekrefte/endre adresse og tidspunkter P Liste over matcher (per planlagt tur) Velger match Får beskjed at ny sjåfør aksepterer/ avviser S&P /avvist (oversikt over tider og adresser) Søker etter match... 2: Sjåfør 30 min. TIMEOUTE Får beskjed om match foresåørsel S Aksepterer match S&P (oversikt over tider og adresser) 3: Ny passasjer Velger match 14

Vedlegg 4 Bestille ny reise UPLANLAGT Sjårfør Bestille ny tur Uplanlagt Sjåfør Jan har en jobb som krever at han må reise mye rundt og dette medfører at han ikke alltid kan planlegge reisemønsteret sitt lenge i forveien. Han liker fleksibiliteten det gir å ha bil, men synes også det er dyrt. Gjennom SharePool kan han legge ut reisen med en gang han vet når og hvor han skal dra. På den måten kan han opprettholde fleksibiliteten ved å ha bil, men få ned kostnadene ganske drastisk. En liten bonus er at han også er med på å skåne miljøet. Fordi han ofte reiser til nye steder og ikke vil bruke masse ekstra tid på å plukke opp passasjerer har han gjennom SharePool spesifisert at han bare plukker opp passasjerer som befinner seg på selve kjørestrekningen. Dermed slipper han å lete seg fram til nye adresser for hver nye tur. 1: Sjåfør Den faste jobbadressen og tidspunkter ligger allerede inne. Man kan endre om ønskelig X minutter senere... Logge inn Kalender/liste over turer Registrere ny tur P&S Bekrefte adresse og tidspunkter Får beskjed om match foresåørsel Info om match: Navn, kart, adresser, tidsberegning osv Aksepterer match P&S (oversikt over tider og adresser) Avviser match 2: Passasjer velger match Får beskjed at ny sjåfør aksepterer/ avviser P&S (oversikt over tider og adresser) 15

Endre tur Sjåfør Vedlegg 5 Nils har en tur mellom hjemsted og jobb hvor han skal plukke opp en passasjer omtrent midtveis på kjørestrekningen. På veien har det skjedd en trafikkulykke og trafikken står stille. For å informere passasjeren om forsinkelsen går Nils inn på SharePool og endrer på turen at han blir mellom 15-20 minutter forsinket. Endre reise, Sjåfør 1: Sjåfør P&S Kalender/liste over turer (oversikt over nye tider og adresser) OK Logge inn P&S Kalender/liste over turer Velger den turen som skal endres og trykker Endre P&S Endre tidspunkt/ adresse (evt beskrive årsak til forsinkelsen) Passasjer bekrefter JA/NEI Avvis Sjåføren kjører resten av veien uten passasjer... Sende forespørsel om sjåføren vil godta endringen? JA/NEI 2: Passasjer JA Hvert 15 min Ingen brukbare matcher på det nåværende tidspunkt Gjenta søket X minutter senere... Får beskjed når en ny match melder seg P Dersom avviser eller over TIMEOUTE-tiden X minutter senere... P&S Kalender/liste over turer (oversikt over nye tider og adresser) OK Får beskjed om endringen (godta eller avvise JA/NEI) Avvis P Liste over matcher Velger match Får beskjed at ny sjåfør aksepterer/ avviser P&S (oversikt over tider og adresser) 30 min. TIMEOUTE 3: Ny sjåfør Får beskjed om match forespørsel S Aksepterer/ avviser match P&S (oversikt over tider og adresser) 16

Vedlegg 6 Endre tur-passasjer tur Passasjer Lise pleier å dra rett hjem fra jobb, men i dag har hun snakket med en venninne i løpet av dagen og de har avtalt å møtes rundt kl 17 på en kafè i Oslo Sentrum. Da rekker hun ikke å dra hjem først. Så fort Lise er klar over at hun må endre reisemønsteret logger hun inn på SharePool og endrer til den nye adressen. Innen ca 40 minutter kommer det opp en ny match som hun velger. Litt senere får hun beskjed at matchen aksepterer. 1: Passasjer Lagre kjøremønsteret Hvert 15 min Ingen brukbare matcher på det nåværende tidspunkt Gjenta søket Får beskjed når en ny match melder seg P X minutter senere... Dersom avviser eller over TIMEOUTE-tiden Logge inn P&S Kalender/liste over turer Velger den turen som skal endres og trykker Endre P&S Endre tidspunkt/ adresse Sjåfør bekrefter OK P Liste over matcher Velger match Får beskjed at ny sjåfør aksepterer/ avviser P&S (oversikt over tider og adresser) Sende forespørsel om sjåføren vil godta endringen? JA/NEI 2: Sjåfør NEI Får beskjed om endringen Kommer ut for salg igjen 30 min. TIMEOUTE 3: Ny sjåfør Får beskjed om match forespørsel S Aksepterer/ avviser match P&S (oversikt over tider og adresser) 17

Avbestille tur Sjåfør Vedlegg 7 Avbestille reise, Sjåfør Andreas merker kvelden i forveien at han begynner å brygge på noe. Han er registrert som sjåfør kl 08.00 dagen etter og 16.30 på ettermiddagen. Han skal plukke opp en passasjer ca 2 km fra hjemstedet sitt som ligger på vei mot arbeidsplassen. Med en gang Andreas skjønner at han er for syk for å dra på jobb logger han seg inn på SharePool og avbestiller turen. 1: Sjåfør Logge inn Kalender/liste over turer Velger den turen som skal avbestilles og avbestille Passasjer bekrefter OK 2: Passasjer Søker etter nye matcher Dersom avviser eller over TIMEOUTE-tiden 6 minutter senere... Får beskjed om avbestillingen Liste over matcher Velger match Får beskjed at ny sjåfør aksepterer/ avviser (oversikt over tider og adresser) Hvert 15 min Ingen brukbare matcher på det nåværende tidspunkt Gjenta søket 10 minutter senere... Får beskjed når en ny match (sjåfør) melder seg 30 min. TIMEOUTE 3: Ny sjåfør Får beskjed om match forespørsel Aksepterer/ avviser match (oversikt over tider og adresser) 18

Vedlegg 14 Terminologi Hva er en Rute? På de innloggede sidene på nett legger man inn informasjonen for sine ruter. Man kan ha flere ruter, men kun èn standardrute som defineres på de innloggede sidene på nett. Det er denne standardruten som vil være den som benyttes i applikasjonen når du legger til nye reiser. En rute inneholder følgende: 1. Et navn (navnet på ruten) 2. Om man er sjåfør eller passasjer 3. Adresser til jobb og fra jobb (begge reiseretninger) 4. Tidsvinduer til og fra jobb (begge reiseretninger) Standardruten vil være den som benyttes i applikasjonen. Dersom man vil benytte en annen rute vil man i dagens løsning måtte gå inn på nett for å endre standardrute. Dette vil man kunne gjøre i mobilapplikasjonen i neste fase. Hva er en Reise? En reise vil bli opprettet når man legger inn nye reiser på applikasjonen. Alle dine reiser vil du få tilgang til i applikasjonen startskjermbilde Mine reiser (fig. 2 i rapporten). En reise inneholder følgende: 1. Om man er sjåfør eller passasjer 2. Adresser til eller fra jobb (kun den ene reiseveien) 3. Tidsvinduer til eller fra jobb (kun den ene reiseveien) En reise er kort fortalt det samme som en rute, men med informasjon for bare den ene reiseretningen. Man kan derfor gå inn å endre tider eller avbestille en spesifikk reisevei uten å påvirke den andre veien. 19

Vedlegg 15 Sharepools honorar 20

Vedlegg 16 Driftskostnader 21

Vedlegg 17 Statusfarger Mine reiser (fig.1) Skjermbildet Mine reiser er brukerens reiseplanlegger. Dette er hovedskjermbildet hvor brukeren får oversikt over planlagte reiser og deres status. Ikonene til venstre i skjermbilde Mine reiser har ulik farge etter hvilken status reisen har. Nedenfor beskrives de ulike statusene: GRÅ OPPRETTET = Reisen er opprettet, men ruteoptimaliseringen er ikke begynt eller det er ikke funnet noen sjåfør til deg enda. GUL Dersom ikonet er gult vil dette si at passasjeren enda ikke har akseptert/avvist reisen. Dersom en passasjer avviser vil han/hun forsvinne fra reiseruten. Alle passasjerer med gul status forsvinner fra reiseruten i det sjåfør trykker Start. GRØNN Dersom ikonet på venstre side er grønt betyr det at passasjeren har akseptert. GRÅ Dersom en av passasjerene på reiseruten avbestiller etter en time før avreise, vil ikonet til den aktuelle passasjeren være grå. RØD FORSLAG MOTTATT = Du har mottatt et forslag. Hverken du eller sjåfør har svart enda. GUL VENTER SVAR... = Du har akseptert og venter på aksept fra sjåfør. AKSEPTER/AVVIS = Passasjer har akseptert deg. Du må gå inn og akseptere/avvise forslaget. GRØNN REISE AVTALT = Både du og sjåfør har akseptert reisen. REISE STARTET = Sjåfør har trykket start på sin app og er på vei. Sharepool gjør oppdateringer for Mine reiser hvert minutt, men dersom du ønsker en raskere oppdatering, kan du riste på mobilen. Statusfarger Reiseruten (fig. 2) Fargen på ikonene til venstre i skjermbilde Reiseruten vil indikere hvilke passasjerer på reiseruten som har akseptert reisen eller ikke: Fig. 1 Fig. 2 22

Vedlegg 18 Planlegg nye reiser Trykk på pluss-ikonet øverst til høyre for å legge til nye reiser. Din standardrute som du har definert på de innloggede sidene på nett kommer automatisk opp. Sharepool vil også automatisk legge inn førstkommende uke og alle dagene for denne uken. Trykk på endre -knappen dersom du vil fjerne noen dager eller endre tidspunkter. Du vi få opp førstkommende uke. Dersom du ønsker å legge inn reiser for nåværende uke, trykker du på uketallet. Da vil du få opp et valg hvor du kan velge denne uke. Trykk endre -knappen dersom du ønsker å endre tidsvinduer for noen av dagene. Velg de dagene du ønsker å bruke Sharepool.. Skyv på skyvelæret for å endre tidsvinduer. Trykk på ferdig -knappen når du er fornøyd. 23

Vedlegg 19 Koblingen (fase 1) Passasjer mottattt forslag på sjåfør: Rød status med hjelpeteksten Forslag mottatt indikerer at Sharepool har funnet et forslag til deg og du må inn og akseptere eller avvise dette forslaget. Dersom du aksepterer, vil reisen ligge inne i Mine reiser med gul eller grønn status (avhengig av om sjåfør har akseptert deg enda). Dersom du avviser, vil reisen ligge inne i Mine reiser med grå status inntill Sharepool finner en ny sjåfør til deg. 24

Vedlegg 20 Selve reisen, fase 2 (Passasjer) Følg sjåfør i kartet. Avreisetidspunkt 25

Vedlegg 21 Selve reisen, fase 2 (Sjåfør) 26

Vedlegg 22 Planlegg nye reiser (fase 2) 4 Velg rute 5 Endre rutedetaljer 3 Planlegg reise 6 Endre tid 2 Velg dato Man kan planlegge for en uke av gangen. Det vil alltid være førstkommende uke som kommer opp i applikasjonen. Trykk på uketallet dersom man ønsker å endre uke. 27

Vedlegg 23 Koblingen (fase 2) 28

Vedlegg 24 Selve reisen, fase 2 (Sjåfør) REISE AVTALT 12b Reiseruten_Kart_sjåfør 2 Mine reiser 11b Reiseruten_Liste_sjåfør De passasjerer som ikke har svart forsvinner fra reiseruten i det sjåføren trykker start 8b Detaljer_Stopp# 29