IT Prosjektrapport for prosjekt i IT I Praksis

"Undersøkelse av hotelldatasystem hos Thon Hotels"

Gruppe 13


VERSJON: 2

Dato: 24/3-2011


FORFATTERE:

Espen Mjølund, Robert Bicanic, Jonas Bjørnerud & Maius Kværner Karlsen


FORORD


INNHOLD


1. INTRODUKSJON.


1.1 Prosjektet

Grunnlag for valg av bedrift til prosjektet

I faget ”IT i praksis” våren 2011 har studentene fått en prosjektoppgave som går ut på å undersøke et datasystem i en valgt bedrift eller organisasjon, med fokus på brukeropplevelse. Ved hjelp av observasjon av systemet i bruk, samt ved hjelp av spørreundersøkelse/intervju med systemets daglige brukere skal vi lage en rapport som beskriver systemet og dets bruksområder. Vi skal se på hva som fungerer, hva som ikke fungerer og mulig forbedringspotensial.

Gruppe 13 sendte i prosjektets startfase ut en skriftlig forespørsel til en rekke bedrifter som vi mente kunne være interessante å foreta undersøkelser hos. Hvem som fikk en henvendelse i innledende runde var basert på krav (antakelse) om at de hadde et større, omfattende datasystem som utgjorde en viktig del av bedriftens infrastruktur og daglige drift. Vi ønsket at det skulle være et system som var ukjent territorium for oss i gruppen, og samtidig ikke var veldig utbredt blant folk flest. Vi ønsket med andre ord ikke å undersøke en bedrift der hovedverktøyet var Microsoft Office-pakken eller tilsvarende ”hyllevare”. På grunnlag av overnevnte ønsker sendte vi ut forespørsel til en rekke hotellkjeder, reisebyråer , et bibliotek, samt noen av de største pizzakjedene i landet. Vi fikk en veldig rask og positiv tilbakemelding fra Svein Daae Johansen ved Olav Thon gruppen. På grunnlag av denne gode responsen føltes det veldig riktig å velge Olav Thon gruppen og nærmere bestemt Thon Hotel Opera som samarbeidspartner i dette prosjektet.


Om Olav Thon Gruppen og Thon Hotels

Olav Thon gruppen er en samlebetegnelse på virksomheter og selskaper hvor Olav Thon er majoritetseier. Olav Thon Gruppen omsatte i 2009 for 6,5 milliarder kroner og sysselsatte ved årsskiftet ca. 2 500 årsverk. Gruppen er delt inn i to divisjoner: Thon Eiendom og Thon Hotels.

Gruppen eier ca. 425 eiendommer i Norge og 25 i utlandet. I tillegg disponeres ca. 40 eiendommer på langsiktige leiekontrakter.

Thon Hotels er en av Norges ledende hotellkjeder med 59 hoteller i Norge og 1 i Sverige. Thon Hotels har også 4 hoteller i Brussel og 1 i Rotterdam.

Thon Hotels er markedsleder i Oslo og Bergen og har hovedfokus innen yrkesreisende.

Systemet vi skal undersøke heter Spirit PMS (Property Management System). Systemet er utviklet av Oslo-baserte SystemPartner International AS. Dette tar seg av et mangfold av essensielle oppgaver tilknyttet hotelldrift: booking, inn/utsjekk, romoversikt, renhold, kurs og konferanse samt rapporteringsfunksjoner i forhold til økonomiavdeling, resepsjon m.m.

Utvikling av prosjektplanen

Versjon Forfatter(e) Beskrivelse av versjon Leveransedato
1 Mjølund, Bicanic, Bjørnerud & Karlsen Utfylling av del 1,2 og 3 25/2-2011
2 Mjølund, Bicanic, Bjørnerud & Karlsen Utfylling av del 4,5 og 6 23/3-2011

1.2 Referanser

Referanser til pensum og andre kilder

Navn Forfatter Forlag År
Diverse matriell Thon Gruppen Thon Gruppen 2011
Understanding Your Users-A Practical Guide to User Requirements Methods Tolls and Techniques Catherine Courage & Kathy Baxter Morgan Kaufmann Publishers 2005
UML destilled 3rd edition Martin Fowlwer Addison-Wesley 2004
URL:(link + dato) * * *

2. ORGANISERING AV PROSJEKTET

2.1 Intern organisering

Espen ble valgt til prosjektleder i gruppen. Han har hovedansvaret for prosjektets helhet, og skal sørge for at delinnleveringer og sluttresultat holder den kvaliteten som forventes. Utover dette stiller alle på lik linje – og alle beslutninger skal tas i fellesskap. Siden dette er et læringsprosjekt fokuserer vi på at alle skal delta innen alle felt av prosjektet. Ansvarsinndeling som presentert i neste punkt gjelder derfor kun det overordnede ansvar for hvert område. Hvert enkelt gruppemedlem er pålagt å skrive en prosjektdagbok der det også føres timer. I tillegg har vi en aktivitetsplan som spesifiserer arbeidsoppgaver fra uke til uke, med informasjon om hvem som er ansvarlig for oppgaven. Denne går et par uker frem i tid og oppdateres kontinuerlig. Denne er underordnet prosjektets milepælsplan. Alle styringsdokumenter ligger tilgjengelig på gruppens hjemmeside: http:// www.stud.hio.no/~s171673/G13/index.php


Prosjektansvarskart

Ansvarlig Navn
Prosjektleder Espen
Webansvarlig Robert
Hovedansvarlig for kvalitetssikring Espen & Marius
Ansvarlig for prosjektplanen Espen
Hovedansvarlig forinformasjonsinnhenting Marius
Hovedansvarlig for analysen Espen & Marius
Ansvarlig for styringsdokumenter Jonas
Ansvarlig for backup Espen

3. STYRINGSPROSESSER

3.1 Mål for prosjektet

Tema:
Vi skal utføre vår prosjektoppgave ved Thon Hotel Opera i Oslo. Hotellet er en del av Thon hotels-kjeden, som igjen er del av Olav Thon Gruppen. Vi skal foreta en undersøkelse av det systemet som kanskje er det viktigste for hotellets daglige drift, ”Spirit PMS”.

Problemstilling:
Vi skal undersøke hvordan systemet fungerer i forhold til de oppgaver det er satt til å løse. Vi skal påvise sterke og eventuelt svake sider ved systemet og om mulig komme med forslag til forbedringer. Resultatet av undersøkelsene skal presenteres i en sluttrapport.

Plan for å nå målet:
For å nå prosjektmålet vil vi jobbe med en kombinasjon av individuelt arbeid og gruppearbeid. Prosjektets fremdrift vil opprettholdes ved hjelp av ukentlige fellesmøter med gjennomgang av utførte oppgaver og innrapportering. Arbeidsmengde og fremdriftsplan vil justeres på grunnlag av dette.

Nødvendig info om bedrift og system som skal undersøkes er tenkt innhentet ved hjelp av samtaler, intervjuer og observasjon av systemet i daglig bruk.

Når det kommer til det rent fagmessige rundt prosjektarbeidet vil vi støtte oss på tidligere erfaringer, pensumlitteratur i faget, faglærer og studentveiledere.

Risikoplanlegging

I punkt 3.3 er en oversikt over uforutsette ting som kan stoppe/hindre/ødelegge prosjektet eller fremdriften. Her følger en forklaring av tabellen:

3.3 Risikostyring

RISIKO KONSEKVENS SANSYNLIGHET RISIKOPOENG FOREBYGGENDE TILTAK TILTAK HVIS PROBLEM OPPSTÅR
Sykdom. 8,00 0,30 2,40 Følge med på arbeidet til de andre i gruppen. Omfordele arbeidsoppgaver.
Ukjent verktøy. 5,00 0,10 0,50 Kursing. Kjøre intern workshop.
Tidsmangel. 7,00 0,80 5,60 Planlegge, og holde interne tidsfrister. Få ekstern hjelp.
Intern kompetanse. 7,00 0,60 4,20 Hjelpe hverandre. Få hjelp fra en veileder.
Uklar kommunikasjon internt. 8,00 0,50 4,00 Ha tett dialog, gjerne e-mail for å forhindre misforståelser. Oppklare misforståelser. Prøve å snakke tydeligere.
Tap av data. 9,00 0,20 6,0 Følge med på arbeidet til medarbeidere, ta backup og bruk dropbox. Hente tilbake data fra din eller andres backup.
Ujevn fordeling av arbeidsoppgaver. 7,00 0,20 1,60 Si ifra om du føler du har for mye å gjøre. Hjelp en kollega.
Nettsiden vises forskjellig i ulike browsere. 4,00 0,70 2,60 Sjekke nettsiden ofte under utvikling. Være løsningsorientert og evt. forenkle sidens utforming
Har ikke fått oppdragsgiver for prosjektet. 9,00 0,60 5,60 Vær aktiv og løsningsorientert. Ta kontakt med mange bedrifter Snakke med veileder om løsning. Vær aktiv uttad.
Ufullstendig dokumentasjon. 8,00 0,60 4,80 Finne ut av omfang tidlig. Ha interne tidsfrister. Skrive dokumentasjon fortløpende. Ikke skippertak.
Valideringsfeil. 4,00 0,70 2,80 Validere siden fortløpende. Bruk tilgjengelig dokumentasjon og finn feil.
Mangel på oppmøte. 8,00 0.70 5,60 Gode og tydelige innkallelser. Personer som ikke møter må få referat fra møte. Andre kan ta tak i vedkommendes oppgaver.
Ikke godkjent leveranse. 8,00 0,40 5,90 Jobbe jevnt, ikke utsette. Les oppgaven nøye. Gjøre endringene som trengs og levere på nytt.

Mange uforutsette ting kan skje under et prosjekt Vi har laget en strategiplan vi vil følge dersom det skulle oppstå noen risikoer som vil påvirke prosjektet.

Sykdom

Det er en sannsynlighet for at noen på gruppen blir syk og ikke kan stille på prosjektmøte eller utføre arbeid som venter.

Forebyggende tiltak kan være at gruppen følger med på arbeidet til hverandre. Dette kan gjøres på ved at man briefer hverandre kort ved hvert møte og viser det arbeidet man har gjort. En annen ting man kan gjøre er å skrive ned det man gjør i en prosjektdagbok som er tilgjengelig for alle på gruppen.

Skulle problemet oppstå er det en god plan å omfordele arbeidet som man har satt som mål slik at det blir en jevn fordeling og arbeidet blir utført selv om noen er borte fra gruppen på grunn av sykdom.

Ukjent verktøy

For å kunne presentere det vi skal i IT i praksis har vi i gruppen blitt introdusert for ny programvare som innebærer diagrammer og skjema for spørreundersøkelser som er nytt for mange av oss. Vi skal også evaluere et system hos oppdragsgiver uten helt å vite så mye om selve systemet. Det som er bra er å ha en intern-workshop hvor man hjelper hverandre med å forstå bruken av verktøyene. Man kan enkelt løse problemet ved at noen i gruppen kan mer om bruken av verktøyet lærer bort til de andre eller at en i gruppen får til oppgave å lese seg opp og lære de andre på gruppen. Man er selv ansvarlig for å lære seg å bruke de verktøyene vi bruker i prosjektet. Skule man stå helt fast kan man spørre veiledere på skolen om hjelp.

Tidsmangel

Det er ikke alltid det er lett å holde tidsfristene som er satt. Det som er lurt er å jobbe jevnt og trutt slik at man ikke blir sittende med mye arbeid og må gjøre store skippertak for å bli ferdig med arbeidsoppgavene. Det er viktig å planlegge og følge milepælsplanen slik at man rekker å bli ferdig med det man skal til rett tid. Ser man at det blir for mye arbeid til at du rekker alt innen del fristene er det lurt å snakke med de andre på gruppen og høre om de kan hjelpe, slik at arbeidsoppgavene blir fordelt på nytt, og at man ikke blir sittende med altfor mye selv. Det er også fint å ha en statusoppdatering på hvert møte (tirsdag og fredag) slik at de andre gruppemedlemmene som er ferdig med sine oppgaver kan hjelpe til med å gjøre ferdig oppgavene som står igjen. Ser man at man fortsatt ikke klarer å levere i tide er det viktig å si ifra til gruppen slik at man kan omorganisere arbeidsfordelingen.

Intern kompetanse

Dette er helt sikkert at alle i gruppen kan være til hjelp for hverandre og stille sterk som en enhet. Det er viktig med god planlegging og at man kan innrømme for gruppen at man ikke kan alt. Det er viktig at man hjelper hverandre slik at man lærer mest mulig av hverandre. Skulle det være slik at man ikke finner løsningen på et problem skal man ta kontakt med lærer i faget eller veiledere for hjelp.

Uklar kommunikasjon i gruppen

Ha en tett dialog og faste gruppemøter. Det er fint å ha møtereferat fra hvert møte som er tilgjengelig for alle i gruppen . På denne måten står det hva som blir tatt opp skrevet i møtereferatet. Meldinger på e-post er også bra for å unngå misforståelse. Det er viktig å snakke klart og tydelig og rydde opp i misforståelser med en gang. Det er viktig å informere alle i gruppen om forandringer slik at alle får lik informasjon til enhver tid, gjerne på e-post. Det er også fint å sette opp flere muligheter for kommunikasjon som f.eks. en Facebook-gruppe, Skype, mulighet for å ringe, sende SMS og at man kan føle seg trygg på at det er greit å sende melding til et annen gruppemedlem om man skulle være usikker på noe.

Tap av data

Dette er en risiko som kan føre til store problemer. Det er viktig og ta backup. Vi i gruppen har blitt enige om å ha hver vår backup av prosjektmappen vi deler felles i Dropbox for å sikre det arbeidet vi har gjort. Hvis problemet skulle oppstå at man ved ett uhell skulle slette noe man ikke skulle ha gjort kan man puste lettet ut at man har backup. Dropbox har også en funksjonalitet som gjør at den har backup av alle filene vi har lagt i mappen.

Ujevn fordeling av arbeidsoppgaver

Sitter man med mye arbeid og ser at man ikke har mulighet til å rekke tidsfristen som er satt skal man kunne ta opp dette med gruppen og få hjelp.

Siden vises ulikt i forskjellige nettlesere

Dette kan løses ved at siden testes kontinuerlig under utviklingen. Hvis problemet er vanskelig å unngå kan det være lurt å forsøke å forenkle designet, slik at konflikter unngås.

Får ikke tak i oppdragsgiver for prosjektet

Først og fremst skal man gjøre alt man kan for å få tak i oppdragsgiver innen tidsfristen i prosjektet. Dette gjør man ved å snakke med venner, familie, kollegaer fra arbeidslivet eller sende ut e-post til bedrifter som er av interesse. Skulle man fortsatt ikke få tak i oppdragsgiver er det viktig å ta kontakt med faglærer. Det er viktig å planlegge i forkant av kontakt med oppdragsgiver samt å presentere det arbeidet vi skal gjøre for dem på en så bra måte som mulig. Det skal føle at de får igjen noe for at de har oss på besøk.

Ufullstendig dokumentasjon

Det er mye dokumentasjon i et prosjekt og man bør skrive den fortløpende. Finn ut omfang tidlig og ha interne tidsfrister for å unngå at det samler seg opp mye.

Siden vises ulikt i forskjellige nettlesere

Dette kan løses ved at siden testes kontinuerlig under utviklingen. Hvis problemet er vanskelig å unngå kan det være lurt å forsøke å forenkle designet, slik at konflikter unngås.

Valideringsfeil på hjemmesiden

Sjekk nettsiden ofte og rett opp i problemene som dukker opp, løs dem når de kommer. Bruk tilgjengelig dokumentasjon for å løse problemer.

Mangel på oppmøte

For å forebygge dette er det viktig med gode og tydelige innkallelser. Det er viktig at alle følger med på møtereferatene når de ikke er tilstede slik at de kan se om det er noen endringer eller at planene har forandret seg slik at man er oppdatert selv om man ikke har vært på møte av en eller annen grunn. Hvis en person ikke møter opp tar en annen over oppgaven.

Ikke godkjent leveranse

Det er viktig å jobbe jevnt og trutt og levere det man skal. Det er ikke lurt å utsette arbeidsoppgavene da det fort bygger seg på og man risikerer å ikke rekke å levere i tide. Skulle man ikke få godkjent leveranse , er det viktig å gjøre de endringene som er nødvendig og levere på nytt.

4. SYSTEMBESKRIVELSE

I dette prosjektet undersøker vi ’SPIRIT PMS’ som er et hotelldatasystem som i disse dager benyttes ved Olav Thon Gruppens hotellkjede, Thon Hotels. PMS står for ’property management system’. Systemet er utviklet av det Oslo-baserte firmaet SystemPartner International (SPI). Systemet er basert på et eldre system, HotelGuide, men har vært på markedet i nåværende form i rundt 15 år. SPIRIT PMS er ute i sin siste versjon og vil fases ut av markedet i forbindelse med at Thon Hotels er i prosess med å bytte til et nytt system.

SPIRIT PMS er menydrevet og er basert på DOS-plattformen. Det er altså ikke basert på Windows, selv om det til vanlig kjøres i et Windows-miljø. Programmet styres ved hjelp av tastaturet og støtter ikke bruk av mus.

Systemet spiller en nøkkelrolle i den daglige driften av et Thon Hotel, og blir benyttet innen de fleste avdelingene knyttet til hotellet. Kort fortalt har systemet følgende moduler:

I vårt prosjekt har vi måttet begrense oss til undersøkelse av systemet brukt i resepsjonsarbeid (front office-modulen), slik at oppgaven ikke skulle bli alt for stor og krevende.

I systemet er hvert hotell etablert som en selvstendig enhet individuelt konfigurert med gjesterom, møtelokaler, priser og artikler. Systemet drar nytte av kjedetilknytningen på flere måter. Mest fremtredende er muligheten for tilgang til de andre hotellenes romtilgjengelighet på dato. Dette er for eksempel praktisk i de tilfeller man er fullbooket og skal anbefale andre hoteller med ledig kapasitet. Alle hotellenes databaser er plassert på Thon Hotels hovedkontor i Oslo og er tilkoplet med datalinjer ut til hotellene.

Skjermbilde fra Spirit PMS MultiHotel rom oversikt

Figur 1 - Skjermbilde av SPIRIT PMS MultiHotel rom oversikt

SPIRIT PMS er fleksibelt og har mulighet til å kople seg til tredjeparts-systemer via interfacer som utvider funksjonaliteten. Dette styres fra hovedkontoret. Her snakker vi om kredittkort-håndtering, telefon, Pay-TV, nøkkelkort, minibar og restaurant. Det er også mulig å inkorporere systemer som styrer energiforbruk, som for eksempel lys og varme, sammen med SPIRIT PMS. Systemet kan også levere tallgrunnlag til regnskapssystemer som for eksempel Visma (Thon Hotels benytter dette).

Skjermbilde fra SPIRIT PMS - Innsjekkingsprogram height=

Figur 2 - Skjermbilde fra SPIRIT PMS - Innsjekkingsprogram

Systemet kjøres som et vindu i Windows operativsystemet. Man møtes av et påloggingsbilde der den aktuelle bruker angir sin personlige innloggingsinformasjon. Systemet er delt opp i flere ”underprogrammer” som utfører de forskjellige oppgavene brukerne har behov for. Til eksempel angir brukeren program ’101’ for å komme til innsjekkingsbildet. ’104’ er program for utsjekk og ’ '401' er for reservasjon. Programmene angis ved hjelp av numpad-tastaturet. I de respektive vinduene navigerer man fra punkt til punkt ved hjelp av piltaster og/eller TABulator-tasten. Valg kan bekreftes med ’enter’-tast. Spesielle funksjoner og valg kan også aksesseres ved hjelp av funksjonstastene og tastatur-snarveier.

De perifere enhetene direkte tilknyttet systemet (maskinen SPIRIT PMS kjører på) er tastatur, mus (ikke i bruk i SPIRIT), skjerm, skriver, nøkkelkort-terminal(skriv/les) og betalingskort-terminal.

Under er et rikt bilde som viser mengden av forskjellige avdelinger og andre systemer som er knyttet opp mot SPIRIT PMS, sett fra en resepsjonists standpunkt.

Rikt bilde av Spirit PMS sett fra en resepsjonists standpunkt

Figur 3 - Rikt bilde av Spirit PMS sett fra en resepsjonists standpunkt

Use Case-modeller og Aktivitetsdiagram.

Her følger et overordnet Use Case-diagram over systemet begrenset til bruk i resepsjonen. Dette etterfølges av tre Use Case beskrivelser med normalflyt og variasjoner. Disse er basert på noen av de mest brukte funksjonene I SPIRIT PMS. Hver modell består av en Use Case-beskrivelse. og et aktivitetsdiagram.

Overordnet Use Case-diagram over Spirit PMS (begrenset til resepsjonen)

Figur 4 - Use Case Diagram som er begrenset til resepsjonen og systemet Spirit PMS

Use Case-beskrivelse 1:Innsjekking i Spirit PMS

Use Case - beskrivelse

Innsjekk i Spirit PMS, Thon Hotels

Aktører: Spirit PMS-system, Resepsjonist, Kunde
Betingelser: Ingen
Trigger: Kunde ønsker å sjekke inn på hotellet

Normal hendelsesflyt:
1.Kunde ankommer resepsjon med ønske om å sjekke inn.
2. Resepsjonist velger innsjekkingsprogrammet i Spirit PMS (valg:101).
3. Resepsjonist søker på de første bokstavene i kundenavn
4. Systemet returnerer liste med treff
5. Resepsjonist velger rett kunde fra liste i systemet.
6. Systemet viser liste med tilgjengelige rom
7. Resepsjonist velger rom fra liste i systemet.
8. Resepsjonist verifiserer betalingsmåte med kunde
9.Resepjonist legger inn betalingsmåte i systemet
10.Systemet lagrer informasjonen
11. Nøkkelkort skrives ut av systemet.
Variasjon A: 5a) Resepsjonist finner ikke bestilling
5a)-1. Kunde oppgir navn eller annen relatert info på nytt
Variasjon B: 5b) Resepsjonist finner ikke bestilling
5b)-1. Resepsjonist oppretter en reservasjon ”Walk-in”
5b)-2. Kunden opplyser om personalia, oppholdslengde og ønsket romtype.
5b)-3. Resepsjonisten legger inn data i systemet

Aktivitetsdiagram - Innsjekk

Diagram over innsjekk med Spirit PMS

Figur 5 - Diagram over innsjekk med Spirit PMS


Use Case - beskrivelse

Utsjekk i Spirit PMS, Thon Hotels

Aktører: Spirit PMS-system, Resepsjonist, Kunde
Betingelser: Kunden er allerede innsjekket ved hotellet
Trigger: Kunde ønsker å sjekke ut fra hotellet

Normal hendelsesflyt:
1.Kunde ønsker å sjekke ut fra hotellet.
2. Resepsjonist velger program 104 i Spirit PMS (utsjekks-program).
3. Resepsjonist ber kunde om navn eller romnummer.
4. Gjest gir nødvendig info til resepsjonist.
5. Resepsjonist søker på oppgitt info i systemet.
6. Resepsjonist velger rommet det gjelder fra søkeresultat.
7. Resepsjonist legger til betalte ekstratjenester på regning (for eksempel minibar).
8. Resepsjonist kontrollerer at betalingsmiddel oppgitt ved innsjekk skal benyttes.
9. Transaksjon utføres.
Variasjon A: 8a) Kunde ønsker å benytte alternativt betalingsmiddel.
8a)-1. Resepsjonist registrerer betalingsmiddel.
Variasjon B: 8b) Kunde ønsker å betale ekstra tjenester med annet betalingsmiddel enn det rommet betales med (dele opp regning)
8b)-1. Resepsjonist registrerer nytt betalingsmiddel
Variasjon C: 9c) Transaksjon ikke utført. Problem med kort
9c)-1. Kunde kan forsøke med alternativt betalingsmiddel.
9c)-2. Resepsjonist går til steg 8 i den normale hendelsesflyten.

Aktivitetsdiagram - Utsjekk

Diagram over utsjekk med Spirit PMS

Figur 6 - Diagram over utsjekk med Spirit PMS


Use Case - beskrivelse

Reservasjon i Spirit PMS, Thon Hotels

Aktører: Spirit PMS-system, Resepsjonist, Kunde
Betingelser: Ingen
Trigger: Kunde ønsker å reservere rom ved hotellet

Normal hendelsesflyt:
1. Gjest ønsker å bestille rom .
2. Resepsjonist velger program 401 i Spirit PMS (Reservasjonsprogram).
3. Resepsjonist registrerer kundeinfo i systemet.
4. Resepsjonist legger inn informasjon om bestilling (dato/lengde for opphold, type rom etc…).
5. Resepsjonist registrerer ønsket betalingsmåte.
6. Resepsjonist bekrefter inntastet informasjon
7.Systemet lagrer informasjonen
Variasjon A: 3a) Kunden er registrert i systemet fra tidligere opphold.
3a)-1. Resepsjonist dupliserer kundeinformasjon fra systemet

Aktivitetsdiagram - Reservasjon

Diagram over reservasjon med Spirit PMS

Figur 7 - Diagram over reservasjon med Spirit PMS


5. RESULTATER: LEVERANSER OG MILEPÆLER

Leveranse 1 - Milepæl (Resultat) Dato
  • Leveranse 1
  • Gruppene skal være opprettet
  • Prosjekthjemmesiden laget
  • Roller / ansvarsfordeling i gruppen diskutert (ev.fordelt).
 29.januar
  • Leveranse 2
  • Har etablert kontakt med firma
  • Har fordelt roller/ ansvarsfordeling i gruppen.
  • Identifiser risikoer.
  • Beskriv innhold i prosjekt, hva har dere gjort, og resultater så langt.
 26.februar
  • Leveranse 3
  • Observasjon hos bedrift utført.
  • Gjennomført intervju med ansatte i bedriften.
  • Bearbeide innsamlet informasjon.
  • Berskrive systemet med tekst, rike bilder og Use Case.
 25.mars
  • Leveranse 4
  • Analyse av innsamlet informasjon.
  • Jobb med egenevaluering.
 29.april
  • Leveranse 5
  • Presentasjon av prosjektet.
  • Tilbakemelding til bedrift.
  • Utarbeide konklusjon
  • Ferdigstille prosjektrapport
 27.mai

6. METODER

7. Mars 2011 var Espen & Jonas på Thon Hotel Opera i Oslo for å observere systemet i bruk. Vi brukte ca. 3 timer på dette. Observasjonen besto hovedsakelig i å ”kikke over skulderen” på resepsjonsmedarbeiderne mens de gjorde sine arbeidsoppgaver som vanlig. I stille perioder fikk vi en av de mest rutinerte medarbeiderne til å gå trinnvis gjennom viktige arbeidsoppgaver slik at vi kunne notere ned forløpet i detalj. Disse notatene utgjør grunnlaget for Use Case-modellene presentert i denne rapporten.

Når vi hadde fått utdelt Thon Hotel Opera som oppdragsgiver hadde vi et møte for å avklare hvordan vi kunne få utført våre undersøkelser på en best mulig måte både for gruppen og hotellet. Vi ga resepsjonssjef Marius Lilleng mulighet til å velge mellom intervju med ansatte eller spørreskjema. Han var positiv til intervju, så da ble vi enige om denne fremgangsmåten. Intervjuene ble utført i to runder, 11 & 18 mars 2011. Espen og Robert tok første runden. Marius og Jonas tok runde nummer to. Vi fikk totalt intervjuet 7 resepsjonsmedarbeidere. Dette danner grunnlaget for våre analyser og konklusjoner, sammen med observasjonen vi har foretatt.

Under observasjon noterte vi flittig på papir. Det samme gjorde vi i forbindelse med intervjuene. I tillegg ble intervjuene spilt inn på en iPhone. Innspillingene og skannede notater er gjort tilgjengelig for gruppen i vår felles DropBox-mappe for å lette bearbeidingen av informasjonen.

Følgende spørsmål ble stilt i forbindelse med intervjuene:

I forbindelse med intervjuene ble det notert ned et intervju-nummer, samt dato for å kunne identifisere intervjuene og kople dem mot respektiv innspilling.

I forbindelse med innsamling av informasjon er det regler man må forholde seg til i henhold til Personopplysningsloven. De mest relevante punktene fra loven i forbindelse med vårt prosjekt er:

Vi har hatt god fokus på dette i forbindelse med dette prosjektarbeidet. I forkant av hvert intervju har vi klargjort følgende for intervjuobjektet:

Ved prosjektet slutt vil innsamlet råmateriale i form av lydopptak og notater fra intervjuene slettes. Bearbeidet materiale som statistikk, opptellinger og vurderinger vil beholdes, men skal ikke kunne settes i sammenheng med enkeltpersoner. Materialet vil heller ikke benyttes til andre formål enn det vi har redegjort for i forbindelse med prosjektet.

7. ANALYSEN

Som nevnt tidligere i rapporten er SPIRIT PMS et system som brukes på tvers av alle hotellets avdelinger. Våre undersøkelser har vært avgrenset til bruk av systemet i hotellets resepsjon, og informasjonen vi har innhentet stammer fra intervjuer med syv medarbeidere fra resepsjonen, samt observasjon av hovedsakelig en av medarbeiderne.

De ansatte

Medarbeiderne som ble intervjuet er i alderen 20 til 30 år gamle. Gjennomsnittsalderen er 24 år.

Gjennomsnittlig ansettelsestid ved hotellet for intervjugruppen er 15,5 måneder. Seneste ansatt har jobbet i resepsjonen i syv måneder. Tidligste ansatt har vært ansatt i 24 måneder.

Når vi ber intervjuobjektene om å plassere sine datakunnskaper på følgende skala: svak, middels, sterk – svarer seks av syv at de anser sine datakunnskaper å være middels, mens én anser sine kunnskaper for å være mellom middels og sterk.

Av de spurte opplyser seks av syv at de bruker datamaskin hjemme.

Fire av syv opplyser at de har vært borti liknende systemer før de begynte å bruke SPIRIT PMS.

Opplæring i systemet

Når det kommer til opplæring av systemet skal hver medarbeider gjennom en toukers opplæringspersiode på systemet. Opplæringen er i stor grad basert på reell bruk av systemet med assistanse fra en av de mer erfarne medarbeiderne. Seks av syv sier de har gjennomgått denne opplæringsperioden, mens én mener han eller hun ble overlatt til seg selv etter to dager med observasjon av systemet i praksis.

Alle de spurte oppgir at de er fornøyd med den opplæringen de har fått på systemet, selv om det blir påpekt at det tar tid å bli utlært.

To av de spurte svarer at de syntes at systemet var uproblematisk å lære seg, mens én syntes at det var vanskelig. De resterende fire mener at det var middels utfordrende å lære seg systemet.

Diagram, vanskelighetsgrad for å lære seg systemet

Figur 8 - Diagram, vanskelighetsgrad for å lære seg systemet

Om systemet (SPIRIT PMS)

På spørsmål om hva systemet blir brukt til i løpet av en arbeidsdag er det tre oppgaver som går igjen: innsjekk av gjester, utsjekk av gjester samt rombooking. Dette er også de tre scenarioene vi har tatt for oss i forbindelse med Use Case-modellene i kapittel 4.

Det er ingen tvil om at systemet er en viktig del av hverdagen for resepsjonistene; Det oppgis fra fire til åtte effektive timers arbeid i SPIRIT PMS i løpet av en åtte timers arbeidsdag. Gjennomsnittlig arbeidstid i systemet er 6,5 timer per arbeidsdag (8 timer). Se diagram under.

- Diagram, daglig bruk av systemet i timer

Figur 9 - Diagram, daglig bruk av systemet i timer

Fem av de spurte synes SPIRIT PMS er et forholdsvis brukervennlig system. De to siste er mindre fornøyd. Se diagram under.

Diagram, systemets brukervennlighet

Figur 10 - Diagram, systemets brukervennlighet

Her følger en kort liste med positive og negative sider som nevnes i forbindelse med brukervennligheten til systemet:

Positivt:

Negativt:

  • Søkemotoren er treg/dårlig.
  • Reservasjoner som kommer via andre hoteller, eller fra nettreservasjon må legges inn i systemet manuelt.
  • Begrenset plass til å legge inn ekstrainformasjon i systemet i forbindelse med bookinger og lignende. Dette kan føre til misforståelser.
  • Liten logikk bak oppbygningen (med tanke på bruk av koder). Lite selvforklarende.
  • Vanskelig å vite hvor i systemet forskjellige funksjoner ligger. Lite hjelp å få av systemet for å finne frem.
  • Mye manuelt arbeid, som burde vært automatisert.
  • Vanskelig å endre på ting man har gjort. Dårlig angrefunksjon. Dette fører til mye ”triksing” med systemet for å rette opp feil.

    • Inntrykket som blir gitt er at de aller fleste er fornøyd med SPIRIT PMS etter at de har brukt det en stund. Samtidig er det flere som synes det er vanskelig å bruke systemet på et tidlig tidspunkt hovedsakelig på grunn av et lite selvforklarende brukergrensesnitt. Det meste styres ved bruk av koder, og hvis man ikke husker disse (eller bruker en huskelapp) får man gjort lite. En del funksjoner og oppgaver oppleves også som unødig tungvinte i bruk for de ansatte.

    Av de spurte opplever fem av syv at systemet er stabilt. Det later til å være enighet blant disse fem om at systemet krasjer ca. en gang per uke. De to som mener systemet er ustabilt mener at det krasjer alt for ofte. Disse to har ikke gitt noen nærmere informasjon rundt hyppigheten.

    I forbindelse med et systemkrasj er det enighet blant de spurte om at det er mulighet for å restarte systemet lokalt, men at hvis ikke dette fungerer er det IT-avdelingen til Thon-gruppen sentralt som må ordne opp.

    På spørsmål om intervjuobjektene har noe de ville forandret på med systemet lister vi opp følgende punkter:

    8. KONKLUSJON

    Hva har vi oppnådd?

    I løpet av dette prosjektet har vi skaffet oss kunnskap om hvordan en hotellresepsjon fungerer i praksis, hva slags krav som stilles til et hotelldatasystem, og hvilke funksjoner systemet har tilgjengelig. Ved observasjon av systemet i bruk, samt gjennom intervju med systemets brukere har vi fått forståelse av hva systemet brukes til, hva brukerne selv mener om systemet, hva som fungerer bra og hva som fungerer mindre bra. Ut i fra dette har vi fått muligheten til å danne oss et bilde av de ansattes tilfredshet ved bruk av SPIRIT PMS. Gjennom analyse og bearbeiding av innsamlet informasjon har vi fått de nødvendige grunnlaget for å kunne beskrive systemet på en informativ måte, samt komme med veloverveide forslag til endringer og forbedringer av systemet.

    Hvordan opplever brukerne systemet?

    Statistikken viser at brukerne jevnt over er ganske fornøyd med SPIRIT PMS. Riktig nok påpeker samtlige på en eller annen måte at systemet er gammeldags og utdatert. Dette setter vi hovedsakelig i sammenheng med systemets brukergrensesnitt mer enn funksjonaliteten. Programmet fremstår på mange måter med det typiske MS-DOS designet som mange kanskje husker igjen fra sent på åtti-tallet/tidlig nitti-tallet. Fargepaletten er begrenset, navigeringen er tastatur-drevet og det hele ser ikke direkte innbydende ut etter dagens standard.

    Utseende har selvfølgelig en del å si for den totale brukervennligheten til systemet, men hvordan systemet løser kjerneoppgaver og hvordan navigasjonen er bygd opp er nok allikevel viktigere. En ting som ble nevnt ofte både i forbindelse med intervjuene var systemets effektivitet. Her de fleste fornøyd. Det nevnes at systemet er veldig raskt og responsivt å jobbe på. Det at all navigering foregår ved hjelp av tastaturet nevnes faktisk som noe positivt, og det er jo ganske interessant, med tanke på at kombinasjonen tastatur/pekeenhet er nærmest enerådende i nye systemer.

    Vi ble selv overveldet over hastigheten resepsjonsmedarbeiderne utførte sine oppgaver på i systemet, når vi var til stede for å observere. Det gikk virkelig fort unna. I følge de ansatte sitter tastekombinasjoner og den generelle manøvreringen veldig godt i fingrene, og dette fører til god effektivitet når man har jobbet på systemet en stund.

    Her er et viktig poeng å dra frem: systemet er effektivt når man kan det. Det er derimot ikke så lett når man skal lære seg dette fra starten av. Over halvparten av de spurte mener at systemet er over middels vanskelig å lære seg. Det påpekes blant annet at det er lite hjelpefunksjoner i systemet, og at navigering gjøres ved hjelp av programkoder. Daglig bruk innebærer at man må ha kodene i hodet eller på en ”jukselapp”. Uten dette kommer man ingen vei.

    Brukerne mener til tross for dette at de har fått en tilfredsstillende opplæring på systemet. Dette tolkes dit hen at de er innforstått med at man faktisk må jobbe en del i løsningen før man kan regne med å mestre denne.

    Det later til å være en parallell mellom brukerens fartstid på systemet og følelsen av brukervennlighet man sitter igjen med. Nettopp fordi det tar lang tid før systemet ”sitter i fingrene”.

    Hvis vi ser litt nærmere på funksjoner i systemet har brukerne litt mer å påpeke. Det sies at systemet inneholder veldig mye nyttig info for resepsjonsmedarbeiderne. Informasjonen er dessverre vanskelig å hente ut av systemet på grunn av en søkemotor som kan late til å være dårlig optimalisert. Søk kan også oppleves som tregt av og til.

    I tillegg er det en del resepsjonists-oppgaver som burde gått automatisk men som må utføres manuelt. For eksempel må internett-bookinger legges inn manuelt i systemet.

    Forslag til endringer / forbedringer i systemet

    Vi på gruppen er ut i fra det vi har erfart ganske fornøyd med SPIRIT PMS. Vi hadde på forhånd regnet med at det skulle være mye å påpeke i et så gammelt system som SPIRIT PMS. Det meste fungerer ganske så effektivt når vi får systemet demonstrert av en som virkelig kan det.

    Vi har allikevel laget en liste med noen få forslag til forbedringer:

    Analysen viser høye tall for hvor mye de ansatte jobber direkte på systemet daglig (ca 6,5 timer i snitt). Vi antar at forbedring av overnevnte punkter kan minke tiden foran dataskjermen noe, men samtidig forteller nok timeantallet rett og slett mye om hvor sentral løsningen er for arbeidet i resepsjonen.

    9.EVALUERING AV PROSESSEN

    For å kunne gjennomføre dette prosjektet på en god måte har gruppens medlemmer blitt nødt sette seg inn i en mengde forskjellige emner. Dette har blitt gjort gjennom å følge forelesninger i faget, lese pensumlitteratur, samt skaffe seg annen nødvendig informasjon hovedsakelig på internett.

    Vi har skaffet oss kunnskap om metoder og verktøy for å kunne beskrive funksjonalitet i datasystemer, vi har lært om intervjuteknikk, brukertesting og datainnsamling og har fått verdifull kunnskap om personvern i forhold til disse områdene.

    Er det noe vi kunne ha gjort annerledes?

    Siden vi i stor grad mangler erfaring med oppgaver av slikt omfang som denne prosjektoppgaven er det sikkert flere ting vi kunne ha gjort annerledes.

    Det mest fremtredende å nevne må være hvordan vi løste intervjubiten, og kanskje hovedsakelig hvordan vi gjorde intervjuforberedelsene. Spørsmålene bestemte vi oss for i fellesskap, og i ettertid ser vi at vi kanskje burde brukt mer tid på formuleringen av disse, slik at spørsmålene ble mindre åpne for tolkning og slik at svarene hadde blitt litt mer statistikk-vennlige. Spørsmålenes svakheter ble vi egentlig først oppmerksomme på i intervju-situasjonen, og da følte vi at det var for sent å snu, selv om vi kanskje reddet oss litt inn gjennom omformulering av spørsmålene på ”direkten”. Så vi vil nok si at intervjubiten kunne vært gjort bedre, og det vil vi nok ha i minnet til neste gang vi står overfor en liknende situasjon.

    Mangler det noe i rapporten?

    Vi har brukt mye tid på utarbeiding av denne rapporten, så den har ingen direkte mangler vi så langt vi kan se, men i tilknytning til forrige punkt kan vi påpeke at analysen kunne ha vært mer omfattende hvis vi hadde hatt enda bedre data i bunn.

    Ellers som nevnt innledningsvis i rapporten er Thon Hotels i ferd med å bytte ut SPIRIT PMS til fordel for et nyere system. I utgangspunktet hadde vi lyst til å ta med en sammenlikning av det nye og det gamle systemet som en del av oppgaven. Tidsmessig ble dette ikke mulig å få til. Det er også en mulighet for at dette ville bidratt til å gjøre prosjektoppgaven og problemstilling mer diffus.

    Er det data vi ikke fikk tak i som kunne ha påvirket resultatene?

    Igjen faller det seg naturlig å henvise til øverste punktet i dette kapittelet. Vi kan ikke peke på spesifikke data vi ikke har fått tak i, men med et grundigere forarbeide i forbindelse med intervjuene, ville vi kunne ha fått et bedre statistisk grunnlag for våres analyse. Ut i fra det materialet vi har i bunn føler vi at vi har fått ut så mye som mulig informasjon.

    Hvordan har samarbeidet fungert i gruppa?

    Vi er alle i gruppen veldig fornøyd med samarbeidet og gruppens sammensetning. Vi har ikke hatt en eneste konflikt i løpet av semesteret vi har arbeidet sammen. De små uenighetene som har vært har blitt løst med en god tone og saklig diskusjon innad i gruppen.

    Vi har forholdt oss til gruppens samarbeidsavtale hele tiden. Vi har holdt oss til kritikk og tilbakemeldinger av den konstruktive typen, og har klart å holde en hyggelig tone oss i mellom.

    Alle har gjort sin del av arbeidet til avtalt tid, og er det noen som har trengt hjelp for å løse en oppgave har vi andre tilbudt den nødvendige hjelpen. I tillegg har vi forsøkt å la alle få prøve seg på alle de forskjellige områdene oppgaven har berørt. Dette føler vi har fungert greit.

    VEDLEGG

    Intervjuguide


    Valid XHTML 5! Valid CSS!