Forprosjekt Skattejakt Telemarkreiser Sluttrapport pr

Transkript

1 RAPPORTBESKRIVELSE Forprosjekt Skattejakt Telemarkreiser Sluttrapport pr Utarbeidet av Pragma AS på oppdrag av BIT Reiseliv, Skattejakt og Telemarkreiser Side 1 av 36

2 Dokumentinformasjon Kunde: Kontraktansvarlig Kunde Leverandør: Kontaktansvarlig Leverandør BIT Reiseliv AS Elisabeth Heyerdahl Jensen Pragma AS Håkon Klausen Opprettet: Revisjon: 1.0 Siste utskrift: :50:00 [ ] Utkast [ ] Forslag [X] Godkjent Revisjonshistorie: Side 2 av 36

3 1 Sammendrag Denne rapporten er utarbeidet i et forprosjekt av Pragma AS på vegne av BIT Reiseliv, Skattejakt og Telemarkreiser. Den tar utgangspunkt i problemstillinger knyttet til integrasjon, både spesifikt i forhold til behovene til Skattejakt og Telemarkreiser, men også behovene som er felles for alle pilotprosjektene i BIT Reiseliv. Prosjektet er også et svar på det ansvaret BIT Reiseliv har fått som tilrettelegger av prosessen med å få de regionale tilbyderne tilknyttet initiativet Nasjonal Booking, som drives frem av de store landsomfattende aktørene i bransjen. Rapporten behandler utviklingen av en utvekslingssentral for Skattejakt og Telemarkreiser. Denne sentralen vil i første omgang sørge for integrasjon mellom de 3 aktuelle portal og bookingsystemene de benytter: R360, CityBreak og Visbook. Funksjonaliteten i integrasjonen kan bygges opp stegvis og dermed tilpasses de forretningsmessige behovene til Telemarkreiser og Skattejakt. Fra starten av er det integrasjon med Visbook som er aktuelt fra både Skattejakt og Telemarkreiser. Dette vil gi mulighet for dynamisk booking av tilbydere innen destinasjoner som benytter Visbook. Sentralen skal bygges opp på en slik måte at Travel Destination løsningen også kan legges til i det planlagte hovedprosjektet (2008 / 2009). Et hovedprosjekt kan kjøres i flere faser, der hver fase vil levere ny funksjonalitet, og kursen på prosjektet kan justeres underveis ut i fra erfaringer ved faktisk bruk. Referansegruppen anbefaler at det etableres et hovedprosjekt som skal utvikle en regional utvekslingssentral. Som en del av dette prosjektet skal leverandørene av bookingløsningene tilpasse sine grensesnitt til en felles standard for tilkobling til utvekslingssentralen. Her vil også Travel Destination delta i integrasjonsarbeidet med de øvrige leverandørene. en vil gi intern kommunikasjon mellom destinasjonenes systemer og en felles eksponering mot andre kanaler (som Nasjonal Booking). I tillegg vil annen informasjonsutveksling kunne gå igjennom sentralen, så som en integrasjon med Tellus Side 3 av 36

4 2 Innhold 1 Sammendrag Innhold Innledning og bakgrunn Prosjektets mandat Organisering Arbeidsmåte Leveranser Begreper og forkortelser Situasjonsbeskrivelse Funksjonelle problemstillinger Integrasjon med tilbyderes systemer for booking Integrasjon med andre kanaler Tilby samlet booking på tvers av regionene til egne kanaler Merkantile Problemstillinger Inntektsfordeling mellom destinasjonsselskaper Kostnadsfordeling ved etablering og bruk av utvekslingssentral Betalingsmodell / kostnadsfordeling ved bruk av flere bookingmotorer Ansvarlig motpart til kunde ved booking på tvers av destinasjoner Tekniske Problemstillinger Meldingsstandarder Leverandører Oversikt Prioritert funksjonell modell Foreslått løsing Side 4 av 36

5 10 Arkitektur for en sentral Funksjonalitet Krav til leverandørene Overnatting Aktiviteter Alternative løsninger Direkte integrasjon Vedlegg: Brukerhistorier Side 5 av 36

6 3 Innledning og bakgrunn BIT Reiseliv, Skattejakt og Telemarkreiser henvendte seg i januar 2008 til Pragma for å få definert et forprosjekt i forbindelse med behov for integrasjon. Som svar på dette utarbeidet Pragma et forslag til mandat og plan for et forprosjekt som dannet grunnlaget for en avtale inngått mellom BIT Reiseliv AS og Pragma AS. Telemarkreiser og Skattejakt er fagansvarlige for dette forprosjektet som er deres fellesprosjekt i BIT Reiseliv, År 1. I henhold til denne avtalen skal Pragma kjøre et forprosjekt som skal resultere i en anbefaling til videre arbeid i et hovedprosjekt. Denne rapporten er resultatet av forprosjektet. 3.1 Prosjektets mandat BIT Reiseliv, Telemarkreiser og Skattejakt ønsker et samhandlingsprosjekt hvor 4 leverandører samarbeider (Citybreak, Visbook, Restech og Travel Destination). Hensikten er 3 delt: Muliggjøre integrasjon mellom destinasjonsselskapenes bookingsystemer (fra Visit og Restech) mot tilbydernes interne systemer (der Visbook har en stor andel av markedet). Tilgjengeliggjøre destinasjonenes samlede mengde tilbydere til andre bookingtjenester, først og fremst Color Line. Å oppnå et kryssalg av tjenester mellom destinasjonene, slik at disse til sammen fremstår som et mer attraktivt reisemål og dermed får en totalt sett større omsetning. Forprosjektet skal definere en utvekslingssentral funksjonelt, standardiseringsmessig og teknisk, slik at IT leverandører av systemer innen reiseliv skal kunne lage tilkoblinger mot sentralen. Forprosjektet skal i utgangspunktet definere en integrasjon basert på behovet Skattejakt og Telemarkreiser har i forbindelse med sitt samarbeid, men denne integrasjonen skal være utvidbar slik at flere destinasjonsselskaper skal kunne bruke denne. Forprosjektet skal arbeide med IT leverandørene for å finne løsninger der disse bærer en del av kostnadene ved en integrasjonsløsning (dekker egen nødvendig utvikling). Pragmas prosjektleder er sekretær i referansegruppen. 3.2 Organisering Prosjektet er ledet av en referansegruppe bestående av følgende personer: Dag Runar Pedersen, Skattejakt, leder Marie Bergsli, Telemarkreiser Elisabeth Heyerdahl Jensen, BIT Reiseliv Pragmas prosjektleder, Håkon Klausen, har deltatt i referansegruppen som sekretær Side 6 av 36

7 3.3 Arbeidsmåte Prosjektet har gjennomført et antall møter med ulike aktører: Workshops og møter med Skattejakt og Telemarkreiser BIT Reiseliv seminar på Reiseliv 08 Møte med Visbook på Gardermoen Møte med Tellus i Oslo Deltakelse på OTA seminar i London Møte med Restech i Kristiansand Møte med Travel Destination i Bergen Møte med Visit Technology i Gøteborg Vi har hatt dialog med de sentrale IT leverandørene til de regionale destinasjonsselskapene. Sentrale problemstillinger har vært: Hvilke integrasjonsmuligheter finnes mot systemene? Spesifikke ønsker fra Telemarkreiser og Skattejakt angående integrasjon med Visbook og ev andre hotellsystemer (for å erstatte bruk av allotments) Har leverandørene støtte for OTA standarden? Hvilke planer og muligheter er det for en ev utvikling av støtte for OTA? Hvilke tanker har leverandørene om integrasjon i det regionale reiselivet? Vil leverandøren være med på et prosjekt for integrasjon? Og i så fall på hvilke betingelser? Underveis i arbeidet har vi hatt uformelle møter og samtaler med oppdragsgiverne, samt trukket på kompetanse internt i Pragma på områder som integrasjon, datakommunikasjon, portalbygging og teknologi. 3.4 Leveranser Forprosjektet leverer følgende dokumenter: (legges ved som vedlegg/ref. eposten) Denne rapporten Presentasjon over forslaget til løsning Side 7 av 36

8 3.5 Begreper og forkortelser XML Extensible Markup Language, er en standard for å strukturere data eller beskrivelser av data (metadata) i elementer ved å bruke tekstkoding eller markeringskoder kalt tagger. Det er en enkel, men svært fleksibel og utbredt standard. EDI Electronic Data Interchange, er et sett med standarder for å strukturere informasjon som skal overføres elektronisk mellom enheter. 3.6 Situasjonsbeskrivelse De regionale destinasjonsselskapene fremstår som ulike i både eierstruktur, målsetning og finansiering/forretningsmodell, og bruker ulike IT systemer som ikke kommuniserer. Dette skaper en fragmentert virkelighet sett fra kundens ståsted. Denne fragmenteringen medfører et dårligere tilbud til kundene, økte kostnader og mindre effekt av markedsføringsmidlene. Selskapene har ulik grad av offentlig eierskap, og ulike typer bransjeaktører inne på eiersiden.. Det er flere forretningsmodeller ifm booking som benyttes av destinasjonsselskapene i dag. Noen få, som Visit Oslo, Destinasjon Lofoten og Telemarkreiser, driver virksomhet som turoperatører, og tar et ansvar for å fronte kundene i destinasjonen. Andre, som Hedmark Reiseliv, Finnmark Reiseliv og Destinasjon Geilo, driver kun som kanaldistributører. Tilbyderne har ansvar for leveranse og kundeforhold direkte mot kunden, men kun for eget produkt. Kanalen tar ikke noe samlet ansvar i henhold til pakkereiseloven. De regionale destinasjonsselskapene bruker i dag 3 ulike systemer for portalbygging og online booking (Visit, Travel Destination, Restec).I tillegg benytter en del lokale destinasjoner systemet Visbook på sine hjemmesider for å tillate on line booking av tilbydere som benytter dette systemet som internt system. Dagens situasjon illustreres med figuren nedenunder som et antall siloer, en per system. I tillegg er det også innenfor hvert IT system sperrer for integrasjon. Dette har dels tekniske, dels økonomiske og dels strategiske grunner. I tillegg har destinasjonsselskapene en forretningsmodell på å gjøre opplevelser tilgjengelige og bookbare Side 8 av 36

9 Allotments Dagens situasjon Lokale dest og turistkontor Telemarkreiser VisitOslo Destination Lofoten Skattejakt Fjord Norge Finnmark Reiseliv Destinasjon Geilo Visbook Visit Restech Travel Dest. Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Visjonen for prosjektet kan illustreres med at det etableres en utvekslingssentral som bygger bro mellom siloene. Visjon for prosjektet Lokale dest og turistkontor Telemarkreiser VisitOslo Destination Lofoten Skattejakt Fjord Norge Finnmark Reiseliv Destinasjon Geilo Andre portaler og media Visbook Visit Restech Travel Dest. Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tilbyder Tellus Side 9 av 36

10 4 Funksjonelle problemstillinger Vi kan dele problemstillingene inn i 3 hovedområder: 1. Integrasjon med tilbyderes systemer for booking. Dette er B2B integrasjon på meldingsnivå. Både Telemarkreiser og Skattejakt har flagget et sterkt behov for denne typen løsninger for å redusere bruk av allotments. 2. Integrasjon med andre kanaler (som Color Line) for å tilby dem et samlet spekter av tilbydere på tvers av regioner. Dette er enten B2B integrasjon på meldingsnivå (XML og/eller EDI), eller en HTML basert rammeløsning. 3. Tilby samlet booking på tvers av regionene til egne kanaler. Dette vil være en B2C integrasjon. 4.1 Integrasjon med tilbyderes systemer for booking Destinasjonsselskapene har en forretningsmodell som innebærer innsalg av bookingtjenester overfor tilbydere av disse tjenestene (som hoteller, campingplasser, aktiviteter etc). Generelt er det derfor viktig at bookingtjenestene fremstår som attraktive. Der er det to forhold som må adresseres: For det første må destinasjonsselskapenes portaler være en attraktiv markedskanal med hensyn på hvor stort nedslagsområde det har og hvor mange bookingen som kommer via denne kanalen. Generelt kan man si at hele dette prosjektet vil bidra til en slik attraktivitet ved at flere kanaler kan integreres og tilbyderne dermed blir bedre eksponert. Det andre forholdet omhandler mer direkte forretningsprosessene hos tilbyderne. Tilbydere har ulike løsninger for sin booking og interndrift av tjenestene. Det er disse løsningene som inneholder oversikten over faktisk tilgjengelige ressurser for booking. 1. Manuelt system (bok, arkivkort, eller lignende) 2. Hotellsystem, eget eller via kjede, (for eksempel Fidelio og Hoist). Prosjektets mandat omfatter ikke integrasjon mot disse, selv om det ikke er noen prinsipielle hindringer for at dette kan implementeres. 3. Visbook, Travel Destination, Restech eller Visit Dagens situasjon innebærer en stor grad av manuelt arbeid for tilbyderne. De må oppdatere allotments i bookingsystemet, og koordinere størrelsen på disse i forhold til egne bookinger og allotments hos andre kanaler. Bookinger kommer til dem kun på e post, og må manuelt registreres i eget system. I Telemark finnes det flere lokale destinasjoner, slik som turistkontorer og lignende, som kjører Visbook med online booking på sin portal. Mange tilbydere har allotments både i Visbook og Visit Side 10 av 36

11 Skattejakt og Telemarkreiser har derfor følgende krav til en integrasjonsmodul: 1. Dynamisk allokering: Bookingmotoren må kunne forespørre tilbyder for ledig kapasitet ved hvert søk, slik at tilbyder ikke behøver å oppdatere allotments. 2. For tjenesteytere med interne systemer som foreløpig ikke lar seg integrere med dynamisk booking er det ønskelig med felles allotments for Visbook og CityBreak/R360. Dette er i praksis samme løsning som i 1, med den eneste forskjellen at CityBreak/R360 vil booke mot allotments og ikke faktiske objekter i Visbook. Dette vil lette situasjonen bl.a. for kjedehotellene med allotments i flere systemer. 3. Bookinger sendes som meldinger til tjenesteyters system slik at manuell registrering blir unødvendig. Disse integrasjonene vil bedre destinasjonsselskapenes konkurransedyktighet overfor tilbyderne i forhold til andre kanaler. I tillegg vil vi anbefale at man ser på utvidede muligheter for rapportering av statistikk: Hvor mange reisende har søkt frem tilbyder, hvor mange reisende har bedt om detaljer om tilbyder, hvordan er forholdet mellom dette og antall søk i større regioner, osv. Dette vil være nyttig informasjon for tilbyder i deres markedsarbeid. 4.2 Integrasjon med andre kanaler Større aktører i markedet, som Color Line, har egne bookingsystemer. Det er viktig for Skattejakt og Telemarkreiser å posisjonere seg slik at de kan eksponere sine tilbydere mot Color Line. Color Line er nå i ferd med å utvikle et mer avansert system for booking, basert på teknologi fra OpenJaw. Dette vil gi store tekniske muligheter for integrasjon med destinasjonsselskapene, men også skape rom for større konkurranse om tilbyderne dersom Color Line skulle velge den linjen. Nasjonal booking/ bookingløsning for Visitnorway kan bli en annen viktig kanal. Integrasjonsløsningen må også her kunne eksponere tilbyderne mot kanalen. Selskapet Travel har som mål å lage en Nordic Travel for distribusjon og bestilling av reiser og opplevelser mellom både små og store reiselivsaktører i Skandinavia. Den tekniske nøkkelen til å eksponere seg mot og bruke tjenester eksponert av disse kanalene er XML meldinger basert på felles bransjestandarder. Bruk av disse gjør at man slipper å lage separate grensesnitt mot hver enkelt aktør. 4.3 Tilby samlet booking på tvers av regionene til egne kanaler Både Skattejakt og Telemarkreiser tilbyr i dag sine bookingtjenester som integrerbar løsning på andre aktørers portaler (som visitsorlandet.com og sorlandet.com). Dette gjøres ved en rammebasert løsning som er meget enkel å integrere Side 11 av 36

12 Løsningene gir imidlertid ikke tilgang til å booke tilbyderepå tvers av systemene destinasjonene bruker. Skattejakt og Telemarkreiser har noe ulike strategier på sin portalbygging på kort sikt. Telemarkreiser har ingen planer om å forlate CityBreak Online plattformen, mens Skattejakt er i ferd med å etablere en egen portal med content management utenfor R360. Dette påvirker arbeidet med løsningsforslag i prosjektet ved at integrasjonsbehovet ut fra Restech ikke nødvendigvis blir det samme som ut fra Visit Side 12 av 36

13 5 Merkantile Problemstillinger Prosjektets mandat omfatter ikke å evaluere merkantile problemstillinger i forbindelse med en integrasjonsløsning. Vi vil likevel dokumentere de spørsmål som har kommet opp i løpet av analyseprosessen. 1. Fordeling av inntekter mellom destinasjonsselskapene ved distribusjon av tilbydere 2. Kostnadsfordeling ved etablering og bruk av 3. Betalingsmodell / kostnadsfordeling ved bruk av flere bookingmotorer 4. Ansvarlig motpart til kunde ved booking på tvers av destinasjoner 5. Forholdet til Nasjonal Booking 5.1 Inntektsfordeling mellom destinasjonsselskaper Destinasjonsselskapene vil ha hver sine kanaler. En booking som gjøres mot en portal mot et annet destinasjonsselskap bør kunne utløse en inntektsfordelig mellom destinasjonene. 5.2 Kostnadsfordeling ved etablering og bruk av utvekslingssentral Det må etableres et avtaleverk mellom destinasjonene om fordeling av kostnader ved bruk av utveklingssentralen. 5.3 Betalingsmodell / kostnadsfordeling ved bruk av flere bookingmotorer Per i dag har destinasjonsselskapene avtale med ulike tekniske leverandører av bookingløsninger som dekker bruk av deres webløsning og søk blant tilbydere som er lagt inn i deres base. Den foreslåtte utvekslingssentral løsningen vil endre dette forholdet noe. Leverandørene av bookingløsninger vil få søketrafikk inn via XML meldinger fra en. Meldingene kan komme som resultat av søk på ulike portaler, uten at det gir noen forskjell ifra et rent teknisk synspunkt. Da søkemotorene vil eksponeres for flere kanaler vil antakelig søkebelastningen for bookingmotorene øke. Uten at denne rapporten går inn på dette forholdet vil endringene sannsynligvis medføre at nåværende driftsavtaler med IT leverandørene må reforhandles. 5.4 Ansvarlig motpart til kunde ved booking på tvers av destinasjoner Det eksisterer ulike modeller innen destinasjonene med hensyn på hvem som er ansvarlig leverandør av en tjeneste som kunden bestiller på kanaler tilhørende en destinasjon. 1. Direkte til tilbyder. Systemet overfører betaling direkte til tilbyder Side 13 av 36

14 2. Provisjon / ikke refundertbart forskudd til destinasjonen, oppgjør på stedet direkte med tilbyder. Denne modellen benyttes av Skattejakt i forbindelse med en del overnattingstilbydere. 3. Full betaling til destinasjonen, som remitterer tilbyder. Dette er modellen som benyttes av Telemarkreiser, samt av Skattejakt i forbindelse med aktiviteter. Alle disse modellene fungerer ved enkle bookinger mot en tilbyder eller ved samlebookinger med flere ansvarlige motparter. For samlebookinger av produkter fra flere tilbydere som pakkes av en leverandør og samlebetales vil denne modellen ikke fungere. Modell 2 vil ikke fungere i tilfeller der man ønsker en større grad av forskuddsbetaling, eller tilbyder ikke ønsker å håndtere betalingsstrømmen selv. I et senario med samarbeid Skattejakt Telemarkreiser vil tilbyderne i Telemark ikke få samme sikkerhet for betaling ved no show som de har i dag mot Telemarkreiser, og vil antakelig derfor være tilbakeholdne med å akseptere bookinger fra Skattejakt. Modell 3 fungerer ved samlebestillinger over flere tilbydere i regionen. Dersom destinasjonen som eier portalen inngår avtaler med andre destinasjoner om eksponering av deres tilbydere på sin kanal, kan modell 3 også fungere. Problemet med modell 3 oppstår når andre kanaler skal gjøre en booking, og det ikke entydig kan identifiseres en enkelt destinasjon som kan ta kundeansvaret Side 14 av 36

15 6 Tekniske Problemstillinger 6.1 Meldingsstandarder Det finnes etablerte standarder for kommunikasjon i bransjen. De viktigste er: OpenTravel Alliance (OTA) OTA utvikler åpne XML meldingsstandarder for bransjen. Vi har som en del av prosjektet vurdert standarden, både med hensyn på organiseringen rundt den og den tekniske kvaliteten på standarden. OpenTravel er en selv finansierende, non profit organisasjon som definerer åpne meldingsstandarder basert på XML. Organisasjonen ble grunnlagt i 1998 av ledende flyselskap, hotellkjeder, bilutleiefirmaer, distributører og teknologileverandører. Medlemmene kommer fra alle segmenter av reiselivsindustrien. OpenTravels rolle er å tilby en akseptert struktur for elektronisk overføring ved å bruke XML meldinger. Organisasjonen gjør dette ved å bygge et forum av leverandører som definerer skjemaene. Skjemaene er åpne, det vil si at spesifikasjonene kan tas i bruk uten lisenskostnader. Skjemaene videreutvikles og revideres etter en formelt definert prosess. Det leveres 2 nye versjoner med skjemaer hvert år. Figuren nedenfor skisserer stegene i denne prosessen: OTA har kun en minimal administrasjon som ansatte ressurser, pt. 2 årsverk. Alt teknisk arbeid gjøres av medlemsbedriftene. Dette sikrer at standarden blir videreutviklet utfra faktiske behov i bransjen Side 15 av 36

16 Eksempel på XML melding etter OTA standarden: Søk etter tilgjengelig hotell i Dalen for 4 netter fra 7. Juli 2008, 2 voksne og 2 barn på hhv 6 og 13 år. <?xml version="1.0" encoding="utf-8"?> <OTA_HotelSearchRQ Version="0.1" xmlns=" xmlns:xsi=" xsi:schemalocation=" d"> <POS> <Source> <RequestorID Type="13" ID="Skattejakt" ></RequestorID> </Source> </POS> <Criteria AvailableOnlyIndicator="true"> <Criterion><HotelRef PropertyClassCode="20" ></HotelRef></Criterion> <Criterion> <Address><CityName>Dalen</CityName></Address> <StayDateRange Start=" " End=" "></StayDateRange> <RoomStayCandidates> <RoomStayCandidate> <GuestCounts> <GuestCount Age="6" Count="1"></GuestCount> <GuestCount Age="13" Count="1" ></GuestCount> <GuestCount AgeQualifyingCode="10" Count="2" ></GuestCount> </GuestCounts> </RoomStayCandidate> </RoomStayCandidates> </Criterion> </Criteria> </OTA_HotelSearchRQ> Travel Technology Initiative (TTI) TTI utvikler hovedsakelig EDI standarder for integrasjon mellom ulike reiselivsaktører. I forhold til XML standarder for samme funksjonalitet deltar de aktivt i OTA, og utvikler ikke egne standarder for dette. I dette prosjektet har vi ikke sett nærmere på disse standardene Proprietære standarder R360, Visbook og Travel Destination har alle sine integrasjonspunkter som benytter egne definisjoner av meldinger. Disse meldingene lar eksterne systemer utføre søk, lese resultater og gjøre bookinger mot systemet Side 16 av 36

17 CityBreak har 2 ulike API løsninger. CityBreak API tillater eksterne portaler å utføre søk og gjøre bookinger mot systemet. CityBreak Aggregator Travel tilbyr et totalt integrert og transparent miljø med aksess til eksterne ressurser fra CityBreak reservasjonssystem. Interne og eksterne ressurser kan mikses og brukes sammen ved dynamisk pakking. I CityBreak benyttes i større grad OTA XML, men her er det en del innslag av egendefinerte meldingsstrukturer, noen som en utvidelse av OTA. I tillegg til OTA har Aggregator støtte for et omfattende sett av proprietære meldingsstandarder mot andre systemer og GDS er Side 17 av 36

18 7 Leverandører Innenfor sfæren av regionale destinasjonsselskaper (som er fokuset for dette prosjektet) er 4 leverandører av systemer dominerende. Leverandørene har noe ulikt fokus på sin virksomhet, og også ulik funksjonalitet og bruksområde. R360 er et forretningskritisk system som kan håndtere alle ressurser som et såkalt PMS (Property Management System). Systemet kan også utnyttes som et Destinasjons Håndterings System med sentral bookingfunksjon. R360 kan også tilby pakker på tvers av bookingsystemer vha Net2Net integrasjonsløsningen til Restech. Visbook er et bookingsystem med fakturering, reskontro, kassatelling, regnskapsrapportering og CRM. Tilleggsmodul for online booking på internett. Travel Destination er utviklet for og sammen med destinasjoner og deres tilbydere. Løsningen har sitt utgangspunkt i BIT Reiseliv (prosjekt i regi av NHO Reiseliv, HSH og Innovasjon Norge) sin satsning på teknologi for reiselivsnæringen. Travel Destination er dermed en skreddersydd for løsning for booking på internett, som er designet ut fra den reisendes, tilbydernes og destinasjonenes behov. CityBreak fra Visit lar Destinasjonsselskaper, turoperatører, reisebyråer og hotellgrupper etablere ende til ende relasjoner med kunder, tilbydere og partnere. CityBreak tilbyr verktøy for å pakketere, distribuere og selge overnatting, transport, aktiviteter, attraksjoner og andre reiserelaterte produkter. De tilbyr også en funksjonalitet for kommunikasjon med eksterne systemer, og har implementert connectorer til en rekke av disse, bl.a. store GDS er Side 18 av 36

19 7.1 Oversikt Leverandør: Visbook AS RRT (Restech) VTG (Visit) Travel Destinations Produkt: VisBook R360 Citybreak Professional Travel Destination Antall kunder/lisenser: Antall årlige bookinger: / Plattform: Linux og MS Windows server Windows, Unix, Linux, RDP/ Citrix ICA klient Microsoft.NET Microsoft.NET ASP, egen/leid server, etc. Flere egne servere hosted på ulike lokaliteter ASP ASP, egen server ASP Utviklingsverktøy : VB.Net, MS VC++, C++, Python, blackdown-jdk, netbeans Delphi 7 C++ VB.net, ASP.net Lagringsformat data: MySQL database, kan utveksle data API, ingen utveksling, noe eksport av tekst Microsoft SQL, ingen utveksling per idag MS SQL, kan utveksle data Side 19 av 36

20 8 Prioritert funksjonell modell Forprosjektet har som hovedmål å definere en løsning som dekker behovene til Skattejakt og Telemarkreiser. Løsningen som defineres skal være slik at den kan utvides til å dekke behovene til andre destinasjonsselskaper om dette blir ønskelig på et senere tidspunkt i det planlagte hovedprosjektet. Skattejakt og Telemarkreiser benytter hhv R360 og CityBreak. I tillegg har begge ønske om integrasjon med Visbook ifm dynamisk booking av objekter der. Den funksjonelle modellen vil derfor begrense seg til å dekke disse 3 systemene. I tillegg vil modellen kun adressere de behov som faktisk er fremkommet i dialogen i prosjektet. Disse spesifikke behovene er (i prioritert rekkefølge): 1. Telemarkreiser ønsker dynamisk booking av objekter i Visbook fra sin portal definert på CityBreak. 2. Skattejakt ønsker mulighet for å definere en egen portal til erstatning for portalen som nå er definert i R360. Via denne ønsker man å kunne dynamisk booke objekter i R360 og i Visbook. 3. Telemarkreiser ønsker mulighet for dynamisk booking av objekter i R360 fra sin portal definert på CityBreak. 4. Skattejakt ønsker mulighet for dynamisk booking av objekter i Telemarkreisers CityBreak installasjon fra sin nye portal. 5. Telemarkreiser ønsker å kunne søke og booke en felles handlekurv på tvers av de 3 bookingsystemene. 6. Skattejakt ønsker å kunne søke og booke en felles handlekurv på tvers av de 3 bookingsystemene. Disse behovene er mer detaljert beskrevet i et sett med brukerhistorier som finnes vedlagt. Oppdelingen her følger av integrasjonsmulighetene i dagens system, planlagt videreutvikling av portalen til Skattejakt og en naturlig oppdeling av et implementeringsprosjekt Side 20 av 36

21 9 Foreslått løsing Basert på de foregående problemstillingene har prosjektet og referansegruppen arbeidet frem en anbefaling til løsning. Prosjektet foreslår å bygge opp en utvekslingssentral for å ivareta integrasjonsbehovene. Denne skal baseres på den åpent tilgjengelige OTA standarden for å sikre en konsistent og kostnadseffektiv tilknytning av alle interessante bookingløsninger. Eierskapet til utvekslingssentralen må utredes nærmere. Figuren nedenfor viser hvordan utvekslingssentralen dels muliggjør dynamisk booking mot Visbook, men også på sikt muliggjør kryssbooking av ressurser mellom portalene til Telemarkreiser og Skattejakt. Konseptuell modell: Sentral for Telemarkreiser og Skattejakt Konseptuel modell Mittsorland Tilbyder Skattejakt Restech Reise kunde Tilbyder Tilbyder Tilbyder Telemarkreiser Visbook Visit Visittelemark - Andre kanaler kan kobles på senere Prosjektet anbefaler at det etableres et hovedprosjekt som skal utvikle en regional utvekslingssentral. Som en del av dette prosjektet skal leverandørene av bookingløsningene tilpasse sine grensesnitt til en felles standard for tilkobling til utvekslingssentralen. Her vil også Travel Destination delta i integrasjonsarbeidet med de øvrige leverandørene Side 21 av 36

22 en vil gi intern kommunikasjon mellom destinasjonenes systemer og en felles eksponering mot andre kanaler (som Nasjonal Booking). I tillegg vil annen informasjonsutveksling kunne gå igjennom sentralen, så som en integrasjon med Tellus. Et hovedprosjekt kan kjøres i flere faser, der hver fase vil levere ny funksjonalitet, og kursen på prosjektet kan justeres underveis ut i fra erfaringer ved faktisk bruk. I figuren under har vi indikert hvilke integrasjoner som vi anbefaler implementert i første fase av hovedprosjektet. Sentral for Telemarkreiser og Skattejakt Prioritert i Leveranse 1 Restech Telemarkreiser - Visbook Skattejakt - Visbook Skattejakt Restech Visbook Utvekslings Sentral Skattejakt Visit Telemark reiser - Andre kanaler kan kobles på senere Sentralen sørger for transparens overfor underliggende bookingmotorer, ved å eksponere et OTAbasert meldingssett som skal være implementert hos bookingmotorene. Sett fra Telemarkreisers portal implementert i CityBreak Online vil man da kun trenge å implementere ett grensesnitt ut fra Integrator i stedet for to, og dette vil være OTA basert. Dette vil minske tilpassingskostnadene i CityBreak, og åpne for kommunikasjon med andre bookingmotorer i fremtiden. Tilsvarende vil en nyutviklet portal i regi av Skattejakt kunne forholde seg til ett grensesnitt Side 22 av 36

23 10 Arkitektur for en sentral Prosjektet har definert en konseptuel teknisk arkitektur for en som kan støtte alle krav som har fremkommet i prosjektet. Denne er beskrevet i et eget dokument. Vi ser imidlertid at en slik sentral bør bygges i flere trinn, der man starter med en basisfunksjonalitet. Dette kapitlet vil beskrive denne basis arkitekturen og funksjonaliteten den gir. Sentral for Telemarkreiser og Skattejakt Modularkitektur Requestors Reposi tory Log Business Layer TCP Portal Booking Sentral WS ComFX City Break Aggregator WCF WS Providers R360 Visbook CityBreak 10.1 Funksjonalitet Sentralen vil støtte et transparent OTA basert grensesnitt inn fra portaler. I første versjon vil et subset av følgende meldinger støttes: OTA_HotelSearchRQ/RS OTA_HotelAvailRQ/RS OTA_HotelResRQ/RS Dette vil gi muligheter for booking av overnatting med de søkeparametere som benyttes i dagens løsninger Side 23 av 36

24 Vi ser for oss bruk av følgende OTA meldingstyper: Situasjon Meldingstype Kommentar Booke aktivitet Søke etter aktiviteter Spørre på tilgjengelighet på aktivitet Lete etter overnatting basert på sted Be om beskrivende informasjon om hotell Søke etter ledige rom Forespørre en reservasjon basert på dynamisk allokering 7.2 OTA_DestActivityResRQ/RS PT ingen OTA meldingstype definert, implementasjon må foreløpig definere egen meldingstype PT ingen OTA meldingstype definert, implementasjon må foreløpig definere egen meldingstype 9.27 OTA_HotelSearchRQ/RS Returnerer en liste basert på kriterier. 9.7 OTA_HotelDescriptiveInfoRQ/RS Returnere beskrivende tekst og bilder. 9.1 OTA_HotelAvailRQ/RS 9.21 OTA_HotelResRQ/RS Kansellere en reservasjon eller deler av den OTA_CancelRQ/RS Må ev utvides til også å håndtere aktiviteter 10.2 Krav til leverandørene Vi ser for oss følgende operasjoner som skal støttes mot bookingmotorene: Overnatting 1. Mottak av OTA meldinger for søk etter overnattingssteder. Meldingen vil inneholde en liste over destinasjonsselskaper det søkes på vegne av. Søket kan være på område og type overnatting, kan også inneholde kriterier på tilgjengelighet for et tidsrom og et antall personer. 2. Utføre søk i henhold til melding 1 blant alle tilbydere som har avtale med ett eller flere av destinasjonsselskapene på listen Side 24 av 36

25 3. Retur av OTA melding med liste over overnattingssteder / aktiviteter som tilfredsstiller søkekriteriene, ev med retur av kun de som har tilgjengelighet i forespurt periode. 4. Mottak av OTA meldinger for spørring på tilgjengelighet av en tilbyder på overnatting. Mulighet for å be om reservering av tilbud i et tidsrom (10 15 minutter). 5. Retur av OTA melding med tilgjengelighet og pris. 6. Mottak av OTA meldinger for reservasjon av tilbud på overnatting (booking). Skal støtte to betalingsmodeller: Avsender av melding håndterer betaling eller bookingmotor håndterer betaling, det siste dog kun med betaling ved avreise / utsending av faktura etter booking. 7. Mottak av OTA melding for kansellering av reservasjon på overnatting. Aktiviteter 8. Mottak av egendefinert meldingstype (på OTA mal) for søk etter aktiviteter. Meldingen vil inneholde en liste over destinasjonsselskaper det søkes på vegne av. Søket kan være på område, kan også inneholde kriterier på tilgjengelighet for et tidsrom og et antall personer. 9. Utføre søk i henhold til melding 8 blant alle tilbydere som har avtale med ett eller flere av destinasjonsselskapene på listen. 10. Retur av melding med liste over overnattingssteder / aktiviteter som tilfredsstiller søkekriteriene, ev med retur av kun de som har tilgjengelighet i forespurt periode. 11. Mottak av meldinger for spørring på tilgjengelighet av en tilbyder på aktivitet. Mulighet for å be om reservering av tilbud i et tidsrom. 12. Retur av melding med tilgjengelighet og pris. 13. Mottak av OTA meldinger for reservasjon av tilbud på aktivitet (booking). Skal støtte begge betalingsmodellene: Avsender av melding håndterer betaling eller bookingmotor håndterer betaling, det siste dog kun med betaling ved avreise / utsending av faktura etter booking. 14. Mottak av melding for kansellering av reservasjon av aktivitet Side 25 av 36

26 11 Alternative løsninger Prosjektets mandat tilsier at det skal etableres en utvekslingssentral. Prosjektet har identifisert én mulig alternativ løsning på bakgrunn av: Problemstillinger drøftet tidligere i rapporten Systemer i bruk og integrasjonsmuligheter hos dem Innspill fra leverandørene Løsningsalternativet som fremstår er å få utviklet integrasjon direkte mellom de aktuelle systemene hos Skattejakt og Telemarkreiser Direkte integrasjon Telemarkreiser baserer sin portalløsning på CityBreak, og har dermed mulighet til å få satt opp en løsning basert på Integratorproduktet til Visit. Via sin OnLineportal og mikrobutikker vil man da kunne booke produkter i R360 og Visbook via den eksisterende portalen (Røde piler på figuren nedenfor). En portal under utvikling av Skattejakt vil tilsvarende kunne integrere seg direkte med R360, Visbook og CityBreak (Orange piler på figuren nedenfor). Integrasjonen kan være via nåværende proprietære kommunikasjonsformer eller via nyutviklede OTA baserte grensesnitt i systemene. Fordelen med denne modellen er en lavere implementasjonskostnad ved få og enkle integrasjoner. Blant de negative aspektene er: Medlemmene av BIT Reiseliv blir avhengige av leverandørene av bookingmotorer for å kunne opprettholde og videreutvikle integrasjonen Side 26 av 36

27 Felles eksponering av destinasjonenes tilbydere blir vanskeliggjort. Leverandørene vil ha full kontroll over mulighetene som tilbys til frontend kanaler. Andre portalaktører vil måtte initiere integrasjon med flere plattformer dersom det ønskes utvidede søk. Figuren nedenfor dette illustrerer dette. På bakgrunn av dette vil prosjektet ikke anbefale løsningsprinsippet med direkte integrasjon Side 27 av 36

28 Vedlegg: Brukerhistorier ID Brukerhistorie Beskrivelse Rolle Kategori 1 Som gjest skal jeg kunne søke opp ledige overnattinger av en viss type, for et antall personer, i en gitt tidsperiode og område for å kunne få valg på foskjellige overnattingssteder jeg kan booke. overnattingsstedene som søkes frem skal være på tvers av bookingmotorer og destinasjoner. vi vil vise informasjon om produktet:sted et, avstand til destinasjoner (eksempel dyreparken), pris, link til mer informasjon. Type: Hotell, hytter, leilighet, camping, gårdsferie eller Alle. Søk 2 Som gjest skal jeg kunne angi en reiserute (eksempel krstiansand larvik) og få listet opp forskjellige tilbud: ledige overnattinger, ledige aktiviteter, avstander, lokasjon på overnattinger/aktiviteter/transport for å kunne planlegge og booke en reise. overnattingsstedene og aktiviteter skal være på tvers av bookingmotorer og destinasjoner. Skal kunne spesifisere hvilke typer som skal være med, eksempel: overnattinger(hotell,hytte, leilighet, osv), aktiviteter ( ), transport (buss, fly, ) det kan være at transport ikke vil være fullintegrert men bare linket til rett sted da dette pt er komplisert. Reiseplanlegger 3 Som gjest skal jeg kunne sette opp mine valg (overnattinger og aktiviteter) i en reiseplanlegger for å kunne bygge og booke en bestilling. overnattingsstedene og aktiviteter skal være på tvers av bookingmotorer og destinasjoner. Reiseplanlegger Side 28 av 36

29 4 Som gjest skal jeg kunne validere ledighet og pris i min reiseplanlegger for å kunne gjennomføre bestillingen. 5 Som gjest skal jeg kunne velge mellom ledige alternativer når overnattiner/aktiviteter i min reiseplanlegger er fullbooket for å kunne få en fullverdig reiserute. Reiseplanlegger Reiseplanlegger 6 Som gjest skal jeg kunne endre alle overnattinger/aktiviteter i reiseplanleggeren for å kunne bruke reiseplanleggeren som planleggingsverktøy. 7 Som gjest skal jeg kunne printe ut reiseplanleggeren for å kunne ta den med å vise den offline. 8 Som gjest skal jeg kunne videresende reiseplanleggeren via e post til reisevenner for å kunne vise reiseplanleggeren til andre. 9 Som gjest skal jeg kunne booke reisen min fra reiseplanleggeren for å bestille overnattinger og aktivitetene i reisen min. 10 Som reisevenn (#8) skal jeg kunne åpne reiserruten inn i en reiseplanlegger gjennom en link i mottatt reiserute e post for å bestille overnattinger og aktivitetene i reisen. Både sted og dato Reiseplanlegger gyldigheten for linken kan tidsbegrenses om ønskelig. reisen (ledighet og pris) vil bli validert i overgangen til kasse funksjon. Reiseplanlegger Reiseplanlegger Reiseplanlegger Reiseplanlegger 11 Som gjest skal jeg kunne legge inn aktiviteter i reiseplanen som ikke skal bookes fordi jeg kanskje ønsker å besøke disse underveis men ikke å bestille i forkant. Reiseplanlegger Side 29 av 36

30 12 Som gjest skal jeg kunne registrere en bruker og logge inn for å få tilgang til mine lagrede reiseplanleggere og mine bestillte reiserruter. Innlogging 13 Som innlogget gjest skal jeg kunne lagre reiseplanleggeren for å kunne jobbe videre med denne på et senere tidspunkt. 14 Som gjest skal jeg kunne booke direkte fra søk for å gjøre bestillingsprosessen enklest mulig. Maks 20 reiseruter kan lagres pr innlogget gjest. Innlogget gjest Reiseplanlegger Baseres på søk i #1 Booking 15 Som gjest skal jeg kunne se prisen (enhetspris og totalpris) på min reise i reiseplanleggeren for å kunne gjøre beslutning om bestilling. Reiseplanlegger 16 Som gjest skal jeg hele tiden bli informert om at pris og ledighet er tentativt frem til bestilling er bekreftet. Informasjon 17 Som gjest skal jeg kunne legge ett produkt fra søk inn i handlekurven for å kunne bygge en bestilling. Handlekurv 18 Som gjest skal jeg samtidig som jeg ser på søk også kunne se totalsum på handlekurv. Handlekurv 19 Som gjest skal jeg kunne velge mellom forhåndsoppsatte reiseruter som du kan ta opp i reiseplanleggeren som utgangspunkt for min reise for å gjøre reiseplanleggingen enklere. Reiseplanlegger 20 Som tar jeg imot ett søk og returnerer resultat med alle tilbydere som tilbys gjennom alle reisemålselskapene jeg har avtale med som passer søket for å gi kunden mest mulig utvalg. produkt informasjon: navn, pris, fra informasjonstilbydere (CMS): beskrivelse, bilder, med mer. Reisemål Side 30 av 36

31 21 Som skal jeg håndtere inngående og utgående pengestrøm for å forenkle økonomiske transaksjoner for tilbydere. Stor boks, utfordring, men et krav om dette er noe vits for kunden. Tilbyder 22 Som tilbyder angir jeg om mine tjenester som selges via en skal betales helt eller delvis på forskudd for å gi valgmulighetene til tilbyderene. 23 Som skal jeg ha differensiert provisjon om jeg tar inn forskuddsbetaling eller ikke fordi det å ta inn foskudd koster med (ta inn penger, avbestilling etc). 24 Som skal jeg kunne booke sømløst fra ulike bookingsystem for å kunne gjennomføre bestillingene kundene gjøre inn til. 25 Som skal jeg garantere bestillingstransaksjonen på tvers av bookingmotorer for å sikre at kunden får bestilt ingen eller alle produkter. 26 Som skal jeg sende bestillingsbekreftelse pr e post og/eller SMS til kunde (bestiller) når den er fullfillment agent for å sluttføre transaksjonen. 27 Som skal mine resultatsett returneres i angitt språk i spørringen for å kunne støtte multi nasjonal booking. TR: Er det noen tilbyder som ikke vil ha forskudd? Ingen på CityBreak bruker noe annet enn forskuddsbetaling. Kan også være andre årsaker. Må også ta hensyn til hvem som tar handling kostnader, for eksempel kostnader med kredittkort. Bookingen gjøres i sanntid. Avhengig av avtaler mhp ansvar og økonomisk oppgjør mellom aktørene (tilbydere, destinasjoner, portaler). Gi melding til bruker dersom det går så lang tid at reservasjonen utgår. Ref Hotels.com, brukervennlig skal sende dette fordi den har juridisk produktansvar. Alternativt at ansvarlig destinasjon blir avsender dersom man ikke har noen sentral enhet. Hvis ikke angitt, returnerer norsk (teknisk innstilling ved norske portal). NB ved ukjent språk i portal bruk engelsk Tilbyder Tilbyder Tilbyder Bookingsystem Bookingsystem Kunde Kunde Side 31 av 36

32 28 Som kunde skal jeg kunne velge språk i mine søk for å kunne støtte internasjonal booking. 29 Som skal jeg har åpne standarder mot eksterne aktører som portaler og bookingsystem for å forenkle integrasjonene. engelsk/tysk/nederlandsk som et minimum ref #27 Flere av bookingmotorene nå takler flere språk Kunde 30 Som administrator av skal jeg kunne legge inn og fjerne destinasjoner for å støtte opp om forretningen til en 31 Som administrator av skal jeg kunne konfigurere kommunikasjon og sikkerhet mot bookingmotorene og distributører for å sikre kommunikajonen. 32 Som administrator av en destinasjon skal jeg kunne legge inn og fjerne avtaler med tilbydere for å eksponere disse i en. Inklusive informasjon om hvilken bookingmotor som benyttes til booking. Orgnr? Admin Admin Dest Admin 33 Som tilbyder administrator skal jeg kunne se på min egen konfigurasjon i en for å verifisere at denne er i henhold til avtaler med destinasjoner. 34 Som destinasjons administrator vil jeg kunne ta ut statistikk over søk og bookinger for å måle min forretning av en. 35 Som administrator vil jeg kunne ta ut statistikk over bruk av en for å måle min forretning. Tilbyder Admin Pr distributer og tilbyder Dest Admin Pr destinasjon, bookingmotor og distributør Hvor "detter kunden" av? Admin Side 32 av 36

33 36 Som administrator vi jeg kunne ta ut statistikk over tekniske målinger for å følge med på om driften går i henhold til de krav som gjelder for mine avtaler 37 Som administrator av frontend skal jeg kunne legge inn predefinerte ledetekster på ulike språk for å sørge for at portalen kan benyttes i angjeldende land. 38 Som administrator vil jeg kunne ta ut rapporter over tilbydere som potensielt ser ut til å være registrert av flere destinasjoner responstid til gjest, responstid fra bookingmotorer, nedetid på bookingmotorer, feilsituasjoner Admin Frontend Admin Det forutsettes at en tilbyder kun skal ha avtale med en destinasjon. Like eller lignende navn/adresse Alternativt at dette ikke gjør noe, det blir konkurranse på pris for å vinne andel av provisjon NB: tenk på konkurranselovgiving! Admin 39 Som gjest skal jeg kunne slette enkelt elementer eller alle elementer fra min handlekurv fordi jeg ikke vil bestille dem likevel. Handlekurv 40 Som gjest vil jeg kunne endre på et valgt element i min handlekurv fordi opprinnelig søk ikke passer med total reiseplan. Innebærer endre dato, antall personer, alder, etc. Medfører at nytt søk på tilgjengelighet og pris må utføres mot bookingmotoren før endringen kan vises Dersom elementet i handlekurven er reservert i bookingmotoren må reservasjonen kanselleres og ny reservasjon gjøres. Portal 41 Som gjest skal jeg kunne booke reisen min fra handlekurven for å bestille overnattinger og aktivitetene i reisen min. reisen (ledighet og pris) vil bli validert i overgangen til kasse funksjon. Handlekurv Side 33 av 36

34 42 Som handlekurv vil jeg kunne reservere elementer i hos bookingmotoren for de elementer som legges i kurven, for å sikre at kunden får booket dem. 43 Som vil jeg kunne ta imot betaling fra kunde vha kredittkort for å sikre at jeg får nødvendig betaling. 44 Som vil jeg kunne kansellere en booking hos en tilbyder for å håndtere at en gjest kansellerer deler av sin bestilling. 45 Som vil jeg kunne kansellere en betaling for å håndtere at en gjest kansellerer sin bestilling. NB kan være problematisk ved delkrediteringer. Bryter med prinisppet om at endringer foregår med kommunikasjon mot distributør, og ikke kan gjøres på nettet. Handlekurv Handlekurv Betaling 46 Som gjest vil jeg ha tilsendt reisedokumenter / vouchers som PDF filer på epost for de tilbudene jeg har forskuddsbetalt fordi jeg vil kunne dokumentere overfor tilbyder at disse er betalt. Dette er verdipapirer for tilbyder ifm oppgjør i etterkant. Legges ved ev faktura fra tilbyder til distributør 47 Som må jeg sende melding til tilbydere som ønsker det når nye bookinger er utført for å sikre at gjesten håndteres riktig. Standard at det sendes melding, tilbyder kan få slått av dette om ønskelig Må gjøres ved booking på allotment, men kan være nyttig også ved dynamisk booking i bookingssystemet 48 Som må jeg kunne integreres med regnskapssystemer hos distributører ifm økonomisk avregning Side 34 av 36

35 49 Som swithc må jeg ta vare på kundeinformasjon for å benytte denne til CRM systemer / markedsføring. 50 Som må jeg ha kriterier for når remittering skjer og når kredittkort trekkes for å sikre korrekt behandling av pengestrømmen. 51 Automatisk påminning om fremtidig trekk via epost Side 35 av 36

36 Om BIT Reiseliv BIT Reiseliv er et utviklingsprosjekt i regi av NHO Reiseliv og Innovasjon Norge. Prosjektet har gjennomført flere faser. Fra 2007 er også HSH Handels- og Servicenæringens Hovedorganisasjon med som prosjekteier. Les mer på bitreiseliv.no Prosjektansvarlig Per Ødegaard Tlf: Mob: per.odegaard@nhoreiseliv.no Prosjektleder Elisabeth Heyerdahl-Jensen Tlf: Mob: heyerdahl@bitreiseliv.no Side 36 av 36