automatiseret vagtplanlægning - · pdf fileautomatiseret vagtplanlægning p1...

Automatiseret vagtplanlægning

P1 projekt, Aalborg UniversitetDatalogiTEK-NAT Basis

Gruppe A224Rune WejdlingNicholas TinggaardAndreas DalsgaardKristian RiishøjNiels HustedMichael MøllerJakob Knudsen

Det Teknisk-Naturvidenskabelige Basisår

Datalogi

Strandvejen 12-14Telefon 96 35 97 31Fax 98 13 63 93http://tnb.aau.dk

Titel:

Automatiseret vagtplanlægning

Tema:

Virkelighed og modeller

Projektperiode:

P1, efterårssemesteret 2005

Projektgruppe:

A224

Deltagere:

Jakob KnudsenAndreas DalsgaardRune WejdlingNiels HustedKristian Riishøj JensenMikael MøllerNicholas Tinggaard

Vejledere:

Morten KühnrichClaus Monrad Spliid

Oplagstal: 18 stk

Sidetal: 80

Appendiks: 4 kapitler

Bilags antal og -art: 1 stk CD-rom

Afsluttet den: 19/12 2005

Synopsis:

I denne rapport følges et projektforløb

som omhandler automatiseret vagtplanlæg-

ning. Projektarbejdet tager udgangspunkt en

række hypoteser omkring problemstillinger

vedrørende vagtplanlægning i praksis. Disse

hypoteser undersøges nærmere og en algorit-

me til automatiseret vagtplanlægning udvik-

les, som et løsningsforslag til problemstillin-

gerne. En vellykket test af vores algoritme,

implementeret i PHP, blev udført. Resultatet

blev en �gyldig� vagtplan, der tog højde for

kvali�kationer, personlige ønsker og løntrin for

en gruppe medarbejdere, i en �ktiv testcase.

Hver medarbejder havde tilknyttet et antal ti-

mer, pr. uge. Afvigelsen fra det fast timetal,

var i testen gennemsnitlig 10%.

Rapportens indhold er frit tilgængeligt, men o�entliggørelse (med kildeangivelse) må kun ske efter aftale

med forfatterne.

Forord

Denne rapport er udarbejdet i forbindelse med P1 projektet løbende fra den 11. oktober tilden 19. december 2005.

Udgangspunktet for dette projekt, er et oplæg fra vejlederen Morten Künrich valgt udfra en fælles interesse i projektgruppen. Derudover har en del af gruppen desuden stiftetbekendtskab med emnet under P0.

Formålet med rapporten er at belyse problematikken omkring vagtplanlægning og auto-matisering af denne proces. Ud fra dette emne beskrives kompleksiteten af problemet og deproblemer, som dette medfører. Problemet undersøges med udgangspunkt i en række lokaleaalborgensiske arbejdsmiljøer. Denne undersøgelse og en vurdering af eksisterende softwaredanner baggrund for et løsningsforslag til et nyt stykke software, som kan overtage opgavenomkring koordinering af arbejdsstyrken i en virksomhed og samtidig tage højde for medar-bejdernes ønsker.

Rune [email protected]

Simon Nicholas Moesby [email protected]

Andreas [email protected]

Kristian Riishø[email protected]

Niels [email protected]

Michael Mø[email protected]

Jakob [email protected]

ii

INDHOLD

1 Indledning 31.1 Forståelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Case brugt i begrebseksemplerne . . . . . . . . . . . . . . . . . . . . . 31.1.2 Sammenhængen mellem begreberne . . . . . . . . . . . . . . . . . . . 31.1.3 Begreber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Problemanalyse 72.1 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Hypoteser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Hypoteserne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Metode til test af hypoteser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Interviewmetode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Sammendrag af interviews . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3 Interview analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.4 Interview konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.5 Metodekritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Software undersøgelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.1 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.2 Udvalgte programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.3 Resultater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.4 Software konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.5 Metodekritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Teknisk problematik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.1 Mulige vagtplanlægning . . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.2 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8 Afgrænsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.9 Metodekritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Løsning 273.1 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Kravspeci�kation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2 Algoritmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1 Algoritme typer til vagtplanlægning . . . . . . . . . . . . . . . . . . . 283.3.2 Algoritmerne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.3 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Udvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.1 Indledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.2 Metode til udvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.3 Intuitiv algoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.4 Resistans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1

Indhold

3.4.5 Videreudvikling af intuitiv algoritme . . . . . . . . . . . . . . . . . . . 343.4.6 Pseudokode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.7 Vurdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5 Vagtplanlægningssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.5.1 System beskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.1 Indledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6.2 Præsentation og opbygning . . . . . . . . . . . . . . . . . . . . . . . . 413.6.3 PHP iCalendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.4 Udvikling af prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.5 Test af prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6.6 Konklusion på test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.6.7 Vurdering af prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Afsluttende afsnit 514.1 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Perspektivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Litteraturliste 53

Bilag 55

A Interview 55A.1 For analyse for interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.2 Hovedinterview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.3 Interviewet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.3.1 Herefter udføres det egentlige interview med den adspurgte . . . . . . 56A.3.2 Indledende spørgsmål om arbejdsplanlægning . . . . . . . . . . . . . . 56A.3.3 Spørgsmål vedrørende det personlige ansvar ved arbejdsplanlægning. . 56A.3.4 Spørgsmål til fejl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.3.5 Spørgsmål til hvad der opstår af utilfredshed i forbindelse med arbejds-

planlægning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.3.6 Spørgsmål til de mere tekniske ting i forbindelse med arbejdsplanlægning. 57A.3.7 Spørgsmål til om folks kvali�kationen har betydning. . . . . . . . . . . 57A.3.8 Spørgsmål til om medarbejderne har medbestemmelse i forbindelse med

planlægningen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.3.9 Gennemgang af vores studieprojekt . . . . . . . . . . . . . . . . . . . . 58

A.4 Interview med Anni Kristensen . . . . . . . . . . . . . . . . . . . . . . . . . . 58

B Software undersøgelses bilag 63B.1 Intelliroster Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63B.2 Time Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66B.3 Work Schedule Dot Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

C Kommentarer til pseudokode 73

D Classes brugt i prototypen 75D.1 Work_schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75D.2 shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75D.3 employee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75D.4 appointment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

2

KAPITEL

1

Indledning

Målet med dette projekt er at udvikle og dokumentere et stykke algoritme, som kan læggeen vagtplan. For at identi�cere disse elementer stiles der mod en forståelse for de problemer,som virksomheder har med vagtplanlægningen i det lokale erhvervsliv.

Projektets initierende problem �vagtplanlægning� er taget ud fra oplæg 4.8 fra P1-projekt-kataloget [7]. Fokus er lagt på det besvær, som selve den proces at lægge en vagtplan og koor-dinere en arbejdsstyrke medfører. I første omgang stiles projektet imod at lette arbejdsbyrdenfor vagtplanlæggeren, som skal udføre denne proces ved at udvikle et stykke software, der kanovertage arbejdet med denne koordinering. Problematikken om at lægge en vagtplan beskuesnærmere i problemanalysen og beskrives i en form, der lægger op til en automatisering afvagtplanlægningsprocessen.

1.1 Forståelse

Meningen med forskellige begreber brugt i dette projekt forklares i dette afsnit. Formålet meddenne udlægning er at dele vagtplanlægningen op i mindre begreber, som er mere overskue-lige. For at kunne forklare begreberne refereres jævnligt til en case beskrevet i afsnit 1.1.1.Denne case er holdt så simpel som mulig, så den ikke giver problemer i forbindelse medvagtplanlægningen. Det er svært at forestille sig en virksomhed, der køres på et så simpeltgrundlag som i denne case. Den benyttes blot til eksempler på værdier, som de de�neredebegrebers egenskaber kan have.

1.1.1 Case brugt i begrebseksemplerne

Et meget lille �rma har to maskiner til at køre dagligt mellem klokken 8:00 og 16:00. Detkræver to medarbejdere at holde en maskine kørende. Begge disse medarbejdere skal desudenhave gennemført et kursus i brug af maskinen. Til at køre de to maskiner har �rmaet femmedarbejdere: Klaus, Peter, Anna, Karen og Markus. De har alle taget det førnævnte kursus.Hver medarbejder arbejder 32 timer om ugen. De har derfor plads i en arbejdsuge til en enkeltfridag. En af medarbejderne ønsker at holde fri om fredagen.

1.1.2 Sammenhængen mellem begreberne

Vagtplanlægningen er delt op efter følgende beskrivelse af processen. For et større eller mindre�rma (begreb 1) skal en vagtplan (begreb 4) lægges. En vagtplanlægger (begreb 2) udførerprocessen vagtplanlægning (begreb 3). Under denne proces tages der hensyn til medarbejderesegenskaber (begreb 9) og vagternes opgaver (begreb 7 og begreb 8). Resultatet af detteer en vagtplan, hvor medarbejderne er fordelt over de givne vagter. Denne vagtplan kankvali�ceres som enten værende en god vagtplan (begreb 5) eller en dårlig vagtplan ved hjælpaf vagtplansvurderingen (begreb 6).

3

Kapitel 1. Indledning

1.1.3 Begreber

Begreb 1. Der skelnes mellem �rmastørrelse. Et lille eller �mindre� �rma er et �rma medmindre en tyve medarbejdere og et stort eller �større� �rma er et �rma med mere end tyvemedarbejdere.

Begreb 2. Vagtplanlæggeren er den person, der udfører processen vagtplanlægning (be-greb 3). Det kan enten være en medarbejder, som manuelt lægger en vagtplan eller en person,der sørger for at det program der skal lægge vagtplanen, har det nødvendige data og sættesigang.

Begreb 3. Vagtplanlægning er den process hvori en vagtplanlægger eller et værktøj plotterde tilgængelige eller kvali�cerede medarbejdere ind på de vagter, der skal bemandes. Undervagtplanlægningen tages i forskellig grad højde for en række forskellige kriterier. Et eksempelpå et kriterium er at en medarbejders (begreb 9) faste timetal skal holdes eller at medar-bejdernes ønsker (begreb 10) skal tilgodeses. Vagtplanlægningen kan altså beskrives som enproces, der ved hjælp af en række opstillede kriterier producerer en vagtplan (begreb 4).

Begreb 4. En vagtplan er en mængde af vagter (begreb 7), som tilsammen udgør en givenvirksomhed eller afdelings aktiviteter. Der skelnes mellem dynamiske og statisk vagtplaner.En statisk vagtplan bruges i forbindelse med en fast mængde vagter, der gentages igen ogigen. Hvis der skal ændres i en fast vagtplan, er det højst en ombytning af to vagter ellermedarbejdere. For eksempel ved udskiftning i medarbejderstaben. En dynamisk vagtplanderimod er i konstant forandring. Vagter kan ændres, idet opgaverne der skal løses ikkenødvendigvis ligger fast. Medarbejderne kan bytte vagter imellem hinanden og derved selvændre vagtplanen. En vagtplan kan udfærdiges som det simple eksempel på tabel 1.1. Denvil dog typisk fremvises i et mere læseligt kalenderformat, hvor vagterne er plottet ind efterderes angivne tidsrum.

Egenskab VærdiNavn Gentagen ugeplan for fabrikVagter Maskinvagt1, Maskinvagt2

Tabel 1.1: Eksempel på vagtplan.

Begreb 5. Idet en vagtplan lægges ud fra en række krav og ønsker givet fra forskelligeparter, er det et oplagt succeskriterie at overholde så mange som muligt af disse krav ogønsker. En vagtplan, som stiller en given part tilfreds vil oftest opfattes af denne part som engod vagtplan. Derfor vil en god vagtplan være en vagtplan, der tilfredsstiller så mange sommuligt ved at opfylde deres krav og ønsker. En god vagtplan opfylder altså så mange sommuligt af de givne kriterier1.

Begreb 6. Vagtplansvurderingen er en proces, hvori en given vagtplan vurderes. En vagtplankan i større eller mindre grad være en god vagtplan (begreb 5) som tidligere de�neret.

Begreb 7. En vagt de�neres som et tidsrum, i hvilket der skal udføres en mængde opgaver(begreb 8). I stedet for at tillægge en vagt en enkelt opgave, kan en vagt indeholde �eresideløbende opgaver. Vagterne har tildelt en mængde medarbejdere (begreb 9), som skaludføre opgaverne i den aktuelle vagt. Mængden af medarbejdere opfylder et krav om mindsteantal som er givet ud fra vagtens opgaver og de skal desuden opfylde de krav som stilles af

1Hvordan dette måles i forbindelse med den udvilede algoritme er nærmere beskrevet i afsnit 3.4.4

4

1.1. FORSTÅELSE

disse opgaver. En vagt kan være unik, hvilket vil sige at det angivne tidsrum løber fra etgivent tidspunkt til et andet. Vagten kan også være gentagen og for eksempel �nde sted hvertorsdag mellem klokken 8:00 og 16:00. Sidstenævnte vil være det mest almindelige i langt de�este virksomheder, idet medarbejderne typisk har faste ansvarsområder og arbejdstider. Enmandagsvagt fra casen i afsnit 1.1.1 vil se ud som på tabel 1.2.

Egenskab VærdiNavn MaskinvagtStartdag Hver mandagStarttid 8:00Slutdag Hver mandagSluttid 16:00Medarbejdere Klaus, Peter, Anna og MarkusOpgaver Passe maskine nummer 1, Passe maskine nummer 2

Tabel 1.2: Eksempel på vagt.

Begreb 8. En opgave de�neres ud fra de krav den stiller til de medarbejdere, der skal løseden. En opgaves eneste e�ekt på en vagt er således tilførelsen af et krav til de medarbejdere,som bliver tildelt denne vagt og antallet af medarbejdere. Eksemplet på tabel 1.3 beskriveropgaven der består i at passe en maskine fra casen i afsnit 1.1.1. Denne opgave indebærerat passe maskinen i løbet af vagten. Dermed angiver opgaven at to medarbejdere, som hartaget kursus i brug af maskinen, skal sættes på en vagt, hvis denne opgave skal løses i løbetaf vagten.

Egenskab VærdiNavn Passe maskine nummer 1Krav 2 medarbejdere som har taget kursus i brug af pladevendermaskinen

Tabel 1.3: Eksempel på opgave.

Begreb 9. En medarbejder tildeles en vagt på baggrund af hans kvali�kationer og de ar-bejdstider, der passer bedst på vedkommende. En medarbejders tidsrelaterede egenskaber kandeles op i �ere kategorier. Alt efter vedkommendes ansættelseskontrakt, skal en vis mængdetimer sættes af i løbet af en tidsperiode. Dette kan for eksempel komme til udtryk i et fasttimetal hver uge. Derudover kan vedkommede have en række personlige aftaler, som kan kom-me i kon�ikt med arbejdet, eller vedkommende kan have et ønske om kun at arbejde 4 ud af5 dage i løbet af en typisk 5-dages arbejdsuge. Vedkommende kan for eksempel fastsætte enforetrukken fridag om fredagen, hvis vedkommende kun skal arbejde 4 ud af 5 hverdage. Bådepersonlige aftaler og ønsker om en fridag kan udtrykkes i et medarbejderønske (begreb 10).

En medarbejder har som nævnt også en række kvali�kationer. Ikke alle medarbejderekan påtage sig alle opgaver i en given virksomhed. På tankstationer må man for eksempelikke lukke alene hvis man endnu ikke er fyldt 18 og i industrien skal man i mange tilfældeuddannes til at bruge de forskellige maskiner. På nogle virksomheder kan forskelligt lønnedemedarbejdere løse nogle af de samme opgaver. F. eks. på en tankstation med medarbejdereover og under 18 år, må begge grupper af medarbejdere kan sætte varer på plads og passedisken; men man må stadig ikke lukke alene, hvis man endnu ikke er fyldt 18. En 18-årig erdog betydeligt dyrere end en 16-årig og det kan derfor i mange tilfælde bedre betale sig athave sidstnævnte tildelt en vagt. Lønnen er altså ikke uden betydning, når man skal vælge

5

Kapitel 1. Indledning

medarbejdere til en given vagt og den er dermed endnu en interessant egenskab for hverenkelt medarbejder. Lønnen kan for eksempel være opgivet som en timeløn. Et eksempel påen medarbejder, lavet ud fra Markus i casen (afsnit 1.1.1), kan ses på tabel 1.4.

Egenskab VærdiNavn MarkusTimer per uge 32Personlige aftaler Aftale1, Aftale2, Aftale3Kvali�kationer Har taget kursus i brug af maskine og sikkerhedskursusTimeløn i kroner 100

Tabel 1.4: Eksempel på medarbejder.

Begreb 10. Et ønske fra en medarbejder om at have fri i en periode, grunder oftest i enaftale denne medarbejder har med en tredjepart. Et sådan ønske de�neres ud fra et tidsrumog en prioritet. Denne prioritet er et udtryk for hvor høj værdi den aktuelle medarbejdertillægger dette ønske. Altså hvor vigtigt det er for medarbejderen at have fri i forbindelsemed det aktuelle ønske i forhold til resten af medarbejderens ønsker. Dette kan for eksempeludtrykkes som �lav�, �medium�, eller �høj� prioritet. En aftale kan for eksempel se ud som itabel 1.5.

Egenskab VærdiNavn Ønske om at få fri på fredagPrioritet MediumStartdag Den 5. januar 2005Starttid 8:00Slutdag Den 5. januar 2005Sluttid 16:00

Tabel 1.5: Eksempel på medarbejderønske.

6

KAPITEL

2

Problemanalyse

Der er �ere indgangsvinkler man kan tage når man skal beskæftige sig med problematikkeromkring begrebet vagtplanlægning. Vi har i gruppen valgt at arbejde med emnet som etproblemorienteret projektarbejde. Det vil sige, vi vil tage udgangspunkt i et egentligt pro-blem, som skal kunne løses i slutningen af projektet. Det kan gøres enten teoretisk eller ipraksis, alt efter hvad vi i projektforløbet har fundet ud af. For at kunne identi�cere hvilkeproblemer der er mest relevante at tage fat på i relation til hovedproblemet vagtplanlægning,har vi fundet det relevant at gøre nogle undersøgelser på baggrund af egne erfaringer medemnet. Disse undersøgelser foretages ved at gå ud i den virkelige verden, samle informationom emnet og derudfra analysere hvilke metoder der bruges og hvilke problemer folk generelthar, når de skal udforme vagtplaner for deres virksomhed eller organisation.

2.1 Metode

For at have en baggrund for undersøgelserne, har vi fundet det nødvendigt først at �ndeen række mulige problemstillinger. Det vil sige, vi vil udarbejde en eller �ere hypoteser om-kring det at lægge en vagtplan og en automatisering af denne på baggrund af en brainstormblandt gruppens medlemmer. Derefter vil vi teste om hypoteserne gælder i praksis. Disseundersøgelser kan yderligere bruges til at identi�cere nogle problematikker, vi ikke har tænktover i vores indledende undersøgelse. Selve undersøgelsen foregår ved, at vi først vil udførenogle interviews og undersøge baggrunden for hvilke vagtplanlægningsmetoder, der anvendesi virksomheder, hvilke virksomheder der kan have gavn af automatisk vagtplanlægning oghvilke forhold der gør sig gældende, når man skal lægge en vagtplan. Derefter vil vi undersø-ge hvilke softwareprodukter, der allerede eksisterer til løsningen eller hjælper til løsningen afproblemet �at lægge en vagtplan�. Efter selve de praktiske undersøgelser, vil vi undersøge denteoretiske kompleksitet, ved at lægge vagtplaner for mange medarbejdere i et teknisk afsnit.Her afdækkes den matematiske baggrund for det at lægge en vagtplan, således omfanget afproblemet bliver mere tydeligt. Disse praktiske og teoretiske undersøgelser skal munde ud ien overordnet problemformulering, hvor de mulige problemstillinger udledt af undersøgelsenlistes op. Problemformuleringen skal kunne lede os mod en afgrænsning, hvor de problema-tikker vi vælger at arbejde med de�neres, således vi kan udarbejde en kravspeci�kation tilvores egen løsning.

2.2 Hypoteser

Følgende hypoteser er opstået ved intern diskussion og overvejelser baseret på erfaringer ogviden som projektgruppens medlemmer besidder omkring vagtplanlægning og beskriver grup-pens teorier omkring problemet �vagtplanlægning�. Hypoteserne beskriver dermed problemet,som gruppen antager, at det ser ud og de problemstillinger man kunne støde på, når manundersøger problemer omkring vagtplanlægning. Hypoteserne nr. 1-8 danner grundlag for, atder er et egentligt problem involveret i vagtplanlægning, mens hypotese nr. 9 danner bag-grunden for en software-baseret løsning af problemet. Hypoteserne testes i problemanalysen,

7

Kapitel 2. Problemanalyse

hvorefter de gyldige eller bekræftede problemstillinger i henhold til en automatisering af envagtplan opridses i problemformuleringen.

2.2.1 Hypoteserne

Hypotese 1. At lægge en vagtplan er en tidskrævende proces, da det ofte gælder, at jo �eremedarbejdere en vagtplan skal lægges for, des sværere bliver det at overskue processen og fåvagtplanen til at hænge sammen. Det tager lang tid for en planlægger at lægge en vagtplanog den tidskrævende opgave koster mange penge i lønninger til vagtplanlæggeren.

Hypotese 2. Idet ikke alle medarbejdere kan eller må løse alle opgaver, øges vagtplanlæg-ningens kompleksitet. Det nytter ikke at sætte medarbejdere på en vagt, hvis ikke de harforudsætningerne for at udføre de opgaver, som vagten indebærer. Derfor må en vagtplan-lægger have overblik over hvilke jobs hver ansat har mulighed for at varetage, så den meste�ektive plan kan lægges. Ved at dokumentere medarbejdernes færdigheder bliver det ogsålettere at �nde a�øsere til ferie- og sygdomdomsrelateret a�øsning eller lignende.

Hypotese 3. Det er vagtplanlæggerens opgave at plotte medarbejdernes afspadsering ogferie ind i vagtplanen på passende tidspunkter, samtidigt med at der bliver taget højdefor medarbejdernes ønsker. Af denne og andre årsager kan det blive nødvendigt at giveandre medarbejdere overarbejde for at få hele planen til at hænge sammen. For eksempel,ved længerevarige sygdomsforløb for en enkelt medarbejder, kan det blive nødvendigt atgive resten af medarbejderstaben en eller �ere timers overarbejde i samme periode, for atvagtplanen kan hænge sammen i henhold til de givne opgaver som skal varetages.

Hypotese 4. Det kan være tilfældet på nogle vagter, at det ikke er nok med en enkelt ansattil at tage vagten. Hvis vagten er meget vigtig, kan der blive behov for at have en a�øser klari forbindelse med akut sygemeldelse. Inden for nogle brancher er dette en nødvendighed forat opretholde produktion eller service. Et eksempel kunne være special uddannede arbejderepå en fabrik eller kokkene på en restaurant.

Hypotese 5. Det kan være svært at overskue, hvem der har arbejdet hvor meget. Det erderfor også en betydelig opgave at holde styr på dette under vagtplanlægning, især hvis manskal sikre sig at arbejdsmiljøregler [5] er overholdt og at overenskomsten overholdes. Derforbetragtes medarbejdernes ønsker om �eksible arbejdstider, som en af de mere uoverskueligedele af vagtplanlægningen. Det kan være svært at tage højde for ønsker om fridage, når manmanuelt skal lægge en vagtplan.

Hypotese 6. På grund af kompleksiteten af vagtplanlægningen øges antallet af menneskeligefejl og personlige problemer kan opstå, fordi medarbejdere kan føle sig tilsidesat i en dårligtopstillet vagtplan. Ved manuel planlægning kan det være svært at overskue og tage højde formedarbejdernes ønsker til en vagtplan og derfor vælger en planlægger ofte at lægge en plan,som ikke tager højde for medarbejderes ønsker.

Hypotese 7. Selve vagtplanlægningen er ikke en populær arbejdsopgave blandt vagtplan-læggere, da det kræver en del tid og overblik, samt det kan være meget problematisk at få dethele til at �gå op�. Rollen som planlægger kan i nogle tilfælde resultere i at en medarbejderbliver opfattet som en �boss-type�, hvilket kan medføre sociale kon�ikter. Hermed menes, atder kan forekomme utilfredse medarbejdere, som følge af vagtplanens udformning og dermedmedføre et negativt syn på vagtplanlæggeren.

Hypotese 8. Mange af de samme faktorer, som er væsentlige under vagtplanlægningen istore virksomheder, er også gældende i små virksomheder. Derfor kan problemerne indenfor

8

2.3. METODE TIL TEST AF HYPOTESER

rimelighedens grænser skaleres op eller ned fra et givent udgangspunkt. Man kan altså tilladesig at fokusere på mindre virksomheder. Ved at fremstille en løsning ud fra de problemer, deropleves hos små virksomheder, vil man også komme relativt tæt på en løsning, som egner sigtil større virksomheder.

Hypotese 9. Der er mangel på brugbare software, der kan assistere med vagtplanlægning.Denne hypotese grunder i at de af gruppens medlemmer, som har rørt vagtplanlægningen ierhvervslivet, ikke har erfaring med, at der bliver brugt software til vagtplanlægningen. Hvisbrugbare værktøjer var tilgængelige, ville det medføre �ere virksomheder benyttede sig afdisse.

2.3 Metode til test af hypoteser

For at undersøge om hypoteserne gjorde sig gældende i erhvervslivet, kontaktede vi noglevirksomheder, som vi mente lagde dynamiske vagtplaner. Gennem interview af vagtplanlæg-gerne i disse virksomheder, undersøgte vi hvilke problemer, de stødte på, når de skulle læggeen vagtplan for deres medarbejdere og om de i det hele taget brugte dynamiske vagtplaner.Hypoteserne dette omhandler er hypoteserne 1 til 8. Derudfra kunne det også vurderes, hvor-vidt der var basis for at lave en softwarebaseret løsning på disse problemer. Vi brugte ogsåinterviewene til at �nde nye informationer, der kunne hjælpe os til at lave en softwareløsning,der bedre kunne bruges i praksis. Ud over disse interviews undersøgtes allerede eksisterendesoftware udviklet til at løse problemet. Formålet med en softwareundersøgelse var at testeom de løsninger, der allerede fandtes, var brugbare og derudover at kunne udlede funktiona-liteter eller overvejelser til en løsning, som kunne løse problemet omkring vagtplanlægningsautomatisering. Formålet var at undersøge hypotese 9.

2.4 Interview

Interviewet har til formål at teste vores hypoteser. Målet med interviewene er at teste ogsandsynliggøre vores hypoteser, således vi bedre kan gøre det klart hvilke problematikker derer at tage fat på, med henblik på hvordan vagtplanlægning foregår i praksis. Derudover vilder kunne dannes et indtryk for hvilken type vagtplanlægning, der bruges i forskellige typervirksomheder.

2.4.1 Interviewmetode

Da hypotese 8 påstår at problemerne kan �ndes både i små og store virksomheder rettesinterviewet mod 3 små og 3 store virksomheder. Derudover har vi fundet 2 �backup� virk-somheder, i tilfælde af at en af de udvalgte virksomheder ikke vil medvirke i rapporten ellervi føler vi mangler konkrete resultater. Som indledende interviewmålgruppe har vi besluttetos for at beskæftige os med virksomheder, der har mange unge ansatte, da disse virksomhedermed stor sandsynlighed, efter vores opfattelse, bruger dynamisk vagtplanlægning i praksis.Da �ere fra gruppen selv har arbejdet på tankstationer og ved at der er mange unge i arbejdenetop der, vælges der som udgangspunkt 3 tankstationer (mindre virksomheder). Derudoverhar vi besluttet os for at gennemføre interview med 3 større virksomheder, navnlig to ple-jehjem og en ungdomshøjskole . Som backup interviewkontakter har vi yderligere valgt totankstationer.

Interviewet er bygget op i mindre grupper af spørgsmål, der er dannet ud fra hypote-serne. De �este af hypoteserne drejer sig om problemstillingerne bag planlægningen af en

9


dynamisk vagtplan, derfor er interviewet rettet mod den ansvarlige for vagtplanlægning, ef-tersom vagtplanlæggeren er den, der ved mest om emnet. Interviewene skal foregå ved etpersonligt interview på virksomheden, da det giver den bedste indsigt i virksomhedens me-tode til vagtplanlægning.

Vi starter med at ringe til de eksterne kontakter, for at undersøge om vi kan brugevirksomheden som interview kontakt og eventuelt derefter aftale et interview møde. Underopkaldet stilles der nogle indledende spørgsmål. Dette gøres for at afklare, om virksomhedenbruger en dynamisk vagtplan. Hvis ikke virksomhederne anvender dynamiske vagtplaner,mener vi ikke at det er hensigtsmæssigt at gennemføre interviewene, dels fordi vores interviewspørgsmål er rettet mod virksomheder, der anvender dynamisk vagtplaner, men også for ikkeat forstyrre virksomhederne mere end nødvendigt.

Spørgsmålene til den interviewede er designede, så der er �ere typer spørgsmål. Ifølge�InterView� [15] er det vigtigt at formulere spørgsmålene rigtigt, så man får nogle brugbaresvar. Formålet med nogle af spørgsmålene er at få svar, der er fyldestgørende udsagn, som visiden kan bruge i forbindelse med argumentering for hypotesernes gyldighed. I andre tilfældebør spørgsmålene give kortere ja-nej svar, der i højere grad gør det muligt at sammenligneforskellige interviewede personers udsagn. Interview spørgsmålene kan ses i bilag A på side 55.

2.4.2 Sammendrag af interviews

Shell Service A/S, Aalborg

Hos Shell Service A/S [3] har bestyreren af tankstationen lagt hele ansvaret for vagtplanenover på medarbejderne. Medarbejderne har valgt at ordne deres vagtplan således, at deen gang om måneden afholder et vagtplanlægningsmøde, hvor medarbejderne kan melde udhvilke vagter, de godt kunne tænke sig at få. På den måde undgås der, at der er mange vagter,der senere skal byttes, når en anden har lavet vagtplanen for dem. Hvis en medarbejder ønskerat bytte en vagt, er det personens eget ansvar.

Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender endynamisk vagtplan.

Statoil A/S, Aalborg Ø

Bestyreren af Statoil A/S [4] står selv for at lægge medarbejdernes vagtplan. Der bruges enfast vagtplan som udgangspunkt, hvor der siden bliver lavet ændringer fra gang til gang. Hvisder er en af medarbejderne, der gerne vil have byttet en af sine vagter, står han/hun selv fordet.


Statoil Servicecenter, Nørresundby

Statoil Servicecenter [25] i Nørresundby har inddelt sine medarbejdere i 2 grupper. Der er3 fastansatte til at passe vagterne om dagen på hverdage samt enkelte dele af weekenden.Aften- og weekendvagter bliver dækket af en gruppe deltidsmedarbejdere. Samlet set harmedarbejderne en fast vagtplan, der forløber over 2 uger. Deltidsmedarbejderne mødes alletil et personalemøde, hvor de så selv kan melde ud hvilke vagter de ønsker at få. Det erden samme model, som tidligere beskrevet hos Shell Service A/S, Aalborg. Hvis der er enmedarbejder der vil have byttet en af sine vagter, står han/hun selv for det.


10

2.4. INTERVIEW

Hydro-Texaco, Nørresundby

På Hydro-Texaco [17] i Nørresundby er der 2 fastansatte samt ejeren, der varetager de vagter,der er i dagtimerne. De vagter der er derudover bliver passet af en gruppe deltidsansatte. Dedeltidsansatte har deres egen vagtplan, som bliver lavet af ejeren. Det er en fast vagtplan,men medarbejderne kan godt komme med ønsker til faste ændringer. De ønsker bliver sidentaget op til det næste personalemøde. For at et ønske kan gennemføres, er det nødvendigtat bytte fast med en anden medarbejder for at undgå at lave en helt ny vagtplan. Hvis enmedarbejder ønsker at bytte en enkelt vagt, står han/hun selv for det.


Ungdomshøjskolen Ternen, Nørresundby

Vi interviewede vagtplanlæggeren på Ungdomshøjskolen Ternen [28] i Nørresundby. På Ter-nen bliver der én gang om året lavet en grundplan, hvor der bliver tager højde for med-arbejdernes ønsker. Hver tolvte uge bliver grundplanen revideret, hvis der for eksempel erkommet nogle nye ønsker fra en af medarbejderne eller på grund af længere sygdomsforløbhos en medarbejder. Der bruges, set over en periode på et år, i gennemsnit ca. 4 timer omugen på at opdatere vagtplanen for 30 medarbejdere samt en gruppe vikarer. Det vil sige, atder på et år bruges ca. 108 timer på opdatering at deres vagtplan. Ud fra dette mener vi atvores hypotese 1 er blevet underbygget. Medarbejderne på Ternen har meget stor frihed tilat komme med ønsker til vagtplanen, som for eksempel ønsker til fridage/afspadsering. Nårmedarbejderen kommer med sit ønske, prøver vagtplanlæggeren i første omgang at tildele enaf de andre fastansatte vagten. Hvis det ikke lykkedes, prøver vedkommende at sætte en afderes vikarer på vagten. Hvis det heller ikke kan lade sig gøre, bliver de nødt til at sige til denmedarbejder, der gerne vil have fri, at det ikke kan lade sig gøre. Hvis det er en af de andremedarbejdere, der accepterer vagten, vil den pågældende medarbejder få noget overarbejde,som skal afspadseres. Det er ikke muligt for en medarbejder at få udbetalt overarbejdstimer,så der skal også tages højde for, hvor meget overarbejde en medarbejder har, når der læggesen vagtplan. Alt dette gør opgaven meget uoverskuelig, hvilket dermed underbygger hypote-se 3 samt hypotese 5. Et andet problem for vagtplanlæggeren er, at de andre medarbejderehar svært ved at �nde ud af, hvornår vedkommende er vagtplanlægger og hvornår denne eren normal medarbejder. Hvis det sker at folk er utilfredse med en vagtplan, vil de i nogletilfælde være utilfredse med vagtplanlæggeren. Dette underbygger hypotese 7.

En direkte transskribering af interviewet fra Ungdomshøjskolen Ternen kan læses i ap-pendix A.4 på side 58.

Lundbyecenteret (Plejehjem)

Medarbejderne på Lundbycenteret [21] har en fast vagtplan. En af medarbejderne har ansva-ret for at holde den opdateret. Den ansvarlige har et stykke software fra KMD1, der hjælpermed at overholde de administrative regler. Programmet melder om fejl, hvis der byttes tovagter, som overskrider de regler, der er opstillet.


1Kommunedata, http://www.kmd.dk/

11

http://www.kmd.dk/


Kærby Hvilehjem (Plejehjem)

Kærby Hvilehjem [10] bruger det samme system fra kommunen som Lundbyecenteret. Enmedarbejder stod for det administrative arbejde med at lægge en vagtplan og validere denmed KMDs system således at der ikke blev overskredet regler og vagtplanen stadig blev lagtinden for virksomhedens rammer.


7-eleven, i Aalborg

7-eleven [1] på Vesterbro kører med en fast vagtplan. Bestyreren vi interviewede sagde, athan mente det var den bedste form for vagtplan, da det var lettest for ham at styre. Hanbehøvede ikke at bruge særligt meget tid på vagtplanen og undgik besværet med at lægge denmere end én gang. Derudover mente han, at en anden gavnlig e�ekt ved at en medarbejderkonsekvent havde de samme vagter, var at vedkommende blev fortrolig med vagten. Hermedmentes, at medarbejderen efter nogen tid vidste, hvordan vedkommende skulle prioritere deenkelte opgaver, selv når der var meget travlt. Bestyreren udtrykte mangel på et program,der kunne sammenholde medarbejdernes indberettede timetal med den lagte vagtplan.


2.4.3 Interview analyse

Foranalysen til interviewene viste, at det egentligt kun er én ud af de 8 adspurgte virk-somheder, der anvendte en dynamisk vagtplan. Da vores hypoteser i høj grad drejer sig omproblemstillingerne ved lægning af en dynamisk vagtplan, mente vi ikke det var relevant atgennemføre interviewet med de virksomheder, der anvender en anden type vagtplanlægning.Ud fra foranalysen fandt vi i stedet frem til 2 andre metoder, der anvendes til planlæg-ning af en vagtplan. Formålet med disse metoder, er at undgå mange af problemerne ved endynamisk vagtplan. Under vores foranalyse opdagede vi også, at det ofte ikke var den vagt-plansansvarlige, der havde et problem. Med en fast vagtplan, der ikke tager meget hensyntil medarbejderne, undgås de planlægningsmæssige problemer. For eksempel �yttes ansvaretfor at bytte vagter i tilfælde af sygdom over på medarbejderne og på den måde undgås derekstra arbejde for den ansvarlige, der også skal passe sine normale opgaver i virksomheden.Vi har herunder listet de 3 metoder til vagtplanlægning, vi nu kender til.

Metode 1. Én person er ansvarlig for planlægningen af vagtplanen og der lægges en nyvagtplan efter hver endt plan uden sammenhæng med den forrige. Her har en medarbejdermulighed for at ønske om fri fra arbejdet. Denne metode er bekostelig og besværlig, da dettager lang tid og opgaven er svær at overskue. Derfor har et �ertal af de eksterne kontaktervalgt ikke at anvende denne løsning. Ved denne metode vil der forekomme bytning af vagtermellem medarbejdere, da der kan forekomme nye aftaler i medarbejdernes private kalender.Det positive ved denne metode er, at alle kan få de attraktive vagter på skift, da vagtplanenændres tit.

Metode 2. Der lægges en fast vagtplan. Det betyder en vagtplan, der løber i en bestemtperiode, for eksempel 3 uger. Efter de 3 uger starter planen forfra. Dette betyder, at enplan kun skal lægges en enkelt gang for en virksomhed og ved udskiftning af en medarbejderovertager den nye medarbejder bare den udskiftedes vagter. Problemet med denne metodeer, at den skaber en masse bytteri mellem medarbejderne. En positiv ting ved denne metode

12

2.4. INTERVIEW

er, at medarbejderen får faste arbejdsdage og vedkommende bliver tryg ved vagten. Det erfor nogle medarbejdere også betryggende at have den samme vagt, da man altid skal arbejdepå det samme tidspunkt.

Metode 3. Inden en vagtplan er udløbet, mødes medarbejderne til et vagtplanlægnings-møde eller personalemøde og melder ud hvilke vagter de ønsker at tage. Med det menes atmedarbejderne fortæller hvilke vagter de ønsker at tage, men metoden kræver at alle medar-bejderne mødes for eksempel en gang om måneden. Denne metode kan reducere ombytningenaf vagter indbyrdes mellem medarbejdere kraftigt, men man undgår det ikke helt, da der altidkan opstå andre planer deres private kalendre.

2.4.4 Interview konklusion

Ud fra foranalysen til interviewene kan vi konkludere, at �ertallet af de adspurgte anvender enanden metode til planlægning af en vagtplan, end den hvor der lægges en dynamisk vagtplan.Ved brug af metode 2 undgås meget af vagtplanlægningsbesværet og der tages ikke megethensyn til medarbejdernes ønsker. Metode 3 tager hensyn til medarbejdernes ønsker, det erdog den enkelte medarbejders eget ansvar at få dem opfyldt, ved at deltage i personalemøder.Ud fra dette har vi fundet frem til, at der kan være et problem, da medarbejderne selv haransvaret for at få opfyldt sine ønsker til vagtplanen.

Vores interview med vagtplanlæggeren hos Ungdomshøjskolen Ternen kan, udover at be-grunde at der �ndes virksomheder med dynamisk vagtplanlægning, bruges til at sandsynlig-gøre nogle af vores hypoteser. Vi har gennem interviewet fundet ud af, at det at lægge envagtplan reelt er et tidskrævende arbejde, især for en større virksomhed og det underbyggerat vores påstand i hypotese 1 er en sandsynlig antagelse, idet den undersøgte virksomhed ieksemplet har en medarbejderstab på 30 personer. Hypotese 3 bliver underbygget i kraftaf, at vagtplanlæggeren i interviewet i særlig grad skal tage hensyn til de enkeltes ønsker omfridage og de enkeltes ferieønsker, når en ny vagtplan lægges. Ved at medarbejderne indbe-retter deres ferie i forvejen, er det muligt at tage hensyn til disse ønsker i en vis grad, såledesat vagtplanen bliver så god som mulig, for så mange som muligt og stadig hænger sammenmed den kvalitet af service der skal ydes.

I kraft af at vagtplanlæggeren i interviewet bruger mange timer på at validere at detsamlede timetal per medarbejder passer og at der, dog sjældent, kan forekomme fejl. Detteunderbygger at hypotese 5 har en vis ind�ydelse i praksis, på hvordan en vagtplan lægges.Ved at der skal tages hensyn til det maksimale antal timer en medarbejder må have i henholdtil arbejdspladsens overenskomst og andre gældende regler, som for eksempel �elleve timersreglen�2, må kompleksiteten ved at lægge en god vagtplan også blive større. Hypotese 4 bliverdelvist begrundet, idet virksomheden i interviewet egentligt har vikarer på standby, der kanvaretage opgaver i tilfælde af langvarig sygdom eller anden fravær. Der er dog ikke behov fora�øsere i tilfælde af akut sygdom, eftersom det er muligt for andre medarbejdere at dækkedisse vagter inden for et vist tidsrum. Om den hypotese er sandsynlig er diskutabelt, eftersomder skal mange forhold til, før det er nødvendigt at indkalde vikarer for at varetage opgaver.

Hypotese 6 og 7 er synliggjort også gennem udsagn i interviewet, idet den vagtplanlæg-ningsansvarlige til en vis grad har følt, at medarbejderne har haft et andet forhold til demi kraft af vagtplanlæggerens rolle, (udover at være medarbejder i virksomheden). Derudoverbetragtes opgaven, hvis den ikke var så kompleks og udfordrende, som en ikke ønskelig opgavehvis ikke disse forhold gjaldt. Det skal siges at disse problemer er løselige i virksomheden og

2Der skal være elleve timer mellem en vagts sluttidspunkt og den næste vagts starttidspunkt for en givenmedarbejder [2]

13


ikke nødvendigvis skaber de problemer, der opridses i hypotese 6 og 7 eftersom de sidenhener løst i vores interview eksempel.

Da det beskrives i interviewet, at der altid skal være en fastansat til stede i virksomhedenpå samme tid som en pædagogstuderende, kan man sandsynliggøre hypotese 2. Selvom depædagogstuderende kan have de samme faglige færdigheder som de fastansatte, kan de ikkeyde den samme kvalitet af service og er ikke så velbefarne inden for arbejdsområdet. Derfor erdet nødvendigt at have medarbejdere tilstede på arbejdspladsen, der kan vejlede de studeren-de. Denne egenskab, vejledning, må betragtes som en medarbejder egenskab, som vagtplanenlægges efter. Det vil sige at i vores interview gælder det, at vagterne på vagtplanen kræveregenskaben �uddannet medarbejder� som kun nogle af medarbejderne besidder.

2.4.5 Metodekritik

Designet af interviewet burde være anderledes. Interviewets målgruppe var meget lille, dadet kun rettede sig imod virksomheder, hvor de anvendte en dynamisk vagtplan. Interviewetburde være designet, så det kunne bruges hos de adspurgte virksomheder, hvor de anvendteandre former for vagtplanlægning. På den måde kunne vi have fået mere indsigt i hvordanandre løser planlægnings problemet. Inden udvælgelsen af de eksterne kontakter, burde vi istørre grad have overvejet hvilke virksomheder, der har brug for en dynamisk vagtplan. Vikunne have tænkt os frem til, at i virksomheder med et omskifteligt service niveau, er der ihøjere grad behov for en vagtplan, der tilpasses det aktuelle service niveau. Det kunne værei restaurationsbranchen, der er en meget sæson-præget branche. På en tankstation kan manlettere klare sig med en statisk vagtplan, da der er et mere fast service niveau. Eftersom vikun �k ét �brugbart� interview ud af undersøgelsen med hensyn til dynamisk vagtplan, burdevi have startet en ny runde med et revideret interviewdesign, der kunne bruges uanset hvilkenvagtplanstype virksomhederne arbejder med. På den måde kunne vi muligvis have nået fremtil en række hypoteser, der var bedre dokumenteret og bedre vist at de var gældende.

2.5 Software undersøgelse

Vi vil udarbejde en test af forskellige programmer for at teste vores hypotese nr. 9 omhandlen-de manglen på brugbare hjælpemidler til at lægge en vagtplan. Ved den samme undersøgelse,vil vi have mulighed for at identi�cere eventuelle problemstillinger ved software løsninger, viselv skal tage stilling til i vores programudvikling.

2.5.1 Metode

For at lave vores analyse, skal der først �ndes nogle programmer, som vi kan teste. Dettegør vi ved at benytte søgetjenesten Google3. Derefter �ndes programmerne enten direkte påprogramudbydernes hjemmeside eller ved hjælp af sider med linksamlinger4 til virksomhe-der, der udbyder software til vagtplanlægning. De fundne programmer blev undersøgt efternedenstående kriterier, som vi har opstillet for at lave en grovsortering af programmerne.Kriterierne er opstillet efter, hvad vi mener vil gøre programmet oplagt at teste.

Fremgangsmåde

Gruppen startede med at opstille nogle kriterier, vi ville udvælge programmer efter:

3http://www.google.dk, der søges på strengene �workscheduling software� og �vagtplanlægning software�.4Som f.eks. denne [9]

14

2.5. SOFTWARE UNDERSØGELSE

• Har programmerne automatiske funktioner?Hermed forstås om programmet har funktioner, der kan automatisere udlægningen ogvedligeholdelsen af vagtplanen.

• Kan vi teste programmet?Har vi mulighed for at downloade en test version af programmet? Kan vi få et test login,hvis det et online system?

• Virker �rmaets beskrivelse af programmet relevant til test.Henvender deres program sig kun til en speci�k faggruppe, eller holder det sig inden forvores målgruppe?

• Kan programmet eksportere til HTML?Har programmet mulighed for at eksportere til en hjemmeside.

Ud af de systemer, der overholdt nogle af ovenstående sorterings punkter, har vi udvalgttre til videre test. Herefter har vi ud fra vores hypoteser og vores egen opfattelse af softwareanvendelighed, opstillet nogle af de kriterier programmerne undersøges for:

• Hvordan er programmerne at bruge?

� Er programmet udstyret med et overskueligt interface?Her bedømmer vi ud fra om programmet er i stand til at vise en hel vagtplan, såman kan danne overblik over sit arbejde. Der bliver også set på om de forskelligefunktioner er placeret logisk, så de vises når man skal bruge dem.

� Hvor lang tid tager det at lære programmet at kende?Er det udstyret med let anvendelig/forståelig bruger�ade? Er programmet lineærtopbygget i konstruktionen af en vagtplan (Det vil sige, skal man angive regler derskal overholdes, medarbejdere i systemet etc. inden man skal lægge en vagtplan?Findes der guides til at lære en ny bruger at bruge programmet?

� Er der inkluderet hjælpefunktion?Er der tilstrækkelig hjælp at �nde til de forskellige funktioner i programmerne.

� Er hjælpefunktionerne brugbare?Her bedømmes, ligesom ovenfor, om man får den speci�kke hjælp man har brugfor til at løse sit problem.

• Hvilke funktioner har programmet?

� Hvordan er programmets mulighed for at lave vagtplaner længere frem i tiden?Her går vi ind og ser om vi kan ligge vagtplan for mere end 1 uge af gangen.

� Er der mulighed for at automatisere vagtplanlægningen?Hvilke automatiske funktioner har programmet?

� Er der mulighed for at bytte vagter?Har programmet hjælpe værktøjer til at bytte vagter mellem medarbejdere?

� Er der funktioner til at ansøge om ferie og/eller arrangere sygemelding?Kan funktioner i programmet sørge for udskiftningen af medarbejdere ved ferieeller evt. sygdom.

� Informerer programmet vagtplanlæggeren om kon�ikter?Kan programmet advare vagtplanlæggeren, hvis de opstillede regler brydes? Det vilsige regler om maksimal/minimal timer per uge eller andre administrative reglerman kunne komme ud for.

15


� Muligheder for at dokumentere medarbejdere i systemet?Hvilke muligheder har programmet for at opstille kriterier og attributter for med-arbejdere og evt. om de er villige til at tage ekstra vagter.

� Er programmet i stand til at lave en overskuelig vagtplan?Ved overskuelig menes der om programmet kan opstille vagtplanen, så man kan sehvem der skal arbejde de forskellige dage, mens man sidder og ligger vagtplanenog om det er muligt at overskue den publicerede version af vagtplanen.

� Har programmet mulighed for at eksportere til HTML?Det vil sige, kan man eksportere vagtplanen til HTML format således man kanlægge den op på en server, så den er tilgængelig for medarbejderne via Internettet.

• Vores vurdering ud fra foregående punkter.Her vil vi til sidst opsummerer vores analyse af programmerne ud fra de tidligere gen-nemgåede kriterier.

2.5.2 Udvalgte programmer

Vi har ud fra vores søgen og afprøvning af software fundet frem til følgende programmer somvi vil undersøge: IntelliRoster Lite [12], Time Tracker [27] og Work Schedule Dot Net [22].

2.5.3 Resultater

IntelliRoster Lite

IntelliRoster Lite er et engelsksproget Windows program til vagtplanlægning fra �rmaetIntellicate [12] og det tilbyder en række værktøjer til hjælp ved vagtplanlægning. Vi harhentet en trial version af IntelliRoster Lite, som vi vil afprøve og undersøge ud fra de imetodeafsnittet de�nerede punkter.

Hvordan er programmet at bruge?

IntelliRoster Lite er baseret på et grundlæggende Windows gra�k interface af typen derogså �ndes i for eksempel Microsoft O�ce, hvilket gør det nemt at omstille sig fra at brugeMicrosoft O�ce programmer til at anvende IntelliRoster Lite (se �gur 2.1 på modståendeside). IntelliRoster Lite er født med en hjælpesektion, hvor der kan søges efter forskelligenøgleord. Den er forholdsvis simpel at bruge, hvis man har erfaring med at anvende andreWindows hjælpefunktioner, men det kan dog tage tid at �nde det man skal bruge hjælp til.Ud over hjælpefunktionen er det muligt for førstegangsbrugere at få vist en række medie�ler,der gennemgår programmets grundlæggende funktionaliteter skridt for skridt. Programmetvirker overskueligt opbygget og det kan opstille en lagt vagtplan pænt og overskueligt.

Hvilke funktioner har programmet?

IntelliRoster Lite er beregnet som et hjælpemiddel til at udarbejde en vagtplan, men in-kluderer ikke et automatiseret metode til at generere en vagtplan. Vagtplanen opstilles påugebasis, hvor det er muligt at lave en vagtplan 10 måneder frem. IntelliRoster Lite inkludereren række værktøjer; et medarbejderkartotek (se �gur B.3 på side 64) til at holde overblik overmedarbejdere/medarbejder kompetencer, en opgave manager til de�nition af arbejdsopgaver(se �gur B.2 på side 64) og en bruger�ade til opsætning af arbejdstimer og tidspunkter forden enkelte arbejder (se �gur B.1 på side 63). Derudover kan man få vist hvor mange timerhver enkelt arbejder er blevet sat til at arbejde inden for en given periode. Således kan man

16


Figur 2.1: IntelliRoster Lite bruger�aden.

sikre man ikke har medarbejdere med for mange timer på skemaet (se �gur B.4 på side 65).Programmet har en del begrænsninger. Det ikke er muligt at bytte vagter mellem medarbej-dere på en vagtplan på en simpel måde, da alle vagterne manuelt skal byttes rundt. Det erikke er noget interaktivt system, så medarbejdere kan heller ikke ansøge om vagtskifte ellerfridage over Internettet, men må gøre det over telefon eller anden kontaktform til vagtplan-læggeren. Programmet informerer ikke brugeren om eventuelle kon�ikter, der kunne opstå ivagtplanen i henhold til regler, der skal overholdes. Det er ikke muligt at de�nere regler, somskal overholdes og det er ikke muligt at de�nere avancerede medarbejder attributter. Detvil sige, man får ikke nogen fejlmeddelelse, hvis man sætter en medarbejder til at udføre etstykke arbejde, han ikke har kompetencer til at udføre.IntelliRoster Lite indeholder funktioner til at printe vagtplanen på papir med forskelligeopsætninger, samt mulighed for at publicere vagtplanerne på en HTML side genereret af pro-grammet (se �gur B.5 på side 65). På den genererede webside er det muligt at se vagtplaneri henhold til enten den overordnede vagtplan eller efter den enkelte medarbejders vagtplan.Skulle man ønske at udgive sin vagtplan på nettet, skal man selv sørge for at �nde en serverman kan lægge sin hjemmeside på.

Vores vurdering ud fra foregående punkter?

IntelliRoster Lite fungerer godt som et hjælpeværktøj til at lægge en vagtplan. Det bliver sta-dig en stor arbejdsbyrde til vagtplanlæggeren, når der skal lægges vagtplan, da programmetikke har automatiske funktioner. Programmets fordel er, at den kan eksportere dokumen-ternes indhold til HTML dokumenter, hvilket gør det muligt at publicere vagtplanerne påinternettet. Det kan spare en vagtplanplanlægger for en del papir- og administrativt arbejdeog gør det muligt at opdatere vagtplanerne hurtigt efter udformning, således at de der skalbruge dem, kan se dem umiddelbart efter de er publicerede.

Time Tracker

Time Tracker er et engelsksproget program lavet af Asgard Systems [27]. Vi har hentet entrial version af Time Tracker, som vi vil undersøge ud fra de forudde�nerede punkter.

17


Hvordan er programmerne at bruge?

Time Tracker tager tid at lære at bruge, men der er tutorial videoer på Agard Systems hjem-meside, som kan hjælpe en bruger til hurtigt at komme igang med programmet. Programmethar en hjælpefunktion, man kan benytte til at søge efter emner, man vil vide mere om. Pro-grammet er udstyret med et stort antal features, hvilke ikke alle er placeret hensigtsmæssigtpå bruger�aden. Programmet er opbygget, så man kan have vagtplanen for en uge eller mereopstillet på skærmen (se �gur B.6 på side 66 og �gur 2.2).

Figur 2.2: Time Trackers opbygning af vagtplanen


Time Tracker kan ikke automatisere vagtplanlægningsprocessen, men kan opstille en skabelonmed antal dage og vagter man har brug for på en uge, hvorefter programmet kan repeterevagter for de pågældende dage i fremtidige ugeskemaer. Det medføre at man kan bruge TimeTracker til at lægge en fast vagtplan for �ere uger frem i tiden. Derudover kan man lave enugentlig rotations plan. Det vil sige, hvis en medarbejder er på arbejdet om formiddagen,i den første uge, er han i den næste på arbejde om eftermiddagen og så fremdeles. Brugesdenne opsætning vil programmet gentage det i vagtplaner for fremtidige uger.

Time Tracker har en del muligheder for at tilpasse en lagt vagtplan. Hvis en medarbejderbytter sine vagter med en anden medarbejder i en periode, kan dette gøres ved at bruge en�Swap Employes� (se �gur B.8 på side 67) funktion. Hvis en medarbejder bliver syg, kanman bruge en �Replace� funktion for at ombytte vagten med en anden medarbejder. Dissefunktioner er en hjælp til at vedligeholde sin vagtplan, i tilfælde man har megen ombytningeller sygdom på arbejdspladsen.

18


Når man opretter medarbejdere (se �gur B.7 på side 67) i systemet, har man mulighed forat de�nere en del variabler, der gør programmet i stand til at informere vagtplanlæggeren omeventuelle kon�ikter med medarbejderes ønsker eller timeantal. Det vil sige, hvis en medar-bejder er sat til at skulle have 37,5 timer i ugen, vil programmet informere vagtplanlæggerenom fejlen, hvis han overskrider dette under planlægningsprocessen. Programmet har ikkemulighed for at eksportere til HTML format, det er kun muligt at publicere vagtplanerne påpapir.

Figur 2.3: Time Trackers visning af ugeplan for en enkelt medarbejder


Time Tracker virker til at være et godt hjælpemiddel til vagtplanlægningen. Programmet erikke i stand til at automatisere vagtplanlægnings processen, men har forskellige features, dergør vedligeholdelse af en forud de�neret vagtplan lettere. For eksempel er programmet anven-deligt, hvis man har en virksomhed der benytter ugentlig rotation i vagtplanen. Timetrackersmangel på evne til at eksportere til HTML er ikke optimal, eftersom al kommunikation medmedarbejderne stadig vil foregå via. papirform, telefoni og almindelig samtale i stedet for atkommunikere over internettet. Dette betyder at vagtplanlæggeren stadig har en stor opgavebare i at få vagtplanerne distribuerede til de relevante personer.

Work Schedule Dot Net

Work Schedule Dot Net [22] er et engelsk sproget Internetbaseret program beregnet til u-darbejdelse af en vagtplan. Programmet virker ved, at en vagtplanlægger logger ind via enhjemmeside og derigennem får adgang til programmet på en server hos Program Works inc.der har udviklet systemet. For at få adgang til programmet kræves det man logger på sombestyrer eller medarbejder med �rma ID, bruger ID og password.

19


Hvordan er programmerne at bruge?

Work Schedule Dot Net er et program, der er gjort tilgængelig gennem brugerens Internetbrowser og kræver ingen installation på brugerens computer. Bruger�aden ligner en alminde-lig hjemmeside. Der bruges standard webformatering til at vise vagtplanen i form af knappersom brugeren kan trykke på, for at se den næste eller foregående uge (se �gur 2.4). Det vilsige, programmet har mulighed for at vise vagtplanen for de efterfølgende uger, men den kankun vise en enkelt uge ad gangen. Programmet er forholdsvist simpelt at gå i gang med,idet det inkluderer en indbygget hjælpefunktion, der giver brugeren mulighed for at se de-monstrations videoer af de forskellige features, som programmet indeholder og instruktion ihvordan man bruger dem. Derudover er der indbygget en �wizard�, der kan guide brugerenigennem en vagtplanlægnings opgave, således der tages fordel af de indbyggede mulighederi programmet. På grund af de indbyggede hjælpefunktioner, er det reelt muligt at lægge envagtplan efter kun at have brugt programmet i et par timer.

Figur 2.4: Work Schedule Dot Net bruger�aden


Programmet har forskellige funktioner, der kan hjælpe en vagtplanlægger til at bevare over-blikket over planen. Den inkluderer også en funktion til at automatisere en vagtplan i henholdtil en række forde�nerede love, som vagtplanlæggeren kan bestemme variabler til.

Automatiserings systemet virker ved at vagtplanlæggeren vælger blandt en række kriteri-er, der �ndes i programmet og de�nerer en mængde forhold inden for disse, som programmetskal tage højde for, når der skal plottes medarbejdere på en vagtplan (se �gur B.12 på si-de 70). For at oprette en automatisk udførsel af en vagtplan, kræver det at vagtplanlæggeren

20


først angiver hvilke love der skal overholdes, opretter grupper til medarbejdere og opretterhvilke opgaver der skal varetages (se �gur B.11 på side 69). Derefter skal man bruge pro-grammets medarbejderkartotek til at oprette medarbejdere i systemet, som programmet skallægge vagtplan for.

I medarbejderkartoteket er det muligt at angive personlig information om den enkeltemedarbejder. Det er f.eks. muligt at angive, hvor mange timer de højst må arbejde på en ugeog hvor mange timer de højst må arbejde på en dag (se �gur B.9 på side 68 og �gur B.10på side 69 for en mere fyldestgørende liste). Når disse trin er afsluttet, kan man køre en"wizard"for planlægning . En �wizard� er et hjælpeværktøj der hjælper en med at lægge sinvagtplan (se �gur B.13 på side 71). Efter at have udført "wizard"funktionen, forelægges envagtplan der er mere eller mindre brugbar alt efter hvor godt vagtplanlæggeren har de�neretsine regler og andre muligheder som systemet tilbyder. Efter den automatiske udførsel erdet muligt for en vagtplanlægger at redigere i vagtplanen manuelt efter behag. Skulle deropstå kon�ikter mellem de de�nerede regler og de�nerede medarbejder egenskaber under denmanuelle planlægning, er der mulighed for at programmet advare om dem (se �gur B.14 påside 71 for en udfyldt vagtplan).

Programmet har mulighed for at publicere vagtplaner på �ere måder. Der er mulighed forat eksportere til Excel regneark, PDF formater og til HTML. For at medarbejderen kan sevagtplanen online, er det nødvendigt for denne at logge sig på �rmaets oprettede system hosProgram Works inc. Som primær funktion kan man se sin egen vagtplan, andres vagtplan hvisvagtplanlæggeren har tilladt det, mulighed for at angive dage hvor man er ledig til at arbejde,skrive sig på vagter der er åbne, bytte vagter med andre brugere, angive hvilke dage man hararbejdet med henblik på løn beregning, forespørge om fritid og se generel information omhvem der har lagt planen og hvordan man kontakter ham/hende (se �gur B.15 på side 72).Hvilke af disse muligheder der er aktive er helt op til planlæggeren, der kan de�nere hvilkemuligheder medarbejderne har, når de logger på deres personlige side.


Work Schedule Dot Net er en avanceret løsning, da den har mange funktionaliteter, hvilkethjælper når der skal lægges en kompliceret vagtplan. Det tager en del tid at tilpasse systemetens virksomhed, da der er mange kriterier, der skal indtastes, før man kan gå i gang med atlægge en vagtplan. Programmets største ulempe er at de eksporterede vagtplaner er megetgra�sk rodet, hvilket resultere i tabt overblik.

2.5.4 Software konklusion

Efter at have afsluttet software undersøgelsen, kan vi se det generelt tager relativt langtid at lære at bruge vagtplanlægningsprogrammer e�ektivt. De �este af programmerne har�tutorial� eller hjælpevideoer, hvilket gør læringsprocessen hurtigere, end hvis man selv skulle�nde ud af at anvende dem, men det tager stadig en tid at sætte sig ind i programmerne.

Efter at have testet programmerne, kan vi konkludere at de tre programmer opfylderhvert deres formål. Intelliroster Lite har ingen automatiske funktioner til udførsel af opgaverved vagtplanlægning. Det bruges som et værktøj til at danne overblik over de vagtplaner dermanuelt lægges. Time Tracker har de �este af de funktioner, der også �ndes i IntelliRosterLite og et par automatiske funktioner, som gør det lettere for brugeren at organisere og læggevagtplaner. Work Schedule Dot Net har features som både IntelliRoster Lite og Time Tracker.Det kan samtidigt bruges uafhængigt af en installeret klient på computeren. Fordelene vedWork Shedule Dot Net er, det kan bruges af mange forskellige typer �rmaer, da det kanlægge e�ektive planer for både store og små virksomheder. Work Schedule Dot Net kræver

21


lidt mere arbejde at sætte sig ind i at bruge. Både fra vagtplanlæggerens og medarbejdernesside, eftersom der er en del funktioner at stifte bekendtskab med.

Ved sammenligning af publiceringsmulighederne i de tre programmer er Work ScheduleDot Net det mest avancerede, da det kan eksportere vagtplaner konstrueret med programmettil HTML �ler, der automatisk lægges op på en uafhængig server tilsluttet internettet. Såledeskan medarbejdere se deres vagtplan hvor som helst de har adgang til en computer medinternetadgang. IntelliRoster Lite har en lignende funktion, men kræver at vagtplanlæggerenselv ligger det op på en webserver. Time Tracker ikke har denne mulighed.

Work Schedule Dot Net kræver mere af virksomheden og medarbejderne, end de andretestede programmer, da opsætning og a�æsning af vagtplanerne foregår via internettet. Detteopvejes af muligheden for at lægge en vagtplan automatisk.

I relation til vores projekt vil det i henhold til det ovenstående være oplagt at især brugeWork Schedule Dot Net som en model, når vi skal overveje hvilke funktionaliteter vi vilinkludere i vores produkt.

Under udarbejdelsen af software testen, har vi fundet frem til at vi ikke kan bekræftehypotese nr 9, da der �ndes brugbart software. Vores analyse har dog givet et indtryk af atsværhedsgraden i af brugen af et produkt stiger med antallet af funktioner, som det fremgåraf �gur 2.5.

Funktioner IR TT WSDNEksport til HTML + - +Vise en hel uge på skærmen + + +Tutorial Videoer + + -Rotations planlægning - + +Automatiseret vagtbytte - + +Oplistning ledige medarbejdere - + +Eksport af timelister + + +Kon�ikt advarsler + + +Tage højde for regler - + +Sværhedsgrad i læringsprocessen Nem Svær Sværest

Figur 2.5: Software sammenligningsoversigt. (IR: IntelliRoster, TT: Time Tracker, WSDN:Work Schedule Dot Net)

2.5.5 Metodekritik

Vi har undersøgt om vi kunne bruge følgende programmer til vores softwaretest:

• Employee scheduling online - Work Schedule DOT NET [22] Programmet er udvalgt tiltest ud fra dets automatiske funktioner.

• Employee Scheduling Software [11] Programmet kan ikke testes, derfor er det ikke valgttil test

• Intellicate - Employee Scheduling and Rostering Software Solutions [12] Programmet erudvalgt til test på grund af det simple interface og mulighed for at generere en hjem-meside ud fra programmets outputdata.

• Online employee scheduling software [23] Programmet kunne kun afprøves hvis manbestilte en demo fremvisning af programmet med en medarbejder fra virksomheden, somskulle bookes. Vi valgte ikke programmet til test på grund af dette.

22

2.6. TEKNISK PROBLEMATIK

• Planahead.dk - Vagtplanlægning på nettet [20] Vi kunne ikke få programmet til at virke,så vi har ikke testet det.

• Retain International - Resource Management & Sta� Planning Software [13] Program-met blev ikke udvalgt til videre test, da bruger�aden var meget svær at bruge

• ScheduleSoft Personnel Scheduling Software [24] Det var ikke muligt at downloade entest af programmet

• ASP.NET Sta� Scheduling Software for Shift Work [26] Vi valgte ikke at teste detteprogram, da det ikke var muligt at se hvordan det så ud inden vi afprøvede det og detkrævede et større installationsarbejde for at virke.

• Vagtplan [30] Det var kun muligt at bestille en konsulent til fremvisning af programmet,så derfor valgte vi ikke at teste det yderligere.

Til at �nde nogle af programmerne, har vi benyttet denne side under vores søgning:

• Personnel Scheduling [9] Denne side indeholder en liste med links til virksomheder, derudbyder løsninger til vagtplanlægning

Efter at have udført vores test kan vi konkludere, at software gennemgangen ikke er re-præsentativ for �ertallet af softwareløsninger, eftersom vi ikke har testet nok programmer.Derudover fandt vi så mange produkter, at vi har været nødt til at grovsortere i henhold tilvores kriterier til programmer, da undersøgelsen ellers ville være meget omfattende. Det kandiskuteres, om det er den rette fremgangsmåde at søge på internettet efter �rmaer, der laversådanne løsninger, eller om vi skulle have overvejet alternative metoder. Man kunne forestillesig, at det var muligt at tage direkte kontakt til virksomheder der arbejder med emnet såsomKMD. Det er dog tvivlsomt om det ville give noget positivt resultat, eftersom vi ikke kenderandre virksomheder. Programmerne er blevet testet på brugerniveau efter hvad vi �nder erbrugervenligt. Det vil sige at vi har set på hvordan programmerne er at bruge og hvad dekan for folk med en vis erfaring med at bruge og vænne sig til nye programmer. Vi har ikkehaft mulighed for at se hvordan programmerne er konstrueret (koden af programmerne), dade er kommercielle programmer beskyttet af ophavsret. Havde det været muligt at se koden,kunne en undersøgelse af koden, muligvis have gavnet vores egen udvikling af et vagtplan-lægningssystem, idet vi kunne hente inspiration fra de andre programmer til udarbejdelse afvores eget. Programmerne, der er testet, har været engelsksprogede, hvilket skyldes mangelpå testbart dansk software, der opfyldte vores kriterier.

2.6 Teknisk problematik

Hvis et stykke software skal kunne lægge en automatisk vagtplan, er det nødvendigt at denogså skal kunne vurdere vagtplanens kvalitet. Hvis ikke et vagtplansprogram kan vurderekvaliteten af en vagtplan, kan man ende med et produkt, der kan lægge en vagtplan; men deter ikke sikkert, at resultatet er brugbart. For at belyse denne problematik, er det nødvendigtat se på den matematiske teoretiske baggrund, for omfanget af problemet, hvis løsningen ogsåskal kunne �nde en god vagtplan.

2.6.1 Mulige vagtplanlægning

Ved automatisk vagtplanlæggning, hvor målet er at �nde den bedste vagtplan, er der etproblem. Dette skyldes at processen skal arbejde med at vælge den bedst mulige vagtplan udfra mange kombinationer af mulige vagter.

23


I følgende afsnit arbejdes med hvorfor, der opstår mange kombinationer, når antallet afmedarbejdere og vagter stiger. I afsnittet er der set bort fra den kompleksitet, der vil være,hvis der skal i beregnes andre faktorer for opstillingen og gyldigheden af en vagtplan, såsomregler der skal overholdes fra planlæggerens side. Der vil være endnu �ere beregninger, hvisman efter at have fundet alle vagtplaner, skal validere om det er gyldige kombinationer, ihenhold til reglerne. F.eks. hvis der skal undersøges om medarbejderen har været på arbejdeinden for 11 timer før en vagt eller andre regler.

A, BM:

AV: A A

AV: A B

AV: B A

AV: B B

BV: A A

BV: A B

BV: B A

BV: B B

Figur 2.6: Her er et lille eksempel på de kombinationer der vil være med 2 medarbejdere og3 vagter. Hvor M er medarbejdere (A og B) og V er vagter.

Antager vi, at der skal være 1 medarbejder på hver vagt, samt at der er M antal medar-bejdere til V antal vagter, kan der udledes at der vil være:MV antal mulige vagtplaner.

Det vil sige, at man kunne �nde alle mulige vagtplaner (mængden af MV ) og derefterundersøge hvilken vagtplan, der er den bedste (et eksempel ses på �gur 2.6).

2.6.2 Konklusion

For at lave den bedst mulige vagtplan automatisk kræver det, at man �nder alle muligevagtplaner, før man kan �nde den bedste vagtplan. I dette afsnit er det vist, at der vil væremange vagtkombinationer, så snart antallet af vagter og mængden af medarbejdere stiger ogman samtidigt skal �nde alle mulige kombinationer af vagtplaner. Derfor vil det ikke værehensigtsmæssigt at �nde den �bedste� vagtplan, men derimod opstille et realistisk mål for en�god� vagtplan istedet. På den måde vil man kunne udvikle et værktøj til udarbejdelse af envagtplan som �nder en løsning inden for en overskuelig periode.

2.7 Problemformulering

I henhold til konklusionerne på de tre analyseafsnit 2.4 på side 9, 2.5 på side 14 og 2.6 påforrige side har vi fundet ud af hvilke problemstillinger, som er relevante at arbejde med irelation til at lægge en �god vagtplan� automatisk.

Ud fra betragtningerne af hvad der gøres i praksis i afsnit 2.4.3, har vi fundet nedenståendeproblemstillinger, som gør sig gældende under processen, at lægge en god vagtplan. En procesder er kompliceret og tidskrævende. Derudover gør følgende delproblemer sig gældende:

Problem 1. Det kan være nødvendigt at give medarbejdere overarbejde på grund af andremedarbejderes fravær forårsaget af f.eks. sygdom eller barsel.

Problem 2. Medarbejderne får ikke ind�ydelse på deres arbejdsuge i en sådan grad, at dekan bestemme over hvilke vagter de får og dermed kan tillade sig at lave personlige aftaler

24

2.8. AFGRÆNSNING

i et tidsrum, hvor de potentielt kunne komme på en vagt. Denne begrænsning sker fordivagtplanlæggeren ikke kan forventes, at lægge en ny vagtplan relativt ofte. Uoverskuelighedenog varigheden af planlægningen medfører altså, at der fortrinsvis laves statiske vagtplaner,hvilket medfører at medarbejderne skal bytte vagter internt, hvis de vil have fri.

Problem 3. Idet man ikke vil kunne forudsige alt fravær, såsom fravær grundet sygdom, erdet nødvendigt at kunne bytte vagter mellem medarbejdere manuelt.

Problem 4. Medarbejdere kan have et negativt forhold til en vagtplanlægger i kraft af, atdenne er ansvarlig for at lægge virksomhedens vagtplan.

Derudover har vi, ud fra betragtninger gjort under vores test og undersøgelse af eksiste-rende softwareløsninger i afsnit 2.5 fundet følgende problemstillinger, der bør tages højde for,hvis man skal lave et automatisk værktøj til at lægge en vagtplan:

Problem 5. Det er nødvendigt for en vagtplanlægger, at kunne de�nere hvilke regler et auto-matisk vagtplanlægnings værktøj skal kunne overholde under udarbejdelsen af en vagtplan.Det gælder for eksempel hvilke muligheder et vagtplanlægningsprogram har for at tildelemedarbejdere i vagtplanen overarbejde og i hvor kraftig grad at �elleve timers reglen� skaloverholdes.

Problem 6. Det er nødvendigt at speci�cere hvilke krav vagterne i vagtplanen stiller tilmedarbejderne. Ligeledes er det nødvendigt at kunne udvælge den medarbejder, som er bedstkvali�ceret til en given vagt.

Problem 7. Hvis en virksomhed benytter sig af en dynamisk vagtplan, bør vagtplanlæggerenhave lettilgængelige muligheder for at publicere disse, gerne således at medarbejdere selv kanholde sig opdateret med eventuelle ændringer i planen.

Problem 8. Man bør tage højde for brugervenlighed, eftersom programmerne bliver sværereat bruge, når de har mange funktioner.

Problem 9. Det er nødvendigt, i forbindelse med ibrugtagningen af et planlægningsværktøj,at sætte sig grundigt ind i hvordan dette fungerer. For at gøre denne proces lettere og hurtigereer det nødvendigt at værktøjet er overskueligt og let anvendeligt.

Ud fra en række teoretiske overvejelser omkring problemet med at lægge en god vagtplan,har vi kunnet udlede det efterfølgende problem, som der også bør tages stilling til i detendelige produkt:

Problem 10. For at lave den bedst mulige vagtplan automatisk kræver det, at man skal�nde alle mulige vagtplaner. Antallet af mulige vagtplaner er meget stort.

2.8 Afgrænsning

Som det ses i problemformuleringen, er der mange forskellige problemer at tage fat på, nårman vil udvikle et værktøj til automatisk udarbejdelse af en vagtplan. I vores projekt har vivalgt nogle emner ud fra vores problemformulering, som vi vil arbejde videre med i projektetmed henblik på udarbejdelse af en algoritme til automatiseret vagtplanlægning. Det drejersig om problemet omkring uoverskueligheden af lægning af en god vagtplan og problem 1, 2,5, 6 og 10.

Algoritmen designes således den kan implementeres som en del i en software applikation,der kan løse ovenstående problemer. Vi vil lave en prototype af et system, der kan afprøve

25


de grundlæggende funktionaliteter i vores algoritme, men kun udvikle den del der skal til forat afprøve disse.

Vi vælger derimod at se bort fra resten af problemstillingerne i vores algoritmeløsning,da vi mener disse er strengt afhængige af om algoritmen kan løse hovedproblemet, at læggeen automatisk vagtplan. Derfor er de sekundære problemer afhængige af om det primæreløses. Desuden er nogle problemer afhængige af menneskelige elementer uden tilknytning tilalgoritmen og kan derfor ikke de�nitivt løses.

Det vil sige: Vi kan ikke vide om medarbejdere får et bedre forhold til deres vagtplanlæggerhvis vagtplanen lægges automatisk og tager højde for deres ønsker og derfor vælger vi ikkeat arbejde videre med dette emne. Vi vil heller ikke inkludere en funktion til at bytte vagtermellem to medarbejdere i det endelige produkt, da det centrale problem reelt er at læggeen vagtplan automatisk. Vi vil ikke decideret undersøge hvordan man laver en brugervenligbruger�ade eller udarbejde letanvendelige publiceringsmuligheder, da det centrale problemer at løse hvordan man automatisk lægger en vagtplan med en algoritmefunktion.

2.9 Metodekritik

Som den overordnede metode til at overskueliggøre problemet vagtplanlægning, valgte vi igruppen at opsætte en række hypoteser, som vi fandt frem til ud fra vores eget indblik iproblemet. For at �nde ud af om vores hypoteser havde grundlag i hvordan problemet gribesan i praksis, udførte vi nogle interviews med personer, der sidder med opgaven til dagligt.

Et af problemerne med denne metode var, at den var meget tidskrævende, da det detikke lykkedes os at �nde nogle egnede personer til vores interview i vores første undersøgelse.Problemet var at de virksomheder, vi havde valgt som interviewmål, ikke lagde en dynamiskvagtplan, hvilket vore interviews egentligt krævede for at være relevante at udføre. Et andetproblem med metoden var, at de personer vi interviewede, ikke rigtigt brugte noget softwaretil hjælp med vagtplanlægningen i udbredt grad. Dette gjorde det svært at få nogle brugbareideer til vagtplanlægnings applikationen.

En metode vi kunne have valgt i stedet for, kunne være at starte med at lave en prototypeaf vores program ud fra de hypoteser eller påstande vi havde opsat, som vi mente måttegælde om vagtplanlægning. På den måde ville man kunne præsentere et mere eller mindrefungerende program for de vagtplanlæggeren, vi ville interviewe. Derved kunne vi måskebedre modtage og bruge feedback fra de vagtplanlæggere vi interviewede til at forbedre voresprogram og tilføje de funktioner til programmet, som de eventuelt kunne mene mangledefor at opfylde deres behov. Denne metode kunne måske også have givet nogle brugbareinformationer fra de vagtplanlæggere, der ellers bruger en fast vagtplan. Kontekstuelt kunnevi, i stedet for indledende at se om applikationen kunne anvendes, vurdere hvilken e�ektprogrammet ville have i samfundet. Grundlaget for en sådan metode ville selvfølgelig være,at programmet rent praktisk kunne bruges, for at der kunne konkluderes noget kontekstueltud fra projektet.

Problemet med denne metode er at den ville være rimelig risikabel, da der kunne brugesen masse tid på at lave et program ud fra nogle ideer, vi kun selv har siddet med. Dette kunneresultere i at vi ville arbejde med et problem, uden at have undersøgt om problemet over-hovedet eksisterede. I værste tilfælde kunne det ende med et program, der ikke var praktiskanvendeligt og derfor ikke reelt kunne bruges i praksis. Udbyttet rent fagligt ville være, at viville få programmeret en masse funktioner i vore valgte programmerings sprog, men vi villemuligvis ikke være blevet klogere på selve problemet omkring automatisk vagtplanlægning.

26

KAPITEL

3

Løsning

For at præsentere vores løsning er kapitlet opdelt i tre afsnit. Det indledende afsnit 3.3omhandler baggrunden for den algoritme, vi vil udarbejde. Her beskrives forskellige typeraf algoritmer, der er brugt som inspiration til udvikling af vores egen algoritme og hvilkenfunktion den skal opfylde. Afsnit 3.4 omhandler selve udviklingen af algoritmen, de metoderder er brugt til udarbejdelsen af den endelige algoritme og den endelige algoritme som skalbenyttes til udarbejdelsen af en prototype. I afsnit 3.6 beskrives selve den praktiske løsning.Det vil sige en kodet prototype samt resultaterne udfra en afprøvning af denne.

3.1 Metode

Udarbejdelsen af vores algoritme falder i tre stadier. Først undersøges der allerede udfær-digede teorier, omkring det at automatisk kunne lægge en vagtplan ved hjælp af forskelligealgoritmer. Disse bruges til at vise, at der er andre metoder til at løse den overordnedeproblematik omkring automatisk vagtplanlægning, men bruges også som grundlag for nog-le overvejelser, der bør gøres, når vores egen algoritme skal udvikles. Således kan der klartde�neres, hvad den skal kunne og hvordan man kan opstille algoritmen. Derefter beskrivesselve udviklingsforløbet for algoritmen, hvilke tanker der er gjort, hvordan den er udviklet,hvilke problemer den i teorien kan løse og hvordan den reelt fungerer. Efter dette afsnit vilvi beskrive det overordnede system, som vi mener algoritmen kræver for at kunne bruges tilautomatisk at generere en god vagtplan og programmere den således at vi får en prototype,der kan testes. På baggrund af vores resultater fra testen og vores arbejdsforløb vil vi til sidstudarbejde en konklusion, der opsummerer resultater fra testen og erfaringer gjort omkringdet at lægge en automatisk vagtplan.

3.2 Kravspeci�kation

I henhold til de udvalgte problemstillinger i problemafgrænsningen har vi udarbejdet to krav-speci�kationer. De to nedenstående kravspeci�kationer er henholdsvis for det samlede system,der kan håndtere en vagtplanlægning systemet og algoritmen der udfører selve vagtplanlæg-ningen.

3.2.1 Systemet

• Systemet skal kunne sørge for at vagtplanlægningen bliver udført ud fra data fra med-arbejdere og den vagtplanlæggeren.

• Det skal være muligt at lægge en vagtplan, uden den ansvarlige skal godkende de an-sattes inputs. Derved lettes vagtplanlæggerens arbejde.

• Efter en vagtplan er lagt, skal systemet kunne lave en rapport, der beskriver timetalpr. medarbejder og hvor god vagtplanen er. Samtidig skal den belyse evt. kon�ikter ivagtplanen.

27

Kapitel 3. Løsning

3.2.2 Algoritmen

• Algoritmen, der lægger vagtplanen, skal kunne tage højde for medarbejdernes kvali-�kationer, således kun personer med de rette forudsætninger bliver tildelt en vagt ivagtplanen.

• Algoritmen skal kunne tage timetal per medarbejder i betragtning og sammenholdedem med hvor mange timer en medarbejder maksimum må have på en uge.

• Under planlægningen bør der tages højde for medarbejderønsker for at mindske util-fredsheden med den lagte vagtplan og derved minimere nødvendigheden for vagtbyttemellem medarbejderne.

3.3 Teori

Dette afsnit har til formål at afdække baggrunden for den algoritme, vi vil udarbejde oghvilken baggrund vi har haft at overveje vores algoritmes udformning ud fra. Baggrundsma-terialet, der danner grundlag for vores idéer, drejer sig om 2 rapporter; den ene kilde er enteknisk gennemgang af problemet �Sta� Scheduling: A Simple Approach that Worked� [14]og den anden en Ph.D. afhandling �Local Search Techniques for Scheduling Problems: Algo-rithms and Software Tools� [6]. Endvidere har vi læst om de enkelte algoritme typer i detåbne web-leksikon Wikipedia1.

Vi vil først fortælle om 3 overordnede algoritme typer, der kan bruges til vagtplanlægning,hvorefter vi beskriver de enkelte algoritmer i dybere detalje, med hvilke metoder de typiskbruger til at løse en opgave. Efter vi har beskrevet de allerede eksisterende algoritme teorier,beskriver vi hvilke idéer, vi vil arbejde videre med i vores løsning. Dette er det teoretiskegrundlag og inspirationen vi har arbejdet ud fra i udviklingen af vores egen algoritme.

3.3.1 Algoritme typer til vagtplanlægning

Grundlæggende �ndes der 3 forskellige typer algoritmer til brug ved vagtplanlægning. Dissetre typer har hvert deres mål og bruger input til at generere vidt forskelligt output.

• Gyldig algoritmeDenne algoritme type vil kun lægge en vagtplan, hvis det er muligt ud fra de givneomstændigheder. Den kontrollerer hele tiden, om den overskrider de opsatte grænser.Det vil sige, den returnerer en fejl og stopper hvis den når en �dead-end�. F.eks. hvis denløber tør for ledige medarbejdere, inden alle vagter er besat. Kun hvis den kan læggeen gyldig vagtplan, giver den et gyldigt output. Vagtplanens gyldighed bliver beregnetud fra de parametre, den er bygget til at tage høje for. Dette kunne evt. være, at enmedarbejder ikke må blive sat 2 gange på den samme vagt.

• Måske-gyldig algoritmeDenne algoritme type vil altid give et output, også selvom det ikke er gyldigt. Denlægger en vagtplan, men kontrollerer ikke gyldigheden undervejs. På den måde vil denikke nå en �dead-end� som gyldig-algoritmen, men kun returnere det den er kommetfrem til. Fordelen ved denne algoritme er, at den kan være hurtigere til at generereoutput, eftersom den ikke skal kontrollere gyldigheden af dette undervejs. Dette krævertil gengæld, at man selv kontrollerer gyldigheden af vagtplanen efterfølgende.

1www.wikipedia.org, et åbent leksikon på internettet hvor alle har adgang til at bidrage med information.

28

http://www.wikipedia.org/

3.3. TEORI

• ForbedringsalgoritmeDenne algoritmetype kræver, at man har lagt en vagtplan på forhånd. Den vil derefterforsøge at forbedre den lagte vagtplan ud fra de kriterier og krav der er opsat i algo-ritmen, ved at �ytte rundt på medarbejderne i vagtplanen. Den kan altså ikke, som deandre algoritmetyper, selvstændigt lave en vagtplan, men derimod �nde ud af om denvagtplan, den har fået som input, kan optimeres i henhold til de krav, som den er lavettil at forbedre imod. Input til denne algoritme kan godt være en ugyldig vagtplan.

3.3.2 Algoritmerne

Ved hjælp af de 2 førnævnte kilder har vi fundet de forskellige algoritmer, der passer indunder vores 3 algoritme typer. I vores beskrivelse af algoritmerne taget udgangspunkt i, atde kun skal anvendes til vagtplanlægning. Derfor har vi undersøgt de metoder, de bruger tilat lægge en vagtplan. De �este af algoritmerne kan også bruges i mange andre sammenhænge,som vi ikke vil gennemgå her.

Greedy Constructive

En �Greedy Constructive� algoritme vil som udgangspunkt sætte de billigste medarbejdere påde vagter, der har færrest antal løsninger. Det vil f.eks. være smart at starte med at udfyldevagter, der kræver at der er 2 personer på arbejde, som samtidigt har nogle �høje� krav tilkvali�kationer med de mest hensigtsmæssige medarbejdere, der lever op til disse krav. Med�høje� krav forstås, at en vagt for eksempel kan kræve at de 2 eneste i virksomheden, der kanbetjene en speciel maskine, begge er tilstede for at vagtens opgaver kan løses og derfor skalde begge sættes på vagten. At en medarbejder er mest hensigtsmæssig til en vagt, kan værede�neret på forskellige måder. F.eks. hvis en medarbejder kun kan én ting, som alle andreansatte også kan, men er billigere end de andre, vil han være den mest hensigtsmæssigemedarbejder til en vagt. Da algoritmen validerer vagtplanen efterhånden som den kommerfrem, er denne algoritme det nærmeste man kommer en �gyldig algoritme� type, som beskreveti forrige afsnit.

Iterative Sampling

Algoritmen vælger en tilfældig vagt i en vagtplan og tildeler en tilfældig medarbejder til den,såfremt personen opfylder vagtens krav. Kravene kunne for eksempel være, at en medarbejderikke har arbejdet de sidste 11 timer, ikke er sat på vagten i forvejen eller at personen kanløse de opgaver vagten kræver. Dette bliver algoritmen ved med, indtil den er løbet tør forvagter at udfylde. Derved løser algoritmen det grundliggende problem, der kan ligge i atoverholde arbejdspladsens regler og sørge for at vagten bliver taget af en medarbejder medde rette kompetencer. Denne metode kan løbe ind i nogle �dead-ends�, da den potentieltbruger medarbejdere med specielle attributter for tidligt. Derfor kan det være nødvendigt,at den bruges �ere gange med samme input for at generere en gyldig vagtplan. Derfor liggeralgoritmen et sted på grænsen mellem �gyldig algoritme� og måske �gyldig algoritme� typerne.

Random-Greedy Constructive

�Random-Greedy Constructive� algoritmen er en variant af �Greedy Constructive� algoritmennævnt tidligere. Den afviger ved, at den tilfældigt vælger en vagt, hvorpå den sætter den mesthensigtsmæssige medarbejder. Denne type algoritme er primært en �måske-gyldig algoritme�,da den lettere kan komme ud i en situation, hvor vagtplanen ikke kan gå op. Den tager ikkehøjde for at medarbejdere med unikke evner, muligvis er blevet sat på vagter med opgaver,

29

Kapitel 3. Løsning

der kan løses af medarbejdere med færre kompetencer og at specialisterne derfor mangler tilspecielle vagter senere i planlægningen. Man kan dog argumentere for, at den i så fald blotvil tildele de medarbejdere overarbejde og derfor stadig lægge en gyldig vagtplan. Dette kandog skabe kon�ikt med andre krav såsom 11 timers reglen.

Random Iterative Improvement

Denne metode tager en tilfældig vagt og �nder en ny tilfældig medarbejder der opfylder kra-vene til vagten. Den gemmer ændringen og arbejder videre ud fra den opdaterede udgave afvagtplanen. Den tager ikke højde for �prisen� på en ændring, kun kravene til vagten. Dennealgoritme kræver en vagtplan, der er lagt på forhånd som input og er derfor en �forbedrings-algoritme�.

Hill-Climbing Iterative Improvement

Denne metode fungere på samme måde som Iterative Improvement, ud over at den kungemmer en ændring i vagtplanen hvis ændringen giver en besparelse. Ellers arbejder denvidere med den uændret udgave af vagtplanen.

Taboo search

Denne metode tager en �dyr� medarbejder (En medarbejder der passer dårligt til de givnekriterier) og gennemgår alle vagter tildelt til denne medarbejder, for at se om der kan �ndesen billigere medarbejder til disse vagter. Der bliver så lavet en �taboo�-liste med vagter, derer ændret, som ikke bliver taget højde for i det næste antal gennemløbninger af algoritmen.Dette antal kunne f.eks. sættes til de næste 10 gennemløbninger, men det er en ting, der kanoptimeres i henhold til. Denne algoritme passer ind under �forbedringsalgoritme� typen ogkræver en vagtplan som input.

Simulated Annealing

Princippet ved denne algoritme er, at den muligvis accepterer ændringer, der ikke forbedrervagtplanen med en forhåbning om, at ændringerne i længden bliver et bedre alternativ, vedat foretage �ere ændringer. Chancen for at ændringer i vagtplanen bliver godtaget falder, somtiden går, da sandsynligheden for at �nde bedre alternativer bliver mindre, jo �ere vagterder byttes. For eksempel hvis en given ændring har forskellen ∆ i omkostninger, så vil dennye ændring i vagtplanen blive accepteret med det samme, såfremt ændringen resulterer i enbilligere vagtplan end den forrige mulighed. Betyder ændringen derimod en stigning i ∆, vilændringen kun blive accepteret med sandsynligheden e−∆/T . T er et udgangspunktsparame-ter, og bruges som et mål til at vurdere ændringer ud fra.

3.3.3 Diskussion

Ud fra forsøgene udført af Jackson og Havens [14] har det vist sig, at det ikke kan betale sig atforbedre en allerede lagt vagtplan med en algoritme, da besparelsen efter lang tids beregningerer minimal. Til gengæld har det vist sig, at Greedy Constructive algoritmen giver nogle goderesultater med kort beregningstid. Derfor vil det være hensigtsmæssigt, at tage princippernei Greedy Constructive algoritmen i betragtning når vi skal overveje, hvordan vi vil designevores egen algoritme.

30

3.4. UDVIKLING

3.4 Udvikling

3.4.1 Indledning

Vi vil udvikle en algoritme, der kan løse vores problem. Målet er at nå frem til en algoritme,der kan opfylde de krav, vi stiller i kravspeci�kationen i afsnit 3.2 på side 27. Vi har i afsnit 3.3på side 28 beskrevet forskellige algoritmer, der kan anvendes til lægning af vagtplaner og andretil forbedring vagtplaner. Vi vælger at udvikle en algoritme, der kan lægge en færdig vagtplanuden efterfølgende at forbedre på den. Baggrunden for at vi ikke vil gøre vores algoritme istand til at forbedre på den vagtplan der lægges �ndes i også teoriafsnittet. Der fandt vi udaf, at det var begrænset, hvor store forbedringerne var, i forhold til hvor kompliceret det varog hvor lang tid det tog at regne ud.

3.4.2 Metode til udvikling

For at udvikle en algoritme, der automatisk kan lægge en vagtplan, vil vi starte med atse på opgaven, som den løses manuelt. Disse tanker og metoder vil vi føre over i en intuitivalgoritme. Vi vil udføre en skrivebordstest af den intuitive algoritme, som foregår ved manueltat lægge en vagtplan ved hjælp af algoritmen. Vi begynder med at opstille et eksempel meden simpel vagtplan og få medarbejdere som vi kan overskue. Dette eksempel bruger vi til atteste den udledede intuitive algoritme. Under denne proces regner vi med at møde problemer,som skal løses og muligheder for optimering af algoritmen. Hvis problemerne løses, revideresalgoritmen efter behov. Når den intuitive algoritme har nået et brugbart stadie, vil vi omskriveden til pseudo-kode til videre bearbejdelse.

3.4.3 Intuitiv algoritme

For at kunne udvikle en algoritme, må vi først se på, problemet kan løses uden nogen baggrundfor at kunne løse opgaven. Vi tager udgangspunkt i en lille case med 3 medarbejdere og8 vagter. Hver medarbejder har en række ønsker, om hvornår de helst ikke vil arbejde.Derudover er der også andre ting, der spiller ind; hvor mange timer skal de have ifølge deresansættelses kontrakt og hvor meget de skal have i løn. Vi påtager os nu vagtplanlæggerensopgave; at samle �puslespillet� af vagter og medarbejdere, så vagtplanen bliver billigst muligog tilgodeser så mange af medarbejdernes ønsker som muligt. Vi prøver derefter at danne os etoverblik over, hvor godt hver enkelt medarbejder passer til de enkelte vagter. Vi formoder, atdet vil være en god ide først at sætte en medarbejder på, der hvor vedkommendes passer bedst.Dernæst vil vi prøve at danne os et overblik over de resterende vagter og sætte medarbejderepå hvor det er mest oplagt, ud fra de andre faktorer der spiller ind. Sådan vil vi gøre indtilalle vagter er tildelt en medarbejder. Det viser sig at vi gentagne gange bruger den sammemetode, så vi kan stille en simpel intuitiv algoritme op som vist i �gur 3.1.

1. Dan et overblik over hvor godt hver medarbejder passer til hver af de ledige vagter.

2. Sæt den medarbejder der passer bedst til en vagt på den vagt.

3. Hvis der stadig er ledige vagter, gå til punkt 1 igen.

Figur 3.1: Intuitiv algoritme i version 1

31

Kapitel 3. Løsning

3.4.4 Resistans

For at kunne bestemme hvilken medarbejder man skal sætte på en given vagt under vagtplan-lægningen, er det nødvendigt at kunne måle medarbejdernes �egnethed�. Målet har i vorestilfælde været at komme med et enkelt tal, som kan måle egnetheden for en given medarbejdertil en given vagt. Vi udtrykker i det efterfølgende denne værdi som �resistans�. Resistansenkan opfattes som en værdi for en medarbejders egnethed til en given vagt. En høj resistanser et udtryk for at medarbejderen ikke passer særligt godt til vagten, hvor en lav resistans eret udtryk for hvor egnet vedkommende er.

For at udtrykke resistansen i et tal skal de forskellige faktorer, som vurderes, når resi-stansen skal bestemmes, alle kunne udtrykkes i et tal der enten har negativ eller positivind�ydelse på resistansen. Hvis en medarbejder for eksempel har en kvali�kation, som skalbruges i en given vagt, falder vedkommendes resistans for denne vagt. Hvis vedkommendehar et ønske om at holde fri på den aktuelle dag, stiger resistansen. En tredje faktor kunnevære timelønnen. Hvis to medarbejdere får forskellig timeløn, men er begge kvali�cerede tilen given vagt, vil en arbejdsgiver være interesseret i den billigste løsning. Dette kan tagesmed i beregningen ved at lægge timelønnen til resistansens værdi. Hvis man begrænser sigtil disse faktorer, vil resistansen altså kunne udtrykkes som i formel 3.1. Bemærk her at kva-li�kationer og ønsker er udtrykt som �1� eller �0� (altså en binær værdi). Det vil sige: entenhar medarbejderen en krævet kvali�kation, eller også har vedkommende det ikke; enten harvedkommende et ønske om at holde fri den dag, eller også har vedkommende det ikke. Såledeshar en medarbejder med en timeløn på 120 kr. i timen, der har de nødvendige kvali�kationertil opgaven og et ønske om at holde fri den aktuelle dag, en resistans på 120.

Timeløn i kr.−Kvali�kation i 1/0+Ønske om fri i 1/0 = 120− 1 + 1 = 120Resistans (3.1)

Som det fremgår af formel 3.1, kan der hurtigt blive et stort spring mellem værdien afde forskellige faktorer. Kvali�kationer og timeløn betyder uendeligt lidt i forhold til time-lønnen. Derfor skaleres de op, så de er sammenlignelige. For at kunne udtrykke de enkeltefaktorer prioriteret i forhold til hinanden, multipliceres der med en faktorskalar. Størrelsen affaktorskalaren kan variere i forskellige situationer, da faktorer som timeløn og kvali�kationerikke altid er lige store i forskellige systemer.

De sammenlignelige faktorer er heller ikke lige vigtige for vagtplanlægningen. Man kunnefor eksempel forestille sig, at der i en virksomhed vægtes højere, at en medarbejder er kvali�-ceret til at udføre opgaverne, der kræves for vagten, end at medarbejderens personlige aftaleroverholdes. Hver faktor skal altså multipliceres med en systemskalar givet fra planlæggerensside. Hvis man ikke vil tillade at personlige ønsker og andre vigtige faktorer kommer til atbetyde at de kvali�cerede personer holder fri og en ukvali�ceret kommer på en vagt, kan sy-stemskalaren på kvali�kationsfaktoren sættes til et meget højt tal. Denne faktor vil dermedlave så stort et skel mellem de kvali�cerede og de ukvali�cerede medarbejdere at man ikke vilkunne komme ud for, at en ukvaliceret medarbejder opnår lavere resistans end en kvali�ceret.Se desuden eksemplet senere i dette afsnit (Se 3.3 på modstående side En negativ system-faktor fra planlæggerens side er udtryk for at en faktor tæller for at sætte medarbejderen påen vagt. Derved er resistansen summen af produkterne af faktorer og deres skalarer som vistpå formel 3.2.

resistans =n∑

i=1

systemskalari · faktorskalari · faktorværdii , hvor n er antallet af faktorer.

(3.2)

32

3.4. UDVIKLING

Eksempel

Resistansens plads i en vagtplanlægningsproces kan være som i følgende eksempel, hvor vivil vælge mellem tre personer, Peter, John og Åge, til en vagt hvor en maskine skal passes.John og Åge kan �nde ud af at passe maskinen, mens Peter endnu ikke har lært at brugeden. Han er ansat fordi han er nyttig andetsteds i �rmaet, men hans timeløn er mindre endde to andre medarbejderes på grund af hans manglende kvali�kationer. Åge har ønsket atholde fri på den aktuelle dag.

Fordi gennemsnitslønnen blandt virksomhedens medarbejdere ligger på 100 kr i timen,er dette faktorskalaren som bruges til at få de binære værdier fra �kvali�kationsfaktoren� og�ønskefaktoren� op på niveau med �timelønsfaktoren� som ikke skaleres op. Systemskalaren for�timelønsfaktoren� og �ønskefaktoren� er identiske, idet virksomheden ikke vægter besparelseraf lønudgifter højere end glade medarbejdere, som får deres ønsker opfyldt. Da det anses somvigtigere at få folk på vagten, der er kvali�cerede til at passe maskinen, er systemskalaren sattil -10.000, hvilket må anses, som en meget stor negativ værdi i forhold til niveauet af de andresystemskalarer. For at �nde et bud på de bedste valg af en medarbejder af de tre ansatte ieksemplet, regnes deres resistanser for vagten ud som på formel 3.3. Selvom Peter ville væredet billigste valg i kraft af hans lave timeløn, �redder� hans manglende kvali�kationer hamfra vagten. John og Åge er begge kvali�cerede og har derfor en meget lav resistans. Hvis ikkeÅge havde ønsket at få fri, ville hans resistans have været lavere end Johns i kraft af deresforskellige timeløn; men fordi Åge har ønsket at få fri, bliver hans resistans højere end Johnsog John bliver derfor sat på vagten.

resistansPeter = systemskalartimeløn · faktorskalartimeløn · faktorværditimeløn

+ systemskalarkvali�kation · faktorskalarkvali�kation · faktorværdikvali�kation+ systemskalarønske · faktorskalarønske · faktorværdiønske= 10 · 1 · 90+ (−10000) · 100 · 0+ 10 · 100 · 0= 900

resistansJohn = systemskalartimeløn · faktorskalartimeløn · faktorværditimeløn

+ systemskalarkvali�kation · faktorskalarkvali�kation · faktorværdikvali�kation+ systemskalarønske · faktorskalarønske · faktorværdiønske= 10 · 1 · 110+ (−10000) · 100 · 1+ 10 · 100 · 0= (−8900)

resistansÅge = systemskalartimeløn · faktorskalartimeløn · faktorværditimeløn

+ systemskalarkvali�kation · faktorskalarkvali�kation · faktorværdikvali�kation+ systemskalarønske · faktorskalarønske · faktorværdiønske= 10 · 1 · 100+ (−10000) · 100 · 1+ 10 · 100 · 1= (−8000)

(3.3)

33

Kapitel 3. Løsning

3.4.5 Videreudvikling af intuitiv algoritme

Vi har nu et matematisk udtryk for, hvor egnet en medarbejder er til en speci�k vagt. Detkan vi bruge til at videreudvikle vores intuitive algoritme, således den ser ud som på �gur 3.2.

1. Find alle medarbejders resistanser til alle ledige vagter.

2. Find medarbejderen med den mindste resistans til en vagt.

3. Tildel vagten til medarbejderen.

4. Hvis der stadig er ledige vagter, start forfra med punkt 1.

Figur 3.2: Intuitiv algoritme version 2

Vi vil nu afprøve denne metode manuelt på vores case fra tidligere i udviklingen. Underafprøvningen opdager vi, at der kan forekomme to resistanser, der er lige store og derformå vi udvælge dem begge i punkt 2 i �gur 3.2. Efter punkt 2 har vi nu mulighed for athave �ere medarbejdere, der alle har den mindste resistans. Vi vælger den medarbejder, hvorgennemsnittet af de andre medarbejderes resistans er størst. Det gør vi, fordi vi mener, det erher, der kan �spares� mest resistans. Hvis vi valgte en anden vagt, ville vi senere skulle sætteen medarbejder på der og være nødsaget til at sætte en medarbejder med stor resistans påvagten, da der ikke ville være andre muligheder. Derfor får vi en ny udgave af vores intuitivealgoritme, der ses på �gur 3.3.

1. Find alle medarbejders resistanser til alle ledige vagter.

2. Find mængden af medarbejdere med de mindste resistanser og mængden af tilhørendevagter.

3. Udtræk den vagt hvor gennemsnittet af de resterende medarbejderes resistanser erstørst.

4. Tildel vagten til medarbejderen.

5. Hvis der stadig er ledige vagter, start forfra med punkt 1.

Figur 3.3: Intuitiv algoritme i version 3

Vi starter forsøget forfra med den nye algoritme. Vi vil gerne have mere struktur, på detder sker under første punkt i algoritmen. Vi systematiserer alle resistanser i en matrice somvist i �gur 3.4 på modstående side. Vi har sat vagterne vandret og medarbejderne lodret imatricen. Det gør det let at �nde resistansen til en bestemt vagt og medarbejder. Hvis viønsker at �nde resistansen til vagt nr. 3 og medarbejder nr. 10, kan man gå ind i matricen ia3,10. Vi ændrer linie 1 i den intuitive algoritme til at bygge resistans-matricen. Dette er enmåde at gøre datamængden tilgængelig på.

Det ses, at det kun er den medarbejder, der sættes på en vagt, der skifter resistans over forde resterende vagter. Derfor kan vi, i stedet for at bygge hele resistans-matricen, nøjes medat opdatere den enkelte medarbejders resistanser for de resterende vagter i matricen. Det erdog stadig nødvendigt at �nde alle resistanser først i algoritmen. Vi kan derfor �ytte den delud af løkken og tilføje at efter en vagt er tildelt, skal medarbejderens resistans opdateres.

34

3.4. UDVIKLING

A =

a1,1 a1,2 ... a1,j

a2,1 a2,2 ... a2,j.

.

.

.

.

.

.

.

.

.

.

.

ai,1 ai,2 ... ai,j

Figur 3.4: Resistans matrice, hvor i er vagt-id og j er medarbejder-id

1. Generer resistans-matrice

2. Find mængden af medarbejdere med de mindste resistanser og mængden af tilhørendevagter

3. Udtræk den vagt hvor gennemsnittet af alle de andre medarbejderes resistanser er størst

4. Tildel vagten til medarbejderen

5. Opdater resistanser

6. Hvis der stadig er ledige vagter, gå til punkt 2.

Figur 3.5: Intuitiv algoritme version 4

Derudover, hvis vagten er fyldt ud, kan alle andres resistanser for denne vagt også slettes.Derfor ser vores intuitive algoritme derefter ud som på �gur 3.5.

Den intuitive algoritme i 3.5 er nu på sit endelige stadie. Det og dog vigtigt at huske på, atdenne algoritme ikke kan bruges til at �nde den bedste vagtplan. Hvis vi skulle bruge dennealgoritme til at �nde den bedste vagtplan, måtte vi, når vi vælger den bedste med arbejder tilen vagt, først undersøge alle de mulige vagtplaner, der kan lægges med medarbejderen på engiven vagt. Det skal gøres for alle medarbejdere til alle vagter. Hvis vi tager en vagtplan med3 vagter og 2 medarbejdere, vil der til hver vagt være to mulige ansatte; det er 2 · 2 · 2 = 23

mulige kombinationer af disse. For hver af dem, er der 3! mulige vagtplaner. Dvs. at der ialt skal lægges 23 · 3! = 48 vagtplaner. Dette vil give mv · v! vagtplaner, der skal lægges, nårresistans matricen udfyldes og yderligere skal de veri�ceres og vurderes. Betragt i stedet dettilfælde, hvor man har 6 medarbejdere og 36 vagter; det vil give regnestykket 636 ·36!, hvilketresulterer i et meget stort antal vagtplaner (ca. 3, 8 · 1069). Disse udregninger bliver megetkomplekse. I algoritmen vælger vi i stedet at vurdere lokalt på medarbejderen i forhold tilden enkelte vagt. På den måde undgår vi at �nde alle disse vagtplaner og dernæst veri�ceredem. Derfor er vores udviklede algoritme kun beregnet til at �nde en god vagtplan og ikkeden bedste.

3.4.6 Pseudokode

Den intuitive algoritme i �gur 3.5 er omskrivet til psuedokode, som er en eksplicit beskrivelseaf algoritmen. Den intuitive algoritme kan derimod fortolkes på �ere måder og kan ikke vur-deres tidsmæssigt. Pseudokode har også fordelen, at det er uafhængigt af programmingssprogog platforme. Man kan udtrykke sin algoritme uden på forhånd at have bestemt hvilket sprogden skal programmeres i. Planlægningsalgoritmen er udtrykt i pseudokodeblokken MAKE-

35

Kapitel 3. Løsning

PLAN, 2 på modstående side. Ud fra den intuitive beskrivelse fra på �gur 3.5 er en mereeksplicit algoritme opstillet i pseudokoden i psudoblok 2 på næste side. Kommentarer somkan hjælpe forståelsen er vedlagt i appendix C på side 73.

GETRESISTANCE funktionen er afhængig af hvilke faktorer der vurderes i en implemen-tation. Et eksempel bygget op omkring eksemplet brugt i forklaringen af resistans i afsnit 3.4.4på side 32 kan være bygget op som følgende pseudokodeblok hvor de forskellige systemscalarsog factorscalars er konstante udtryk for de forskellige skalarer og employeedata og shiftdataer lister af data som beskriver en vagt og en medarbejder.

Pseudokode 1.GETRESISTANCE(employeedata, shiftdata):

01: resistance ← 0

02: resistance ← resistance + systemscalars[salary] · factorscalars[salary] · shiftdata[hours] · employeedata[salary]

03: if shiftdata[requirements] == empployeedata[kvali�cation]

04: factorvalue[kvali�cation] ← 1

05: else

06: factorvalue[kvali�cation] ← 0

07: resistance ← resistance + systemscalars[kvali�cation] · factorscalars[kvali�cation] · factorvalue[kvali�cation]

08: factorvalue[wish] ← 0

09: if employeedata[wishstarttime] ≤ shiftdata[endtime] 10: if shiftdata[endtime] ≤ employeedata[wishendtime]

11: factorvalue[wish] ← 1

12: resistance ← resistance + systemscalars[wish] · factorscalars[wish] · factorvalue[wish]

13: return resistance

3.4.7 Vurdering

Algoritmen har nu fået sin endelige form. Vi vil i dette afsnit vurdere algoritmens køretidsamt lave en vurdering i forhold til de krav, vi stillede i kravspeci�kationen 3.2 på side 27.Derudover vil vi gennemgå algoritmen, for at undersøge om den altid vil stoppe, eller om denløber uendeligt. Vi vil også kategorisere vores algoritme i forhold til, om den er gyldig ellermåske-gyldig, som nævnt i teoriafsnittet 3.3 på side 28.

Køretid for planlægningsalgoritmen

For at vurdere hvor lang tid man kan risikere at bruge på at lægge en vagtplan med denudviklede algoritme fra afsnit 3.4.6 på forrige side, opstilles O-notation2 med henblik på enimplementering i PHP.

Idet den tid det tager at tildele en værdi til en variabel, sammenligne og udføre almin-delig aritmetik3 ikke afhænger af mængden af data som algoritmen fodres med, anses disseoperationers tidsforbrug for at være konstante. Det skal her nævnes, at hver gang en løkkepå formen: �for each A in B do...� udføres, sættes variablen A til en ny del af B og at i enløkke på formen: �while A > B do...� sammenlignes A og B.

Køretiden for den samlede algoritme er summen af køretiden for hver linie, hvor køretidenfor en linie er produktet af den kontante tid ci, som det tager at køre linien en gang og antalletaf gange linien bliver kørt i løbet af algoritmens kørsel. Den højest mulige køretid kan derforantages at være summen af alle produkter af hver linies køretid og det maksimale antal gangelinien kan blive kørt.

2Læs: Store �O� notation. Emnet er nærmere beskrevet i �Introduction to Algorithms� [29]3Almindelig aritmetik forstås her som addition, subtraktion, multiplikation og division.

36

3.4. UDVIKLING

Idet funktionen GETRESISTANCE ikke kører nogen løkker igennem vil gennemkørslenaf den tage konstant tid. Altså er O(GETRESISTANCE) ≤ 1. Man vil selvfølgelig kunnelave en mere kompleks algoritme, som muligvis vil kunne lægge vagtplaner bedre4, men ensimpel resistansfunktion vil også virke i algoritmen for MAKEPLAN.

I udtrykkene for køretiden for hver enkelt linie i pseudokodeblok 2 og i ligning 3.4 påden følgende side bruges en række forkortede variabelnavne i forhold til psudokodenblokkene: s er antallet af vagter5, e er antallet medarbejdere6 og si og ei er henholdvis en enkeltmedarbejder og en enkelt vagt. n er det maksimale antal opgaver en vagt kan have.

Idet MAKEPLAN(employees, shifts) udtrykkes som P(e, s) og GETRESISTANCE(employee, shift)udtrykkes R(ei , si) opstilles et udtryk for O(P(e, s)) i ligning 3.4 på næste side på baggrundaf observationerne for hver enkelt linie i pseudoblok 2.

Pseudokode 2.Køretid: MAKEPLAN(employees, shifts):

01://Find alle ledige medarbejderes resistanser overfor alle ledige vagter.c1 02:resmatrix ← { { } }c2s 03:for each shift in allshiftsc3se 04: for each employee in employeesc4seO(R(s, e)) 05: resmatrix[shift][employee] ← GETRESISTANCE(employee,shift)c5 06:freeshifts ← allshiftsc6ns 07:while |freeshifts| > 0

08: //...�nd den mindste forekomne resistans.09: //+ Find mængden af vagter hvor denne medarbejder har denne resistans.

c7ns 10: minres ← infc8ns 11: minshifts ← { }c9ns 12: minemployees ← { }c10ns 13: countminres ← 0c11ns2 14: for each shift in freeshiftsc12ns2e 15: for each employee in employeesc13ns2e 16: if resmatrix[shift][employee] < minresc14ns2e 17: minres ← resmatrix[shift][employee]c15ns2e 18: minemployees ← {employee}c16ns2e 19: minshifts ← {shift}c17ns2e 20: countminres ← 1c18ns2e 21: else if resmatrix[shift][employee] = minresc19ns2e 22: countminres ← countminres + 1c20ns2e 23: minemployees ← minemployees + {employee}c21ns2e 24: minshifts ← minshifts + {shift}

25: //Udtræk den vagt hvor gennemsnittet af alle de andre medarbejderes resistanser er størst.c22ns 26: maxmean ← -infc23ns2e 27: for i=0 to countminresc24ns2e 28: count ← 0c25ns2e 29: sum ← 0c24ns2e2 30: for each employee in employeesc26ns2e2 31: if employee != minemployees[i]c27ns2e2 32: count ← count + 1c28ns2e2 33: sum ← sum + resmatrix[minshifts[i]][employee]c29ns2e 34: mean = sum/countc30ns2e 35: if mean > maxmeanc31ns2e 36: maxmean ← meanc32ns2e 37: bestemployee ← minemployees[i]c33ns2e 38: bestshift ← minshifts[i]

39: //Tildel denne person denne vagt.c34ns 40: assign(bestemployee,bestshift)c35ns 41: if isfree(bestshift)c36ns 42: freeshifts ← freeshifts/{bestshift}

43: //Opdater alle personers resistans overfor denne vagt.c37nse 44: for each employee in employeesc38nseO(R(e, s)) 45: itresmatrix[bestshift][employee] ← GETRESISTANCE(employee,bestshift

46: //Opdater denne persons resistanser overfor alle vagter.c39ns2 47: for each shift in freeshiftsc40ns2 48: resmatrix[shift][bestemployee] ← GETRESISTANCE(bestemployee, shift)

49:return shifts

4Det er gjort til implementeringensdelen af dette projekt.5�s� for �shifts�.6�e� for �employees�.

37

Kapitel 3. Løsning

k ≥ nci

O(P (e, s)) ≤k + ks + kse + kseO(R(ei, si)) + kns + kns2

+ ns2e + ns2e2 + knse + knseO(R(ei, si))

k ≤ ks ≤ ns ≤ ns2 ≤ ns2e ≤ ns2e2

se ≤ seO(R(ei, si))nse ≤ nseO(R(ei, si))O(k) = 1

⇒O(P (e, s)) ≤ seO(R(ei, si) + nseO(R(ei, si)) + ns2e2

⇒{seO(R(ei, si) ≤ nseO(R(ei, si)) ≤ ns2e2O(R(ei, si))⇒O(P (e, s)) ≤ ns2e2O(R(ei, si))

(3.4)

Vil algoritmen altid stoppe? Vil den komme med et resultat?

Vi vil i dette afsnit gennemgå algoritmen i dens endelige pseudoform (Se afsnit 3.4.6 påside 35). Det gør vi for at vurdere om algoritmen altid vil komme med et resultat.

Hoved-løkken algoritmen kører igennem, starter på linie 07 og den kører kun så længestørrelsen af mængden freeshifts er større end nul. Det gør den, fordi vi i hver gennemkørselaf hoved-løkken, ender med at tildele en medarbejder til en opgave på en vagt. Der vil altidblive tildelt en medarbejder til en vagt og hver gang en vagt bliver �fyldt op�, fjernes denfra mængden af frie vagter på linie 42. Størrelsen af denne mængde vil altså på et tidspunktramme 0.

Løkkerne som startes på linierne 14 og 15 kører alle medarbejderne igennem for hvervagt. Denne løkke vil også altid ende, da mængderne employees og freeshift ikke ændrersig under planlægningen. Løkken vil også altid afsende et resultat, i form af en mængdeaf mulige �bedste� par af medarbejdere og vagter, da den undersøger for mindste resistans.Idet resistansen som udgangspunkt sættes til uendelig, vil der altid være en resistans, der ermindre end denne.

Den sidste store løkke der starter på linie 27 løber de to mænger indeholdende medarbej-dere og vagter som danner potentielt bedste par, igennem parallelt. Den løber kun så længe,at der er par i de to mængder, da tælleren countminres har samme størrelse, som antalletaf par. Løkken resulterer også altid i et sæt bestemployee og bestshift som er det bedste par.Det gør den fordi et gennemsnit af alle andre medarbejderes resistans til denne vagt holdesop imod det hidtil fundne gennemsnit som i starten af løkken bliver sat til minus uendelig.Derfor vil løkken altid �nde mindst et højere gennemsnit. De to sidste løkker, som starterpå linierne 44 og 47, opdaterer resistansmatrissen. De kører henholdsvis de to mængder em-ployees og freeshifts igennem. Begge disse mængder er afgrænsede og løkkerne vil derfor allekomme til et endeligt.

Vi kan ud fra vurderingen se, at algoritmen altid vil afsluttes, da ingen af løkkerne vilrisikere at kunne løbe uendeligt. Algoritmen vil også altid komme ud med et resultat, idet derunder hver gennemkørsel af �hovedløkken� på linie 14 vil blive sat en medarbejder på en vagt

38

3.4. UDVIKLING

og denne løkke først ender, når alle vagter har de medarbejdere, de skal bruge. Om resultateter gyldigt, kan vi dog ikke garantere. Man kan forestille sig episoder, hvor en medarbejder, derer sat på vagten, stadig har den mindste resistans til en vagt, selvom han allerede er placeretpå vagten. Dette vil dog kun ske i få tilfælde, hvor ingen andre har de rette kvali�kationer ogderfor får endnu større resistanser. Dette afhænger selvfølgelig af, hvordan de skalarer, somer beskrevet i afsnit 3.4.4 på side 32, bliver sat.

Gyldigt eller måske-gyldigt resultat?

Som beskrevet i teori afsnittet 3.3 på side 28, kan vi kategorisere algoritmer i to grupper.Den �gyldige� gruppe, der kun returnerer gyldige resultater, men ikke gør det hver gang. Hvisde f.eks. modtager ugyldigt input, vil algoritmen nå til en �dead-end�. Den anden gruppe,de �måske gyldige�, vil altid returnere et resultat, som måske/måske ikke er gyldigt. Voresalgoritme er en �måske-gyldig� algoritme, da den som nævnt ovenfor altid �nder en vagtplan.Man kan argumentere for, at det i dette tilfælde er bedst med en �måske-gyldig� algoritme,da vi mener, det er bedre at få lagt en vagtplan i stedet for ingen. Hvis vores algoritme laveren ugyldig vagtplan, vil det være den ansvarlige for vagtplanen, der må lave noget yderligerearbejde for at få vagtplanen til at gå op. F.eks. kunne der ska�es en vikar til at løse opgaveneller uddanne en medarbejder til opgaven.

Opfyldelse af kravspeci�kationen

I kravspeci�kationen 3.2 på side 27 har vi listet en række krav til algoritmen. Herundervurderer vi, hvor godt algoritmen lever op til kravene.

• Automatisere opgaven, at lægge en vagtplanAlgoritmen vil ved en gennemkørsel altid ende med en vagtplan, men om denne ergyldig, kan vi ikke altid være sikre på. Der kan forekomme særtilfælde, hvor ingen kantage en vagt, så alle får en høj resistans. Algoritmen vil alligevel �nde den �bedste�medarbejder at sætte på opgaven.

• Tage højde for vagternes krav til medarbejdernes kvali�kationerDette krav opfyldes, idet man udregner resistansen til en vagt. Hvis en vagt kræver, atman har truck-kørekort, vil alle medarbejdere uden truck-kørekort, få en højere resistansend de som har kortet. Det er dog også i denne sammenhæng, man kan komme ud for,at en medarbejder uden truck-kørekort bliver sat på en vagt, såfremt ingen med stortkørekort kan tage vagten. Da alle vil have en høj resistans. I dette tilfælde, vil det væreandre faktorer, som for eksempel lønnen, der kommer til at afgøre, hvem der får tildeltvagten.

• Tage højde for det aftalte timetal pr. medarbejderDet antal timer medarbejderne har kontrakt på, skal algoritmen bedst muligt sørge forde får tildelt. Det gør den under beregningen af resistansen til en vagt.

• Tage højde for medarbejdernes ønsker om at få friMedarbejderne har mulighed for at ønske om fri fra arbejde. Disse ønsker tager algorit-men højde for, når medarbejderens data indlæses. Hvis en vagt ligger samtidig med etønske om fri, stiger medarbejderes resistans til denne vagt. Faktoren regnes med, nårmedarbejderes resistans til en vagt beregnes.

39

Kapitel 3. Løsning

3.5 Vagtplanlægningssystem

I følgende afsnit vil vi beskrive en mulig opbygning af et system, der kan opfylde de krav,som vi stiller i henhold til kravspeci�kationen i afsnit 3.2.

Beskrivelsen af systemet er opbygget af 3 dele. Først beskrives medarbejdernes del, deref-ter planlæggerens del og til sidst systemdelen på serveren. Senere beskriver vi, hvordan voresalgoritme implementeres i systemet og dermed den prototype af systemet vi har udarbejdetfor at kunne teste vores algoritme.

3.5.1 System beskrivelse

En mulig måde at imødekomme udfordringerne opstillet i problemformuleringen, er at stille enwebserver til rådighed hvor henholdsvis planlægger og medarbejdere, uafhængigt af hinanden,kan lagre de data, som skal tages med i vagtplanlægningen som illustreret på �gur 3.6.

Medarbejder delen

Systemet vil fungere således, at hver medarbejder i virksomheden logger ind på en webs-ide med et personligt login. På denne side kan medarbejderne redigere i deres personligeoplysninger, som vil bliver brugt til lønudbetaling og andre administrative opgaver. Medar-bejderne skal derudover sende deres personlige digitale kalender til systemet, hvori de harindsat forskellige aftaler, på dage de ikke ønsker at arbejde.

Planlæggerens del

Planlæggerdelen af systemet vil indeholde forskellige funktioner til at oprette og redigereregler som f.eks. love og overenskomster, der skal medtages, når systemet lægger en vagt-plan. Planlæggeren skal også oprette den vagtplans skabelonen, som det automatiske systemudfylder med medarbejdere. Vagtplans skabelonen bliver oprettet, så hver vagt får kriteriersom f.eks. faglige krav til medarbejderen. Derudover vil planlæggeren også have mulighedfor, at indsætte forskellige informationer om medarbejdere. Det kan f.eks. være medarbejder-nes kompetencer eller foretrukne fridage. Redigeringen af disse informationer vil ikke væretilgængelige for andre end planlæggeren og vil blive brugt under udlægningen af planen.Planlæggeren vil derefter kunne bede systemet udarbejde en vagtplan. Systemet vil da prøveat udarbejde en vagtplan og generere evt. advarsler om forudde�nerede regler, der kan væreoverskredet. Når planlæggeren har genereret bare en tilfredsstillende vagtplan, bliver dennepubliceret som et webdokument, hvor medarbejder kan logge på, se og eventuelt downloadederes vagtplan, eller den kan sendes som et dokument til medarbejderne per email.

Systemet på serveren

Systemet, der skal køre på webserveren, vil som tidligere beskrevet modtage de informationer,der bliver sendt til serveren fra brugerne. Disse informationer vil blive bearbejdet, konver-teret og gemt i databasen således de senere er lettilgængelige, når vagtplanen skal lægges.Når planlæggeren beder systemet generere en vagtplan, vil webserveren hente informationerfra databasen og de forskellige kalender�ler, som medarbejderne har indsendt. Disse infor-mationer vil systemet benytte, når det skal kæde vagter sammen med medarbejdere for at�nde frem til en god vagtplan. De indlæste informationer vil indeholde informationer om-kring medarbejder ønsker. Dette vil medføre, at systemet, så vidt det er muligt, ikke sætteren medarbejder på vagt en dag, hvor medarbejderen har ønsket sig fri. Ud fra dette kansystemet give medarbejderne fri, hvis de har haft overarbejde.

40

3.6. PROTOTYPE

Figur 3.6: Dataens oprindelse i et planlægninssystem

3.6 Prototype

3.6.1 Indledning

Formålet med prototypen er, at teste om vores algoritme virker efter hensigten. Prototypener bygget efter systemet beskrevet i forrige afsnit 3.5 på forrige side, dog kun med de deleer nødvendige for at kunne teste algoritmen. Det vil sige, vi er interesserede i at vide, omden kan lægge en gyldig vagtplan, samt hvor lang køretid den har. Vi har under udviklingenaf vores prototype undersøgt, hvordan man skulle præsentere og opbygge programmet (Seafsnit 3.6.2). Hvorefter er vi gik dybere ned i udviklingen af prototypen (Se afsnit 3.6.4 påside 44). Som en afslutning på vores prototype udvikling har vi testet om prototypen funge-rede efter hensigten.

3.6.2 Præsentation og opbygning

Prototypen er opbygget, så systemet indlæser nogle kalender �ler7 fra de medarbejdere, derskal indsættes i en vagtplanen. Herefter indlæser systemet en vagtplansskabelon fra en kalen-der�l, som systemet senere vil indsætte medarbejderne i. Prototypen er opbygget som vistpå �gur 3.7 på næste side. Her ses, at systemet starter med at importere bruger-informationfra en database, hvorefter den indlæser alle kalender�lerne og vagtplansskabelonen. Denneinformation sendes så til vores planlægningsalgoritme, som plotter alle medarbejderne påvagterne i vagtplansskabelonen. Denne skabelon bliver til sidst skrevet ned i en ny kalender�l, som siden kan fremvises i et kalenderprogram. Ved at benytte kalender�ler, undgår vi atskulle programmere og udvikle et interface til fremvisning af den genererede vagtplan.

Webserverdelen af prototypen er yderligere beskrevet (Se �gur 3.11 på side 46). Dettediagram viser, hvordan systemet vil kunne inddeles i 3 dele. Den første del er en �reader� del,

7Vi benytter iCal kalender standarden i prototypen, hvilket vil blive videre beskrevet i afsnit 3.6.2 påside 43

41

Kapitel 3. Løsning

Slut

Import af brugere fra database

Import fra ønsker fraical udfra bruger info

Import af skabelon fra ical

Algoritmen modtager vagtskabalon og bruger informationer.

Find alle medarbejders resistans for alle vagt

Udvælg medarbejderen med den laveste resistans og sæt på vagten

Opdatere den valgte medarbejders resistans på alle ledige vagter

Samtlige besatte vagter konverteres til ical

Den færdige ical med vagtplanen fremvises i phpICalendar

Finder den vagt med dengennemsnitlige højeste resistans

Flere ledige vagter

JA NEJ

Slut

Start

Figur 3.7: Flowchart over prototype

der behandler de indsendte data. Dernæst har vi selve algoritmen, der bearbejder dataene oglaver en vagtplan. Endelig har vi den del, der konverterer det endelige output til den færdigekalender�l, som kan vises i et kalenderprogram.

Opbygning

Til vores prototype har vi valgt at benytte iCal8 standarden. Vores prototype er program-meret i PHP [18] med dertilhørende MySQL [16] database9. Prototypens interface10 brugerPHPiCalendar til fremvisning af vagtplanen, som er beskrevet i afsnit 3.6.3.

Vi har til prototypen oprettet en medarbejderdatabase 3.8 til at gemme de forskelligeinformationer, som bliver brugt til vagtplanlægningen.

uid smallint(5) Medarbejderens User IDsalary smallint(5) ID på attribut der skal påhæftes medarbejderenworkweek smallint(5) Antal timer i ugen en medarbejder skal arbejdeskills varchar(255) csv's med skills for medarbejderen

Figur 3.8: Medarbejder database

I prototypen har vi brugt følgende komponenter:

• iCal import funktionEftersom vi har valgt at arbejde med iCal �ler, skal vi først �nde eller udvikle en funktion

8iCal, se sektion 3.6.29MySQL er en Open Source database-server.

10Kalender fremviser, der gra�sk kan opstille en kalender på en hjemmeside.

42

3.6. PROTOTYPE

til at importere bruger-information fra iCal �ler.

• iCal eksport funktionVi skal også �nde / udvikle en funktion til at skrive en vagtplan korrekt ud i en iCal �l.

• Database udtræknings funktionerVi skal udvikle funktioner til at trække den information ud, vi har liggende i en database

• Algoritme til udvælgelseHjertedelen i vores prototype er algoritmen, som vi vil konstruere i PHP

iCalendar

iCalendar11, er en standard(RFC 2445) [8] til udveksling af kalenderaftaler samt andre ka-lenderopgaver, f.eks. todo lister med mere. Vi har valgt at bruge iCal standarden, fordi der�ndes et stort antal af programmer til visning og redigering af iCal (se �gur 3.9). Den delaf iCal standarden vi skal bruge er VEVENT. En VEVENT indeholder information om engiven kalender aftale.

Eksempel på hvordan en iCal VEVENT kan se ud:

BEGIN:VEVENT //Starter aftaleUID:20051206T213650Z-9287-1000-1-0@ubuntu //Unik aftale IDDTSTAMP:20051206T213650Z //Dato for oprettelseDTSTART:20051207T120000 //Tidspunkt for aftale startDTEND:20051207T154500 //Tidspunkt for aftale ophørSUMMARY:Opgave skrivning //Beskrivelse af opgavenLOCATION:uni //StedCLASS:PUBLIC //Type af aftaleDESCRIPTION:Skriv afsnit ... //Beskrivelse af opgavenEND:VEVENT //Afslutter aftale

Tider i iCal, som for eksempel DTSTART, skal læses År 2005 Måned 12 Dato 07 T Timer12 Minutter 00 Sekunder 00.

Anvendelse af iCal standarden

Da det ikke er alle iCal programmer på �gur 3.9, som understøtter alle dele af standarden,har vi valgt følgende fremgangsmåde for at indlæse og skrive de iCal �ler, der skal bruges.Skabelon-vagtplanen indlæses og for hver en aftale oprettes der en vagt. For at vi kan oprette

1. Evolution

2. Microsoft Outlook

3. Lotus Notes

4. Apple iCal

5. Mozilla Sunbird/Calendar

Figur 3.9: 5 eksempler på kalender programmer

en vagt, skal vi have de informationer, som en vagt består af (Se de�nition 2 på den følgendeside), dog skal vi ikke vide hvilke medarbejdere, som der er sat på vagten, da det er en skabelonvi indlæser. Endvidere bliver medarbejder id'et hentet fra databasen, når vi indlæser vagten

11iCalender også kendt under forkortelsen iCal

43

Kapitel 3. Løsning

og skal derfor ikke hentes fra iCal �len. Imidlertid mangler vi at vide, hvilke opgaver der skaludføres på en given vagt. Derfor har vi valgt, at man skal skrive en tekststreng på følgendeform i beskrivelses felt:

REQ;lift,driveHvor "lift,drive"er krav. Ordene er prede�neret i programmet og oversættes til et heltal.En medarbejder kan, som nævnt i de�nitionen af en medarbejder (Se 3 på næste side),

have nogle medarbejder ønsker. Et medarbejderønske er et tidsinterval med en prioritet.Prioriteten angiver i hvor høj grad medarbejderen ikke vil have en vagt. Medarbejderønskerindlæses fra en iCal �l for hver medarbejder. Måden man angiver prioritet er ved at skriveen tekst streng af formen i beskrivelses feltet:

PRI;xHvor x er et tal fra 1 til 3.

3.6.3 PHP iCalendar

Vi har valgt at bruge PHP iCalendar [19] til fremvisning af de iCal �ler, som vores algoritmelaver. PHP iCalendar opstiller iCal �lerne på en overskuelig måde12, så man hurtigt kan fået overblik over en evt. vagtplan. PHP iCalendar indeholder næsten de samme funktioner,som raditionelle kalender programmer. Dog med den væsentlige forskel, at det ikke er muligtat lave ændringer i kalenderen. PHP iCalendar er kun en fremviser.

Grunden til vi har valgt at bruge PHP iCalendar er, som navnet også antyder, at det erskrevet i PHP og så er det samtidigt open source. Det giver os mulighed for at kunne laveændringer i deres scripts, så det kan tilpasses vores funktionaliteter.

3.6.4 Udvikling af prototype

I dette afsnit vil vi beskrive, hvordan vi har opbygget vores prototype, hvilke problemer vihar haft undervejs og hvordan vores kode er opbygget.

Objektorientering

For at gå et skridt videre mod implementeringen, startede vi med at omskrive den tidlige-re viste pseudokode til objektorienteret kode. Her introduceredes en række klasser ud frabegreberne i afsnit 1.1.3. Et par af de de�nerede klasser indeholder funktioner eller vari-abler, som ikke bliver brugt under selve planlægningen, men de viser sig nyttige i løbet afimplementeringen, f.eks. ved import og eksport funktionen.

For at danne et overblik, har vi lavet et uml diagram 3.10 på modstående side, derillustrerer klasserne og hvordan de hænger sammen. En lille sidebemærkning er at �schedule�er en base klasse, der bliver nedarvet i �shift� og �appointments�.

De�nition 1. En vagtplan er i begrebsafsnittet blot en mængde af vagter. Klassen som skalrepræsentere en vagtplan, kalder vi �work_schedule�. �Work_schedule� indeholder såledesogså kun en liste af �shifts�13. En tabel over attributes og funktioner ses i tabel D.1 påside 75

De�nition 2. En vagt de�neres som klassen "shift". I henhold til begrebsafsnittet indeholderen vagt en liste af evner, som kræves af medarbejderne ud fra de opgaver, der skal løses. Denneliste af �requirements� er en liste af tal, som henviser til en evne. F.eks. to medarbejdere med

12Demo: http://phpicalendar.net/phpicalendar/13Man kunne selvfølgelig argumentere for ikke at lave en klasse til vagtplanen, idet det kun er en enkelt

liste; men i forbindelse med implementeringen viser det sig praktisk at have denne klasse at bygge videre på.

44

3.6. PROTOTYPE

Figur 3.10: UML diagram over klasserne i produktet

evnen �4� er påkrævet til vagten forekommer �4� to gange på listen. De medarbejdere somer sat på en vagt, placeres på en liste af medarbejder �id�er. Listen over medarbejder �id�erkaldes �employees_assigned� og er en liste af heltal, der refererer til en id på en medarbejder.Desuden strækker en vagt sig over et tidsinterval, der huskes ved et starttidspunkt og etsluttidspunkt. De resterende funktioner og attributter kan ses på tabel D.2 på side 75

De�nition 3. En medarbejder de�nerer vi som klassen �employee�, så klassen skal indehol-de informationer omkring medarbejderens timeløn (�salary�), det timetal han skal udfylde iløbet af en uge (�weekhours�) og hvad han kan (�skills�). Disse er udtrykt i de samme heltal,som bruges til �requirements� i de�nitionen af �shift�. Endelig har medarbejderen også nog-le �appointments� som er medarbejderønsker, der falder sammen med vagter i vagtplanen.Til udregning af resistansen bruges medarbejderens �appointments�, �salary�, �weekhours�,�assigned� og �skills�. Resistansen �ndes ved at kalde funktionen �get_resistance�. Samtligefunktioner og attributes kan ses på tabel D.3 på side 75

De�nition 4. Endvidere har vi de�neret klassen �appointment�, der er et medarbejder ønske.Det er de�neret som et id, der indikerer hvilken vagt id ønsket gælder i henhold til, og ettidsinterval som i en �shift�. Den har den dog kun en prioritet, som gives i et heltal i intervallet[1; 3], hvor 3 er højeste prioritet. En tabel med alle attributter og funktioner kan ses påtabel D.4 på side 76

"reader-del

"reader-delen, henter en skabelon, til en vagtplan ud af en iCal �l 3.6.2 på side 43. Skabelonener den overordnede vagtplan, som indeholder alle de vagter man ønsker skal besættes. Detder kendetegner skabelonen er, at der ikke er sat medarbejdere på vagterne. Skabelonen eren instans af klassen �work_schedule�(se de�nition 1 på modstående side). Dens indhold

45

Kapitel 3. Løsning

Webserver

iCalResult

iCalemployee

iCalskabalon

Database

ReaderWriter

Scalar Employee Shifts work_schedule

Algoritme

Badness Time Conflicts iCal ResultLøn

Figur 3.11: Overblik over prototypen

består af en række instanser af klassen �shift�(se de�nition 2 på side 44). Derefter henter vialle medarbejdere, samt det data der er for medarbejderne, ud fra en database og indlæserderes evt. medarbejder ønsker fra en iCal �l, medarbejder ønsker gemmes kun, såfremt derammer sammen med en vagt i skabelon vagtplanen. For at holde styr på dataene, laver vien ny instans af klassen employee (se de�nition 3 på forrige side) for alle medarbejdere. Detnæste der sker i vores prototype, er at vi fastsætte nogle systemskalarer, som beskrevet iafsnit 3.4.4 på side 32. For at danne en oversigt af funktioner der anvendes til indlæsningeraf data henvises til 3.2 på modstående side. Når dataene er blevet indlæst erklæres nogleglobale variabler 3.1. Grunden til vi anvender globale variabler er for, at undgå at kopiereinformationerne en masse gange.

Variablens navn Datatype Beskrivelse

scalars int[]globalt assoiceret array over systemskalarer, indeholder key-strings�salary�, �workweek�, �appointment� og �skills�.

work_schedule work_schedule globalt vagtplans objekt.free_shifts shift[] globalt array med frie vagter.res_matrix int[][] globalt 2 dimentionelt modstands array.skills int[] globalt assoiceret array med skills.employees employee[] globalt array med medarbejdere, med index fra 1-n.DEF_DEBUG int global variabel som bestemmer mængden af debug output.

Tabel 3.1: Globale variabler

46

3.6. PROTOTYPE

Funktionens navn Parameter Returværdi Beskrivelse

load_employees string ical_folder employee[]

tager en streng som parameter, strengen angiverhvilken mappe medarbejdernes iCal �ler erplaceret i, funktionen returnere et array afindlæste medarbejdere.

get_employee_data - -funktionen returnere et array med indlæstemedarbejder, dog er iCal �lerne ikke indlæstendnu.

load_template_sp string ical_�le work_schedule

tager en streng som parameter, strengen angiverplaceringen af iCal �len som indeholder skabelonvagtplanen, funktionen returnere en vagtplan,hvor der endnu ikke er påsat medarbejdere.

get_skill_id string name -funktionen returnere en skill-id ud fra parameteretname, vedhjælp af det globale skills array.

get_shift_con�ict int start, int end int[] con�ictsreturnere array over vagter som falder sammenmed tidsintervallet fra start til end.

Tabel 3.2: Funktioner til at indlæse data

algoritmen

Nu er vi nået til det punkt, hvor vi har de oplysninger, der skal bruges for at køre vo-res algoritme. Selve algoritmen er en implentering af den pseudokoden 2 på side 37. Dogmed den forskel, at vi gennem videreudvikling har implenteret en mere ambitiøs version afget_resistance.

Når algoritmen er færdig, returnerer den 5 ting. Den samlede resistans for de medarbejdereden har sat på vagter. Den samlede timeløn, der er brugt for at få lavet vagtplanen. Tidenalgoritmen har været om at lave vagtplanen samt antallet af kon�ikter. Endeligt returnererden en instans af hele vagtplanen, det vil sige en work_schedule.

get_resistance

Den væsentlige forskel ved videreudviklingen af get_resistance er, at en vagt kan have mereend et krav. Ligeledes kan en medarbejder have mere end en evne. Imidlertid har vi valgt atde�nere, at 1 krav på en vagt, kræver 1 medarbejder. Hvis en medarbejder, er blevet tildelten vagt, hvor vedkommene har evner til mere end et af kravene på en vagt. I såfald bliver vinød til at vurdere, hvor godt han passer på vagten, med hensyn til hver enkelt evne og krav.Et eksempel kunne være at en vagt krævede 2 medarbejdere på en vagt. De 2 krav vagten harer, at der skal være en chef og en som kan tømme skaldespanden. De �este medarbejdere kantømme skraldespanden, men det er kun chefen som kan udfylde chef-rollen. I midlertid kunnedet forekomme, at chefen allerde var blevet sat på vagten til at tømme skaldespanden. På denmåde ville man kunne komme ud for, at algoritmen ikke ville kunne lave en vagtplan. Det vilvi undgå ved at danne alle kombinationer af medarbejdernes kvali�kationer og vagtens krav.En potientiel ny medarbejder til denne vagt bliver bedømt ud fra hvor stor en mængde af dissekombinationer, der har et uopfyldt krav til en kvali�kation, som den potentielle medarbejderhar.

�Evaluering�

På baggrund af de data genereres en graf, der kan bruges til at danne et overblik over hvor godtprocessen er gået. Grafen viser hvor meget resistanse der er brugt på at lave vagtplanen, hvormeget løn der er brugt på at lave vagtplanen, hvor lang tid det har taget at køre algortimenog endelig hvor mange kon�ikter der opstod. Til sidst skrives en �result� iCal �l, der sidenkan vises i en iCal fremviser.

47

Kapitel 3. Løsning

3.6.5 Test af prototypen

Til test af prototypen, valgte vi at bruge en �ktiv case, som tog udgangspunkt i vagtplanenpå en tankstation.

I vores case var der 18 medarbejdere ansat til at dække perioden fra kl. 18:00 til kl. 07:00på hverdage og hele weekenden. Resten af tiden, bemandes tankstationen af det faste daghold.De 18 medarbejder vi ville lægge en vagtplan for, var delt op i 2 hold; et aften-/weekendholdog et nathold. Aften-/weekendholdet skullr dække alle hverdage fra 18:00 til 24:00 samt heleweekenden, dog ikke i tidsrummet mellem 24:00 og 07:00. Perioden fra 24:00 til 07:00 blevdækket af natholdet, alle ugens 7 dage. Ud over de to hold, var der også en gruppe nyemedarbejdere, som ikke havde erfaring nok til at stå alene på en vagt. De måtte kun ståsammen med en erfaren medarbejder, det vil sige de kun kunne tage vagter i weekenden,da det var det eneste tidspunkt der var dobbletvagter. Holdene havde forskellige opgaver,f.eks. skulle de der arbejder på natholdet gøre butikken rent, hvilket aften-/weekendholdetikke skulle tænke på. Prototypen blev testet med en tom vagtplan for tankstationen, for atog få den til at udfylde en vagtplanen. Vi valgte at lægge vagtplanen for Januar 2006. Icasen havde vi besluttet, at medarbejderne �k forskellig timeløn. Derudover var hver enkeltansat sat til et forskelligt antal plantimer i ugen. For at lave en, krævende test af voresalgoritmes funktioner, havde vi lavet ønsker til 13 ud af de 16 medarbejdere (se eksemplerpå medarbejder ønsker i tabel 3.4 på side 50). Hver medarbejder (som ses i tabel 3.3) havdetilknyttet en kvali�kation: nat, gammel eller ny. Det var disse, der i algoritmen skulle afgøre,om en medarbejder måtte arbejde på vagten. Vi generede en iCal-�l for hver medarbejder

Medarbejder-id Kvali�kation Timeløn Timer pr. uge1 Nat 90 162 Gammel 89 5,53 Gammel 88 64 Ny 93 95 Gammel 81 5,56 Gammel 82 5,57 Nat 88 178 Gammel 90 5,59 Gammel 84 5,510 Gammel 84 5,511 Ny 82 912 Gammel 90 5,513 Gammel 90 614 Nat 83 1615 Gammel 82 616 Ny 81 9

Tabel 3.3: Medarbejder liste

og inkluderede hver deres ønsker. Derudover havde vi en iCal-�l for selve tanktstationensvagtplan. Disse �ler blev uploadet til prototypen og vi kørte algoritmen på de uploadededata. Efter ca. 2 sek, havde prototypen udfyldt vagtplanen. Der var ingen kon�ikter, hvilketvil sige at ingen �k tildelt vagter, de ikke havde kvali�kationerne til. Under udfyldning afvagtplanen, tog prototypen højde for antallet af timer en medarbejder var sat til at skullehave. Gennemsnitlig har hver ansat tildelt 33.125 timer over hele måneden.Vi kan ud fra vores

48

3.6. PROTOTYPE

resultater se, at den gennemsnitlige afvigelse i forhold til, hvor mange timer medarbejderenskulle havde haft, er på ca. +/- 3,25 timer om måneden eller ca. 10 %. Da den korteste vagter på 5 timer, mener vi at denne �lille� afvigelse er acceptabelt, da planen aldrig vil kunne gåop, så alt går i 0. Ud fra grafen 3.12 kan vi se at prototypen tager højde for timelønnen. Der

Figur 3.12: Grafen viser medarbejdernes timeløn stillet op mod afvigelsen i timetal over helemåneden.

kan blandt andet ses at de der har fået overarbejde, er dem med lav timeløn, hvorimod allemedarbejderne der får mere end gennemsnittet i løn, maksimalt har 0,5 timers overarbejde.Dette giver en god besparelse for arbejdsgiveren. Vi holdt samtlige medarbejderes ønsker opmod vagtplanen og kunne se at der ikke var et eneste ønske, som var blevet brudt. Vi kanderfor konkludere, at den kan tage hensyn til medarbejdernes ønsker.

Vores prototype kan afprøves på: http://p1.squarky.dk/På den vedlagte CD-rom ligger alle �lerne fra vores testcase. Dette inkludere alle me-

darbejdernes ønsker, i iCal format, den samlede vagtplan (udfyldt og ikke udfyldt) i iCal,samt regneark med uddybning af testresultaterne. Filerne �ndes i mappen �testcase� og �len��loversigt.txt� indeholder en kort beskrivelse at �lerne.

3.6.6 Konklusion på test

Vi kan ud fra testen af vores prototype konkludere, at vores algoritme ved testen virkerefter hensigten. Vi har udviklet en algoritme der ved testen lagde en gyldig vagtplan, derfor hver medarbejder, tog højde for timeløn, antal timer pr. uge, kvali�kationer og ønsker.Krav til ønsker og kvali�kationer, blev opfyldt. Timetallet pr. uge, afveg i gennemsnit 10%pr. medarbejder. Hvor godt algoritmen tog højde for timelønnen, er svært at give en korrektværdi for. Dog kunne vi ud fra grafen i �gur 3.12, se at medarbejderne der �k mere engennemsnittet i løn, højest havde 0,5 timers overarbejde.

49

Kapitel 3. Løsning

Navn Beskrivelse Priotet1.ics Medarbejde ønske om fri i uge 2 22.ics Medarbejde ønske om fri i uge 3 13.ics Medarbejde ønske om fri i uge 4 14.ics Medarbejde ønske om fri i weekenden 27 til 29 jan 15.ics Medarbejde ønske om fri i weekenden 20 til 22 jan 26.ics Medarbejde ønske om fri i weekenden 13 til 15 jan 37.ics Medarbejde ønske om fri i weekenden 6 til 8 jan 18.ics Medarbejde ønske om fri d. 6,11,20 og 25 jan 1,1,1,39.ics Medarbejde ønske om fri d. 7,13,17,19 og 23 jan 2,1,3,3,110.ics Medarbejde ønske om at få fri hver tirsadg 311.ics Medarbejde ønske om at få fri hver onsdag 212.ics Medarbejde ønske om at få fri hver torsdag 113.ics Ingen Ønsker -14.ics Ingen Ønsker -15.ics Ingen Ønsker -16.ics Medarbejde ønkse om fri i uge 1 3

Tabel 3.4: Medarbejder ønsker

3.6.7 Vurdering af prototypen

På grund af kompleksiteten i beregningerne, har vi valgt at se bort fra overlappende vagteri vores algoritme. Dette betyder at vi ikke kan have 2 vagter der ligger oven i hinanden, davi kan risikere at en medarbejder skal passe to vagter på samme tid. Vi kan omgå problemetved at tilføje �ere opgaver til en vagt, så vi på den måde kan få �ere til at arbejde på sammetid og samtidig sikre at en medarbejder ikke skal klare 2 opgaver. Dette leder os dog tilen anden svaghed i vores prototype, da tilføjelse af opgaver til en vagt vil betyde en storstigning i beregninger der skal udføres for den vagt. Vi skal derfor begrænse opgaverne for atberegningstiden ikke bliver alt for stor.

Et andet kriterium, som den ikke kan tage højde for, er elleve timers reglen [2]. Detteskyldes også at det vil kræve for mange beregninger, da algoritmen skal løbe alle vagterigennem, hver gang den skal tilføje en medarbejder til en vagt, for at kontrollere at reglenikke overskrides.

50

KAPITEL

4

Afsluttende afsnit

4.1 Konklusion

Målet med dette projekt har været at sætte os ind i problematikkerne bag vagtplanlægningog derudfra konstruere en algoritme til automatisk vagtplanlægning. Konstruktionen af enfungerende algoritme lykkedes og afprøvningen af denne har vi gennemført, ved udviklingen afen prototype programmeret i PHP. Denne fungerende algoritme kan på et senere tidspunktimplementeres i et system, som vi også har udarbejdet et udkast til. Problemerne dettesystem skulle kunne løse, er de problemstillinger der er listet op i vores problemafgrænsningi afsnit 2.8. Vi kan både ud fra vores analyse men også ud fra vores arbejde med algoritmenkonkludere, at vagtplanlægning er et stort og komplekst problem, der kræver meget tid, hvisman vil sættes grundigt ind i problematikkerne og kunne løse dem.

Problemerne vi mener, vi har løst med vores algoritme, er opstillet på efterfølgende liste,samt i hvilket afsnit vi mener det er vist, at problemerne er blevet løst.

• 1 Det kan være nødvendigt at give medarbejdere overarbejde på grund af andre med-arbejderes fravær forårsaget af f.eks. sygdom eller barsel.Som det kan ses i algoritmetesten i afsnit 3.6.5 på side 48, kan det være nødvendigt atgive medarbejderne overarbejde, men ikke kun på grund af de ovenstående situationer.I testen blev nogle af medarbejderne tildelt overarbejde for at vagtplanen kunne falde påplads. I de �este tilfælde var det de billigste medarbejdere, der blev sat på vagterne somhavende overarbejde for at få vagterne til at stemme.

• 2 Medarbejderne får ikke ind�ydelse på deres arbejdsuge i en sådan grad, at de kanbestemme over hvilke vagter de får og dermed kan tillade sig at lave personlige aftaler iet tidsrum, hvor de potentielt kunne komme på en vagt. Denne begrænsning sker, fordidet ikke kan forventes, at vagtplanlæggeren kan lægge en ny vagtplan relativt ofte.Uoverskueligheden og varigheden af planlægningen medfører, at der fortrinsvis lavesstatiske vagtplaner, hvilket medfører at medarbejderne skal bytte vagter internt, hvisde vil have fri.I henhold til testen af algoritmen i afsnit 3.6.5 på side 48, kan vi konkludere at etautomatisk system, kan tilgodese medarbejdernes ønsker. Dette kan igen prioritereshøjere i algoritmens opbygning, således at systemet i højere grad forsøger at tilgodesemedarbejdernes ønsker.

• 5 Det er nødvendigt for en vagtplanlægger, at kunne de�nere hvilke regler et automatiskvagtplanlægningsværktøj, skal kunne overholde under udarbejdelsen af en vagtplan. Detgælder for eksempel hvilke muligheder et vagtplanlægningsprogram har for at tildelemedarbejdere i vagtplanen overarbejde.Dette er i vores system opbygget som en mængde skalarer, der kan varieres. Disseskalarer benyttes, når resistansen for en vagt skal udregnes (Se afsnit 3.4.4 på side 32).

• 6 Det er nødvendigt at speci�cere, hvilke krav vagterne i vagtplanen stiller til medar-bejderne. Ligeledes er det nødvendigt at kunne udvælge den medarbejder, som er bedst

51

Kapitel 4. Afsluttende afsnit

kvali�ceret til en given vagt.Vi har i vores algoritme brugt kvali�kations krav til udregning af en medarbejders resi-stans for en vagt, således at medarbejderne testes om de er de bedst egnede til vagterne.Dette kan ses i afsnit 3.4.4 på side 32. Vores test kunne udfylde en vagtplan med kva-li�kationskrav til medarbejderne.

• 10 For automatisk at lave den bedst mulige vagtplan kræver det, at man højst sand-synligt skal �nde alle mulige vagtplaner. Antallet af mulige vagtplaner er meget stort.Vi har i vores system ikke gået efter at ligge den bedste vagtplan, da dette indebærer atman højst sandsynligt skal �nde alle mulige vagtplaner. I stedet har vi gået efter at liggeen god vagtplan ved at bruge en konstruktiv algoritme, der lokalt vurderer hvor godt enmedarbejder passer til en vagt. Dette kan ses i det tekniske afsnit 2.6 på side 23

Da en løsning af ovenstående problemer var det overordnede problem formuleret i proble-mafgrænsningen, må vi konkludere at projektet har været en succes.

4.2 Perspektivering

Projekt har nu nået sin ende. Vi vil forsøge at se projektet i et lidt større perspektiv. Detgør vi ved at stille en række spørgsmål til projektet: hvordan kunne man komme videre meddette projekt? Hvilke steder er det oplagt at tage fat i et fremtidigt arbejde? Hvad ville derske, hvis vi lod en virksomhed bruge vores vagtplanlægningssystem? Ville det ændre nogetved arbejdsmiljøet i virksomheden? Ville medarbejderne kunne mærke en forskel?

I et fremtidigt arbejde ville det i første omgang være oplagt, at se nærmere på de problem-stillinger vi valgte fra i afgrænsningen 2.8 på side 25. Man kunne være at gøre det muligt atbytte vagter internt mellem de ansatte, eller tage bedre højde for brugervenligheden i produk-tet ved at udvikle en e�ektiv bruger�ade, som skulle gøre det lættere for en vagtplanlæggerat administrere sine medarbejdere. Det vil generelt være oplagt at færdigudvikle prototypentil et endeligt system, hvor medarbejderne kunne logge på og oprette deres egen kalenderemed private aftaler. Udover at lave selve systemet, kan man også optimere algoritmen, så denbedre vil kunne løse de problemer, som vi fandt frem til under vurderingen af algoritmen 3.4.7på side 36.

Man kunne, ud over at forbedre prototypen også forestille sig, at produktet, det vil sigedet samlede system i afsnit 3.6 på side 41, kunne udvides med en række moduler, der gørdet mere anvendeligt i praksis for en vagtplanlægger. Man kunne blandt andet udregne detkonkrete brugte timetal per medarbejder og binde det sammen med medarbejdernes løn, sådet bliver muligt, at se hvor dyr en vagtplan bliver for en arbejdsgiver.

Det ville også være interessant at dykke ned i overvejelserne omkring, hvad der ville ske,hvis vi satte en virksomhed til at anvende vores udviklede system. Hvis vores algoritme opti-meres til at tage højde for �ere regler, som en virksomhed kunne de�nere, kunne det medføre,at virksomheder, der ofte laver dynamiske vagtplaner, ville benytte systemet og derved lettearbejdsbyrden for vagtplanlæggeren. Derudover kunne man forestille sig, at det ville væretil gavn for medarbejderne, hvis programmet kunne tage højde for deres ønsker under ud-arbejdelsen af en vagtplan. Ved at kunne få varierende vagtplaner og �eksible vagtplaner,kunne man forestille sig at medarbejdere ville blive mere tilfredse, da de i højere grad villefå deres ønsker om fridage opfyldt. En anden situation man kunne forestille sig, var at �erevirksomheder ville overveje at bruge omskiftelige vagtplaner, eftersom programmet gør detbesværlige arbejde lettere for vagtplanlæggeren.

52

LITTERATUR

[1] 7-eleven. Vesterbro 95, 9000 Aalborg, Tlf: 98 11 47 01/98 11 47 11.

[2] Arbejdstilsynet. Daglig hvileperiode, at-meddelelse nr. 5.01.1, November 1997. http:

//www.at.dk/sw4619.asp, pr. 15-12-2005.

[3] Shell Service A/S. Karolinelundsvej 45, 9000 Aalborg, Tlf: 98 12 55 88.

[4] Statoil A/S. Hadsundvej 212, 9220 Aalborg Ø, Tlf: 98 15 11 22/98 15 24 88.

[5] Beskæftigelsesministeriet. Arbejdsmiljøloven, http://www.retsinfo.dk/info/

infolev/bes.htm, pr. 18-12-2005.

[6] Luca Di Gaspero. Local Search Techniques for Scheduling Problems: Algorithms andSoftware Tools. PhD thesis, Dipartimento di Matematica e Informatica � Universitàdegli Studi di Udine, Udine, Italy, 2003.

[7] Diverse. P1-projektkatalog for naturvidenskab, 2005. http://tnb.aau.dk/fg/nat/

intra/p1/Nat_projektkatalog_e2005.pdf.

[8] D. Stenerson (Microsoft) F. Dawson(Lotus). Internet calendaring and scheduling coreobject speci�cation. http://www.ietf.org/rfc/rfc2445.txt, D.18-12-2005.

[9] HR-guide.com. Personnel scheduling. http://www.hr-software.net/pages/217.htm

D.18-12-2005.

[10] Kærby Hvilehjem. Ny kærvej 16, 9000 Aalborg, Tlf: 98 13 66 00.

[11] Cybershift inc. Employee scheduling, employee scheduling software, labor manage-ment, free employee scheduling software, employee training scheduling. http://www.

cybershift.com/products_overview.asp D.18-12-2005.

[12] Intellicate. Intelliroster lite. http://www.intellicate.com D.18-12-2005.

[13] Retain International. Resource management & sta� planning software. http://www.

retaininternational.com/ D.18-12-2005.

[14] W. Ken Jackson, William S. Havens, and Harry Dollard. Sta� scheduling: A simpleapproach that worked. Technical Report CMPT97-23, Intelligent systems lab, Centrefor systems science, Simon Fraser University, 1997.

[15] Steinar Kvale. InterView. Hans Reitzels Forlag a/s, 1994.

[16] MySQL. Database. http://www.mysql.com, open source databasen MySQL, D.18-12-2005.

[17] Hydro Texaco Nørresundby. Østergade 27-29, 9400 Nørresundby, Tlf: 98 17 03 20.

[18] PHP. Php: Hypertext preprocessor. http://www.php.net, Programmeringssproget P-HP D.18-12-2005.

53

http://www.at.dk/sw4619.asp

http://www.at.dk/sw4619.asp

http://www.retsinfo.dk/info/infolev/bes.htm

http://www.retsinfo.dk/info/infolev/bes.htm

http://tnb.aau.dk/fg/nat/intra/p1/Nat_projektkatalog_e2005.pdf

http://tnb.aau.dk/fg/nat/intra/p1/Nat_projektkatalog_e2005.pdf

http://www.ietf.org/rfc/rfc2445.txt

http://www.hr-software.net/pages/217.htm

http://www.cybershift.com/products_overview.asp

http://www.cybershift.com/products_overview.asp

http://www.intellicate.com

http://www.retaininternational.com/

http://www.retaininternational.com/

http://www.mysql.com

http://www.php.net

Litteratur

[19] phpicalendar. phpicalendar, open source projekt. http://www.phpicalendar.net/

D.18-12-2005.

[20] Planahead. Vagtplanlægning på nettet. http://www.planahead.dk/ eller en googlecache http://64.233.183.104/search?q=cache:csjkTV-2IVEJ:www.planahead.dk/

+planahead.dk\&hl=da D.18-12-2005.

[21] Lundbyecenteret (Plejehjem). Lundbyesgade 33, 9000 Aalborg, Tlf: 98 16 20 00.

[22] Inc Program Works. Work schedule dot net. http://www.workschedule.net D.18-12-2005.

[23] ScheduleAnywhere. Online employee scheduling software. https://www.

scheduleanywhere.com/site/default.aspx D.18-12-2005.

[24] ScheduleSoft. Personnel scheduling software. http://www.schedulesoft.com/ D.18-12-2005.

[25] Statoil Servicecenter. Østergade 41, 9400 Nørresundby, Tlf: 98 17 38 25.

[26] ASP.NET Sta� Scheduling Software. Sta� scheduling software for shift work. http:

//www.staffscheduling.com/ D.18-12-2005.

[27] Asgaard system. Time tracker. http://asgaardsystem.com D.18-12-2005.

[28] Ungdomshøjskolen Ternen. Ani Kristensen, Studievej 7, 9400 Nørresundby, Tlf:96 32 15 00.

[29] Ronald L. Rivest Cli�ord Stein Thomas H. Cormen, Charles E. Leiserson. Introdutionto Algorithms 2nd ed. The MIT Press, 2003.

[30] Vagtplan. http://www.vagtplan.dk/ D.18-12-2005.

54

http://www.phpicalendar.net/

http://www.planahead.dk/

http://64.233.183.104/search?q=cache:csjkTV-2IVEJ:www.planahead.dk/+planahead.dk&hl=da

http://64.233.183.104/search?q=cache:csjkTV-2IVEJ:www.planahead.dk/+planahead.dk&hl=da

http://www.workschedule.net

https://www.scheduleanywhere.com/site/default.aspx

https://www.scheduleanywhere.com/site/default.aspx

http://www.schedulesoft.com/

http://www.staffscheduling.com/

http://www.staffscheduling.com/

http://asgaardsystem.com

http://www.vagtplan.dk/

BILAG

A

Interview

A.1 For analyse for interview

Det første skridt under vores interview var at lave et kort telefon-interview, der havde til for-mål, at undersøge om interviewet kan bruges på den eksterne kontakt. Følgende indledningblev brugt til den undersøgelse:

For at introducere os selv, brugte vi følgende form, således de virksomheder vi kontaktedevidste hvad telefonopkaldet drejede sig om: �Goddag, jeg er 1. års datalogi studerende påAalborg universitet. Jeg er en del af en studiegruppe på 7 mand, der arbejder med et studi-eprojekt. Vi arbejder med problemerne omkring planlægningen af en vagtplan. Vi har noglehypoteser vi gerne vil have testet. Men for at vi kan det, vil vi gerne aftale et interview. Førstvil gerne stille et par spørgsmål pr. tlf.� Hvis de kontaktede virksomheder udtrykte interessefor at deltage i vores undersøgelse, var næste skridt at etablere, hvilken type vagtplan, virk-somheden bruger med et nyt spørgsmål:

�Hvordan lægger i en vagtplan i jeres virksomhed?�Hvis der ikke lægges en dynamisk vagtplan, f.eks. hvis de brugte en fast vagtplan, valgte

vi ikke at bruge kontakten til videre interview, ved at fortælle den interviewede:

�Vi kan desværre ikke bruges jeres eksempel, da vores interview er målrettet en andensituation.�

Hvis kontakten derimod brugte en dynamisk vagtplan, aftaltes et personligt interview pået senere tidspunkt, hvor både interviewer og den adspurgte havde tid. Interviewet indledtesmed en kort introduktion, hvorefter selve interviewet udførtes.

A.2 Hovedinterview

Dette afsnit indeholder de overordnede spørgsmål som skulle bruges under et personligt in-terview med en kontaktperson. Interviewet startes med en kort indledning om hvem deninterviewede talte med og formålet med det:

�Goddag, vi er datalogi-studerende på Aalborg universitet på 1. år. Vi er i Oktober månedstartet på et studie-projekt, hvor vi arbejder med problemerne i og omkring planlægningenaf en vagtplan. Vi vil gennem dette interview stille en række spørgsmål og det er meningenat de skal teste om de problemstillinger, vi tror der �ndes, er sande, så vi kan udvikle etcomputer system, der kan hjælpe med at lægge en arbejdsplan.�

A.3 Interviewet

Inden vi går i gang med selve interviewet, skal vi have nogle praktiske oplysninger på plads.Spørgsmålene er udformet således, at vi får et godt indtryk af arbejdsgangen omkring det at

55

Bilag A. Interview

lægge en vagtplan i virksomheden og om vi direkte må bruge de informationer vi får ud afvores rapport i interviewet.

1. Hvad er dit fulde navn?

2. Du er den ansvarlige for arbejdsplanlægningen her, er det sandt?

3. Er det i orden med dig, at vi citere dig i vores rapport?

A.3.1 Herefter udføres det egentlige interview med den ads-

purgte

A.3.2 Indledende spørgsmål om arbejdsplanlægning

4. Hvor stor en periode lægger du en arbejdsplan for?

5. Hvor mange medarbejdere lægger du arbejdsplan for ad gangen?

6. Vil du forsøge at beskrive, hvordan du lægger en arbejdsplan? Gerne i detaljer.

7. Hvor lang tid tager det for dig at gennemføre den metode du beskriver?

8. Synes du at det tager lang tid at lægge en arbejdsplan?

9. Tror du det kan gøres hurtigere?

10. Hvor synes du de største problemer opstår, i forbindelse med planlægningen af enarbejdsplan?

A.3.3 Spørgsmål vedrørende det personlige ansvar ved arbejds-

planlægning.

11. Er du glad for at have ansvaret for planlægning af arbejdsplanen? (vil du uddybehvorfor?)

12. Har du selv valgt at tage arbejdsplanlægningen som en af dine opgaver?

13. Tror du dine kollegaer har en anderledes opfattelse af dig, fordi du har ansvaret forarbejdsplanlægningen?

A.3.4 Spørgsmål til fejl.

14. Er der sket fejl som først er blevet opdaget efter medarbejderne har modtaget arbejds-planen?

15. Hvilke fejl opstår oftest i den situation?

16. Hvorfor tror du de fejl forekommer?

56

A.3. INTERVIEWET

A.3.5 Spørgsmål til hvad der opstår af utilfredshed i forbindelse

med arbejdsplanlægning.

17. Opstår der ofte utilfredshed med den endelige arbejdsplan?

18. Har du oplevet situationer, hvor folk har set skævt til dig pga. dit ansvar for arbejds-planlægningen?

A.3.6 Spørgsmål til de mere tekniske ting i forbindelse med

arbejdsplanlægning.

19. I forbindelse med planlægningen er det så en del af din opgave at tage højde for hvormeget afspadsering den enkelte medarbejder har til gode?

20. Har en medarbejder med optjent afspadsering selv mulighed for at vælge tidspunktet,hvor han/hun ønsker at afvikle denne?

21. Er det din opgave at passe det ind i arbejdsplanen?

22. Er det sket at du har måtte give nogle medarbejdere overarbejde, for at få vagplanentil nå sammen?

23. Hvordan fordeler du den byrde blandt medarbejderne?

24. Er det svært for dig at overholde arbejdsmiljøregler og overenskomsten når du plan-lægger?

25. Har du oplevet at du var nødsaget til at gå på kompromis med arbejdsmiljøloven elleroverenskomsten for at få arbejdsplanen til at gå op?

26. Tager du højde for medarbejdere, som har et højt sygefravær? F.eks hvis en medarbejderofte har svært ved at komme op mandag morgen og derfor melder sig syg.

27. Forekommer der vagter i jeres arbejdsplan, hvor der behov for at sætte en a�øser på,der er parat til at træde til hvis der opstår akut sygdom?

28. Hvordan foregår ferieplanlægningen? (beskriv)

29. Hvilke problemer kan der opstå vedrørende ferieplanlægningen?

30. Kan du huske episoder hvor du har haft svært ved at bevare overblikket gennem plan-lægningen af en arbejdsplan?

A.3.7 Spørgsmål til om folks kvali�kationen har betydning.

31. Har folks kvali�kationer betydning på hvordan jeres vagtplan bliver lagt?

32. Er der bestemte opgaver som der kun er få eller en person som kan udføre. Så det erpåkrævet at en bestemt person er på arbejde?

57

Bilag A. Interview

A.3.8 Spørgsmål til om medarbejderne har medbestemmelse i

forbindelse med planlægningen.

33. Er det muligt for medarbejderne at ønske fri på bestemte ugedag/datoer?

34. Er det altid muligt for dig at opfylde deres ønsker?

A.3.9 Gennemgang af vores studieprojekt

Vi har tænkt os at prøve på et udvikle et produkt, der kan lægge en arbejdsplan automatisk.Systemet skal kunne tage højde for regler og love, samt medarbejdernes ønsker, som ferie ogevt. ønske om fast fri dage. Systemet skal være web baseret, så medarbejderen kan logge indpå en hjemmeside og se arbejdsplanen, samt have mulighed for at ønske ferie og fridage. Denansvarlige for arbejdsplanlægningen skal kun holde systemet kørende ved at få computerentil at lægge nye arbejdsplaner.

• Kan du se problemer i forbindelse med vores produkt?

• Hvad har du af idéer til vores produkt?

Vi vil gerne sige tak for hjælpen, ville i være interesserede i at få en kopi af rapporten, nården er færdig i slutningen af december måned?

A.4 Interview med Anni Kristensen

Vi har gennem en telefon samtale aftalt et interview med Anni Kristensen. Hun arbejder påUngdomshøjskole Ternen, som er en institution for unge multihandicappede.

Indlednings spørgsmål

1. Hvad er dit fulde navn?Svar: Anni Kristensen

2. Du er den ansvarlige for arbejdsplanlægningen her, er det sandt?Svar: Ja det er jeg sammen med afdelingslederen. Jeg laver et udkast og går det igennemsammen afdelingslederne hver torsdag.

3. Er det i orden med dig at vi citerer dig i vores rapport?Svar: Ja det er det.

Indledende spørgsmål om arbejdsplanlægning

4. Hvor stor en periode lægger du en arbejdsplan for?Svar: Der lægges for 12 uger ad gangen. Vi har en grundplan som kører 12 uger adgangen.

5. Hvor mange ansatte lægger du vagtplan for ad gangen?Svar: Vi har 3 grupper, men 10 ansatte i hver.Nicholas: Altså 30 ?Svar: Ja ca., så har jeg en gruppe med nattevagter med 5 ansatte.Nicholas: I har altså døgnbemanding?

58

A.4. INTERVIEW MED ANNI KRISTENSEN

Svar: Ja og så har vi en service gruppe som kører af sig selv.Rune: De 10 ansatte i hver gruppe arbejder kun i deres egen gruppe?Svar: Ja de arbejder kun i deres egen gruppe. Der udover har jeg x antal vikarer.Rune: Nattevagterne er det så nogen af de samme som der er i daggrupperne?Svar: Nej de har deres egen natgruppe. Der er 5 fastansatte som nattevagter og envikar til at dække dem.

6. Vil du forsøge at beskrive, hvordan du lægger en arbejdsplan? Gerne i detaljer.Svar: Det er den jeg kalder for grundplanen og den er lagt på forhånd. I den indgår såde ønsker som de ansatte har, som f.eks. at få fri om torsdagen eller hvad det nu er.Den laver vi måske om en gang om året og den kører hele tiden.Nicholas: Dvs. at i fra starten af har fået lagt en vagtplan, hvor alle har sagt hvad fornogle dage de helst vil arbejde?Svar: Så forsøger man at lægge det ind så det passer, men det er umuligt at få allesønsker igennem.

7. Hvor lang tid tager det for dig at gennemføre den metode du beskriver?Svar: Med en 12 ugers plan når jeg lægger den ud?Nicholas: Ja.Svar: Det er afhængig af hvor mange ønsker der ligger på forhånd, men ca. 4 timer medat få den udskrevet og få lavet de ændringer der skal laves i den.

8. Synes du at det tager lang tid at lægge en arbejdsplan?Svar: Det tager et par timer.Nicholas: Så alt i alt kan man sige at du bruger 2 timer om ugen?Svar: Ja ca. men nogen gange er det mere, f.eks. når der er sygdom, så kan det godttage op til 5 timer om ugen.Nicholas: Så hvis man ser på gennemsnittet på et år er det tæt på 3 til 4 timer om året?

Svar: Ja, måske tættest på 4 timer om ugen, hvis du gør det på den måde.Nicholas: Og det vil så kunne gøres hurtigere, jo færre præferencer de ansatte har.Svar: Ja helt sikkert, jo færre ønske de ansatte har, jo mere glat går det for mig. Jeger jo ansat på den måde at jeg har 10 timer om ugen til det. Det vil så sige, at jeg kanarbejde langt frem i tiden. Men ud at de 10 timer skal jeg også indberette lønnen. Detgør jeg hver torsdag. Det tager 2 timer ca.

9. Hvor synes du de største problemer opstår i forbindelse med planlægningen af en vagt-plan?Svar: Det største problem er at få de ansattes ønsker til at passe, fordi der ligger såmange regler inden for arbejds-tids planlægning. Der er især 11 timers reglen, det erden vi slås mest med. 11 timers reglen betyder at der skal være 11 timer mellem hvervagt den ansatte har. Man kan dog lave en aftale med fagforeningen om, at man måovertræde den en gang om ugen. (Men det kan vi ikke få lavet til vores medhjælper.)Så det skal hele tiden passes ind, at hvis en ansat er der til kl. 21 må hun ikke mødefør kl. 8 næste dag. Det er en af de ting der tager ekstremt meget tid.Nicholas: Må i ikke bare ringe til den ansatte og høre om det er iorden?Svar: Nej det må vi ikke. Det er det største problem jeg har. Man skal hele tiden siddehold styr på hvor mange timer den enkelte medarbejder har. En anden ting jeg tit harproblemer med er at et fri døgn er på 35 timer.Nicholas: Så det er de formelle regler der tager mest tid?Svar: Ja de tager meget tid.

59

Bilag A. Interview

Spørgsmål vedrørende det personlige ansvar ved arbejdsplanlægning.

10. Er du glad for at have ansvaret for planlægning af vagtplanen? (Vil du uddybe hvorfor?)Svar: Jeg synes det er spænende. Det er en udfordring. Hvis det ikke var en udfordringtror jeg hurtigt jeg vil blive træt af det, fordi man få en del skældud over at tingeneikke er som folk vil have det.Nicholas: Bliver du ikke sur over det når du har lagt et stor arbejde i det?Svar: Jo det gør jeg, men det sker ikke så tit.

11. Har du selv valgt at tage vagtplanlægningen som en af dine opgaver?Svar: Jeg �k den tilbudt af min forstander.

12. Tror du dine kollegaer har en anderledes opfattelse af dig, fordi du har ansvaret forvagtplanlægningen?Svar: Ja for nogens vedkommende har der været.Nicholas: Er det noget du vil beskrive.Svar: Der er jo det ved det, at jeg er vagtplanlægger og pædagog, så for nogen hardet været lidt svært at skellene mellem om jeg var pædagogen eller planlæggeren oghvornår jeg var det. Men det er efterhånden blevet løst.

Spørgsmål til fejl.

13. Er der sket fejl som først er blevet opdaget efter de ansatte har modtaget vagtplanen?Svar: Det sker men ikke tit.Nicholas: Hvordan opdaterer du det?Svar: Jeg SMS'er rund til folk når jeg sidder med på en vagt, så skal de melde tilbagetil mig på SMS. Derudover har jeg nogen som arbejder her x antal timer, så lægger jegen besked til dem, så kan de komme og sige til mig hvis det ikke passer dem.

14. Hvilke fejl opstår oftest i den situation?Se ovenover.

15. Hvorfor tror du de fejl forekommer?Se ovenover.

Spørgsmål til utilfredshed med arbejdsplanlægning.

16. Opstår der ofte utilfredshed med den endelige arbejdsplan?Svar: Nej det er der ikke. Der er altid nogen brok røve, dem høre man på og lukker detud af der andet øre.

17. Har du oplevet situationer, hvor folk har set skævt til dig pga. dit ansvar for arbejds-planlægningen?Svar: Det er der altid.

Spørgsmål til de mere tekniske ting i forbindelse med arbejdsplanlægning.

18. I forbindelse med planlægningen er det så en del af din opgave at tage højde for hvormeget afspadsering den enkelte medarbejder har til gode?Svar: Ja det er det, men med vores faste vagtplan skulle det gå i 0.

60

A.4. INTERVIEW MED ANNI KRISTENSEN

Nicholas: Må i godt udbetale overarbejde?Svar: Nej det må vi ikke.

19. Har en ansat med optjent afspadsering selv mulighed for at vælge tidspunktet, hvorhan/hun ønsker at afvikle denne?Svar: Fuldstændig, de kan bare komme med ønsker så prøver jeg på at opfylde dem.

20. Er det din opgave at passe det ind i arbejdsplanen?Svar: Ja, jeg skal dog melde tilbage hvis jeg ikke kan få det til at passe ind.

21. Hvordan fordeler du den byrde blandt de ansatte?Svar: Hvis det sker at jeg får en sygemelding onsdag, torsdag og fredag, så går jeg førstind og ser på om der er en af vikarerne der har arbejdsfrie dage, så sætter jeg dem på.Hvis det sker at der ikke er nogen af vikarerne der kan, ringer jeg til min forstander ogspørger om jeg må sætte en af de faste på.

22. Har du oplevet at du var nødsaget til at gå på kompromis med arbejdsmiljøloven elleroverenskomsten for at få arbejdsplanen til at gå op?Svar: Ja det er sket, man kan jo også komme til at tælle forkert.

23. Tager du højde for ansatte, der har et højt sygefravær? F.eks hvis en ansat ofte harsvært ved at komme op mandag morgen og derfor melder sig syg.Svar: Nej det har jeg ikke med i mine planer.

24. Forekommer der vagter i jeres arbejdsplan, hvor der behov for at sætte en a�øser på,der er parat til at træde til hvis der opstår akut sygdom?Svar: Nej det er der ikke. Man har noget der hedder streg dage og noget der hedderBF dage. Streg dag er ikke så dyre som BF dage, så man tager selvfølge dem med stregdag først.

25. Hvordan foregår ferieplanlægningen? (beskriv)Svar: Vi får ferie ønsker ind så tidligt som det nu er muligt, dem sætter vi dem op påen tavle. Så er der ellers op til de enkelte grupper at ordne det. Det er alle de ansatte ogvikarer der kommer med ønsker, men der skal altid være 4 af de fastansatte til rådighed.

26. Hvilke problemer kan der opstå vedrørende ferieplanlægningen?Svar: Normalt løser det sig selv ved at folk �ytter deres ferie en uger den ene vej elleren uge den anden vej.

27. Kan du huske episoder hvor du har haft svært ved at bevare overblikket gennem plan-lægningen af en arbejdsplan?Svar: Hvis der vælter noget med en masse sygdom, så kan det godt være svært. Såsent som en kvarter før i kom, for tiden har vi 7 8 sygemelding, så skal men lige tænkealternativt. På grund af at der er en kvinde arbejdsplads, er der også tit sygemeldingerpga. af børn og graviditet.

Spørgsmål til om folks kvali�kationen har betydning.

28. Har folks kvali�kationer betydning på hvordan jeres vagtplan bliver lagt?Svar: Nej ikke umiddelbart. Vi prøver dog at undgå, at det kun er pædagogstuderendeder er i huset.

29. Er der bestemte opgaver som der kun er få eller en person som kan udføre, så det erpåkrævet at en bestemt person er på arbejde? se ovenover.

61

Bilag A. Interview

Spørgsmål til om de ansatte har medbestemmelse i forbindelse med plan-lægningen.

30. Er det muligt for de ansatte at ønske fri på bestemte ugedag/datoer?Svar: De kan lægge ønsker til mig året rundt. Vi vælger dog at sige at uge 8, 42 ogsommerferien, er børneferie, som vi kalder det. Der har vi nogen datoer hvor vi gernevil have ønskerne inden. Derudover kan de bare komme med deres ønske, men helst såtidligt som muligt.

31. Er det altid muligt for dig at opfylde deres ønsker?Se ovenover

62

BILAG

B

Software undersøgelses bilag

B.1 Intelliroster Lite

Figur B.1: Vagtperiode editor til redigering af en valgt vagtperiode.

63

Bilag B. Software undersøgelses bilag

Figur B.2: Opgave editor til redigering af en speci�k opgave

Figur B.3: Medarbejderkartotek til tilføje og vælge medarbejdere.

64

B.1. INTELLIROSTER LITE

Figur B.4: Et eksempel på en udfyldt vagtplan.

Figur B.5: En publiceret vagtplan i webformat

65


B.2 Time Tracker

Figur B.6: Her ses en vagtplans oversigt

66

B.2. TIME TRACKER

Figur B.7: Medarbejderkartotek til udvælgselse og redigering af medarbejdere

Figur B.8: Erstatnings funktion til vagtbytte, og erstatning ved fx. sygemelding

67


B.3 Work Schedule Dot Net

Figur B.9: Medarbejder kartotek hvor man kan oprette, redigere og slette medarbejdere

68

B.3. WORK SCHEDULE DOT NET

Figur B.10: Medarbejder kartotek til speci�kationer af kvali�kationer (udfyldt)

Figur B.11: Opgave editor til redigering af en speci�k opgave

69


Figur B.12: Overordnet opsætning for �rma

70

B.3. WORK SCHEDULE DOT NET

Figur B.13: Wizard funktion under udførsel

Figur B.14: En udfyldt vagtplan

71


Figur B.15: En publiceret vagtplan

72

BILAG

C

Kommentarer til pseudokode

Dette er kommentarer til hver linie i pseudokoden i afsnit 3.4.6. Bemærk at de enkelte kom-mentarer, som er i selve pseudokoden, ikke er inkluderet her.

Pseudokode 3.01:

02: Start med en tom resistansmatrice.

03: kør alle vagter i vagtplanen igennem.

04: kør alle medarbejdere i virksomheden igennem.

05: Tilføj til resistansmatricen den aktuelle medarbejders resistans overfor den aktuelle vagt.

06:Som udgangspunkt mangler alle vagter stadigt medarbejdere. Derfor er mængden freeshifts lig mængden allshifts.

07: Mens antallet af frie vagter er større end nul så gentag.

08:

09:

10: Den minimale fundne resistans er som udgangspunkt uendelig stor, så den første vil være mindre.

11: Mængden af vagter hvor den minimale resistans forekommer er som udgangspunkt tom.

12: Mængden af medarbejdere som har den minimale resistans er også tom.

13: Antallet af forekomster af den minimale resistans er endnu 0.

14: Kør alle de endnu frie vagter igennem.

15: Kør alle medarbejdere i medarbejderkartoteket igennem.

16: Hvis den aktuelle medarbejders resistans for den aktuelle vagt er mindre end den minimale resistans.

17: Sæt den mindst fundne resistans til den nyligt fundne.

18: Sæt mængden af medarbejdere som har den minimale resistans til en mængde kun indeholdende den aktuelle.

19: Sæt mængden af vagter som har den minimale resistans til en mængde kun indeholdende den aktuelle.

20: Sæt antallet af fundne forekomster af den minimale resistans til 1.

21: Hvis derimod den aktuelle medarbejders resistans for den aktuelle vagt er lig den minimale resistans.

22: Læg 1 til antallet af fundne forekomster af den minimale resistans

23: Læg den aktuelle medarbejder til mængden af medarbejdere som har den minimale resistans.

24: Læg den aktuelle vagt til mængden af vagter som har den minimale resistans.

25:

26: Sæt det maksimale fundne gennemsnit til et uendelig stort negativt tal.

27: Kør et tal i igennem alle tal fra 0 til antallet af forekomster af den minimale resistans.

28: Sæt en tæller til 0.

29: Sæt en sum til 0.

30: Kør alle medarbejdere i virksomheden igennem.

31: Hvis den aktuelle medarbejder ikke er den medarbejder som har den aktuelle forekomst af den minimale

resistans.

32: Læg 1 til tælleren.

33: Læg den aktuelle medarbejders resistans for vagten knyttet til den aktuelle forekomst af den minimale resi-

stans til summen.

34: Sæt middeltallet til summen divideret med antallet.

35: Hvis middeltallet er mindre end det foreløbige maksimale middeltal.

36: Sæt det foreløbige maksimale middeltal til det nye fundene middeltal.

37: Sæt den bedste medarbejder til medarbejderen som hører til den aktuelle forekomst af den minimale resistans.

73

Bilag C. Kommentarer til pseudokode

38: Sæt den bedste vagt til vagten som hører til den aktuelle forekomst af den minimale resistans.

39:

40: Sæt den bedste medarbejder på den vagt, som han er bedst til

41: Hvis den vagt, som den bedste medarbejder er blevet sat på, ikke længere mangler arbejdskraft.

42: Fjern vagten fra mængden af vagter, som mangler arbejdskraft.

43:

44: Kør alle medarbejdere i virksomheden igennem.

45: Opdater alle personers resistans for den vagt.

46:

47: Kør alle de endnu frie vagter igennem.

48: opdatere denne persons resistans overfor alle vagter.

49: returner alle shifts, som nu har tildelte medarbejdere

74

BILAG

D

Classes brugt i prototypen

Vores backend har en en række classes, som står for alle de centrale dele i vores prototype.Classes er en samling af en række funktioner og variabler. Vi har følgende classes i voresprototype.

D.1 Work_schedule

�work_schedule� er en vagtplan, som indeholder er gruppe vagter(�shift�, se D.2). Den harfølgende attributes (Se tabel D.1) og funktioner (Se tabel D.2).

Datatype Attribute beskrivelseshift[] shifts Array af vagter

Tabel D.1: Work_schedule attributter

Funktioner parameter returværdi beskrivelseadd_shift shift shift - tilføjer vagt til array over vagter.show - string (ical) returnere en tekststreng, indeholdende vagtplanen i iCal format

Tabel D.2: Work_schedule funktioner

D.2 shift

shift er en instans af en vagt, den har følgende attributter (tabel D.3) og funktioner (tabel D.4på den følgende side).

Datatype Attributter Beskrivelseint id id der bruges til at henvise til vagtenint start start tidenint end slut tidenint[] requirements array af kravint[] assigned_employees array af medarbejder_id'er som er tildelt vagten

Tabel D.3: Shift attributter

D.3 employee

En medarbejder(employee) har følgende attributter (Se tabel D.6 på næste side) og funktio-ner (Se tabel D.6 på den følgende side) til at sætte dem.

75

Bilag D. Classes brugt i prototypen

Funktions navn parameter returværdi beskrivelseset_id int id - tager et parameter tildeler den til attributen idset_start int start - tager et parameter tildeler den til attributen startset_end int end - tager et parameter tildeler den til attributen endget_id - int returnere attributen idget_start - int returnere attributen startget_end - int returnere attributen endget_duration - int returnere tidsintervalet i timer.

add_requirement int requirement -tager et krav som parameter og tilføjer den tilarray'et af requirements.

get_requirements - int[] returnere array af krav.

assign_employee employee employee employee employeetilføjer en medarbejder id til array'et afmedarbjeder_id'er.

is_free - boolreturnere sandt hvis der er færre folktildelt vagten, end antallet af krav på vagten

get_requirements_needed - int[][]returnere et array af arrays af kvali�kationerder ikke er udfyldt på vagten

get_requirement_combination - int[][]returnere et array af arrays med alle muligekombinationer af requirements

get_needed_combination int[] req_combi int[]laver array over evner der mangler, til engiven kombination af krav

is_assigned int id boolmodtager et medarbejder id som parameterog returnere sandt hvis medarbejderen er tildelt vagten.

Tabel D.4: Shift funktioner

Datatype Attributter Beskrivelseint id id på medarbejderenint salary timelønint workweek antal timer en medarbejder skal have om ugenint assigned timer medarbejderen allerede er blevet tildeltappointment[] appointments array af personlige ønskerint[] skills arrray af evner

string con�ictindeholder en medarbejders eventuelle kon�ikt,mod sidste vagt funktionen get_resistance er blevet kaldt med

Tabel D.5: employee attributter

Funktions navn parameter returværdi beskrivelseset_id int id - tager et parameter tildeler den til attributen id.set_salary int salary - tager et parameter tildeler den til attributen salary.set_workweek int workweek - tager et parameter tildeler den til attributen workweek.get_id - int returnere attributen idget_salary - int returnere attributen salaryget_workweek - int returnere attributen workweek

set_assigned int hours -modtager et parameter og addere parameteret tilattributen assigned

get_assigned - int returnere antallet af allerede tildelte timer

set_appointments int appointment -modtager et personligt ønske som parameter og tiføjerdet til et array

get_appointment_priority int shift_id intreturnere et personligt ønskes prioritet, til en givenvagt's id

set_skills int skill - modtager en evne og tiføjer den til array'et af evner.get_skills - int[] returnere et array over evner.

get_skill_match shift shift intreturnere 10000 hvis der er en kon�ikt, ellers returnereden et tal, der indikere, hvor godt medarbejderen passer til opgaven

has_con�ict - stringser om personen har kon�ikt overfor den vagt,som blev givet som parameter sidste gangget_resistance blev kaldt og sætter attributten til en tom tekststreng

get_con�ict - string returnere en evt. kon�ikt, uden at slette den.

get_resistance shift shift inttager en vagt og returnere medarbejderens resistancetil den givne vagt.

Tabel D.6: employee funktioner

D.4 appointment

Et medarbejder ønske har følgende attributter (Se table D.7 på næste side) og funktioner (Setable D.8 på modstående side).

76

D.4. APPOINTMENT

Datatype Attributter Beskrivelseint id id'et henviser til hvilken vagten ønsket gælder.int start start tidenint end slut tidenint priority prioritet for personlige ønsker

Tabel D.7: appointment attributter

Funktionens navn Parameter Returværdi Beskrivelseset_id int id - tager et parameter tildeler den til attributen id.set_start int start - tager et parameter tildeler den til attributen start.set_end int end - tager et parameter tildeler den til attributen end.set_priority int priority - tager et parameter tildeler den til attributen priority.get_id - int returnere attributen idget_start - int returnere attributen startget_end - int returnere attributen endget_duration - int returnere tidsintervalet i timer.

Tabel D.8: appointment funktioner

77

automatiseret vagtplanlægning - · pdf fileautomatiseret vagtplanlægning p1...

Documents