Automatiseret vagtplanlægning

Transkript

1 Automatiseret vagtplanlægning P1 projekt, Aalborg Universitet Datalogi TEK-NAT Basis Gruppe A224 Rune Wejdling Nicholas Tinggaard Andreas Dalsgaard Kristian Riishøj Niels Husted Michael Møller Jakob Knudsen

2 Det Teknisk-Naturvidenskabelige Basisår Datalogi Strandvejen Telefon Fax Titel: Automatiseret vagtplanlægning Tema: Virkelighed og modeller Projektperiode: P1, efterårssemesteret 2005 Projektgruppe: A224 Deltagere: Jakob Knudsen Andreas Dalsgaard Rune Wejdling Niels Husted Kristian Riishøj Jensen Mikael Møller Nicholas Tinggaard Vejledere: Morten Kühnrich Claus Monrad Spliid Oplagstal: 18 stk Synopsis: I denne rapport følges et projektforløb som omhandler automatiseret vagtplanlægning. Projektarbejdet tager udgangspunkt en række hypoteser omkring problemstillinger vedrørende vagtplanlægning i praksis. Disse hypoteser undersøges nærmere og en algoritme til automatiseret vagtplanlægning udvikles, som et løsningsforslag til problemstillingerne. En vellykket test af vores algoritme, implementeret i PHP, blev udført. Resultatet blev en gyldig vagtplan, der tog højde for kvalikationer, personlige ønsker og løntrin for en gruppe medarbejdere, i en ktiv testcase. Hver medarbejder havde tilknyttet et antal timer, pr. uge. Afvigelsen fra det fast timetal, var i testen gennemsnitlig 10%. Sidetal: 80 Appendiks: 4 kapitler Bilags antal og -art: 1 stk CD-rom Afsluttet den: 19/ Rapportens indhold er frit tilgængeligt, men oentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

3

4 Forord Denne rapport er udarbejdet i forbindelse med P1 projektet løbende fra den 11. oktober til den 19. december Udgangspunktet for dette projekt, er et oplæg fra vejlederen Morten Künrich valgt ud fra en fælles interesse i projektgruppen. Derudover har en del af gruppen desuden stiftet bekendtskab med emnet under P0. Formålet med rapporten er at belyse problematikken omkring vagtplanlægning og automatisering af denne proces. Ud fra dette emne beskrives kompleksiteten af problemet og de problemer, som dette medfører. Problemet undersøges med udgangspunkt i en række lokale aalborgensiske arbejdsmiljøer. Denne undersøgelse og en vurdering af eksisterende software danner baggrund for et løsningsforslag til et nyt stykke software, som kan overtage opgaven omkring koordinering af arbejdsstyrken i en virksomhed og samtidig tage højde for medarbejdernes ønsker. Rune Wejdling runelw@tnb.aau.dk Simon Nicholas Moesby Tinggaard nicholas@tnb.aau.dk Andreas Dalsgaard andrease@tnb.aau.dk Kristian Riishøj krj1985@tnb.aau.dk Niels Husted nielsh@tnb.aau.dk Michael Møller mikaelhm@tnb.aau.dk Jakob Knudsen jakobsk@tnb.aau.dk ii

5 INDHOLD 1 Indledning Forståelse Case brugt i begrebseksemplerne Sammenhængen mellem begreberne Begreber Problemanalyse Metode Hypoteser Hypoteserne Metode til test af hypoteser Interview Interviewmetode Sammendrag af interviews Interview analyse Interview konklusion Metodekritik Software undersøgelse Metode Udvalgte programmer Resultater Software konklusion Metodekritik Teknisk problematik Mulige vagtplanlægning Konklusion Problemformulering Afgrænsning Metodekritik Løsning Metode Kravspecikation Systemet Algoritmen Teori Algoritme typer til vagtplanlægning Algoritmerne Diskussion Udvikling Indledning Metode til udvikling Intuitiv algoritme Resistans

6 Indhold Videreudvikling af intuitiv algoritme Pseudokode Vurdering Vagtplanlægningssystem System beskrivelse Prototype Indledning Præsentation og opbygning PHP icalendar Udvikling af prototype Test af prototypen Konklusion på test Vurdering af prototypen Afsluttende afsnit Konklusion Perspektivering Litteraturliste 53 Bilag 55 A Interview 55 A.1 For analyse for interview A.2 Hovedinterview A.3 Interviewet A.3.1 Herefter udføres det egentlige interview med den adspurgte A.3.2 Indledende spørgsmål om arbejdsplanlægning A.3.3 Spørgsmål vedrørende det personlige ansvar ved arbejdsplanlægning.. 56 A.3.4 Spørgsmål til fejl A.3.5 Spørgsmål til hvad der opstår af utilfredshed i forbindelse med arbejdsplanlægning A.3.6 Spørgsmål til de mere tekniske ting i forbindelse med arbejdsplanlægning. 57 A.3.7 Spørgsmål til om folks kvalikationen har betydning A.3.8 Spørgsmål til om medarbejderne har medbestemmelse i forbindelse med planlægningen A.3.9 Gennemgang af vores studieprojekt A.4 Interview med Anni Kristensen B Software undersøgelses bilag 63 B.1 Intelliroster Lite B.2 Time Tracker B.3 Work Schedule Dot Net C Kommentarer til pseudokode 73 D Classes brugt i prototypen 75 D.1 Work_schedule D.2 shift D.3 employee D.4 appointment

7 KAPITEL 1 Indledning Målet med dette projekt er at udvikle og dokumentere et stykke algoritme, som kan lægge en vagtplan. For at identicere 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-projektkataloget [7]. Fokus er lagt på det besvær, som selve den proces at lægge en vagtplan og koordinere en arbejdsstyrke medfører. I første omgang stiles projektet imod at lette arbejdsbyrden for vagtplanlæggeren, som skal udføre denne proces ved at udvikle et stykke software, der kan overtage arbejdet med denne koordinering. Problematikken om at lægge en vagtplan beskues nærmere i problemanalysen og beskrives i en form, der lægger op til en automatisering af vagtplanlægningsprocessen. 1.1 Forståelse Meningen med forskellige begreber brugt i dette projekt forklares i dette afsnit. Formålet med denne udlægning er at dele vagtplanlægningen op i mindre begreber, som er mere overskuelige. For at kunne forklare begreberne refereres jævnligt til en case beskrevet i afsnit Denne case er holdt så simpel som mulig, så den ikke giver problemer i forbindelse med vagtplanlægningen. Det er svært at forestille sig en virksomhed, der køres på et så simpelt grundlag som i denne case. Den benyttes blot til eksempler på værdier, som de denerede begrebers egenskaber kan have Case brugt i begrebseksemplerne Et meget lille rma har to maskiner til at køre dagligt mellem klokken 8:00 og 16:00. Det kræver to medarbejdere at holde en maskine kørende. Begge disse medarbejdere skal desuden have gennemført et kursus i brug af maskinen. Til at køre de to maskiner har rmaet fem medarbejdere: 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 enkelt fridag. En af medarbejderne ønsker at holde fri om fredagen 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ører processen vagtplanlægning (begreb 3). Under denne proces tages der hensyn til medarbejderes egenskaber (begreb 9) og vagternes opgaver (begreb 7 og begreb 8). Resultatet af dette er en vagtplan, hvor medarbejderne er fordelt over de givne vagter. Denne vagtplan kan kvaliceres som enten værende en god vagtplan (begreb 5) eller en dårlig vagtplan ved hjælp af vagtplansvurderingen (begreb 6). 3

8 Kapitel 1. Indledning Begreber Begreb 1. Der skelnes mellem rmastørrelse. Et lille eller mindre rma er et rma med mindre en tyve medarbejdere og et stort eller større rma er et rma med mere end tyve medarbejdere. Begreb 2. Vagtplanlæggeren er den person, der udfører processen vagtplanlægning (begreb 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ættes igang. Begreb 3. Vagtplanlægning er den process hvori en vagtplanlægger eller et værktøj plotter de tilgængelige eller kvalicerede medarbejdere ind på de vagter, der skal bemandes. Under vagtplanlægningen tages i forskellig grad højde for en række forskellige kriterier. Et eksempel på et kriterium er at en medarbejders (begreb 9) faste timetal skal holdes eller at medarbejdernes ønsker (begreb 10) skal tilgodeses. Vagtplanlægningen kan altså beskrives som en proces, 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 given virksomhed 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 og igen. Hvis der skal ændres i en fast vagtplan, er det højst en ombytning af to vagter eller medarbejdere. For eksempel ved udskiftning i medarbejderstaben. En dynamisk vagtplan derimod er i konstant forandring. Vagter kan ændres, idet opgaverne der skal løses ikke nø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. Den vil dog typisk fremvises i et mere læseligt kalenderformat, hvor vagterne er plottet ind efter deres angivne tidsrum. Egenskab Navn Vagter Værdi Gentagen ugeplan for fabrik 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 forskellige parter, 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 en god vagtplan. Derfor vil en god vagtplan være en vagtplan, der tilfredsstiller så mange som muligt ved at opfylde deres krav og ønsker. En god vagtplan opfylder altså så mange som muligt af de givne kriterier 1. Begreb 6. Vagtplansvurderingen er en proces, hvori en given vagtplan vurderes. En vagtplan kan i større eller mindre grad være en god vagtplan (begreb 5) som tidligere deneret. Begreb 7. En vagt deneres 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 ere sideløbende opgaver. Vagterne har tildelt en mængde medarbejdere (begreb 9), som skal udføre opgaverne i den aktuelle vagt. Mængden af medarbejdere opfylder et krav om mindste antal som er givet ud fra vagtens opgaver og de skal desuden opfylde de krav som stilles af 1 Hvordan dette måles i forbindelse med den udvilede algoritme er nærmere beskrevet i afsnit

9 1.1. FORSTÅELSE disse opgaver. En vagt kan være unik, hvilket vil sige at det angivne tidsrum løber fra et givent tidspunkt til et andet. Vagten kan også være gentagen og for eksempel nde sted hver torsdag 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. En mandagsvagt fra casen i afsnit vil se ud som på tabel 1.2. Egenskab Værdi Navn Maskinvagt Startdag Hver mandag Starttid 8:00 Slutdag Hver mandag Sluttid 16:00 Medarbejdere Klaus, Peter, Anna og Markus Opgaver Passe maskine nummer 1, Passe maskine nummer 2 Tabel 1.2: Eksempel på vagt. Begreb 8. En opgave deneres ud fra de krav den stiller til de medarbejdere, der skal løse den. En opgaves eneste eekt 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 beskriver opgaven der består i at passe en maskine fra casen i afsnit Denne opgave indebærer at passe maskinen i løbet af vagten. Dermed angiver opgaven at to medarbejdere, som har taget kursus i brug af maskinen, skal sættes på en vagt, hvis denne opgave skal løses i løbet af vagten. Egenskab Værdi Navn Passe maskine nummer 1 Krav 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 kvalikationer og de arbejdstider, der passer bedst på vedkommende. En medarbejders tidsrelaterede egenskaber kan deles op i ere kategorier. Alt efter vedkommendes ansættelseskontrakt, skal en vis mængde timer sættes af i løbet af en tidsperiode. Dette kan for eksempel komme til udtryk i et fast timetal hver uge. Derudover kan vedkommede have en række personlige aftaler, som kan komme i konikt med arbejdet, eller vedkommende kan have et ønske om kun at arbejde 4 ud af 5 dage i løbet af en typisk 5-dages arbejdsuge. Vedkommende kan for eksempel fastsætte en foretrukken fridag om fredagen, hvis vedkommende kun skal arbejde 4 ud af 5 hverdage. Både personlige aftaler og ønsker om en fridag kan udtrykkes i et medarbejderønske (begreb 10). En medarbejder har som nævnt også en række kvalikationer. Ikke alle medarbejdere kan påtage sig alle opgaver i en given virksomhed. På tankstationer må man for eksempel ikke lukke alene hvis man endnu ikke er fyldt 18 og i industrien skal man i mange tilfælde uddannes til at bruge de forskellige maskiner. På nogle virksomheder kan forskelligt lønnede medarbejdere løse nogle af de samme opgaver. F. eks. på en tankstation med medarbejdere over og under 18 år, må begge grupper af medarbejdere kan sætte varer på plads og passe disken; men man må stadig ikke lukke alene, hvis man endnu ikke er fyldt 18. En 18-årig er dog betydeligt dyrere end en 16-årig og det kan derfor i mange tilfælde bedre betale sig at have sidstnævnte tildelt en vagt. Lønnen er altså ikke uden betydning, når man skal vælge 5

10 Kapitel 1. Indledning medarbejdere til en given vagt og den er dermed endnu en interessant egenskab for hver enkelt 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ærdi Navn Markus Timer per uge 32 Personlige aftaler Aftale1, Aftale2, Aftale3 Kvalikationer Har taget kursus i brug af maskine og sikkerhedskursus Timelø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 en aftale denne medarbejder har med en tredjepart. Et sådan ønske deneres ud fra et tidsrum og en prioritet. Denne prioritet er et udtryk for hvor høj værdi den aktuelle medarbejder tillægger dette ønske. Altså hvor vigtigt det er for medarbejderen at have fri i forbindelse med det aktuelle ønske i forhold til resten af medarbejderens ønsker. Dette kan for eksempel udtrykkes som lav, medium, eller høj prioritet. En aftale kan for eksempel se ud som i tabel 1.5. Egenskab Værdi Navn Ønske om at få fri på fredag Prioritet Medium Startdag Den 5. januar 2005 Starttid 8:00 Slutdag Den 5. januar 2005 Sluttid 16:00 Tabel 1.5: Eksempel på medarbejderønske. 6

11 KAPITEL 2 Problemanalyse Der er ere indgangsvinkler man kan tage når man skal beskæftige sig med problematikker omkring begrebet vagtplanlægning. Vi har i gruppen valgt at arbejde med emnet som et problemorienteret projektarbejde. Det vil sige, vi vil tage udgangspunkt i et egentligt problem, som skal kunne løses i slutningen af projektet. Det kan gøres enten teoretisk eller i praksis, alt efter hvad vi i projektforløbet har fundet ud af. For at kunne identicere hvilke problemer 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 med emnet. Disse undersøgelser foretages ved at gå ud i den virkelige verden, samle information om emnet og derudfra analysere hvilke metoder der bruges og hvilke problemer folk generelt har, 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 nde en række mulige problemstillinger. Det vil sige, vi vil udarbejde en eller ere hypoteser omkring det at lægge en vagtplan og en automatisering af denne på baggrund af en brainstorm blandt gruppens medlemmer. Derefter vil vi teste om hypoteserne gælder i praksis. Disse undersøgelser kan yderligere bruges til at identicere nogle problematikker, vi ikke har tænkt over i vores indledende undersøgelse. Selve undersøgelsen foregår ved, at vi først vil udføre nogle interviews og undersøge baggrunden for hvilke vagtplanlægningsmetoder, der anvendes i virksomheder, hvilke virksomheder der kan have gavn af automatisk vagtplanlægning og hvilke 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 af problemet at lægge en vagtplan. Efter selve de praktiske undersøgelser, vil vi undersøge den teoretiske 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 af problemet bliver mere tydeligt. Disse praktiske og teoretiske undersøgelser skal munde ud i en overordnet problemformulering, hvor de mulige problemstillinger udledt af undersøgelsen listes op. Problemformuleringen skal kunne lede os mod en afgrænsning, hvor de problematikker vi vælger at arbejde med deneres, således vi kan udarbejde en kravspecikation til vores egen løsning. 2.2 Hypoteser Følgende hypoteser er opstået ved intern diskussion og overvejelser baseret på erfaringer og viden som projektgruppens medlemmer besidder omkring vagtplanlægning og beskriver gruppens 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 man undersøger problemer omkring vagtplanlægning. Hypoteserne nr. 1-8 danner grundlag for, at der er et egentligt problem involveret i vagtplanlægning, mens hypotese nr. 9 danner baggrunden for en software-baseret løsning af problemet. Hypoteserne testes i problemanalysen, 7

12 Kapitel 2. Problemanalyse hvorefter de gyldige eller bekræftede problemstillinger i henhold til en automatisering af en vagtplan opridses i problemformuleringen Hypoteserne Hypotese 1. At lægge en vagtplan er en tidskrævende proces, da det ofte gælder, at jo ere medarbejdere 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 vagtplan og 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ægningens kompleksitet. Det nytter ikke at sætte medarbejdere på en vagt, hvis ikke de har forudsætningerne for at udføre de opgaver, som vagten indebærer. Derfor må en vagtplanlægger have overblik over hvilke jobs hver ansat har mulighed for at varetage, så den mest eektive 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 og ferie ind i vagtplanen på passende tidspunkter, samtidigt med at der bliver taget højde for medarbejdernes ønsker. Af denne og andre årsager kan det blive nødvendigt at give andre 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 at give resten af medarbejderstaben en eller ere timers overarbejde i samme periode, for at vagtplanen 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 ansat til at tage vagten. Hvis vagten er meget vigtig, kan der blive behov for at have en aøser klar i forbindelse med akut sygemeldelse. Inden for nogle brancher er dette en nødvendighed for at opretholde produktion eller service. Et eksempel kunne være special uddannede arbejdere på en fabrik eller kokkene på en restaurant. Hypotese 5. Det kan være svært at overskue, hvem der har arbejdet hvor meget. Det er derfor også en betydelig opgave at holde styr på dette under vagtplanlægning, især hvis man skal sikre sig at arbejdsmiljøregler [5] er overholdt og at overenskomsten overholdes. Derfor betragtes medarbejdernes ønsker om eksible arbejdstider, som en af de mere uoverskuelige dele af vagtplanlægningen. Det kan være svært at tage højde for ønsker om fridage, når man manuelt skal lægge en vagtplan. Hypotese 6. På grund af kompleksiteten af vagtplanlægningen øges antallet af menneskelige fejl og personlige problemer kan opstå, fordi medarbejdere kan føle sig tilsidesat i en dårligt opstillet vagtplan. Ved manuel planlægning kan det være svært at overskue og tage højde for medarbejdernes ø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 vagtplanlæggere, da det kræver en del tid og overblik, samt det kan være meget problematisk at få det hele til at gå op. Rollen som planlægger kan i nogle tilfælde resultere i at en medarbejder bliver opfattet som en boss-type, hvilket kan medføre sociale konikter. Hermed menes, at der kan forekomme utilfredse medarbejdere, som følge af vagtplanens udformning og dermed medføre et negativt syn på vagtplanlæggeren. Hypotese 8. Mange af de samme faktorer, som er væsentlige under vagtplanlægningen i store virksomheder, er også gældende i små virksomheder. Derfor kan problemerne indenfor 8

13 2.3. METODE TIL TEST AF HYPOTESER rimelighedens grænser skaleres op eller ned fra et givent udgangspunkt. Man kan altså tillade sig at fokusere på mindre virksomheder. Ved at fremstille en løsning ud fra de problemer, der opleves hos små virksomheder, vil man også komme relativt tæt på en løsning, som egner sig til 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 i erhvervslivet, ikke har erfaring med, at der bliver brugt software til vagtplanlægningen. Hvis brugbare værktøjer var tilgængelige, ville det medføre ere virksomheder benyttede sig af disse. 2.3 Metode til test af hypoteser For at undersøge om hypoteserne gjorde sig gældende i erhvervslivet, kontaktede vi nogle virksomheder, som vi mente lagde dynamiske vagtplaner. Gennem interview af vagtplanlæggerne i disse virksomheder, undersøgte vi hvilke problemer, de stødte på, når de skulle lægge en 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, hvorvidt 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 eksisterende software udviklet til at løse problemet. Formålet med en softwareundersøgelse var at teste om de løsninger, der allerede fandtes, var brugbare og derudover at kunne udlede funktionaliteter eller overvejelser til en løsning, som kunne løse problemet omkring vagtplanlægnings automatisering. Formålet var at undersøge hypotese Interview Interviewet har til formål at teste vores hypoteser. Målet med interviewene er at teste og sandsynliggøre vores hypoteser, således vi bedre kan gøre det klart hvilke problematikker der er at tage fat på, med henblik på hvordan vagtplanlægning foregår i praksis. Derudover vil der kunne dannes et indtryk for hvilken type vagtplanlægning, der bruges i forskellige typer virksomheder Interviewmetode Da hypotese 8 påstår at problemerne kan ndes både i små og store virksomheder rettes interviewet mod 3 små og 3 store virksomheder. Derudover har vi fundet 2 backup virksomheder, i tilfælde af at en af de udvalgte virksomheder ikke vil medvirke i rapporten eller vi føler vi mangler konkrete resultater. Som indledende interviewmålgruppe har vi besluttet os for at beskæftige os med virksomheder, der har mange unge ansatte, da disse virksomheder med 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 arbejde netop der, vælges der som udgangspunkt 3 tankstationer (mindre virksomheder). Derudover har vi besluttet os for at gennemføre interview med 3 større virksomheder, navnlig to plejehjem og en ungdomshøjskole. Som backup interviewkontakter har vi yderligere valgt to tankstationer. Interviewet er bygget op i mindre grupper af spørgsmål, der er dannet ud fra hypoteserne. De este af hypoteserne drejer sig om problemstillingerne bag planlægningen af en 9

14 Kapitel 2. Problemanalyse dynamisk vagtplan, derfor er interviewet rettet mod den ansvarlige for vagtplanlægning, eftersom vagtplanlæggeren er den, der ved mest om emnet. Interviewene skal foregå ved et personligt interview på virksomheden, da det giver den bedste indsigt i virksomhedens metode til vagtplanlægning. Vi starter med at ringe til de eksterne kontakter, for at undersøge om vi kan bruge virksomheden som interview kontakt og eventuelt derefter aftale et interview møde. Under opkaldet stilles der nogle indledende spørgsmål. Dette gøres for at afklare, om virksomheden bruger en dynamisk vagtplan. Hvis ikke virksomhederne anvender dynamiske vagtplaner, mener vi ikke at det er hensigtsmæssigt at gennemføre interviewene, dels fordi vores interview spørgsmål er rettet mod virksomheder, der anvender dynamisk vagtplaner, men også for ikke at 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 brugbare svar. Formålet med nogle af spørgsmålene er at få svar, der er fyldestgørende udsagn, som vi siden kan bruge i forbindelse med argumentering for hypotesernes gyldighed. I andre tilfælde bør spørgsmålene give kortere ja-nej svar, der i højere grad gør det muligt at sammenligne forskellige interviewede personers udsagn. Interview spørgsmålene kan ses i bilag A på side Sammendrag af interviews Shell Service A/S, Aalborg Hos Shell Service A/S [3] har bestyreren af tankstationen lagt hele ansvaret for vagtplanen over på medarbejderne. Medarbejderne har valgt at ordne deres vagtplan således, at de en gang om måneden afholder et vagtplanlægningsmøde, hvor medarbejderne kan melde ud hvilke 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 ønsker at bytte en vagt, er det personens eget ansvar. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan. Statoil A/S, Aalborg Ø Bestyreren af Statoil A/S [4] står selv for at lægge medarbejdernes vagtplan. Der bruges en fast vagtplan som udgangspunkt, hvor der siden bliver lavet ændringer fra gang til gang. Hvis der er en af medarbejderne, der gerne vil have byttet en af sine vagter, står han/hun selv for det. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan. Statoil Servicecenter, Nørresundby Statoil Servicecenter [25] i Nørresundby har inddelt sine medarbejdere i 2 grupper. Der er 3 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 har medarbejderne en fast vagtplan, der forløber over 2 uger. Deltidsmedarbejderne mødes alle til et personalemøde, hvor de så selv kan melde ud hvilke vagter de ønsker at få. Det er den samme model, som tidligere beskrevet hos Shell Service A/S, Aalborg. Hvis der er en medarbejder der vil have byttet en af sine vagter, står han/hun selv for det. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan. 10

15 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. De deltidsansatte 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 siden taget op til det næste personalemøde. For at et ønske kan gennemføres, er det nødvendigt at bytte fast med en anden medarbejder for at undgå at lave en helt ny vagtplan. Hvis en medarbejder ønsker at bytte en enkelt vagt, står han/hun selv for det. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan. Ungdomshøjskolen Ternen, Nørresundby Vi interviewede vagtplanlæggeren på Ungdomshøjskolen Ternen [ 28] i Nørresundby. På Ternen bliver der én gang om året lavet en grundplan, hvor der bliver tager højde for medarbejdernes ønsker. Hver tolvte uge bliver grundplanen revideret, hvis der for eksempel er kommet nogle nye ønsker fra en af medarbejderne eller på grund af længere sygdomsforløb hos en medarbejder. Der bruges, set over en periode på et år, i gennemsnit ca. 4 timer om ugen på at opdatere vagtplanen for 30 medarbejdere samt en gruppe vikarer. Det vil sige, at der på et år bruges ca. 108 timer på opdatering at deres vagtplan. Ud fra dette mener vi at vores hypotese 1 er blevet underbygget. Medarbejderne på Ternen har meget stor frihed til at komme med ønsker til vagtplanen, som for eksempel ønsker til fridage/afspadsering. Når medarbejderen kommer med sit ønske, prøver vagtplanlæggeren i første omgang at tildele en af de andre fastansatte vagten. Hvis det ikke lykkedes, prøver vedkommende at sætte en af deres vikarer på vagten. Hvis det heller ikke kan lade sig gøre, bliver de nødt til at sige til den medarbejder, der gerne vil have fri, at det ikke kan lade sig gøre. Hvis det er en af de andre medarbejdere, 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ægges en vagtplan. Alt dette gør opgaven meget uoverskuelig, hvilket dermed underbygger hypotese 3 samt hypotese 5. Et andet problem for vagtplanlæggeren er, at de andre medarbejdere har svært ved at nde ud af, hvornår vedkommende er vagtplanlægger og hvornår denne er en normal medarbejder. Hvis det sker at folk er utilfredse med en vagtplan, vil de i nogle tilfælde være utilfredse med vagtplanlæggeren. Dette underbygger hypotese 7. En direkte transskribering af interviewet fra Ungdomshøjskolen Ternen kan læses i appendix A.4 på side 58. Lundbyecenteret (Plejehjem) Medarbejderne på Lundbycenteret [21] har en fast vagtplan. En af medarbejderne har ansvaret for at holde den opdateret. Den ansvarlige har et stykke software fra KMD 1, der hjælper med at overholde de administrative regler. Programmet melder om fejl, hvis der byttes to vagter, som overskrider de regler, der er opstillet. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan. 1 Kommunedata, 11

16 Kapitel 2. Problemanalyse Kærby Hvilehjem (Plejehjem) Kærby Hvilehjem [10] bruger det samme system fra kommunen som Lundbyecenteret. En medarbejder stod for det administrative arbejde med at lægge en vagtplan og validere den med KMDs system således at der ikke blev overskredet regler og vagtplanen stadig blev lagt inden for virksomhedens rammer. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan. 7-eleven, i Aalborg 7-eleven [1] på Vesterbro kører med en fast vagtplan. Bestyreren vi interviewede sagde, at han mente det var den bedste form for vagtplan, da det var lettest for ham at styre. Han behøvede ikke at bruge særligt meget tid på vagtplanen og undgik besværet med at lægge den mere end én gang. Derudover mente han, at en anden gavnlig eekt ved at en medarbejder konsekvent havde de samme vagter, var at vedkommende blev fortrolig med vagten. Hermed mentes, at medarbejderen efter nogen tid vidste, hvordan vedkommende skulle prioritere de enkelte opgaver, selv når der var meget travlt. Bestyreren udtrykte mangel på et program, der kunne sammenholde medarbejdernes indberettede timetal med den lagte vagtplan. Vi gennemførte ikke selve det personlige interview, da virksomheden ikke anvender en dynamisk vagtplan Interview analyse Foranalysen til interviewene viste, at det egentligt kun er én ud af de 8 adspurgte virksomheder, der anvendte en dynamisk vagtplan. Da vores hypoteser i høj grad drejer sig om problemstillingerne ved lægning af en dynamisk vagtplan, mente vi ikke det var relevant at gennemfø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ægning af en vagtplan. Formålet med disse metoder, er at undgå mange af problemerne ved en dynamisk vagtplan. Under vores foranalyse opdagede vi også, at det ofte ikke var den vagtplansansvarlige, der havde et problem. Med en fast vagtplan, der ikke tager meget hensyn til medarbejderne, undgås de planlægningsmæssige problemer. For eksempel yttes ansvaret for at bytte vagter i tilfælde af sygdom over på medarbejderne og på den måde undgås der ekstra 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 ny vagtplan efter hver endt plan uden sammenhæng med den forrige. Her har en medarbejder mulighed for at ønske om fri fra arbejdet. Denne metode er bekostelig og besværlig, da det tager lang tid og opgaven er svær at overskue. Derfor har et ertal af de eksterne kontakter valgt ikke at anvende denne løsning. Ved denne metode vil der forekomme bytning af vagter mellem 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 bestemt periode, for eksempel 3 uger. Efter de 3 uger starter planen forfra. Dette betyder, at en plan kun skal lægges en enkelt gang for en virksomhed og ved udskiftning af en medarbejder overtager den nye medarbejder bare den udskiftedes vagter. Problemet med denne metode er, at den skaber en masse bytteri mellem medarbejderne. En positiv ting ved denne metode 12

17 2.4. INTERVIEW er, at medarbejderen får faste arbejdsdage og vedkommende bliver tryg ved vagten. Det er for nogle medarbejdere også betryggende at have den samme vagt, da man altid skal arbejde på det samme tidspunkt. Metode 3. Inden en vagtplan er udløbet, mødes medarbejderne til et vagtplanlægningsmøde eller personalemøde og melder ud hvilke vagter de ønsker at tage. Med det menes at medarbejderne fortæller hvilke vagter de ønsker at tage, men metoden kræver at alle medarbejderne mødes for eksempel en gang om måneden. Denne metode kan reducere ombytningen af vagter indbyrdes mellem medarbejdere kraftigt, men man undgår det ikke helt, da der altid kan opstå andre planer deres private kalendre Interview konklusion Ud fra foranalysen til interviewene kan vi konkludere, at ertallet af de adspurgte anvender en anden 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 meget hensyn til medarbejdernes ønsker. Metode 3 tager hensyn til medarbejdernes ønsker, det er dog 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 har ansvaret for at få opfyldt sine ønsker til vagtplanen. Vores interview med vagtplanlæggeren hos Ungdomshøjskolen Ternen kan, udover at begrunde at der ndes virksomheder med dynamisk vagtplanlægning, bruges til at sandsynliggøre nogle af vores hypoteser. Vi har gennem interviewet fundet ud af, at det at lægge en vagtplan reelt er et tidskrævende arbejde, især for en større virksomhed og det underbygger at vores påstand i hypotese 1 er en sandsynlig antagelse, idet den undersøgte virksomhed i eksemplet har en medarbejderstab på 30 personer. Hypotese 3 bliver underbygget i kraft af, at vagtplanlæggeren i interviewet i særlig grad skal tage hensyn til de enkeltes ønsker om fridage og de enkeltes ferieønsker, når en ny vagtplan lægges. Ved at medarbejderne indberetter deres ferie i forvejen, er det muligt at tage hensyn til disse ønsker i en vis grad, således at vagtplanen bliver så god som mulig, for så mange som muligt og stadig hænger sammen med den kvalitet af service der skal ydes. I kraft af at vagtplanlæggeren i interviewet bruger mange timer på at validere at det samlede timetal per medarbejder passer og at der, dog sjældent, kan forekomme fejl. Dette underbygger at hypotese 5 har en vis indydelse i praksis, på hvordan en vagtplan lægges. Ved at der skal tages hensyn til det maksimale antal timer en medarbejder må have i henhold til arbejdspladsens overenskomst og andre gældende regler, som for eksempel elleve timers reglen 2, må kompleksiteten ved at lægge en god vagtplan også blive større. Hypotese 4 bliver delvist begrundet, idet virksomheden i interviewet egentligt har vikarer på standby, der kan varetage opgaver i tilfælde af langvarig sygdom eller anden fravær. Der er dog ikke behov for aøsere i tilfælde af akut sygdom, eftersom det er muligt for andre medarbejdere at dække disse vagter inden for et vist tidsrum. Om den hypotese er sandsynlig er diskutabelt, eftersom der 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ægningsansvarlige til en vis grad har følt, at medarbejderne har haft et andet forhold til dem i kraft af vagtplanlæggerens rolle, (udover at være medarbejder i virksomheden). Derudover betragtes opgaven, hvis den ikke var så kompleks og udfordrende, som en ikke ønskelig opgave hvis ikke disse forhold gjaldt. Det skal siges at disse problemer er løselige i virksomheden og 2 Der skal være elleve timer mellem en vagts sluttidspunkt og den næste vagts starttidspunkt for en given medarbejder [2] 13

18 Kapitel 2. Problemanalyse ikke nødvendigvis skaber de problemer, der opridses i hypotese 6 og 7 eftersom de sidenhen er løst i vores interview eksempel. Da det beskrives i interviewet, at der altid skal være en fastansat til stede i virksomheden på samme tid som en pædagogstuderende, kan man sandsynliggøre hypotese 2. Selvom de pædagogstuderende kan have de samme faglige færdigheder som de fastansatte, kan de ikke yde den samme kvalitet af service og er ikke så velbefarne inden for arbejdsområdet. Derfor er det nødvendigt at have medarbejdere tilstede på arbejdspladsen, der kan vejlede de studerende. Denne egenskab, vejledning, må betragtes som en medarbejder egenskab, som vagtplanen lægges efter. Det vil sige at i vores interview gælder det, at vagterne på vagtplanen kræver egenskaben uddannet medarbejder som kun nogle af medarbejderne besidder Metodekritik Designet af interviewet burde være anderledes. Interviewets målgruppe var meget lille, da det kun rettede sig imod virksomheder, hvor de anvendte en dynamisk vagtplan. Interviewet burde være designet, så det kunne bruges hos de adspurgte virksomheder, hvor de anvendte andre former for vagtplanlægning. På den måde kunne vi have fået mere indsigt i hvordan andre løser planlægnings problemet. Inden udvælgelsen af de eksterne kontakter, burde vi i større grad have overvejet hvilke virksomheder, der har brug for en dynamisk vagtplan. Vi kunne have tænkt os frem til, at i virksomheder med et omskifteligt service niveau, er der i højere grad behov for en vagtplan, der tilpasses det aktuelle service niveau. Det kunne være i restaurationsbranchen, der er en meget sæson-præget branche. På en tankstation kan man lettere klare sig med en statisk vagtplan, da der er et mere fast service niveau. Eftersom vi kun k ét brugbart interview ud af undersøgelsen med hensyn til dynamisk vagtplan, burde vi have startet en ny runde med et revideret interviewdesign, der kunne bruges uanset hvilken vagtplanstype virksomhederne arbejder med. På den måde kunne vi muligvis have nået frem til 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 omhandlende manglen på brugbare hjælpemidler til at lægge en vagtplan. Ved den samme undersøgelse, vil vi have mulighed for at identicere eventuelle problemstillinger ved software løsninger, vi selv skal tage stilling til i vores programudvikling Metode For at lave vores analyse, skal der først ndes nogle programmer, som vi kan teste. Dette gør vi ved at benytte søgetjenesten Google 3. Derefter ndes programmerne enten direkte på programudbydernes hjemmeside eller ved hjælp af sider med linksamlinger 4 til virksomheder, der udbyder software til vagtplanlægning. De fundne programmer blev undersøgt efter nedenstå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: 3 der søges på strengene workscheduling software og vagtplanlægning software. 4 Som f.eks. denne [9] 14

19 2.5. SOFTWARE UNDERSØGELSE Har programmerne automatiske funktioner? Hermed forstås om programmet har funktioner, der kan automatisere udlægningen og vedligeholdelsen 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 specik faggruppe, eller holder det sig inden for vores 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 udvalgt tre til videre test. Herefter har vi ud fra vores hypoteser og vores egen opfattelse af software anvendelighed, opstillet nogle af de kriterier programmerne undersøges for: 15 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 forskellige funktioner 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 brugerade? Er programmet lineært opbygget i konstruktionen af en vagtplan (Det vil sige, skal man angive regler der skal 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 specikke hjælp man har brug for 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 ferie eller evt. sygdom. Informerer programmet vagtplanlæggeren om konikter? Kan programmet advare vagtplanlæggeren, hvis de opstillede regler brydes? Det vil sige regler om maksimal/minimal timer per uge eller andre administrative regler man kunne komme ud for.

20 Kapitel 2. Problemanalyse Muligheder for at dokumentere medarbejdere i systemet? Hvilke muligheder har programmet for at opstille kriterier og attributter for medarbejdere 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 se hvem der skal arbejde de forskellige dage, mens man sidder og ligger vagtplanen og 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 kan læ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 gennemgåede kriterier Udvalgte programmer Vi har ud fra vores søgen og afprøvning af software fundet frem til følgende programmer som vi vil undersøge: IntelliRoster Lite [12], Time Tracker [27] og Work Schedule Dot Net [22] Resultater IntelliRoster Lite IntelliRoster Lite er et engelsksproget Windows program til vagtplanlægning fra rmaet Intellicate [12] og det tilbyder en række værktøjer til hjælp ved vagtplanlægning. Vi har hentet en trial version af IntelliRoster Lite, som vi vil afprøve og undersøge ud fra de i metodeafsnittet denerede punkter. Hvordan er programmet at bruge? IntelliRoster Lite er baseret på et grundlæggende Windows grak interface af typen der også ndes i for eksempel Microsoft Oce, hvilket gør det nemt at omstille sig fra at bruge Microsoft Oce programmer til at anvende IntelliRoster Lite (se gur 2.1 på modstående side). IntelliRoster Lite er født med en hjælpesektion, hvor der kan søges efter forskellige nøgleord. Den er forholdsvis simpel at bruge, hvis man har erfaring med at anvende andre Windows 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 medieler, der gennemgår programmets grundlæggende funktionaliteter skridt for skridt. Programmet virker 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 inkluderer 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 inkluderer en række værktøjer; et medarbejderkartotek (se gur B.3 på side 64) til at holde overblik over medarbejdere/medarbejder kompetencer, en opgave manager til denition af arbejdsopgaver (se gur B.2 på side 64) og en brugerade til opsætning af arbejdstimer og tidspunkter for den enkelte arbejder (se gur B.1 på side 63). Derudover kan man få vist hvor mange timer hver enkelt arbejder er blevet sat til at arbejde inden for en given periode. Således kan man 16

21 2.5. SOFTWARE UNDERSØGELSE Figur 2.1: IntelliRoster Lite brugeraden. 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 medarbejdere på en vagtplan på en simpel måde, da alle vagterne manuelt skal byttes rundt. Det er ikke er noget interaktivt system, så medarbejdere kan heller ikke ansøge om vagtskifte eller fridage over Internettet, men må gøre det over telefon eller anden kontaktform til vagtplanlæggeren. Programmet informerer ikke brugeren om eventuelle konikter, der kunne opstå i vagtplanen i henhold til regler, der skal overholdes. Det er ikke muligt at denere regler, som skal overholdes og det er ikke muligt at denere avancerede medarbejder attributter. Det vil sige, man får ikke nogen fejlmeddelelse, hvis man sætter en medarbejder til at udføre et stykke arbejde, han ikke har kompetencer til at udføre. IntelliRoster Lite indeholder funktioner til at printe vagtplanen på papir med forskellige opsætninger, samt mulighed for at publicere vagtplanerne på en HTML side genereret af programmet (se gur B.5 på side 65). På den genererede webside er det muligt at se vagtplaner i 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 server man 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 stadig en stor arbejdsbyrde til vagtplanlæggeren, når der skal lægges vagtplan, da programmet ikke har automatiske funktioner. Programmets fordel er, at den kan eksportere dokumenternes 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 arbejde og gør det muligt at opdatere vagtplanerne hurtigt efter udformning, således at de der skal bruge 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 en trial version af Time Tracker, som vi vil undersøge ud fra de foruddenerede punkter. 17

22 Kapitel 2. Problemanalyse Hvordan er programmerne at bruge? Time Tracker tager tid at lære at bruge, men der er tutorial videoer på Agard Systems hjemmeside, som kan hjælpe en bruger til hurtigt at komme igang med programmet. Programmet har en hjælpefunktion, man kan benytte til at søge efter emner, man vil vide mere om. Programmet er udstyret med et stort antal features, hvilke ikke alle er placeret hensigtsmæssigt på brugeraden. Programmet er opbygget, så man kan have vagtplanen for en uge eller mere opstillet på skærmen (se gur B.6 på side 66 og gur 2.2). Figur 2.2: Time Trackers opbygning af vagtplanen Hvilke funktioner har programmet? Time Tracker kan ikke automatisere vagtplanlægningsprocessen, men kan opstille en skabelon med antal dage og vagter man har brug for på en uge, hvorefter programmet kan repetere vagter for de pågældende dage i fremtidige ugeskemaer. Det medføre at man kan bruge Time Tracker til at lægge en fast vagtplan for ere uger frem i tiden. Derudover kan man lave en ugentlig 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. Bruges denne 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 medarbejder bytter 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, kan man bruge en Replace funktion for at ombytte vagten med en anden medarbejder. Disse funktioner er en hjælp til at vedligeholde sin vagtplan, i tilfælde man har megen ombytning eller sygdom på arbejdspladsen. 18

23 2.5. SOFTWARE UNDERSØGELSE Når man opretter medarbejdere (se gur B.7 på side 67) i systemet, har man mulighed for at denere en del variabler, der gør programmet i stand til at informere vagtplanlæggeren om eventuelle konikter med medarbejderes ønsker eller timeantal. Det vil sige, hvis en medarbejder er sat til at skulle have 37,5 timer i ugen, vil programmet informere vagtplanlæggeren om fejlen, hvis han overskrider dette under planlægningsprocessen. Programmet har ikke mulighed 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 Vores vurdering ud fra foregående punkter? Time Tracker virker til at være et godt hjælpemiddel til vagtplanlægningen. Programmet er ikke i stand til at automatisere vagtplanlægnings processen, men har forskellige features, der gør vedligeholdelse af en forud deneret vagtplan lettere. For eksempel er programmet anvendeligt, hvis man har en virksomhed der benytter ugentlig rotation i vagtplanen. Timetrackers mangel på evne til at eksportere til HTML er ikke optimal, eftersom al kommunikation med medarbejderne stadig vil foregå via. papirform, telefoni og almindelig samtale i stedet for at kommunikere over internettet. Dette betyder at vagtplanlæggeren stadig har en stor opgave bare 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 en hjemmeside 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å som bestyrer eller medarbejder med rma ID, bruger ID og password. 19

24 Kapitel 2. Problemanalyse Hvordan er programmerne at bruge? Work Schedule Dot Net er et program, der er gjort tilgængelig gennem brugerens Internet browser og kræver ingen installation på brugerens computer. Brugeraden ligner en almindelig hjemmeside. Der bruges standard webformatering til at vise vagtplanen i form af knapper som brugeren kan trykke på, for at se den næste eller foregående uge (se gur 2.4). Det vil sige, programmet har mulighed for at vise vagtplanen for de efterfølgende uger, men den kan kun 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 demonstrations videoer af de forskellige features, som programmet indeholder og instruktion i hvordan man bruger dem. Derudover er der indbygget en wizard, der kan guide brugeren igennem en vagtplanlægnings opgave, således der tages fordel af de indbyggede muligheder i programmet. På grund af de indbyggede hjælpefunktioner, er det reelt muligt at lægge en vagtplan efter kun at have brugt programmet i et par timer. Figur 2.4: Work Schedule Dot Net brugeraden Hvilke funktioner har programmet? Programmet har forskellige funktioner, der kan hjælpe en vagtplanlægger til at bevare overblikket over planen. Den inkluderer også en funktion til at automatisere en vagtplan i henhold til en række fordenerede love, som vagtplanlæggeren kan bestemme variabler til. Automatiserings systemet virker ved at vagtplanlæggeren vælger blandt en række kriterier, der ndes i programmet og denerer en mængde forhold inden for disse, som programmet skal tage højde for, når der skal plottes medarbejdere på en vagtplan (se gur B.12 på side 70). For at oprette en automatisk udførsel af en vagtplan, kræver det at vagtplanlæggeren 20

25 2.5. SOFTWARE UNDERSØGELSE først angiver hvilke love der skal overholdes, opretter grupper til medarbejdere og opretter hvilke opgaver der skal varetages (se gur B.11 på side 69). Derefter skal man bruge programmets medarbejderkartotek til at oprette medarbejdere i systemet, som programmet skal lægge vagtplan for. I medarbejderkartoteket er det muligt at angive personlig information om den enkelte medarbejder. Det er f.eks. muligt at angive, hvor mange timer de højst må arbejde på en uge og hvor mange timer de højst må arbejde på en dag (se gur B.9 på side 68 og gur B.10 på 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 sin vagtplan (se gur B.13 på side 71). Efter at have udført "wizard"funktionen, forelægges en vagtplan der er mere eller mindre brugbar alt efter hvor godt vagtplanlæggeren har deneret sine regler og andre muligheder som systemet tilbyder. Efter den automatiske udførsel er det muligt for en vagtplanlægger at redigere i vagtplanen manuelt efter behag. Skulle der opstå konikter mellem de denerede regler og denerede medarbejder egenskaber under den manuelle 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 for at eksportere til Excel regneark, PDF formater og til HTML. For at medarbejderen kan se vagtplanen online, er det nødvendigt for denne at logge sig på rmaets oprettede system hos Program Works inc. Som primær funktion kan man se sin egen vagtplan, andres vagtplan hvis vagtplanlæ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 har arbejdet med henblik på løn beregning, forespørge om fritid og se generel information om hvem 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 denere hvilke muligheder medarbejderne har, når de logger på deres personlige side. Vores vurdering ud fra foregående punkter? Work Schedule Dot Net er en avanceret løsning, da den har mange funktionaliteter, hvilket hjælper når der skal lægges en kompliceret vagtplan. Det tager en del tid at tilpasse systemet ens virksomhed, da der er mange kriterier, der skal indtastes, før man kan gå i gang med at lægge en vagtplan. Programmets største ulempe er at de eksporterede vagtplaner er meget grask rodet, hvilket resultere i tabt overblik Software konklusion Efter at have afsluttet software undersøgelsen, kan vi se det generelt tager relativt lang tid at lære at bruge vagtplanlægningsprogrammer eektivt. 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 opfylder hvert deres formål. Intelliroster Lite har ingen automatiske funktioner til udførsel af opgaver ved vagtplanlægning. Det bruges som et værktøj til at danne overblik over de vagtplaner der manuelt lægges. Time Tracker har de este af de funktioner, der også ndes i IntelliRoster Lite og et par automatiske funktioner, som gør det lettere for brugeren at organisere og lægge vagtplaner. 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 ved Work Shedule Dot Net er, det kan bruges af mange forskellige typer rmaer, da det kan lægge eektive planer for både store og små virksomheder. Work Schedule Dot Net kræver 21

26 Kapitel 2. Problemanalyse lidt mere arbejde at sætte sig ind i at bruge. Både fra vagtplanlæggerens og medarbejdernes side, eftersom der er en del funktioner at stifte bekendtskab med. Ved sammenligning af publiceringsmulighederne i de tre programmer er Work Schedule Dot Net det mest avancerede, da det kan eksportere vagtplaner konstrueret med programmet til HTML ler, der automatisk lægges op på en uafhængig server tilsluttet internettet. Således kan medarbejdere se deres vagtplan hvor som helst de har adgang til en computer med internetadgang. IntelliRoster Lite har en lignende funktion, men kræver at vagtplanlæggeren selv 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 andre testede programmer, da opsætning og aæsning af vagtplanerne foregår via internettet. Dette opvejes 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 bruge Work Schedule Dot Net som en model, når vi skal overveje hvilke funktionaliteter vi vil inkludere i vores produkt. Under udarbejdelsen af software testen, har vi fundet frem til at vi ikke kan bekræfte hypotese nr 9, da der ndes brugbart software. Vores analyse har dog givet et indtryk af at sværhedsgraden i af brugen af et produkt stiger med antallet af funktioner, som det fremgår af gur 2.5. Funktioner IR TT WSDN Eksport til HTML Vise en hel uge på skærmen Tutorial Videoer Rotations planlægning Automatiseret vagtbytte Oplistning ledige medarbejdere Eksport af timelister Konikt 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) 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 til test ud fra dets automatiske funktioner. Employee Scheduling Software [11] Programmet kan ikke testes, derfor er det ikke valgt til test Intellicate - Employee Scheduling and Rostering Software Solutions [12] Programmet er udvalgt til test på grund af det simple interface og mulighed for at generere en hjemmeside ud fra programmets outputdata. Online employee scheduling software [23] Programmet kunne kun afprøves hvis man bestilte en demo fremvisning af programmet med en medarbejder fra virksomheden, som skulle bookes. Vi valgte ikke programmet til test på grund af dette. 22

27 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] Programmet blev ikke udvalgt til videre test, da brugeraden var meget svær at bruge ScheduleSoft Personnel Scheduling Software [24] Det var ikke muligt at downloade en test af programmet ASP.NET Sta Scheduling Software for Shift Work [26] Vi valgte ikke at teste dette program, da det ikke var muligt at se hvordan det så ud inden vi afprøvede det og det kræ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, der udbyder løsninger til vagtplanlægning Efter at have udført vores test kan vi konkludere, at software gennemgangen ikke er repræ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 til vores kriterier til programmer, da undersøgelsen ellers ville være meget omfattende. Det kan diskuteres, om det er den rette fremgangsmåde at søge på internettet efter rmaer, der laver sådanne løsninger, eller om vi skulle have overvejet alternative metoder. Man kunne forestille sig, at det var muligt at tage direkte kontakt til virksomheder der arbejder med emnet såsom KMD. Det er dog tvivlsomt om det ville give noget positivt resultat, eftersom vi ikke kender andre virksomheder. Programmerne er blevet testet på brugerniveau efter hvad vi nder er brugervenligt. Det vil sige at vi har set på hvordan programmerne er at bruge og hvad de kan for folk med en vis erfaring med at bruge og vænne sig til nye programmer. Vi har ikke haft mulighed for at se hvordan programmerne er konstrueret (koden af programmerne), da de 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 vagtplanlægningssystem, idet vi kunne hente inspiration fra de andre programmer til udarbejdelse af vores eget. Programmerne, der er testet, har været engelsksprogede, hvilket skyldes mangel på 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 den også skal kunne vurdere vagtplanens kvalitet. Hvis ikke et vagtplansprogram kan vurdere kvaliteten af en vagtplan, kan man ende med et produkt, der kan lægge en vagtplan; men det er ikke sikkert, at resultatet er brugbart. For at belyse denne problematik, er det nødvendigt at se på den matematiske teoretiske baggrund, for omfanget af problemet, hvis løsningen også skal kunne nde en god vagtplan Mulige vagtplanlægning Ved automatisk vagtplanlæggning, hvor målet er at nde den bedste vagtplan, er der et problem. Dette skyldes at processen skal arbejde med at vælge den bedst mulige vagtplan ud fra mange kombinationer af mulige vagter. 23

28 Kapitel 2. Problemanalyse I følgende afsnit arbejdes med hvorfor, der opstår mange kombinationer, når antallet af medarbejdere 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åsom regler der skal overholdes fra planlæggerens side. Der vil være endnu ere beregninger, hvis man efter at have fundet alle vagtplaner, skal validere om det er gyldige kombinationer, i henhold til reglerne. F.eks. hvis der skal undersøges om medarbejderen har været på arbejde inden for 11 timer før en vagt eller andre regler. M: A, B V: A A A V: A A B V: A B A V: A B B V: B A A V: B A B V: B B A V: B B B Figur 2.6: Her er et lille eksempel på de kombinationer der vil være med 2 medarbejdere og 3 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 medarbejdere til V antal vagter, kan der udledes at der vil være: M V antal mulige vagtplaner. Det vil sige, at man kunne nde alle mulige vagtplaner (mængden af M V ) og derefter undersøge hvilken vagtplan, der er den bedste (et eksempel ses på gur 2.6) Konklusion For at lave den bedst mulige vagtplan automatisk kræver det, at man nder alle mulige vagtplaner, før man kan nde den bedste vagtplan. I dette afsnit er det vist, at der vil være mange vagtkombinationer, så snart antallet af vagter og mængden af medarbejdere stiger og man samtidigt skal nde alle mulige kombinationer af vagtplaner. Derfor vil det ikke være hensigtsmæ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 en vagtplan 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 i relation 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ående problemstillinger, som gør sig gældende under processen, at lægge en god vagtplan. En proces der 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 andre medarbejderes fravær forårsaget af f.eks. sygdom eller barsel. Problem 2. Medarbejderne får ikke indydelse på deres arbejdsuge i en sådan grad, at de kan bestemme over hvilke vagter de får og dermed kan tillade sig at lave personlige aftaler 24

29 2.8. AFGRÆNSNING i et tidsrum, hvor de potentielt kunne komme på en vagt. Denne begrænsning sker fordi vagtplanlæggeren ikke kan forventes, at lægge en ny vagtplan relativt ofte. Uoverskueligheden og 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, er det nødvendigt at kunne bytte vagter mellem medarbejdere manuelt. Problem 4. Medarbejdere kan have et negativt forhold til en vagtplanlægger i kraft af, at denne er ansvarlig for at lægge virksomhedens vagtplan. Derudover har vi, ud fra betragtninger gjort under vores test og undersøgelse af eksisterende 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 denere hvilke regler et automatisk 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 tildele medarbejdere i vagtplanen overarbejde og i hvor kraftig grad at elleve timers reglen skal overholdes. Problem 6. Det er nødvendigt at specicere hvilke krav vagterne i vagtplanen stiller til medarbejderne. Ligeledes er det nødvendigt at kunne udvælge den medarbejder, som er bedst kvaliceret til en given vagt. Problem 7. Hvis en virksomhed benytter sig af en dynamisk vagtplan, bør vagtplanlæggeren have lettilgængelige muligheder for at publicere disse, gerne således at medarbejdere selv kan holde sig opdateret med eventuelle ændringer i planen. Problem 8. Man bør tage højde for brugervenlighed, eftersom programmerne bliver sværere at 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 hurtigere er 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 det endelige 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år man vil udvikle et værktøj til automatisk udarbejdelse af en vagtplan. I vores projekt har vi valgt nogle emner ud fra vores problemformulering, som vi vil arbejde videre med i projektet med henblik på udarbejdelse af en algoritme til automatiseret vagtplanlægning. Det drejer sig 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

30 Kapitel 2. Problemanalyse de grundlæggende funktionaliteter i vores algoritme, men kun udvikle den del der skal til for at 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ægge en automatisk vagtplan. Derfor er de sekundære problemer afhængige af om det primære løses. Desuden er nogle problemer afhængige af menneskelige elementer uden tilknytning til algoritmen og kan derfor ikke denitivt løses. Det vil sige: Vi kan ikke vide om medarbejdere får et bedre forhold til deres vagtplanlægger hvis vagtplanen lægges automatisk og tager højde for deres ønsker og derfor vælger vi ikke at arbejde videre med dette emne. Vi vil heller ikke inkludere en funktion til at bytte vagter mellem to medarbejdere i det endelige produkt, da det centrale problem reelt er at lægge en vagtplan automatisk. Vi vil ikke decideret undersøge hvordan man laver en brugervenlig brugerade eller udarbejde letanvendelige publiceringsmuligheder, da det centrale problem er 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 i gruppen at opsætte en række hypoteser, som vi fandt frem til ud fra vores eget indblik i problemet. For at nde ud af om vores hypoteser havde grundlag i hvordan problemet gribes an 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 det ikke 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 dynamisk vagtplan, hvilket vore interviews egentligt krævede for at være relevante at udføre. Et andet problem med metoden var, at de personer vi interviewede, ikke rigtigt brugte noget software til hjælp med vagtplanlægningen i udbredt grad. Dette gjorde det svært at få nogle brugbare ideer til vagtplanlægnings applikationen. En metode vi kunne have valgt i stedet for, kunne være at starte med at lave en prototype af vores program ud fra de hypoteser eller påstande vi havde opsat, som vi mente måtte gælde om vagtplanlægning. På den måde ville man kunne præsentere et mere eller mindre fungerende program for de vagtplanlæggeren, vi ville interviewe. Derved kunne vi måske bedre modtage og bruge feedback fra de vagtplanlæggere vi interviewede til at forbedre vores program og tilføje de funktioner til programmet, som de eventuelt kunne mene manglede for at opfylde deres behov. Denne metode kunne måske også have givet nogle brugbare informationer fra de vagtplanlæggere, der ellers bruger en fast vagtplan. Kontekstuelt kunne vi, i stedet for indledende at se om applikationen kunne anvendes, vurdere hvilken eekt programmet 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 kontekstuelt ud fra projektet. Problemet med denne metode er at den ville være rimelig risikabel, da der kunne bruges en masse tid på at lave et program ud fra nogle ideer, vi kun selv har siddet med. Dette kunne resultere i at vi ville arbejde med et problem, uden at have undersøgt om problemet overhovedet eksisterede. I værste tilfælde kunne det ende med et program, der ikke var praktisk anvendeligt og derfor ikke reelt kunne bruges i praksis. Udbyttet rent fagligt ville være, at vi ville få programmeret en masse funktioner i vore valgte programmerings sprog, men vi ville muligvis ikke være blevet klogere på selve problemet omkring automatisk vagtplanlægning. 26

31 KAPITEL 3 Løsning For at præsentere vores løsning er kapitlet opdelt i tre afsnit. Det indledende afsnit 3.3 omhandler baggrunden for den algoritme, vi vil udarbejde. Her beskrives forskellige typer af algoritmer, der er brugt som inspiration til udvikling af vores egen algoritme og hvilken funktion den skal opfylde. Afsnit 3.4 omhandler selve udviklingen af algoritmen, de metoder der er brugt til udarbejdelsen af den endelige algoritme og den endelige algoritme som skal benyttes 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ærdigede teorier, omkring det at automatisk kunne lægge en vagtplan ved hjælp af forskellige algoritmer. Disse bruges til at vise, at der er andre metoder til at løse den overordnede problematik omkring automatisk vagtplanlægning, men bruges også som grundlag for nogle overvejelser, der bør gøres, når vores egen algoritme skal udvikles. Således kan der klart deneres, hvad den skal kunne og hvordan man kan opstille algoritmen. Derefter beskrives selve 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 vil vi beskrive det overordnede system, som vi mener algoritmen kræver for at kunne bruges til automatisk 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 sidst udarbejde en konklusion, der opsummerer resultater fra testen og erfaringer gjort omkring det at lægge en automatisk vagtplan. 3.2 Kravspecikation I henhold til de udvalgte problemstillinger i problemafgrænsningen har vi udarbejdet to kravspecikationer. De to nedenstående kravspecikationer er henholdsvis for det samlede system, der kan håndtere en vagtplanlægning systemet og algoritmen der udfører selve vagtplanlægningen Systemet 27 Systemet skal kunne sørge for at vagtplanlægningen bliver udført ud fra data fra medarbejdere og den vagtplanlæggeren. Det skal være muligt at lægge en vagtplan, uden den ansvarlige skal godkende de ansattes inputs. Derved lettes vagtplanlæggerens arbejde. Efter en vagtplan er lagt, skal systemet kunne lave en rapport, der beskriver timetal pr. medarbejder og hvor god vagtplanen er. Samtidig skal den belyse evt. konikter i vagtplanen.

32 Kapitel 3. Løsning 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 i vagtplanen. Algoritmen skal kunne tage timetal per medarbejder i betragtning og sammenholde dem 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 utilfredsheden med den lagte vagtplan og derved minimere nødvendigheden for vagtbytte mellem medarbejderne. 3.3 Teori Dette afsnit har til formål at afdække baggrunden for den algoritme, vi vil udarbejde og hvilken baggrund vi har haft at overveje vores algoritmes udformning ud fra. Baggrundsmaterialet, der danner grundlag for vores idéer, drejer sig om 2 rapporter; den ene kilde er en teknisk gennemgang af problemet Sta Scheduling: A Simple Approach that Worked [ 14] og den anden en Ph.D. afhandling Local Search Techniques for Scheduling Problems: Algorithms and Software Tools [6]. Endvidere har vi læst om de enkelte algoritme typer i det åbne web-leksikon Wikipedia 1. 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 typisk bruger 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 teoretiske grundlag og inspirationen vi har arbejdet ud fra i udviklingen af vores egen algoritme Algoritme typer til vagtplanlægning Grundlæggende ndes der 3 forskellige typer algoritmer til brug ved vagtplanlægning. Disse tre typer har hvert deres mål og bruger input til at generere vidt forskelligt output. Gyldig algoritme Denne algoritme type vil kun lægge en vagtplan, hvis det er muligt ud fra de givne omstæ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 den løber tør for ledige medarbejdere, inden alle vagter er besat. Kun hvis den kan lægge en gyldig vagtplan, giver den et gyldigt output. Vagtplanens gyldighed bliver beregnet ud fra de parametre, den er bygget til at tage høje for. Dette kunne evt. være, at en medarbejder ikke må blive sat 2 gange på den samme vagt. Måske-gyldig algoritme Denne algoritme type vil altid give et output, også selvom det ikke er gyldigt. Den lægger en vagtplan, men kontrollerer ikke gyldigheden undervejs. På den måde vil den ikke nå en dead-end som gyldig-algoritmen, men kun returnere det den er kommet frem til. Fordelen ved denne algoritme er, at den kan være hurtigere til at generere output, eftersom den ikke skal kontrollere gyldigheden af dette undervejs. Dette kræver til gengæld, at man selv kontrollerer gyldigheden af vagtplanen efterfølgende. 1 et åbent leksikon på internettet hvor alle har adgang til at bidrage med information. 28

33 3.3. TEORI Forbedringsalgoritme Denne algoritmetype kræver, at man har lagt en vagtplan på forhånd. Den vil derefter forsøge at forbedre den lagte vagtplan ud fra de kriterier og krav der er opsat i algoritmen, ved at ytte rundt på medarbejderne i vagtplanen. Den kan altså ikke, som de andre algoritmetyper, selvstændigt lave en vagtplan, men derimod nde ud af om den vagtplan, den har fået som input, kan optimeres i henhold til de krav, som den er lavet til at forbedre imod. Input til denne algoritme kan godt være en ugyldig vagtplan Algoritmerne Ved hjælp af de 2 førnævnte kilder har vi fundet de forskellige algoritmer, der passer ind under vores 3 algoritme typer. I vores beskrivelse af algoritmerne taget udgangspunkt i, at de kun skal anvendes til vagtplanlægning. Derfor har vi undersøgt de metoder, de bruger til at 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 udfylde vagter, der kræver at der er 2 personer på arbejde, som samtidigt har nogle høje krav til kvalikationer 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 kan betjene en speciel maskine, begge er tilstede for at vagtens opgaver kan løses og derfor skal de begge sættes på vagten. At en medarbejder er mest hensigtsmæssig til en vagt, kan være deneret på forskellige måder. F.eks. hvis en medarbejder kun kan én ting, som alle andre ansatte også kan, men er billigere end de andre, vil han være den mest hensigtsmæssige medarbejder til en vagt. Da algoritmen validerer vagtplanen efterhånden som den kommer frem, er denne algoritme det nærmeste man kommer en gyldig algoritme type, som beskrevet i 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 medarbejder ikke har arbejdet de sidste 11 timer, ikke er sat på vagten i forvejen eller at personen kan løse de opgaver vagten kræver. Dette bliver algoritmen ved med, indtil den er løbet tør for vagter at udfylde. Derved løser algoritmen det grundliggende problem, der kan ligge i at overholde arbejdspladsens regler og sørge for at vagten bliver taget af en medarbejder med de rette kompetencer. Denne metode kan løbe ind i nogle dead-ends, da den potentielt bruger 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 ligger algoritmen 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 algoritmen nævnt tidligere. Den afviger ved, at den tilfældigt vælger en vagt, hvorpå den sætter den mest hensigtsmæ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 ikke højde for at medarbejdere med unikke evner, muligvis er blevet sat på vagter med opgaver, 29

34 Kapitel 3. Løsning der kan løses af medarbejdere med færre kompetencer og at specialisterne derfor mangler til specielle vagter senere i planlægningen. Man kan dog argumentere for, at den i så fald blot vil tildele de medarbejdere overarbejde og derfor stadig lægge en gyldig vagtplan. Dette kan dog skabe konikt 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 kravene til vagten. Den gemmer ændringen og arbejder videre ud fra den opdaterede udgave af vagtplanen. Den tager ikke højde for prisen på en ændring, kun kravene til vagten. Denne algoritme kræver en vagtplan, der er lagt på forhånd som input og er derfor en forbedringsalgoritme. Hill-Climbing Iterative Improvement Denne metode fungere på samme måde som Iterative Improvement, ud over at den kun gemmer en ændring i vagtplanen hvis ændringen giver en besparelse. Ellers arbejder den videre med den uændret udgave af vagtplanen. Taboo search Denne metode tager en dyr medarbejder (En medarbejder der passer dårligt til de givne kriterier) og gennemgår alle vagter tildelt til denne medarbejder, for at se om der kan ndes en billigere medarbejder til disse vagter. Der bliver så lavet en taboo-liste med vagter, der er æ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 kan optimeres i henhold til. Denne algoritme passer ind under forbedringsalgoritme typen og kræver en vagtplan som input. Simulated Annealing Princippet ved denne algoritme er, at den muligvis accepterer ændringer, der ikke forbedrer vagtplanen med en forhåbning om, at ændringerne i længden bliver et bedre alternativ, ved at foretage ere ændringer. Chancen for at ændringer i vagtplanen bliver godtaget falder, som tiden går, da sandsynligheden for at nde bedre alternativer bliver mindre, jo ere vagter der byttes. For eksempel hvis en given ændring har forskellen i omkostninger, så vil den nye ændring i vagtplanen blive accepteret med det samme, såfremt ændringen resulterer i en billigere vagtplan end den forrige mulighed. Betyder ændringen derimod en stigning i, vil ændringen kun blive accepteret med sandsynligheden e /T. T er et udgangspunktsparameter, og bruges som et mål til at vurdere ændringer ud fra Diskussion Ud fra forsøgene udført af Jackson og Havens [14] har det vist sig, at det ikke kan betale sig at forbedre en allerede lagt vagtplan med en algoritme, da besparelsen efter lang tids beregninger er minimal. Til gengæld har det vist sig, at Greedy Constructive algoritmen giver nogle gode resultater med kort beregningstid. Derfor vil det være hensigtsmæssigt, at tage principperne i Greedy Constructive algoritmen i betragtning når vi skal overveje, hvordan vi vil designe vores egen algoritme. 30

35 3.4. UDVIKLING 3.4 Udvikling 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 kravspecikationen i afsnit 3.2 på side 27. Vi har i afsnit 3.3 på side 28 beskrevet forskellige algoritmer, der kan anvendes til lægning af vagtplaner og andre til forbedring vagtplaner. Vi vælger at udvikle en algoritme, der kan lægge en færdig vagtplan uden efterfølgende at forbedre på den. Baggrunden for at vi ikke vil gøre vores algoritme i stand til at forbedre på den vagtplan der lægges ndes i også teoriafsnittet. Der fandt vi ud af, at det var begrænset, hvor store forbedringerne var, i forhold til hvor kompliceret det var og hvor lang tid det tog at regne ud Metode til udvikling For at udvikle en algoritme, der automatisk kan lægge en vagtplan, vil vi starte med at se på opgaven, som den løses manuelt. Disse tanker og metoder vil vi føre over i en intuitiv algoritme. Vi vil udføre en skrivebordstest af den intuitive algoritme, som foregår ved manuelt at lægge en vagtplan ved hjælp af algoritmen. Vi begynder med at opstille et eksempel med en simpel vagtplan og få medarbejdere som vi kan overskue. Dette eksempel bruger vi til at teste 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, revideres algoritmen efter behov. Når den intuitive algoritme har nået et brugbart stadie, vil vi omskrive den til pseudo-kode til videre bearbejdelse Intuitiv algoritme For at kunne udvikle en algoritme, må vi først se på, problemet kan løses uden nogen baggrund for at kunne løse opgaven. Vi tager udgangspunkt i en lille case med 3 medarbejdere og 8 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 deres ansættelses kontrakt og hvor meget de skal have i løn. Vi påtager os nu vagtplanlæggerens opgave; at samle puslespillet af vagter og medarbejdere, så vagtplanen bliver billigst mulig og tilgodeser så mange af medarbejdernes ønsker som muligt. Vi prøver derefter at danne os et overblik over, hvor godt hver enkelt medarbejder passer til de enkelte vagter. Vi formoder, at det 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 medarbejdere på hvor det er mest oplagt, ud fra de andre faktorer der spiller ind. Sådan vil vi gøre indtil alle vagter er tildelt en medarbejder. Det viser sig at vi gentagne gange bruger den samme metode, så vi kan stille en simpel intuitiv algoritme op som vist i gur 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

36 Kapitel 3. Løsning Resistans For at kunne bestemme hvilken medarbejder man skal sætte på en given vagt under vagtplanlægningen, er det nødvendigt at kunne måle medarbejdernes egnethed. Målet har i vores tilfælde været at komme med et enkelt tal, som kan måle egnetheden for en given medarbejder til en given vagt. Vi udtrykker i det efterfølgende denne værdi som resistans. Resistansen kan opfattes som en værdi for en medarbejders egnethed til en given vagt. En høj resistans er et udtryk for at medarbejderen ikke passer særligt godt til vagten, hvor en lav resistans er et udtryk for hvor egnet vedkommende er. For at udtrykke resistansen i et tal skal de forskellige faktorer, som vurderes, når resistansen skal bestemmes, alle kunne udtrykkes i et tal der enten har negativ eller positiv indydelse på resistansen. Hvis en medarbejder for eksempel har en kvalikation, som skal bruges i en given vagt, falder vedkommendes resistans for denne vagt. Hvis vedkommende har et ønske om at holde fri på den aktuelle dag, stiger resistansen. En tredje faktor kunne være timelønnen. Hvis to medarbejdere får forskellig timeløn, men er begge kvalicerede til en given vagt, vil en arbejdsgiver være interesseret i den billigste løsning. Dette kan tages med i beregningen ved at lægge timelønnen til resistansens værdi. Hvis man begrænser sig til disse faktorer, vil resistansen altså kunne udtrykkes som i formel 3.1. Bemærk her at kvalikationer og ønsker er udtrykt som 1 eller 0 (altså en binær værdi). Det vil sige: enten har medarbejderen en krævet kvalikation, eller også har vedkommende det ikke; enten har vedkommende et ønske om at holde fri den dag, eller også har vedkommende det ikke. Således har en medarbejder med en timeløn på 120 kr. i timen, der har de nødvendige kvalikationer til opgaven og et ønske om at holde fri den aktuelle dag, en resistans på 120. Timeløn i kr. Kvalikation i 1/0 + Ønske om fri i 1/0 = = 120Resistans (3.1) Som det fremgår af formel 3.1, kan der hurtigt blive et stort spring mellem værdien af de forskellige faktorer. Kvalikationer og timeløn betyder uendeligt lidt i forhold til timelønnen. Derfor skaleres de op, så de er sammenlignelige. For at kunne udtrykke de enkelte faktorer prioriteret i forhold til hinanden, multipliceres der med en faktorskalar. Størrelsen af faktorskalaren kan variere i forskellige situationer, da faktorer som timeløn og kvalikationer ikke altid er lige store i forskellige systemer. De sammenlignelige faktorer er heller ikke lige vigtige for vagtplanlægningen. Man kunne for eksempel forestille sig, at der i en virksomhed vægtes højere, at en medarbejder er kvaliceret til at udføre opgaverne, der kræves for vagten, end at medarbejderens personlige aftaler overholdes. Hver faktor skal altså multipliceres med en systemskalar givet fra planlæggerens side. Hvis man ikke vil tillade at personlige ønsker og andre vigtige faktorer kommer til at betyde at de kvalicerede personer holder fri og en ukvaliceret kommer på en vagt, kan systemskalaren på kvalikationsfaktoren sættes til et meget højt tal. Denne faktor vil dermed lave så stort et skel mellem de kvalicerede og de ukvalicerede medarbejdere at man ikke vil kunne komme ud for, at en ukvaliceret medarbejder opnår lavere resistans end en kvaliceret. Se desuden eksemplet senere i dette afsnit (Se 3.3 på modstående side En negativ systemfaktor 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 vist på formel 3.2. n resistans = systemskalar i faktorskalar i faktorværdi i, hvor n er antallet af faktorer. i=1 (3.2) 32

37 3.4. UDVIKLING Eksempel Resistansens plads i en vagtplanlægningsproces kan være som i følgende eksempel, hvor vi vil 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 bruge den. Han er ansat fordi han er nyttig andetsteds i rmaet, men hans timeløn er mindre end de to andre medarbejderes på grund af hans manglende kvalikationer. Åge har ønsket at holde 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 kvalikationsfaktoren 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 besparelser af lønudgifter højere end glade medarbejdere, som får deres ønsker opfyldt. Da det anses som vigtigere at få folk på vagten, der er kvalicerede til at passe maskinen, er systemskalaren sat til , hvilket må anses, som en meget stor negativ værdi i forhold til niveauet af de andre systemskalarer. For at nde et bud på de bedste valg af en medarbejder af de tre ansatte i eksemplet, regnes deres resistanser for vagten ud som på formel 3.3. Selvom Peter ville være det billigste valg i kraft af hans lave timeløn, redder hans manglende kvalikationer ham fra vagten. John og Åge er begge kvalicerede 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 deres forskellige timeløn; men fordi Åge har ønsket at få fri, bliver hans resistans højere end Johns og John bliver derfor sat på vagten. resistans Peter = systemskalar timeløn faktorskalar timeløn faktorværdi timeløn + systemskalar kvalikation faktorskalar kvalikation faktorværdi kvalikation + systemskalar ønske faktorskalar ønske faktorværdi ønske = ( 10000) = 900 resistans John = systemskalar timeløn faktorskalar timeløn faktorværdi timeløn + systemskalar kvalikation faktorskalar kvalikation faktorværdi kvalikation + systemskalar ønske faktorskalar ønske faktorværdi ønske = ( 10000) = ( 8900) resistans Åge = systemskalar timeløn faktorskalar timeløn faktorværdi timeløn (3.3) + systemskalar kvalikation faktorskalar kvalikation faktorværdi kvalikation + systemskalar ønske faktorskalar ønske faktorværdi ønske = ( 10000) = ( 8000) 33

38 Kapitel 3. Løsning Videreudvikling af intuitiv algoritme Vi har nu et matematisk udtryk for, hvor egnet en medarbejder er til en specik vagt. Det kan vi bruge til at videreudvikle vores intuitive algoritme, således den ser ud som på gur 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. Under afprøvningen opdager vi, at der kan forekomme to resistanser, der er lige store og derfor må vi udvælge dem begge i punkt 2 i gur 3.2. Efter punkt 2 har vi nu mulighed for at have ere medarbejdere, der alle har den mindste resistans. Vi vælger den medarbejder, hvor gennemsnittet af de andre medarbejderes resistans er størst. Det gør vi, fordi vi mener, det er her, der kan spares mest resistans. Hvis vi valgte en anden vagt, ville vi senere skulle sætte en 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 intuitive algoritme, der ses på gur Find alle medarbejders resistanser til alle ledige vagter. 2. Find mængden af medarbejdere med de mindste resistanser og mængden af tilhørende vagter. 3. Udtræk den vagt hvor gennemsnittet af de resterende medarbejderes resistanser er stø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å det der sker under første punkt i algoritmen. Vi systematiserer alle resistanser i en matrice som vist i gur 3.4 på modstående side. Vi har sat vagterne vandret og medarbejderne lodret i matricen. 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 i a 3,10. Vi ændrer linie 1 i den intuitive algoritme til at bygge resistans-matricen. Dette er en må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 for de resterende vagter. Derfor kan vi, i stedet for at bygge hele resistans-matricen, nøjes med at opdatere den enkelte medarbejders resistanser for de resterende vagter i matricen. Det er dog stadig nødvendigt at nde alle resistanser først i algoritmen. Vi kan derfor ytte den del ud af løkken og tilføje at efter en vagt er tildelt, skal medarbejderens resistans opdateres. 34

39 3.4. UDVIKLING A = a 1,1 a 1,2... a 1,j a 2,1 a 2,2... a 2,j... a i,1 a i,2... a i,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ørende vagter 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å, at denne algoritme ikke kan bruges til at nde den bedste vagtplan. Hvis vi skulle bruge denne algoritme til at nde den bedste vagtplan, måtte vi, når vi vælger den bedste med arbejder til en vagt, først undersøge alle de mulige vagtplaner, der kan lægges med medarbejderen på en given vagt. Det skal gøres for alle medarbejdere til alle vagter. Hvis vi tager en vagtplan med 3 vagter og 2 medarbejdere, vil der til hver vagt være to mulige ansatte; det er = 2 3 mulige kombinationer af disse. For hver af dem, er der 3! mulige vagtplaner. Dvs. at der i alt skal lægges 2 3 3! = 48 vagtplaner. Dette vil give m v v! vagtplaner, der skal lægges, når resistans matricen udfyldes og yderligere skal de vericeres og vurderes. Betragt i stedet det tilfælde, hvor man har 6 medarbejdere og 36 vagter; det vil give regnestykket !, hvilket resulterer i et meget stort antal vagtplaner (ca. 3, ). Disse udregninger bliver meget komplekse. I algoritmen vælger vi i stedet at vurdere lokalt på medarbejderen i forhold til den enkelte vagt. På den måde undgår vi at nde alle disse vagtplaner og dernæst vericere dem. Derfor er vores udviklede algoritme kun beregnet til at nde en god vagtplan og ikke den bedste Pseudokode Den intuitive algoritme i gur 3.5 er omskrivet til psuedokode, som er en eksplicit beskrivelse af algoritmen. Den intuitive algoritme kan derimod fortolkes på ere måder og kan ikke vurderes tidsmæssigt. Pseudokode har også fordelen, at det er uafhængigt af programmingssprog og platforme. Man kan udtrykke sin algoritme uden på forhånd at have bestemt hvilket sprog den skal programmeres i. Planlægningsalgoritmen er udtrykt i pseudokodeblokken MAKE- 35

40 Kapitel 3. Løsning PLAN, 2 på modstående side. Ud fra den intuitive beskrivelse fra på gur 3.5 er en mere eksplicit algoritme opstillet i pseudokoden i psudoblok 2 på næste side. Kommentarer som kan hjælpe forståelsen er vedlagt i appendix C på side 73. GETRESISTANCE funktionen er afhængig af hvilke faktorer der vurderes i en implementation. Et eksempel bygget op omkring eksemplet brugt i forklaringen af resistans i afsnit på side 32 kan være bygget op som følgende pseudokodeblok hvor de forskellige systemscalars og factorscalars er konstante udtryk for de forskellige skalarer og employeedata og shiftdata er 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[kvalication] 04: factorvalue[kvalication] 1 05: else 06: factorvalue[kvalication] 0 07: resistance resistance + systemscalars[kvalication] factorscalars[kvalication] factorvalue[kvalication] 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 Vurdering Algoritmen har nu fået sin endelige form. Vi vil i dette afsnit vurdere algoritmens køretid samt lave en vurdering i forhold til de krav, vi stillede i kravspecikationen 3.2 på side 27. Derudover vil vi gennemgå algoritmen, for at undersøge om den altid vil stoppe, eller om den løber uendeligt. Vi vil også kategorisere vores algoritme i forhold til, om den er gyldig eller må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 den udviklede algoritme fra afsnit på forrige side, opstilles O-notation 2 med henblik på en implementering i PHP. Idet den tid det tager at tildele en værdi til en variabel, sammenligne og udføre almindelig aritmetik 3 ikke afhænger af mængden af data som algoritmen fodres med, anses disse operationers tidsforbrug for at være konstante. Det skal her nævnes, at hver gang en løkke på formen: for each A in B do... udføres, sættes variablen A til en ny del af B og at i en lø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øretiden for en linie er produktet af den kontante tid c i, som det tager at køre linien en gang og antallet af gange linien bliver kørt i løbet af algoritmens kørsel. Den højest mulige køretid kan derfor antages at være summen af alle produkter af hver linies køretid og det maksimale antal gange linien kan blive kørt. 2 Læs: Store O notation. Emnet er nærmere beskrevet i Introduction to Algorithms [29] 3 Almindelig aritmetik forstås her som addition, subtraktion, multiplikation og division. 36

41 3.4. UDVIKLING Idet funktionen GETRESISTANCE ikke kører nogen løkker igennem vil gennemkørslen af den tage konstant tid. Altså er O(GETRESISTANCE) 1. Man vil selvfølgelig kunne lave en mere kompleks algoritme, som muligvis vil kunne lægge vagtplaner bedre 4, men en simpel 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 vagter 5, e er antallet medarbejdere 6 og s i og e i er henholdvis en enkelt medarbejder 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(e i, s i ) opstilles et udtryk for O(P(e, s)) i ligning 3.4 på næste side på baggrund af 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. c 1 02:resmatrix { { } } c 2 s 03:for each shift in allshifts c 3 se 04: for each employee in employees c 4 seo(r(s, e)) 05: resmatrix[shift][employee] GETRESISTANCE(employee,shift) c 5 06:freeshifts allshifts c 6 ns 07:while freeshifts > 0 08: //...nd den mindste forekomne resistans. 09: //+ Find mængden af vagter hvor denne medarbejder har denne resistans. c 7ns 10: minres inf c 8ns 11: minshifts { } c 9ns 12: minemployees { } c 10ns 13: countminres 0 c 11 ns 2 14: for each shift in freeshifts c 12 ns 2 e 15: for each employee in employees c 13 ns 2 e 16: if resmatrix[shift][employee] < minres c 14ns 2 e 17: minres resmatrix[shift][employee] c 15 ns 2 e 18: minemployees {employee} c 16 ns 2 e 19: minshifts {shift} c 17 ns 2 e 20: countminres 1 c 18ns 2 e 21: else if resmatrix[shift][employee] = minres c 19ns 2 e 22: countminres countminres + 1 c 20 ns 2 e 23: minemployees minemployees + {employee} c 21 ns 2 e 24: minshifts minshifts + {shift} 25: //Udtræk den vagt hvor gennemsnittet af alle de andre medarbejderes resistanser er størst. c 22 ns 26: maxmean -inf c 23 ns 2 e 27: for i=0 to countminres c 24ns 2 e 28: count 0 c 25 ns 2 e 29: sum 0 c 24 ns 2 e 2 30: for each employee in employees c 26 ns 2 e 2 31: if employee!= minemployees[i] c 27ns 2 e 2 32: count count + 1 c 28ns 2 e 2 33: sum sum + resmatrix[minshifts[i]][employee] c 29 ns 2 e 34: mean = sum/count c 30 ns 2 e 35: if mean > maxmean c 31ns 2 e 36: maxmean mean c 32ns 2 e 37: bestemployee minemployees[i] c 33 ns 2 e 38: bestshift minshifts[i] 39: //Tildel denne person denne vagt. c 34 ns 40: assign(bestemployee,bestshift) c 35 ns 41: if isfree(bestshift) c 36 ns 42: freeshifts freeshifts/{bestshift} 43: //Opdater alle personers resistans overfor denne vagt. c 37 nse 44: for each employee in employees c 38 nseo(r(e, s)) 45: itresmatrix[bestshift][employee] GETRESISTANCE(employee,bestshift 46: //Opdater denne persons resistanser overfor alle vagter. c 39 ns 2 47: for each shift in freeshifts c 40 ns 2 48: resmatrix[shift][bestemployee] GETRESISTANCE(bestemployee, shift) 49:return shifts 4 Det er gjort til implementeringensdelen af dette projekt. 5 s for shifts. 6 e for employees. 37

42 Kapitel 3. Løsning k nc i O(P (e, s)) k + ks + kse + kseo(r(e i, s i )) + kns + kns 2 + ns 2 e + ns 2 e 2 + knse + knseo(r(e i, s i )) k ks ns ns 2 ns 2 e ns 2 e 2 se seo(r(e i, s i )) nse nseo(r(e i, s i )) O(k) = 1 O(P (e, s)) seo(r(e i, s i ) + nseo(r(e i, s i )) + ns 2 e 2 { seo(r(ei, s i ) nseo(r(e i, s i )) ns 2 e 2 O(R(e i, s i )) (3.4) O(P (e, s)) ns 2 e 2 O(R(e i, s i )) Vil algoritmen altid stoppe? Vil den komme med et resultat? Vi vil i dette afsnit gennemgå algoritmen i dens endelige pseudoform (Se afsnit 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ænge størrelsen af mængden freeshifts er større end nul. Det gør den, fordi vi i hver gennemkørsel af hoved-løkken, ender med at tildele en medarbejder til en opgave på en vagt. Der vil altid blive tildelt en medarbejder til en vagt og hver gang en vagt bliver fyldt op, fjernes den fra mængden af frie vagter på linie 42. Størrelsen af denne mængde vil altså på et tidspunkt ramme 0. Løkkerne som startes på linierne 14 og 15 kører alle medarbejderne igennem for hver vagt. Denne løkke vil også altid ende, da mængderne employees og freeshift ikke ændrer sig under planlægningen. Løkken vil også altid afsende et resultat, i form af en mængde af 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 er mindre end denne. Den sidste store løkke der starter på linie 27 løber de to mænger indeholdende medarbejdere 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 antallet af 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 holdes op 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 starter på linierne 44 og 47, opdaterer resistansmatrissen. De kører henholdsvis de to mængder employees og freeshifts igennem. Begge disse mængder er afgrænsede og løkkerne vil derfor alle komme til et endeligt. Vi kan ud fra vurderingen se, at algoritmen altid vil afsluttes, da ingen af løkkerne vil risikere at kunne løbe uendeligt. Algoritmen vil også altid komme ud med et resultat, idet der under hver gennemkørsel af hovedløkken på linie 14 vil blive sat en medarbejder på en vagt 38

43 3.4. UDVIKLING og denne løkke først ender, når alle vagter har de medarbejdere, de skal bruge. Om resultatet er gyldigt, kan vi dog ikke garantere. Man kan forestille sig episoder, hvor en medarbejder, der er sat på vagten, stadig har den mindste resistans til en vagt, selvom han allerede er placeret på vagten. Dette vil dog kun ske i få tilfælde, hvor ingen andre har de rette kvalikationer og derfor får endnu større resistanser. Dette afhænger selvfølgelig af, hvordan de skalarer, som er beskrevet i afsnit 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. Hvis de 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. Vores algoritme 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 laver en ugyldig vagtplan, vil det være den ansvarlige for vagtplanen, der må lave noget yderligere arbejde for at få vagtplanen til at gå op. F.eks. kunne der skaes en vikar til at løse opgaven eller uddanne en medarbejder til opgaven. Opfyldelse af kravspecikationen I kravspecikationen 3.2 på side 27 har vi listet en række krav til algoritmen. Herunder vurderer vi, hvor godt algoritmen lever op til kravene. Automatisere opgaven, at lægge en vagtplan Algoritmen vil ved en gennemkørsel altid ende med en vagtplan, men om denne er gyldig, kan vi ikke altid være sikre på. Der kan forekomme særtilfælde, hvor ingen kan tage 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 kvalikationer Dette krav opfyldes, idet man udregner resistansen til en vagt. Hvis en vagt kræver, at man har truck-kørekort, vil alle medarbejdere uden truck-kørekort, få en højere resistans end 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 stort kørekort kan tage vagten. Da alle vil have en høj resistans. I dette tilfælde, vil det være andre faktorer, som for eksempel lønnen, der kommer til at afgøre, hvem der får tildelt vagten. Tage højde for det aftalte timetal pr. medarbejder Det antal timer medarbejderne har kontrakt på, skal algoritmen bedst muligt sørge for de får tildelt. Det gør den under beregningen af resistansen til en vagt. Tage højde for medarbejdernes ønsker om at få fri Medarbejderne har mulighed for at ønske om fri fra arbejde. Disse ønsker tager algoritmen 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år medarbejderes resistans til en vagt beregnes. 39

44 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 kravspecikationen i afsnit 3.2. Beskrivelsen af systemet er opbygget af 3 dele. Først beskrives medarbejdernes del, derefter planlæggerens del og til sidst systemdelen på serveren. Senere beskriver vi, hvordan vores algoritme implementeres i systemet og dermed den prototype af systemet vi har udarbejdet for at kunne teste vores algoritme System beskrivelse En mulig måde at imødekomme udfordringerne opstillet i problemformuleringen, er at stille en webserver 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 webside med et personligt login. På denne side kan medarbejderne redigere i deres personlige oplysninger, som vil bliver brugt til lønudbetaling og andre administrative opgaver. Medarbejderne skal derudover sende deres personlige digitale kalender til systemet, hvori de har indsat forskellige aftaler, på dage de ikke ønsker at arbejde. Planlæggerens del Planlæggerdelen af systemet vil indeholde forskellige funktioner til at oprette og redigere regler som f.eks. love og overenskomster, der skal medtages, når systemet lægger en vagtplan. Planlæggeren skal også oprette den vagtplans skabelonen, som det automatiske system udfylder med medarbejdere. Vagtplans skabelonen bliver oprettet, så hver vagt får kriterier som f.eks. faglige krav til medarbejderen. Derudover vil planlæggeren også have mulighed for, at indsætte forskellige informationer om medarbejdere. Det kan f.eks. være medarbejdernes kompetencer eller foretrukne fridage. Redigeringen af disse informationer vil ikke være tilgæ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øve at udarbejde en vagtplan og generere evt. advarsler om foruddenerede regler, der kan være overskredet. Når planlæggeren har genereret bare en tilfredsstillende vagtplan, bliver denne publiceret som et webdokument, hvor medarbejder kan logge på, se og eventuelt downloade deres vagtplan, eller den kan sendes som et dokument til medarbejderne per . 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, konverteret 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 informationer fra databasen og de forskellige kalenderler, som medarbejderne har indsendt. Disse informationer 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 omkring medarbejder ønsker. Dette vil medføre, at systemet, så vidt det er muligt, ikke sætter en medarbejder på vagt en dag, hvor medarbejderen har ønsket sig fri. Ud fra dette kan systemet give medarbejderne fri, hvis de har haft overarbejde. 40

45 3.6. PROTOTYPE 3.6 Prototype Indledning Figur 3.6: Dataens oprindelse i et planlægninssystem Formålet med prototypen er, at teste om vores algoritme virker efter hensigten. Prototypen er bygget efter systemet beskrevet i forrige afsnit 3.5 på forrige side, dog kun med de dele er nødvendige for at kunne teste algoritmen. Det vil sige, vi er interesserede i at vide, om den kan lægge en gyldig vagtplan, samt hvor lang køretid den har. Vi har under udviklingen af vores prototype undersøgt, hvordan man skulle præsentere og opbygge programmet (Se afsnit 3.6.2). Hvorefter er vi gik dybere ned i udviklingen af prototypen (Se afsnit på side 44). Som en afslutning på vores prototype udvikling har vi testet om prototypen fungerede efter hensigten Præsentation og opbygning Prototypen er opbygget, så systemet indlæser nogle kalender ler 7 fra de medarbejdere, der skal indsættes i en vagtplanen. Herefter indlæser systemet en vagtplansskabelon fra en kalenderl, som systemet senere vil indsætte medarbejderne i. Prototypen er opbygget som vist på gur 3.7 på næste side. Her ses, at systemet starter med at importere bruger-information fra en database, hvorefter den indlæser alle kalenderlerne og vagtplansskabelonen. Denne information 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 kalenderler, undgår vi at skulle programmere og udvikle et interface til fremvisning af den genererede vagtplan. Webserverdelen af prototypen er yderligere beskrevet (Se gur 3.11 på side 46). Dette diagram viser, hvordan systemet vil kunne inddeles i 3 dele. Den første del er en reader del, 7 Vi benytter ical kalender standarden i prototypen, hvilket vil blive videre beskrevet i afsnit på side 43 41

46 Kapitel 3. Løsning Start Import af brugere fra database Import fra ønsker fra ical udfra bruger info Import af skabelon fra ical Find alle medarbejders resistans for alle vagt Algoritmen modtager vagtskabalon og bruger informationer. Finder den vagt med den gennemsnitlige højeste resistans Udvælg medarbejderen med den laveste resistans og sæt på vagten Opdatere den valgte medarbejders resistans på alle ledige vagter JA Flere ledige vagter NEJ Samtlige besatte vagter konverteres til ical Slut Slut Den færdige ical med vagtplanen fremvises i phpicalendar Figur 3.7: Flowchart over prototype der behandler de indsendte data. Dernæst har vi selve algoritmen, der bearbejder dataene og laver en vagtplan. Endelig har vi den del, der konverterer det endelige output til den færdige kalenderl, som kan vises i et kalenderprogram. Opbygning Til vores prototype har vi valgt at benytte ical 8 standarden. Vores prototype er programmeret i PHP [18] med dertilhørende MySQL [16] database 9. Prototypens interface 10 bruger PHPiCalendar til fremvisning af vagtplanen, som er beskrevet i afsnit Vi har til prototypen oprettet en medarbejderdatabase 3.8 til at gemme de forskellige informationer, som bliver brugt til vagtplanlægningen. uid smallint(5) Medarbejderens User ID salary smallint(5) ID på attribut der skal påhæftes medarbejderen workweek smallint(5) Antal timer i ugen en medarbejder skal arbejde skills varchar(255) csv's med skills for medarbejderen Figur 3.8: Medarbejder database I prototypen har vi brugt følgende komponenter: ical import funktion Eftersom vi har valgt at arbejde med ical ler, skal vi først nde eller udvikle en funktion 8 ical, se sektion MySQL er en Open Source database-server. 10 Kalender fremviser, der grask kan opstille en kalender på en hjemmeside. 42

47 3.6. PROTOTYPE til at importere bruger-information fra ical ler. ical eksport funktion Vi skal også nde / udvikle en funktion til at skrive en vagtplan korrekt ud i en ical l. Database udtræknings funktioner Vi skal udvikle funktioner til at trække den information ud, vi har liggende i en database Algoritme til udvælgelse Hjertedelen i vores prototype er algoritmen, som vi vil konstruere i PHP icalendar icalendar 11, er en standard(rfc 2445) [8] til udveksling af kalenderaftaler samt andre kalenderopgaver, 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 del af ical standarden vi skal bruge er VEVENT. En VEVENT indeholder information om en given kalender aftale. Eksempel på hvordan en ical VEVENT kan se ud: BEGIN:VEVENT UID: T213650Z @ubuntu DTSTAMP: T213650Z DTSTART: T DTEND: T SUMMARY:Opgave skrivning LOCATION:uni CLASS:PUBLIC DESCRIPTION:Skriv afsnit... END:VEVENT //Starter aftale //Unik aftale ID //Dato for oprettelse //Tidspunkt for aftale start //Tidspunkt for aftale ophør //Beskrivelse af opgaven //Sted //Type af aftale //Beskrivelse af opgaven //Afslutter aftale Tider i ical, som for eksempel DTSTART, skal læses År 2005 Måned 12 Dato 07 T Timer 12 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 denition 2 på den følgende side), dog skal vi ikke vide hvilke medarbejdere, som der er sat på vagten, da det er en skabelon vi indlæser. Endvidere bliver medarbejder id'et hentet fra databasen, når vi indlæser vagten 11 icalender også kendt under forkortelsen ical 43

48 Kapitel 3. Løsning og skal derfor ikke hentes fra ical len. Imidlertid mangler vi at vide, hvilke opgaver der skal udføres på en given vagt. Derfor har vi valgt, at man skal skrive en tekststreng på følgende form i beskrivelses felt: REQ;lift,drive Hvor "lift,drive"er krav. Ordene er predeneret i programmet og oversættes til et heltal. En medarbejder kan, som nævnt i denitionen 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ønsker indlæses fra en ical l for hver medarbejder. Måden man angiver prioritet er ved at skrive en tekst streng af formen i beskrivelses feltet: PRI;x Hvor x er et tal fra 1 til PHP icalendar Vi har valgt at bruge PHP icalendar [19] til fremvisning af de ical ler, som vores algoritme laver. PHP icalendar opstiller ical lerne på en overskuelig måde 12, 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 muligt at 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 er skrevet 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 Udvikling af prototype I dette afsnit vil vi beskrive, hvordan vi har opbygget vores prototype, hvilke problemer vi har haft undervejs og hvordan vores kode er opbygget. Objektorientering For at gå et skridt videre mod implementeringen, startede vi med at omskrive den tidligere viste pseudokode til objektorienteret kode. Her introduceredes en række klasser ud fra begreberne i afsnit Et par af de denerede klasser indeholder funktioner eller variabler, som ikke bliver brugt under selve planlægningen, men de viser sig nyttige i løbet af implementeringen, f.eks. ved import og eksport funktionen. For at danne et overblik, har vi lavet et uml diagram 3.10 på modstående side, der illustrerer 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. Denition 1. En vagtplan er i begrebsafsnittet blot en mængde af vagter. Klassen som skal repræsentere en vagtplan, kalder vi work_schedule. Work_schedule indeholder således også kun en liste af shifts 13. En tabel over attributes og funktioner ses i tabel D.1 på side 75 Denition 2. En vagt deneres som klassen "shift". I henhold til begrebsafsnittet indeholder en vagt en liste af evner, som kræves af medarbejderne ud fra de opgaver, der skal løses. Denne liste af requirements er en liste af tal, som henviser til en evne. F.eks. to medarbejdere med 12 Demo: 13 Man 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

49 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 som er sat på en vagt, placeres på en liste af medarbejder ider. Listen over medarbejder ider kaldes 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 et sluttidspunkt. De resterende funktioner og attributter kan ses på tabel D.2 på side 75 Denition 3. En medarbejder denerer vi som klassen employee, så klassen skal indeholde informationer omkring medarbejderens timeløn (salary), det timetal han skal udfylde i løbet af en uge (weekhours) og hvad han kan (skills). Disse er udtrykt i de samme heltal, som bruges til requirements i denitionen af shift. Endelig har medarbejderen også nogle 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. Samtlige funktioner og attributes kan ses på tabel D.3 på side 75 Denition 4. Endvidere har vi deneret klassen appointment, der er et medarbejder ønske. Det er deneret som et id, der indikerer hvilken vagt id ønsket gælder i henhold til, og et tidsinterval 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 på side 43. Skabelonen er den overordnede vagtplan, som indeholder alle de vagter man ønsker skal besættes. Det der kendetegner skabelonen er, at der ikke er sat medarbejdere på vagterne. Skabelonen er en instans af klassen work_schedule(se denition 1 på modstående side). Dens indhold 45

50 Kapitel 3. Løsning Webserver ical Result ical employee ical skabalon Database Writer Reader Scalar Employee Shifts work_schedule Algoritme Badness Løn Time Conflicts ical Result Figur 3.11: Overblik over prototypen består af en række instanser af klassen shift(se denition 2 på side 44). Derefter henter vi alle medarbejdere, samt det data der er for medarbejderne, ud fra en database og indlæser deres evt. medarbejder ønsker fra en ical l, medarbejder ønsker gemmes kun, såfremt de rammer sammen med en vagt i skabelon vagtplanen. For at holde styr på dataene, laver vi en ny instans af klassen employee (se denition 3 på forrige side) for alle medarbejdere. Det næste der sker i vores prototype, er at vi fastsætte nogle systemskalarer, som beskrevet i afsnit på side 32. For at danne en oversigt af funktioner der anvendes til indlæsninger af data henvises til 3.2 på modstående side. Når dataene er blevet indlæst erklæres nogle globale variabler 3.1. Grunden til vi anvender globale variabler er for, at undgå at kopiere informationerne 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

51 3.6. PROTOTYPE Funktionens navn Parameter Returværdi Beskrivelse load_employees string ical_folder employee[] tager en streng som parameter, strengen angiver hvilken mappe medarbejdernes ical ler er placeret i, funktionen returnere et array af indlæste medarbejdere. get_employee_data - - funktionen returnere et array med indlæste medarbejder, dog er ical lerne ikke indlæst endnu. load_template_sp string ical_le work_schedule tager en streng som parameter, strengen angiver placeringen af ical len som indeholder skabelon vagtplanen, funktionen returnere en vagtplan, hvor der endnu ikke er påsat medarbejdere. get_skill_id string name - funktionen returnere en skill-id ud fra parameteret name, vedhjælp af det globale skills array. get_shift_conict int start, int end int[] conicts returnere array over vagter som falder sammen med 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 vores algoritme. Selve algoritmen er en implentering af den pseudokoden 2 på side 37. Dog med den forskel, at vi gennem videreudvikling har implenteret en mere ambitiøs version af get_resistance. Når algoritmen er færdig, returnerer den 5 ting. Den samlede resistans for de medarbejdere den har sat på vagter. Den samlede timeløn, der er brugt for at få lavet vagtplanen. Tiden algoritmen har været om at lave vagtplanen samt antallet af konikter. Endeligt returnerer den 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 mere end et krav. Ligeledes kan en medarbejder have mere end en evne. Imidlertid har vi valgt at denere, at 1 krav på en vagt, kræver 1 medarbejder. Hvis en medarbejder, er blevet tildelt en vagt, hvor vedkommene har evner til mere end et af kravene på en vagt. I såfald bliver vi nø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 har er, at der skal være en chef og en som kan tømme skaldespanden. De este medarbejdere kan tømme skraldespanden, men det er kun chefen som kan udfylde chef-rollen. I midlertid kunne det forekomme, at chefen allerde var blevet sat på vagten til at tømme skaldespanden. På den måde ville man kunne komme ud for, at algoritmen ikke ville kunne lave en vagtplan. Det vil vi undgå ved at danne alle kombinationer af medarbejdernes kvalikationer og vagtens krav. En potientiel ny medarbejder til denne vagt bliver bedømt ud fra hvor stor en mængde af disse kombinationer, der har et uopfyldt krav til en kvalikation, som den potentielle medarbejder har. Evaluering På baggrund af de data genereres en graf, der kan bruges til at danne et overblik over hvor godt processen er gået. Grafen viser hvor meget resistanse der er brugt på at lave vagtplanen, hvor meget løn der er brugt på at lave vagtplanen, hvor lang tid det har taget at køre algortimen og endelig hvor mange konikter der opstod. Til sidst skrives en result ical l, der siden kan vises i en ical fremviser. 47

52 Kapitel 3. Løsning Test af prototypen Til test af prototypen, valgte vi at bruge en ktiv case, som tog udgangspunkt i vagtplanen på en tankstation. I vores case var der 18 medarbejdere ansat til at dække perioden fra kl. 18:00 til kl. 07:00 på 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-/weekendhold og et nathold. Aften-/weekendholdet skullr dække alle hverdage fra 18:00 til 24:00 samt hele weekenden, dog ikke i tidsrummet mellem 24:00 og 07:00. Perioden fra 24:00 til 07:00 blev dækket af natholdet, alle ugens 7 dage. Ud over de to hold, var der også en gruppe nye medarbejdere, 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-/weekendholdet ikke skulle tænke på. Prototypen blev testet med en tom vagtplan for tankstationen, for at og få den til at udfylde en vagtplanen. Vi valgte at lægge vagtplanen for Januar I casen havde vi besluttet, at medarbejderne k forskellig timeløn. Derudover var hver enkelt ansat sat til et forskelligt antal plantimer i ugen. For at lave en, krævende test af vores algoritmes funktioner, havde vi lavet ønsker til 13 ud af de 16 medarbejdere (se eksempler på medarbejder ønsker i tabel 3.4 på side 50). Hver medarbejder (som ses i tabel 3.3) havde tilknyttet en kvalikation: 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 Kvalikation Timeløn Timer pr. uge 1 Nat Gammel 89 5,5 3 Gammel Ny Gammel 81 5,5 6 Gammel 82 5,5 7 Nat Gammel 90 5,5 9 Gammel 84 5,5 10 Gammel 84 5,5 11 Ny Gammel 90 5,5 13 Gammel Nat Gammel Ny 81 9 Tabel 3.3: Medarbejder liste og inkluderede hver deres ønsker. Derudover havde vi en ical-l for selve tanktstationens vagtplan. Disse ler blev uploadet til prototypen og vi kørte algoritmen på de uploadede data. Efter ca. 2 sek, havde prototypen udfyldt vagtplanen. Der var ingen konikter, hvilket vil sige at ingen k tildelt vagter, de ikke havde kvalikationerne til. Under udfyldning af vagtplanen, tog prototypen højde for antallet af timer en medarbejder var sat til at skulle have. Gennemsnitlig har hver ansat tildelt timer over hele måneden.vi kan ud fra vores 48

53 3.6. PROTOTYPE resultater se, at den gennemsnitlige afvigelse i forhold til, hvor mange timer medarbejderen skulle havde haft, er på ca. +/- 3,25 timer om måneden eller ca. 10 %. Da den korteste vagt er 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 hele måneden. kan blandt andet ses at de der har fået overarbejde, er dem med lav timeløn, hvorimod alle medarbejderne 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 op mod vagtplanen og kunne se at der ikke var et eneste ønske, som var blevet brudt. Vi kan derfor konkludere, at den kan tage hensyn til medarbejdernes ønsker. Vores prototype kan afprøves på: På den vedlagte CD-rom ligger alle lerne fra vores testcase. Dette inkludere alle medarbejdernes ø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 Konklusion på test Vi kan ud fra testen af vores prototype konkludere, at vores algoritme ved testen virker efter hensigten. Vi har udviklet en algoritme der ved testen lagde en gyldig vagtplan, der for hver medarbejder, tog højde for timeløn, antal timer pr. uge, kvalikationer og ønsker. Krav til ønsker og kvalikationer, 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 korrekt værdi for. Dog kunne vi ud fra grafen i gur 3.12, se at medarbejderne der k mere en gennemsnittet i løn, højest havde 0,5 timers overarbejde. 49

54 Kapitel 3. Løsning Navn Beskrivelse Priotet 1.ics Medarbejde ønske om fri i uge ics Medarbejde ønske om fri i uge ics Medarbejde ønske om fri i uge ics Medarbejde ønske om fri i weekenden 27 til 29 jan 1 5.ics Medarbejde ønske om fri i weekenden 20 til 22 jan 2 6.ics Medarbejde ønske om fri i weekenden 13 til 15 jan 3 7.ics Medarbejde ønske om fri i weekenden 6 til 8 jan 1 8.ics Medarbejde ønske om fri d. 6,11,20 og 25 jan 1,1,1,3 9.ics Medarbejde ønske om fri d. 7,13,17,19 og 23 jan 2,1,3,3,1 10.ics Medarbejde ønske om at få fri hver tirsadg 3 11.ics Medarbejde ønske om at få fri hver onsdag 2 12.ics Medarbejde ønske om at få fri hver torsdag 1 13.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 Vurdering af prototypen På grund af kompleksiteten i beregningerne, har vi valgt at se bort fra overlappende vagter i vores algoritme. Dette betyder at vi ikke kan have 2 vagter der ligger oven i hinanden, da vi kan risikere at en medarbejder skal passe to vagter på samme tid. Vi kan omgå problemet ved at tilføje ere opgaver til en vagt, så vi på den måde kan få ere til at arbejde på samme tid og samtidig sikre at en medarbejder ikke skal klare 2 opgaver. Dette leder os dog til en anden svaghed i vores prototype, da tilføjelse af opgaver til en vagt vil betyde en stor stigning i beregninger der skal udføres for den vagt. Vi skal derfor begrænse opgaverne for at beregningstiden ikke bliver alt for stor. Et andet kriterium, som den ikke kan tage højde for, er elleve timers reglen [2]. Dette skyldes også at det vil kræve for mange beregninger, da algoritmen skal løbe alle vagter igennem, hver gang den skal tilføje en medarbejder til en vagt, for at kontrollere at reglen ikke overskrides. 50

55 KAPITEL 4 Afsluttende afsnit 4.1 Konklusion Målet med dette projekt har været at sætte os ind i problematikkerne bag vagtplanlægning og derudfra konstruere en algoritme til automatisk vagtplanlægning. Konstruktionen af en fungerende algoritme lykkedes og afprøvningen af denne har vi gennemført, ved udviklingen af en prototype programmeret i PHP. Denne fungerende algoritme kan på et senere tidspunkt implementeres i et system, som vi også har udarbejdet et udkast til. Problemerne dette system skulle kunne løse, er de problemstillinger der er listet op i vores problemafgrænsning i afsnit 2.8. Vi kan både ud fra vores analyse men også ud fra vores arbejde med algoritmen konkludere, at vagtplanlægning er et stort og komplekst problem, der kræver meget tid, hvis man 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 Det kan være nødvendigt at give medarbejdere overarbejde på grund af andre medarbejderes fravær forårsaget af f.eks. sygdom eller barsel. Som det kan ses i algoritmetesten i afsnit på side 48, kan det være nødvendigt at give 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 som havende overarbejde for at få vagterne til at stemme. 2 Medarbejderne får ikke indydelse på deres arbejdsuge i en sådan grad, at de kan bestemme over hvilke vagter de får og dermed kan tillade sig at lave personlige aftaler i et tidsrum, hvor de potentielt kunne komme på en vagt. Denne begrænsning sker, fordi det 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 laves statiske vagtplaner, hvilket medfører at medarbejderne skal bytte vagter internt, hvis de vil have fri. I henhold til testen af algoritmen i afsnit på side 48, kan vi konkludere at et automatisk system, kan tilgodese medarbejdernes ønsker. Dette kan igen prioriteres højere i algoritmens opbygning, således at systemet i højere grad forsøger at tilgodese medarbejdernes ønsker. 5 Det er nødvendigt for en vagtplanlægger, at kunne denere hvilke regler et automatisk vagtplanlægningsværktøj, skal kunne overholde under udarbejdelsen af en vagtplan. Det gælder for eksempel hvilke muligheder et vagtplanlægningsprogram har for at tildele medarbejdere i vagtplanen overarbejde. Dette er i vores system opbygget som en mængde skalarer, der kan varieres. Disse skalarer benyttes, når resistansen for en vagt skal udregnes (Se afsnit på side 32). 6 Det er nødvendigt at specicere, hvilke krav vagterne i vagtplanen stiller til medarbejderne. Ligeledes er det nødvendigt at kunne udvælge den medarbejder, som er bedst

56 Kapitel 4. Afsluttende afsnit kvaliceret til en given vagt. Vi har i vores algoritme brugt kvalikations krav til udregning af en medarbejders resistans for en vagt, således at medarbejderne testes om de er de bedst egnede til vagterne. Dette kan ses i afsnit på side 32. Vores test kunne udfylde en vagtplan med kvalikationskrav til medarbejderne. 10 For automatisk at lave den bedst mulige vagtplan kræver det, at man højst sandsynligt 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 at man højst sandsynligt skal nde alle mulige vagtplaner. I stedet har vi gået efter at ligge en god vagtplan ved at bruge en konstruktiv algoritme, der lokalt vurderer hvor godt en medarbejder 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 problemafgræ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. Det gør vi ved at stille en række spørgsmål til projektet: hvordan kunne man komme videre med dette projekt? Hvilke steder er det oplagt at tage fat i et fremtidigt arbejde? Hvad ville der ske, hvis vi lod en virksomhed bruge vores vagtplanlægningssystem? Ville det ændre noget ved 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 problemstillinger vi valgte fra i afgrænsningen 2.8 på side 25. Man kunne være at gøre det muligt at bytte vagter internt mellem de ansatte, eller tage bedre højde for brugervenligheden i produktet ved at udvikle en eektiv brugerade, som skulle gøre det lættere for en vagtplanlægger at administrere sine medarbejdere. Det vil generelt være oplagt at færdigudvikle prototypen til et endeligt system, hvor medarbejderne kunne logge på og oprette deres egen kalendere med private aftaler. Udover at lave selve systemet, kan man også optimere algoritmen, så den bedre vil kunne løse de problemer, som vi fandt frem til under vurderingen af algoritmen på side 36. Man kunne, ud over at forbedre prototypen også forestille sig, at produktet, det vil sige det samlede system i afsnit 3.6 på side 41, kunne udvides med en række moduler, der gør det mere anvendeligt i praksis for en vagtplanlægger. Man kunne blandt andet udregne det konkrete 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 optimeres til at tage højde for ere regler, som en virksomhed kunne denere, kunne det medføre, at virksomheder, der ofte laver dynamiske vagtplaner, ville benytte systemet og derved lette arbejdsbyrden for vagtplanlæggeren. Derudover kunne man forestille sig, at det ville være til gavn for medarbejderne, hvis programmet kunne tage højde for deres ønsker under udarbejdelsen 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 ville få deres ønsker om fridage opfyldt. En anden situation man kunne forestille sig, var at ere virksomheder ville overveje at bruge omskiftelige vagtplaner, eftersom programmet gør det besværlige arbejde lettere for vagtplanlæggeren. 52

57 LITTERATUR [1] 7-eleven. Vesterbro 95, 9000 Aalborg, Tlf: / [2] Arbejdstilsynet. Daglig hvileperiode, at-meddelelse nr , November http: // pr [3] Shell Service A/S. Karolinelundsvej 45, 9000 Aalborg, Tlf: [4] Statoil A/S. Hadsundvej 212, 9220 Aalborg Ø, Tlf: / [5] Beskæftigelsesministeriet. Arbejdsmiljøloven, infolev/bes.htm, pr [6] Luca Di Gaspero. Local Search Techniques for Scheduling Problems: Algorithms and Software Tools. PhD thesis, Dipartimento di Matematica e Informatica Università degli Studi di Udine, Udine, Italy, [7] Diverse. P1-projektkatalog for naturvidenskab, intra/p1/nat_projektkatalog_e2005.pdf. [8] D. Stenerson (Microsoft) F. Dawson(Lotus). Internet calendaring and scheduling core object specication. D [9] HR-guide.com. Personnel scheduling. D [10] Kærby Hvilehjem. Ny kærvej 16, 9000 Aalborg, Tlf: [11] Cybershift inc. Employee scheduling, employee scheduling software, labor management, free employee scheduling software, employee training scheduling. cybershift.com/products_overview.asp D [12] Intellicate. Intelliroster lite. D [13] Retain International. Resource management & sta planning software. retaininternational.com/ D [14] W. Ken Jackson, William S. Havens, and Harry Dollard. Sta scheduling: A simple approach that worked. Technical Report CMPT97-23, Intelligent systems lab, Centre for systems science, Simon Fraser University, [15] Steinar Kvale. InterView. Hans Reitzels Forlag a/s, [16] MySQL. Database. open source databasen MySQL, D [17] Hydro Texaco Nørresundby. Østergade 27-29, 9400 Nørresundby, Tlf: [18] PHP. Php: Hypertext preprocessor. Programmeringssproget P- HP D

58 Litteratur [19] phpicalendar. phpicalendar, open source projekt. D [20] Planahead. Vagtplanlægning på nettet. eller en google cache +planahead.dk\&hl=da D [21] Lundbyecenteret (Plejehjem). Lundbyesgade 33, 9000 Aalborg, Tlf: [22] Inc Program Works. Work schedule dot net. D [23] ScheduleAnywhere. Online employee scheduling software. scheduleanywhere.com/site/default.aspx D [24] ScheduleSoft. Personnel scheduling software. D [25] Statoil Servicecenter. Østergade 41, 9400 Nørresundby, Tlf: [26] ASP.NET Sta Scheduling Software. Sta scheduling software for shift work. http: // D [27] Asgaard system. Time tracker. D [28] Ungdomshøjskolen Ternen. Ani Kristensen, Studievej 7, 9400 Nørresundby, Tlf: [29] Ronald L. Rivest Cliord Stein Thomas H. Cormen, Charles E. Leiserson. Introdution to Algorithms 2nd ed. The MIT Press, [30] Vagtplan. D

59 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 formål, at undersøge om interviewet kan bruges på den eksterne kontakt. Følgende indledning blev brugt til den undersøgelse: For at introducere os selv, brugte vi følgende form, således de virksomheder vi kontaktede vidste 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 studieprojekt. Vi arbejder med problemerne omkring planlægningen af en vagtplan. Vi har nogle hypoteser vi gerne vil have testet. Men for at vi kan det, vil vi gerne aftale et interview. Først vil gerne stille et par spørgsmål pr. tlf. Hvis de kontaktede virksomheder udtrykte interesse for at deltage i vores undersøgelse, var næste skridt at etablere, hvilken type vagtplan, virksomheden 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 anden situation. 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 indledtes med 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 interview med en kontaktperson. Interviewet startes med en kort indledning om hvem den interviewede talte med og formålet med det: Goddag, vi er datalogi-studerende på Aalborg universitet på 1. år. Vi er i Oktober måned startet på et studie-projekt, hvor vi arbejder med problemerne i og omkring planlægningen af en vagtplan. Vi vil gennem dette interview stille en række spørgsmål og det er meningen at de skal teste om de problemstillinger, vi tror der ndes, er sande, så vi kan udvikle et computer 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

60 Bilag A. Interview lægge en vagtplan i virksomheden og om vi direkte må bruge de informationer vi får ud af vores 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? Herefter udføres det egentlige interview med den ads- A.3.1 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 en arbejdsplan? A.3.3 Spørgsmål vedrørende det personlige ansvar ved arbejdsplanlægning. 11. Er du glad for at have ansvaret for planlægning af arbejdsplanen? (vil du uddybe hvorfor?) 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 for arbejdsplanlægningen? A.3.4 Spørgsmål til fejl. 14. Er der sket fejl som først er blevet opdaget efter medarbejderne har modtaget arbejdsplanen? 15. Hvilke fejl opstår oftest i den situation? 16. Hvorfor tror du de fejl forekommer? 56

61 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 arbejdsplanlæ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 hvor meget 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å vagplanen til 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 planlægger? 25. Har du oplevet at du var nødsaget til at gå på kompromis med arbejdsmiljøloven eller overenskomsten 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 medarbejder ofte 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 planlægningen af en arbejdsplan? A.3.7 Spørgsmål til om folks kvalikationen har betydning Har folks kvalikationer 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 er påkrævet at en bestemt person er på arbejde?

62 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 og evt. ønske om fast fri dage. Systemet skal være web baseret, så medarbejderen kan logge ind på en hjemmeside og se arbejdsplanen, samt have mulighed for at ønske ferie og fridage. Den ansvarlige for arbejdsplanlægningen skal kun holde systemet kørende ved at få computeren til 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år den 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 igennem sammen 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 ad gangen. 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

63 A.4. INTERVIEW MED ANNI KRISTENSEN 59 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 en vikar 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 for nogle 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 med at 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 godt tage 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. Jeg er jo ansat på den måde at jeg har 10 timer om ugen til det. Det vil så sige, at jeg kan arbejde langt frem i tiden. Men ud at de 10 timer skal jeg også indberette lønnen. Det gø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 vagtplan? 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 er den vi slås mest med. 11 timers reglen betyder at der skal være 11 timer mellem hver vagt 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øde fø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 sidde hold styr på hvor mange timer den enkelte medarbejder har. En anden ting jeg tit har problemer 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.

64 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 udfordring tror jeg hurtigt jeg vil blive træt af det, fordi man få en del skældud over at tingene ikke 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 for vagtplanlæ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 har det været lidt svært at skellene mellem om jeg var pædagogen eller planlæggeren og hvornå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 tilbage til mig på SMS. Derudover har jeg nogen som arbejder her x antal timer, så lægger jeg en 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 det ud af der andet øre. 17. Har du oplevet situationer, hvor folk har set skævt til dig pga. dit ansvar for arbejdsplanlæ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 hvor meget afspadsering den enkelte medarbejder har til gode? Svar: Ja det er det, men med vores faste vagtplan skulle det gå i 0. 60

65 A.4. INTERVIEW MED ANNI KRISTENSEN 61 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, hvor han/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ørst ind 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 og spø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 eller overenskomsten 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 har svæ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 hedder BF dage. Streg dag er ikke så dyre som BF dage, så man tager selvfølge dem med streg dag 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 og vikarer 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 eller en uge den anden vej. 27. Kan du huske episoder hvor du har haft svært ved at bevare overblikket gennem planlæ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ænke alternativt. På grund af at der er en kvinde arbejdsplads, er der også tit sygemeldinger pga. af børn og graviditet. Spørgsmål til om folks kvalikationen har betydning. 28. Har folks kvalikationer betydning på hvordan jeres vagtplan bliver lagt? Svar: Nej ikke umiddelbart. Vi prøver dog at undgå, at det kun er pædagogstuderende der er i huset. 29. Er der bestemte opgaver som der kun er få eller en person som kan udføre, så det er påkrævet at en bestemt person er på arbejde? se ovenover.

66 Bilag A. Interview Spørgsmål til om de ansatte har medbestemmelse i forbindelse med planlæ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 og sommerferien, er børneferie, som vi kalder det. Der har vi nogen datoer hvor vi gerne vil 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

67 BILAG B Software undersøgelses bilag B.1 Intelliroster Lite Figur B.1: Vagtperiode editor til redigering af en valgt vagtperiode. 63

68 Bilag B. Software undersøgelses bilag Figur B.2: Opgave editor til redigering af en specik opgave Figur B.3: Medarbejderkartotek til tilføje og vælge medarbejdere. 64

69 B.1. INTELLIROSTER LITE Figur B.4: Et eksempel på en udfyldt vagtplan. Figur B.5: En publiceret vagtplan i webformat 65

70 Bilag B. Software undersøgelses bilag B.2 Time Tracker Figur B.6: Her ses en vagtplans oversigt 66

71 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

72 Bilag B. Software undersøgelses bilag B.3 Work Schedule Dot Net Figur B.9: Medarbejder kartotek hvor man kan oprette, redigere og slette medarbejdere 68

73 B.3. WORK SCHEDULE DOT NET Figur B.10: Medarbejder kartotek til specikationer af kvalikationer (udfyldt) Figur B.11: Opgave editor til redigering af en specik opgave 69

74 Bilag B. Software undersøgelses bilag Figur B.12: Overordnet opsætning for rma 70

75 B.3. WORK SCHEDULE DOT NET Figur B.13: Wizard funktion under udførsel Figur B.14: En udfyldt vagtplan 71

76 Bilag B. Software undersøgelses bilag Figur B.15: En publiceret vagtplan 72