servicehåndtering i watergroup a/s - etd.dtu.dketd.dtu.dk/thesis/274602/dip10_53.pdf ·...

Servicehåndtering i Watergroup A/S

Casper Skovgaard – s072750

Kongens Lyngby, 31.01.2011

IMM.B.ENG.2010-53


Side 2 af 45

DTU Vejleder: Mads Nyborg

Danmarks Tekniske Universitet

Institut for Information og Matematisk Modellering

Byg. 321, 2800 Kgs. Lyngby, Danmark


Side 3 af 45

1 Resumé Dette afgangsprojekt har til formål, at jeg som konsulent for virksomheden

Watergroup A/S, skulle finde frem til punkter hvorpå de kunne forbedre sig IT-

mæssigt. Jeg fandt frem til, at det kunne være en god ide at optimere deres

servicehåndtering. Varetagelse af konsulentrollen har derfor resulteret i denne

rapport, som kan siges at være en gennemarbejdet vejledning med gode råd, til

hvordan Watergroup A/S anskaffer sig et IT-system til håndtering af deres service.

Rapporten tager et juridisk udgangspunkt for servicesystemet, for derefter at komme

rundt om behov og krav til sådan et IT-system. Disse belyses af metoder og modeller

fra objektorienteret analyse, herunder Unified Process, hvilket gerne skulle skabe en

fornemmelse af servicesystemet, samt en forståelse af interaktionen mellem aktører

og servicesystem. Arkitektur og design af servicesystemet bliver også berørt.

Rapporten indeholder til sidst et forslag til hvordan service, som et produkt kan udvide

sit forretningspotentiale hos Watergroup A/S. Rapporten rundes af med at

konkluderer på, om servicesystemet er en god løsning til håndtering af service hos

Watergroup A/S, samt hvordan sådan en anskaffelse og implementering bedst opnås.


Side 4 af 45

2 Summary

The purpose of this final project is that I as a consultant for the company Watergroup

A/S have to identify points on which they could improve IT-wise. I found that it could

be a good idea to optimize their service management. The consultant role has

therefore resulted in this report, that is a worked through guidance with advice in how

Watergroup A/S acquires an IT system for managing their service.

The report takes a legal basis for the service system to get around the needs and

demands for such an IT system. This is illustrated by methods and models from object

oriented analysis including the Unified Process, which should create a sense of the

service system and an understanding of the interaction between actors and service

system. Architecture and design of the service system will also be touched.

Finally the report includes a proposal for how Watergroup A/S can grow their business

potential of the product services. The report closes with the conclusion on whether the

service system is a good solution to handle service at Watergroup A/S, furthermore

how such an acquisition and implementation is best achieved.


Side 5 af 45

4 Indholdsfortegnelse 1 Resumé ...................................................................................................................... 3

2 Summary ................................................................................................................... 4

4 Indholdsfortegnelse .................................................................................................. 5

5 Problemformulering .................................................................................................. 7

5.1 Problemstilling ................................................................................................... 7

6 Målgruppe ................................................................................................................. 7

7 Begrundelse og baggrund for afgangsprojekt ........................................................... 8

7.1 Watergroup A/S ................................................................................................. 8

7.2 Afgangsprojektets setup .................................................................................... 9

8 IT-orienteret betragtning af Watergroup A/S ........................................................... 9

8.1 Hjemmesiden ................................................................................................... 10

8.2 Arbejdsprocedurer - service ............................................................................ 10

9 Rapportens afgrænsning ......................................................................................... 11

10 Det juridiske ............................................................................................................ 12

10.1 IT-kontrakter .................................................................................................... 12

10.1.1 Hvad skal leveres? .................................................................................... 12

10.1.2 Hvordan skal det leveres? ........................................................................ 13

10.1.3 Hvad og hvornår skal der betales? ........................................................... 13

10.1.4 Andre kommercielle forhold .................................................................... 14

10.1.5 Generelle anbefalinger ved kontraktforhandlinger ................................. 15

11 Servicesystem .......................................................................................................... 16

11.1 IT-projekt .......................................................................................................... 16

11.2 Risici ................................................................................................................. 18

11.2.1 Systemudvikling ........................................................................................ 18

12 Systemfastlæggelse og -afgrænsning ...................................................................... 20

12.1 Nuværende servicehåndtering ........................................................................ 20

12.2 Funktionelle krav.............................................................................................. 22

12.3 Aktører ............................................................................................................. 23

12.4 Non funktionelle krav ...................................................................................... 25

12.4.1 Brugervenlighed (Usability) ...................................................................... 25

12.4.2 Pålidelighed (Reliability) ........................................................................... 26


Side 6 af 45

12.4.3 Præsterer (Performance) .......................................................................... 27

12.4.4 Skalerbarhed ............................................................................................. 27

13 Use case diagram .................................................................................................... 28

14 Use case beskrivelser .............................................................................................. 29

14.1 Use case 1: Opret kundeprofil / serviceaftale ................................................. 30

15 Arkitektur og design ................................................................................................ 35

15.1 Domænemodel ................................................................................................ 35

15.2 Systemsekvensdiagram .................................................................................... 37

15.2.1 Use case 1: Opret kundeprofil / serviceaftale .......................................... 37

15.3 Arkitekturmodeller .......................................................................................... 38

15.4 Screen mock-ups .............................................................................................. 39

15.5 Prototype ......................................................................................................... 40

16 Udvidet forretningspotentiale ................................................................................ 40

16.1 Fjernovervågning og styring ............................................................................ 40

17 Konklusion ............................................................................................................... 42

18 Appendiks ................................................................................................................ 43

A Screen mock-ups: Use case 1 .............................................................................. 43

19 Litteraturliste ........................................................................................................... 44


Side 7 af 45

5 Problemformulering Hvordan kan servicehåndteringen hos Watergroup A/S forbedres? Kan et IT-system

være løsningen? I så fald hvordan varetages en IT-løsning og hvad skal der tages højde

for?

5.1 Problemstilling Jeg vil med baggrund i mit studie, diplomingeniørretningen Internetteknologi og

økonomi ved Danmarks Tekniske Universitet og Copenhagen Business School, varetage

en konsulentrolle hos firmaet Watergroup A/S, i forhold til at optimere deres

servicehåndtering. Jeg ønsker derfor via denne rapport, at vise de færdigheder og

nøglekompetencer jeg har tilegnet mig på mit studie. Derfor har jeg taget udfordringen

op og vil vise, at jeg kan fungere som konsulent – en rådgiver der har 360-graders

forståelse for IT-orienterede problemstillinger i virksomheder [1]. Kan jeg via denne

rapport koble de forretningsmæssige og juridiske aspekter, i forhold til IT-orienterede

produkter og løsninger, som tværfagligheden i mit studie har lagt op til. Så jeg kan

bidrage med fornuftig og brugbar rådgivning og vejledning, i hvordan Watergroup A/S

kan optimere deres servicehåndtering.

6 Målgruppe Denne rapport er skrevet med henblik på, at læseren har kendskab til de emner, der

berøres i problemstillingen, svarende til at vedkommende har taget

diplomingeniørretningen Internetteknologi og økonomi ved Danmarks Tekniske

Universitet og Copenhagen Business School. Der tages derfor ikke hensyn til at

personer, der ikke har dette, muligvis ikke vil være i stand til at læse og forstå

indholdet af rapporten. Det kan eksempelvis være på grund af fagsprog eller en

tværfaglige tilgang til opgaven. Det er hensigten, at programmører eller andre IT-

studerende skal kunne læse afsnittene, der er IT-orienterede og umiddelbart derefter

være i stand til, at arbejde videre med de foreslåede produkter eller løsninger

svarende til en agil arbejdsmetode. Forretningsmæssig er målgruppen for rapporten

Watergroup A/S.


Side 8 af 45

7 Begrundelse og baggrund for afgangsprojekt Jeg synes det er spændende, at analysere virksomheder og hjælpe dem med at være

innovative og visionære i forhold til forretning, produkter og drift med videre. Det vil

jeg gerne være god til og derfor er jeg ikke i tvivl om, at jeg gerne vil afprøve mig selv i

rollen som konsulent. Jeg vil se om jeg kan skabe værdi for en virksomhed og gøre den

mere konkurrencedygtig. Min indstilling og hvad jeg kommer med af løsning, skal

endvidere også gerne være noget, virksomheden finder yderst interessant og brugbart.

Så der er en gensidig forståelse og nytteværdi af et samarbejde omkring mit

afgangsprojekt om virksomheden, som bliver nød til at sætte noget tid og andre

ressourcer af til, at det kan omhandle dem. Min baggrund for at skrive dette

afgangsprojekt, er de færdigheder og nøglekompetencer, jeg har tilegnet mig under

mit studie som diplomingeniør på retningen Internetteknologi og økonomi ved

Danmarks Tekniske Universitet og Copenhagen Business School.

Virksomheden, mit afgangsprojekt bliver henvendt til, er Watergroup A/S. Jeg har

været i praktik et semester hos Watergroup A/S og derfor, er det oplagt at jeg skriver

mit afgangsprojekt i samarbejde med dem, da jeg har lært dem at kende og de har lært

mig at kende.

7.1 Watergroup A/S Watergroup A/S er en lille virksomhed med fem ansatte, der består af ingeniører og

servicepersonale og holder til i Birkerød. Watergroup A/S sælger primært

mekaniskudstyr for vand- og slambehandling. Watergroup A/S påtager sig dog også

design, implementering og indkøring, samt service af dette udstyr og har oparbejdet

en stor erfaring omkring dette. Virksomheden er en viden baseret og projektstyret

organisation, der løser opgaver i samarbejde med kunder og/eller totalentreprenører

og rådgivere [2]. Derfor har Watergroup A/S tit gang i nye og til tider større projekter,

for hele tiden at tilegne sig ny viden og udnytte virksomhedens potentiale fuldt ud.


Side 9 af 45

7.2 Afgangsprojektets setup Grundet størrelsen af Watergroup A/S har de ingen IT-afdeling, så når deres IT driller,

hyre de eller trækker de på ekstern ekspertise. Erik, adm. direktør for Watergroup A/S,

mener, at Watergroup A/S kan trænge til et løft på IT-området. Det gør han fordi, at

samfundet bliver mere og mere digitaliseret, samt han synes at have en fornemmelse

af, at nogle ting kan gøres bedre og lettere ved hjælp af IT i Watergroup A/S. Her

kommer jeg ind i billedet og bliver hyret som konsulent i forbindelse med, at jeg skal

lave mit afgangsprojekt. Betingelsen for afgangsprojekt fra Watergroup A/S side, er at

jeg finder frem til nogle centrale og relevante punkter, der kan forbedres i Watergroup

A/S ved hjælp af IT. For derefter at komme med en komplet vejleding og begrundelse

for hvorfor og hvordan de skal håndtere en eller flere af de punkter, jeg måtte finde.

Dette har jeg sagt ja til og accepteret, da det fyldestgøre det afgangsprojekt jeg gerne

vil lave.

8 IT-orienteret betragtning af Watergroup A/S For at finde frem til centrale og relevante punkter der kan tages hånd om IT-mæssigt i

Watergroup A/S, har jeg lavet følgende betragtninger på baggrund af, hvad jeg har set

og oplevet i Watergroup A/S, samt samtaler jeg har haft med de ansatte.

Organisatorisk set betyder størrelsen af Watergroup A/S meget, da den har stor

indflydelse på arbejdsgangene i virksomheden. De ansatte har som udgangspunkt

nogle fast ansvarsområder, men skal være omstillingsklare og fleksible, da de skal

kunne træde til hvor, det er nødvendigt, når det er nødvendigt. Desuden er den

arbejdsmæssige struktur i Watergroup A/S mere eller mindre flad, så alle arbejder og

snakker sammen. Derfor har organisationen i Watergroup A/S ikke brug for en større

IT-strategi, komplekse systemer, automatiske arkiver eller et intranet at kommunikere

sammen på. Det vil være spild af ressourcer, da der ikke er kapacitet eller fordel i at

benytte disse IT-mæssige muligheder på et højere niveau, end hvad der passer til deres

type og størrelse af virksomhed. Watergroup A/S er generelt opdateret med de IT-

løsninger, som passer til deres virksomhed.


Side 10 af 45

8.1 Hjemmesiden Et punkt der derimod kunne ses nærmere på, er hjemmesiden for Watergroup A/S. De

har ganske vist en hjemmeside, men den kunne indholdsmæssigt og enkelte steder

layoutmæssigt godt forbedres [3]. Endvidere er den engelske version af hjemmesiden

langt fra brugbar. En hurtig søgning på Google.dk viser desuden at Watergroup A/S

langtfra dukker op øverst, når der søges på deres produkter. Dette taget i betragtning,

samt at alle i samfundet bruger internettet og Google enormt, kunne det være en ide

at have en rigtig god hjemmeside. En hjemmeside, der er pænt præsenteret og har alt

relevant indhold, samt kommer højt på søgning af nøgleord hos eksempelvis Google.

En hypotese, som kan opstilles, er, at dette vil synliggøre og øge tilfredsheden hos

kunderne og øge rekrutteringen af nye kunder til Watergroup A/S. Dette til trods for at

enkelte ansatte i Watergroup A/S mener, at kunder i denne branche primært skaffes

gennem netværk.

8.2 Arbejdsprocedurer - service IT-mæssigt kunne der også kigges på de generelle projektorienterede- eller små

arbejdsprocedurer, der er i virksomheden. De forekommer mere eller mindre fast i

Watergroup A/S og kan derfor eventuelt overtages eller forbedres via IT-systemer.

Specielt serviceområdet kunne være interessant at arbejde med. Her ligger

arbejdsprocedurerne fast fra gang til gang, samt serviceområdet er et vigtigt

grundelement i forretningen Watergroup A/S. Det at udføre service svinger nemlig ikke

ligeså meget i efterspørgsel eller er nær så risikabelt, som det for eksempel er at lave

projekter. At lave service er derfor en forholdsvis stabil forretning, der sørger for nogle

faste indtægter til Watergroup A/S. Det har Watergroup A/S fundet ud af og ønsker

derfor at gøre mere ud af dette område, samt gøre det til en endnu mere stabil

forretning for dem selv. Derfor har Watergroup A/S lavet et nyt produkt, kaldet

serviceaftaler, som de ønsker at indgå med alle de kunder, de tidligere har lavet

service hos. Watergroup A/S prøver derfor, at finde en måde de bedst muligt kan

håndtere deres service og de nye serviceaftaler på. Hvilket passende kunne prøves at

løses med et IT-system. Det skal være et IT-system, der kan håndtere dele eller hele

processen omkring at lave service. Det vil sige IT-systemet eventuelt skal kunne

håndtere alt fra orientering og koordinering om hvor og hvornår, der skal laves service,

samt hvilken service der skal laves, hvilke reservedele der er brug for med videre.

Forretningsmæssigt skal sådan et IT-system begrundes i, at det vil effektivisere den

nuværende og fremtidige servicehåndteringen hos Watergroup A/S, så de spare tid,

penge og andre ressourcer, samt giver muligheder for udvikling af produktet service,

der både vil være til gavn for kunderne og Watergroup A/S.


Side 11 af 45

9 Rapportens afgrænsning På baggrund af ovenstående betragtninger findes serviceområdet som et relevant og

interessant punkt at kigge nærmere på IT-mæssigt. Derfor vil denne rapport

fremadrettet rådgive og vejlede Watergroup A/S, i hvordan en IT-støttet

servicehåndteringen kan gribes an og implementeres.

Løsningen til en IT-støttet servicehåndtering tænkes at være et servicesystem, der kan

forenkle og gøre arbejdsgangene lettere i forbindelse med at håndtere service. Fordele

som sådan et servicesystem vil medføre er, at der spares meget tid på planlægning af

arbejdet og de administrative rutiner, samt en højere effektivitet hos medarbejderen,

der får et bedre overblik over kunder, opgaver og tid. Kunderne vil også opleve fordele

i form af hurtigere svar og eksakte informationer om arbejdets udførelse. Derfor

indeholder denne rapport, et forslag til et servicesystem der bliver tilpasset behovene

hos Watergroup A/S. Det vil sige et system der kan tage hånd om kommunikationen

mellem kontoret og servicemedarbejderen. Det kan håndtere servicebesøg som ordre i

en kalender og desuden indeholde funktioner som indkøb, lagerstyring, fakturering,

økonomistyring og statistik.

Servicesystemet vil i denne rapport blive belyst i form af teori og modeller, der hjælper

med at klarlægge systemets omfang og relevante funktioner. Der vil ved hjælp af teori

blive lavet en systemfastlæggelse og -afgrænsning, samt beskrevet noget arkitektur og

design af servicesystemet. Mens der via modeller, som use case diagram, use case

beskrivelser og domænemodel vil blive forklaret funktionaliteten af servicesystemet i

forhold til aktører, deres relationer med systemet og de handlinger de skal kunne

foretage sig med systemet. Denne gennemgang af servicesystemet skulle gerne gøre

Watergroup A/S i stand til at finde en IT-leverandør, der på baggrund af

specifikationerne og en dialog med Watergroup A/S om tilpasninger kan lave og levere

servicesystemet.

Rapporten vil derfor også indeholde en juridisk vejledning og begrundelse for hvordan

Watergroup A/S bør finde deres leverandør og behandle forhandlingerne om levering

af sådan et IT-system. Der vil ligeledes blive gjort nogle forretnings- og

produktmæssige overvejelser omkring dette og service generelt.


Side 12 af 45

10 Det juridiske For at disponere optimalt og imødekomme de problemer der måtte opstå i forbindelse

med at få lavet og leveret et servicesystem, er det en god ide at have styr på reglerne

omring dette. Derfor er erhvervsjuraen et godt sted at tage udgangspunkt.

Erhvervsvirksomhed er fremadrettet, internationalt orienteret, udøves ved

problemløsning, forhandlingsprocesser og en integreret hensyntagen til økonomi,

samfundsforhold og almene retsprincipper. Udførelsen af erhvervsjuraen er

modsatrettet den traditionelle juridiske metode, der bruger juraen bagudrettet som

middel til at håndtere tvister/konfliktløsning ved domstole. Altså er erhvervsjuraen en

præventiv anvendelse af juraen til forebyggelse af konflikter og indgreb for at nå en

optimal disponering [4]. Det er en god ide at have erhvervsjuraen integreret som en

del af virksomhedens styrings- og ledelsesredskaber. De love og regler Watergroup A/S

skal tage højde for findes i privatretten, også kaldet formueretten, da Watergroup A/S

er en privatejet virksomhed. Privatretten kan deles i to kategorier, hvor af den ene er

obligationsretten. I obligationsrettens almindelige del findes for eksempel

fordringsretten, køberetten, erstatningsretten og aftaleretten, som indeholder

centrale regler og love, når man driver virksomhed.

10.1 IT-kontrakter I forbindelse med at indgå aftale med en IT-leverandør er der visse ting, man skal være

påpasselig med. Generelt i en aftalerelation er det vigtigt, at få præciseret hvad der

skal leveres, hvor det skal leveres og hvornår det skal leveres. Opfyldes dette ikke kan

det give anledning til tvister og derved alvorlige konsekvenser for begge parter, da en

kontrakt er bindende. Det kan være økonomiske konsekvenser, som konsekvenser

hvor på opgaven bliver løst, så en kontrakt må ikke tages forgivet og anses som en

formalitet.

I IT-kontrakter er det derfor vigtigt at være omhyggelig og påpasselig med

formuleringerne, beskrive detaljer tilstrækkeligt og generelt være nøjagtigt og

systematisk omkring afgrænsning med videre. Det er derfor en god ide, at få IT-

kontrakten hurtigt på banen, da følgende centrale emner kan tage tid at få på plads.

10.1.1 Hvad skal leveres?

Det er vigtigt at få afklaret, hvad det præcist er der skal leveres. Så i dette tilfælde hvad

er behovene og kravene til servicesystemet. Det vil til dels blive beskrevet senere i

rapporten via afsnittende Servicesystem, Use case diagram, Use case beskrivelser og

Arkitektur og design. Disse beskrivelser skal så være genstand for en

forventningsafstemning med leverandøren for, at opnå enighed om hvad

servicesystemet skal opfylde.


Side 13 af 45

Det skal desuden overvejes om der købes en samlet IT-løsning, om man køber

hardware, software og konsulentydelser – herunder om der er tale om

totalleverancekontrakt eller om man sammenstykker løsningen af enkelte

komponenter [5].

10.1.2 Hvordan skal det leveres?

Når der er opnået enighed om hvordan servicesystemet skal se ud, skal det aftales,

hvordan der skal leveres. Da Watergroup A/S er en privat virksomhed, er de ikke

underlagt udbudsregler, som de offentlige virksomheder er. Derfor kan Watergroup

A/S indhente tilbud, som de har lyst til og af hvem de har lyst til. Flere offentlige IT-

projekter er skredet i både tid og pris, som af flere menes at være fordi det offentlige

køre IT-projekterne stramt efter vandfaldsmodellen [6]. Levering efter

vandfaldsmodellen betyder, at der ved kontraktunderskrift er opnået enighed omkring

IT-løsningen. Fra erfaringer har det vist sig, at disse fastprisløsninger sjældent holder,

da softwareudvikling er et domæne af høje forandringer og ustabilitet –

softwareudvikling er med andre ord ofte udvikling af nye produkter [7]. Så det vil

anbefales Watergroup A/S at aftale en agil/iterativ levering, hvor der løbende opnås

enighed om kravene til løsningen, mens projektet er i gang.

10.1.3 Hvad og hvornår skal der betales?

Dernæst skal der aftales, hvad der skal betales og hvornår der skal betales. Dette er

relevant i forhold til hvem, der hæfter for eventuelle fejl og mangler. Udgangspunktet

er det aftalte og der hvor juraen kommer ind i billedet, er hvis intet er aftalt. Som

udgangspunkt skal der ske opfyldelse på realdebitors (købers) sted (bopæl eller

forretningssted), jf. princippet i Købeloven [8] (KBL) § 9 (afhentnings køb), samt at

opfyldelse skal ske efter påkrav fra realkreditor (køber), jf. princippet i KBL § 12. Det

følger af gensidighedsprincippet jf. principperne i KBL §§ 14-16 at de respektive ydelser

skal præsteres samtidig, det vil sige, at betaling modtages ved levering. I forbindelse

med IT-aftaler er det normalt at aftale aflevering, hyppigst betegnet som

"overtagelsesprøve", hvilket er en aftale om tidspunktet for risikoens overgang, der

ligger senere i tid end levering, som er det tidspunkt køber modtager det aftalte.

Denne form for aftale om betaling ligger fint i tråd med den agile/iterative levering, da

det giver køber mulighed for at teste løsningen i sin helhed og kan gøre indsigelser for

eventuelle fejl og mangler, inden risikoen for det aftalte, endeligt overgår til køber.

Kodeordet her er tidspunktet for risikoens overgang og gøres som beskrevet, bevares

incitamentet for at leverandøren levere en ordentlig løsning. Derfor anbefales det at

Watergroup A/S aftaler denne form for betaling.


Side 14 af 45

10.1.4 Andre kommercielle forhold

Udover ovenstående omfatter en IT-kontrakt også andre kommercielle forhold, såsom

sanktioner eller dagbod køber skal have ved misligholdelse, som forsinkelser og

lignende. Det er derfor vigtigt, at kontrakten udarbejdes, så den passer på det

konkrete projekt og en standard konkrakt kan derfor ikke anbefales. Ved agil/iterativ

levering kan en standard kontrakt heller ikke anvendes, da disse kræver en klar

kravspecifikation fra begyndelsen og derfor ofte er bygget op omkring

vandfaldsmodellen.

Det er ligeledes vigtigt at overveje magtforholdet i forhold til sin leverandør, da det har

betydning for den indflydelse, man kan få på kontraktens vilkår. Kan køber desuden få

givet nogle garantier, vil det være godt. Garantier er dog nok svære at få, da

leverandør skal leve hundrede procent op til garantien, hvis det ikke skal kunne anses

som misligholdelse og køber derved kan gøre misligholdelsesbeføjelser gældende, som

for eksempel genlevering, forholdsmæssigt afslag med videre og i sidste ende muligvis

ophæve aftalen. Så hvis Watergroup A/S kan få givet nogle garantier, er det ganske

fint, men nok usandsynligt.

Andre aspekter der bør overvejes ved en IT-kontrakt [9]:

Overholdelse af konkurrenceloven

Placering og rækkeviden af projektlederansvaret

Omfanget af kundes medvirken og regulering - hvis kunden ikke medvirker

Ansvar for uafdækkede forhold og grænseflader til andre systemer

Hvordan skal afprøvning foregå og hvad skal der ske, hvis prøverne ikke

godkendes

Fejl og mangler ved standard software


Side 15 af 45

10.1.5 Generelle anbefalinger ved kontraktforhandlinger

Følgende anbefalinger bør Watergroup A/S benytte sig af ved kontraktforhandlinger

[10]. Aftal fra start af med modsat part at den ene udarbejder et udkast til aftalen, som

der så kan forhandles ud fra. Har man ikke noget at forhandle ud fra, er det svært at

forhandle og derved blive enige om en kontrakt. Inden man sætter sig til

forhandlingsbordet, skal parten der ikke har lavet kontraktudkastet, have lejlighed til

at gennemgå og kommenterer på den. Når man kommenterer en kontrakt, skal der

kommes med konkrete ændringsforslag, da det ikke er nok at skrive ”uacceptabelt”.

Kommentarer kan ikke bruges til noget, hvis der ikke forklares hvad det er, der er

”uacceptabelt”. Desuden skal det gøres tydeligt, hvad man ønsker der skal ændres,

hvortil man altid bør bruge ændringsmarkering.

Når ovenstående er foretaget, burde begge parter være klar til at begynde

kontraktforhandlingerne, som er en god ide at sætte god tid af til. Vær desuden sikker

på at begge parter er repræsenteret af kompetente personer og personer, der har

kompetencer til at træffe beslutninger på både det tekniske og det kommercielle plan.

I denne forbindelse kan det være en god ide, at alliere sig med en advokat til at læse

kontrakten efter forhandlingerne og sørge for at man ikke bliver bundet, af noget man

ikke har lyst til at bindes af. Advokaten kan også være tilstede under

kontraktforhandlingerne, så juridiske spørgsmål løbende kan afklares mellem parterne.

Ved notering af ændringer kan det være en god ide, at en af parterne sidder med

kontrakten og retter i den med den andens accept efterhånden som der opnås

enighed. For det kan trække forhandlingerne ud og give anledning til mange

misforståelser, hvis begge parter sidder og tager noter, for efterfølgende hver især at

gå hjem for at rette kontrakten til efter hvad de troede, man er blevet enig om.


Side 16 af 45

11 Servicesystem Som det tidligere er nævnt, kan processen for softwareudvikling ligestilles med

processen for at udvikle nye produkter, da processen er præget af stor usikkerhed og

man derfor skal være omstillingsklar til at kunne ændre kurs. Derfor kaldes alt

softwareudvikling, som i dette tilfælde er udviklingen af et system, næsten også altid

for et projekt.

11.1 IT-projekt Et projekt er nemlig betegnet ved at være en arbejdsform, der bruges når

udgangspunktet for en opgave er kompliceret og uoverskuelig, da man ikke har den

nødvendige viden for at gå i gang med opgaven. Et projekt er typisk en engangsopgave,

der er unik, da arbejdet omkring et projekt og resultatet heraf aldrig er set før [11]. Når

endvidere at systemudvikling ofte betragtes som en projekttype for sig selv, er det

fordi [12]:

IT-sektoren er meget ung rent faglig og projektmæssigt. Det har medført, at der

ikke er den samme projektkultur som i udviklings- og leveranceprojekter.

Systemudvikling foregår ofte i et meget tæt samarbejde med kunden i en fælles

læringsproces, som ikke ses i udviklings- og leveranceprojekter.

IT- og systemudviklingsprojekter gennemføres meget iterativt og der er

modstand imod skarpe faseopdelinger og vandfaldsmodellen.

Et typisk IT-projekt omfatter en række IT problemstillinger med databaser, netværk og

distribution af data og servicesystemet er ingen undtagelse. Et IT-projekt anbefales at

foregå i tæt samarbejde med kunden, da det er en læringsproces, hvor systemet skal

tilpasses kundes arbejdsgange, problemstillinger og systemer.

Watergroup A/S anbefales at sikre sig dette samarbejde omkring servicesystemet og

derfor være involveret i projektarbejdet, så projektet får den rigtige målsætning og

problemformulering, der bliver udviklet og detaljeret hen gennem forløbet.

Watergroup A/S skal sikre sig, at de får anskueliggjort servicesystemet og lavet tests af

løsningsforslagene, så de bliver tilfredse med det servicesystem, de ender op med.

Overtagelsen af servicesystemet vil endvidere også blive lettere ved deltagelse i

projektet, da de ansatte hos Watergroup A/S løbende vil få kendskab og færdigheder

til at bruge det færdige servicesystem.


Side 17 af 45

Følgende arbejdsmetode kan derfor anbefales ved systemudvikling:

Figuren viser en iterativ arbejdsmetode for systemudvikling [13]

Denne arbejdsmetode er iterativ og vil sikre at servicesystemet hele tiden bliver

tilpasset ønsker og behov af Watergroup A/S. Endvidere håndterer denne

arbejdsmetode usikkerheden og den manglende viden, illustreret af nedenstående

figur, i et IT-projekt godt. Da systemudviklingen derved hele tiden føler sig stille og

roligt frem, så man bedre kan bevare styringen økonomisk og retningsmæssigt af

projektet og bevare derfor muligheden for at ændre kurs eller stoppe det, før projektet

løber løbsk og risikere at blive en fiasko. Den iterative arbejdsmetode bør suppleres af

actionlister, hvor problemer listes, når de dukker op. Actionlister hjælper ligeledes med

at bevare styringen og overblikket af projektet, da problemerne bliver rubriceret og

det angives, om de kan vente, er i gang eller er løst og testet.

Figuren viser at usikkerheden i projektopgaven er faldende hen gennem forløbet som

konsekvens af, at viden om det pågældende emne er voksende, efterhånden som

projektdeltagerne får flere erkendelser gennem projektet [14]

Design/coding Test Design/coding Test Design/coding Test

Typisk projektforløb

Tiden

Usikkerhed mht. mål og midler

Viden og erkendelser


Side 18 af 45

11.2 Risici I forbindelse med et IT-projekt, i dette tilfælde systemudvikling af servicesystemet, vil

der altid være en række risici. Disse risici er gode at identificere allerede fra

begyndelsen af projektet. Når alle risici er identificerede, skal det vurderes hvor

alvorlige de er og på den baggrund skal man vælge hvad man vil foretage sig. Til dette

kan anbefales at lave en risikoanalyse, der kan hjælpe en med at prioritere de største

risici, prioritere indsatsen og hjælpe med at give indsigt i projektet og de kritiske

elementer. En risikoanalyse vil også hjælpe til at forventningsafstemme projektet½ og

på baggrund af den, kan vurderes om projektet skal oprettes, forsættes som hidtil eller

ændre retning ved, at man eventuel prøver på at afhjælpe eller nedbringe de alvorlige

risici, der måtte være.

Watergroup A/S skal derfor grundigt vurdere de risici, et IT-projekt omkring

servicesystemet måtte være belastet af. Først og fremmest skal de vurdere, om de kan

have nyttet af servicesystemet, som det foreslås her i rapporten eller om skal det

ændres, så det kan noget mere eller noget mindre. Dernæst skal de via de juridiske

aspekter, der er klarlagt tidligere i rapporten omkring IT-kontrakter, få afklaret en

masse kommercielle risici der er forbundet med at sætte projektet i søen. Helt centralt

er det vigtigt at vurdere om servicesystemet vil være mere værd end den tid, de penge

og ressourcer, det vil koste at få lavet og implementerer servicesystemet i Watergroup

A/S.

Vurderes servicesystemet til at være alle pengene værd, er det vigtigt at huske

aspekter, som oplæringen og overdragelsen af systemet til de medarbejder, der skal

bruge det. Det er vigtigt at tænke på, og der skal sættes nok tid og hjælp af til dette, så

medarbejderne bliver dus med servicesystemet og ikke irriteres over det, så de ikke vil

eller kan bruge det, når der er brugt tid og penge på at lave servicesystemet.

11.2.1 Systemudvikling

I forbindelse med udviklingen af selve servicesystemet, er der også en del risici. Det vil

være risici som, at få styr på de non funktionelle og funktionelle krav, databasen,

sammenspillet mellem aktører og servicesystem – brugergrænsefladen med videre.

Alle de risici der måtte findes omkring udviklingen af servicesystem, kan behandles af

føromtalte iterative arbejdsmetode. Denne form for arbejdsmetode bliver præsenteret

og gennemgået detaljeret, hvis man tager udgangspunkt i Unified Process.


Side 19 af 45

Unified Process er netop en iterativ metode, som benyttes i forbindelse med

systemudvikling og består af fire faser [15]:

Inception – forberedelsesfase, hvor der skabes overblik over hvilke krav, der er

til systemet.

Elaboration – etableringsfase, hvor centrale dele af systemet udvikles og

programmeres.

Construction – konstruktionsfase, hvor systemet gøres robust, og resterende

dele af systemet færdigudvikles.

Transition – afslutningsfase, hvor formålet er at rette eventuelle fejl i systemet

og videregive det til drift.

Det anbefales at udviklingen af servicesystemet sker efter denne metode. Denne

rapport vil starte på metoden og forsøge at klarlægge servicesystemets brugerkrav,

sammenspillet med aktører og andre aspekter for en leverandør, så det skulle være

mulig for Watergroup A/S i et samarbejde med leverandøren at udvikle og

implementerer servicesystemet. Rapporten vil præsentere Inception fasen, ved at

identificere og tage udgangspunkt i nogle kritiske use cases, som skal udvikles først.

For at bevare den iterative tankegang, er finten så at man udviklingsmæssigt i

Elaboration fasen, går i dybden med én eller to use cases og får afprøvet alle aspekter,

det vil sige arkitekturen, lidt GUI samt de non funktionelle krav. Hvis det så viser sig, at

enkelte risici er blevet fejlvurderet og de kritiske use cases ikke kan implementeres

ordentligt, så kan projektet stadig stoppes inden det går rigtig galt og bliver for dyrt.


Side 20 af 45

12 Systemfastlæggelse og -afgrænsning Resten af rapporten vil handle om selve produktet service og indeholde en beskrivelse

af servicesystemet på baggrund af Inception fasen fra Unified Process. Til at starte med

skal servicesystemet fastlægges og afgrænses. For at gøre dette tages der

udgangspunkt i hvordan håndteringen af service foregår på nuværende tidspunkt.

Derefter kigges der på hvad der kan gøres bedre og hvilke funktioner et servicesystem

skal kunne klare for Watergroup A/S, samt hvilke ønsker de måtte have til et

servicesystem. Her følger en beskrivelse af hvordan service håndteres på nuværende

tidspunkt i Watergroup A/S.

12.1 Nuværende servicehåndtering Serviceaftalerne er et forholdsvist nyt produkt som Watergroup A/S tilbyder og er en

kontrakt der skrives mellem Watergroup A/S og en kunde, om at Watergroup A/S

varetager service på kundens anlæg i Danmark. På nuværende tidspunkt har

Watergroup A/S fem serviceaftaler, indeholdende fire til syv anlæg pr. serviceaftale, da

det er lettere og billigere at samle flere anlæg pr. serviceaftale, frem for at lave en

serviceaftale pr. anlæg. Som standard laves der almindelig service én gang årligt, for

enkelte serviceaftaler laves der almindelig service hvert halve år. Akut service og ekstra

reservedele med videre indgår som udgangspunkt ikke i serviceaftalerne og koster

derfor kunden ekstra.

Alle serviceaftaler administreres fra Watergroups kontor af den serviceansvarlige

medarbejder Katrine. Hun holder styr på samtlige serviceaftaler i sin Outlook-kalender,

hvor hun har lavet følgende kategorisering af kunder, der henvender sig til Watergroup

A/S for at få varetaget service:

Serviceaftaler – Watergroup A/S har skrevet kontrakt omkring fast service med

kunden.

Mulige serviceaftaler – Alle de kunder Watergroup A/S har lavet service hos

sidste år og vil prøve at få lavet en serviceaftale med.

Ekstra service – Til de kunder der har behov for ekstra service udover

serviceaftalen.

Andet – Fx montering af nye dele med videre.

Almindelig service – En kunde, der ikke har en serviceaftale, ringer og bestiller

service.


Side 21 af 45

I marken har Watergroup A/S deres servicemedarbejder Lars, der foretager al service.

Det gør han fra mandag til torsdag. Servicebesøg hos kunderne koordineres indbyrdes

mellem Katrine og Lars ved at de ringer sammen. Ting der tages højde for er, at Lars

skal kunne nå så mange anlæg som mulig, specielt hvis han skal til Jylland, da det tager

længere tid og koster flere penge, at sende ham over broen til den anden side af

Storebælt. Ligeledes har Lars også ret til nogle fridage, som skal passes ind.

Katrine ringer også til kunden og koordinere at servicebesøget passer med dem og om

anlægget er bemandet, hvis Lars skulle have brug for hjælp til noget.

Efter overstået service ringer Lars til Katrine og indberetter alle nødvendige

oplysninger omkring den foretagende service, som for eksempel timeforbrug, kørsel,

brug af reservedele og om anlægget har brug for nye reservedele, som så skal bestilles.

På kontoret samler Katrine oplysningerne om timeforbrug, kørsel, reservedele med

videre. At indhente oplysninger på reservedelene er besværligt, da hun skal vide den

præcise maskintype før hun kan finde en pris, der desuden skal stå i forhold til det

Watergroup A/S har givet for den hos sin leverandør. På standard reservedele er der

en fast pris. Alle informationer om reservedele har Watergroup A/S placeret i mapper

på kontoret. Ovenstående oplysninger indsamles for at kunne udregne en pris på

servicebesøget eller eventuelle ekstra udgifter ved et serviceaftalebesøg.

For at holde styr på forløbet noteres følgende i en ordrebog:

1. Skriver ordre ind når den er aftalt

2. Skriver beløb ind når faktura er sendt

3. Skriver når faktura er betalt, som tjekkes ved at kigge på de noterede

fakturabeløb i ordrebogen og en kontoudskrift fra bankkonti


Side 22 af 45

12.2 Funktionelle krav Ud fra ovenstående beskrivelse af den nuværende håndtering af service i Watergroup

A/S, samt deres ønsker til et servicesystem, er følgende funktionelle krav identificeret.

Kravene er listet uvilkårligt. Altså skal systemet kunne:

Oprette, redigere og slette en kundeprofil, indeholdende eventuel serviceaftale mellem Watergroup A/S og kunden. Kundeprofil og serviceaftale skal tilsammen indeholde oplysninger om anlæg, maskiner, reservedele, servicebesøg, serviceaftale pr. halve eller hele år med videre.

Administrer forskellige typer af servicebesøg, samt data om tidligere og fremtidig servicebesøg.

Oprette, redigere og slette servicebesøg for hver enkelt kunde.

Lave en kundedatabase, hvor kundeprofil, serviceaftaler og data om servicebesøg for hver kunde kan opbevares.

Administrerer og koordinere aftalte servicebesøg med påmindelser, samt hvor og hvornår det er tid til service igen jf. serviceaftalerne (i en kalender).

Administrerer dage Lars ikke kan lave service (i en kalender).

Lave en online indberetning, som Lars kan foretage på anlægget efter endt service, af alle de nødvendige oplysninger, som fx timeforbrug, kørsel, brug af reservedele og bestilling af manglende reservedele, yderligere kommentarer med videre.

Administrerer og påminde om at få bestilt manglende reservedele til et bestemt anlæg inden næste servicebesøg.

Snakke med en maskindatabase, for at kunne hente information om samtlige typer af maskiner og reservedele.

Bruges til at udregne en pris for et servicebesøg eller ekstra service.

Snakke sammen med bogholderisystemet for at kunne lave fakturaer og sende dem elektronisk.

Bruges som (mere eller mindre automatisk) ordrebog i henhold til service.


Side 23 af 45

12.3 Aktører Kendetegnet ved en aktør er, at aktøren integrerer direkte med servicesystemet.

Aktørerne kan deles op i kategorier, nemlig som Primary actor, Supporting actor og

Offstage actor [16]. Af aktører til servicesystemet er der primært fundet mennesker,

som vil være Primary actor, mens to systemer til agerer som Supporting actor.

Navn: Katrine (Servicekoordinater)

Ansvar og færdigheder i forhold til servicesystemet:

Katrine skal kunne bruge servicesystemet til at oprette, redigere og slette

kundeprofiler og serviceaftaler. Hun skal kunne administrere servicebesøg, ved at

oprette, redigere og slette disse. Hun skal kunne finde information ud om kunderne og

deres servicebesøg. Endvidere skal hun via en kalender kunne koordinere

servicebesøg, samt blive mindet om når servicebesøgene forestår.

Katrine skal kunne bruge servicesystemet til at beregne priser for servicebesøg. Derfor

skal hun også kunne finde informationer og priser fra indberetningen på service, samt

på forskellige typer af maskiner og reservedele. Hun skal kunne få lavet og sendt

fakturaer. Sidst men ikke mindst skal hun kunne bruge servicesystemet som ordrebog.

Navn: Lars (Servicemand)


Lars skal kunne finde information om kunderne og deres servicebesøg. Han skal via en

kalender kunne se hvor og hvornår han skal på servicebesøg, samt blive mindet om når

servicebesøgene forestår. Han skal kunne oplyse hvornår han ikke kan lave service i

kalenderen.

Lars skal kunne bruge servicesystemet til at lave en online indrapportering på

timeforbrug, kørsel, reservedele med videre, efter at han er færdige med at foretage

service hos kunden. Derfor skal han kunne finde informationer og priser på forskellige

typer af maskiner og reservedele i servicesystemet.


Side 24 af 45

Navn: Watergroup A/S ansatte


Andre Watergroup A/S ansatte skal kunne finde information om kunderne og deres

servicebesøg. De skal via en kalender kunne se hvor og hvornår Watergroup A/S skal

lave servicebesøg. De skal kunne finde informationer og priser på forskellige typer af

maskiner og reservedele. Samt medarbejderen, der laver bogholderi, skal kunne bruge

servicesystemets ordrebog og tjekke at den stemmer overens med bogholderiet, for

derved at kunne godkende ordrerne i ordrebogen.

Navn: Maskindatabase


Maskindatabasen skal kunne snakke sammen med servicesystemet, så servicesystemet

kan finde og hente informationer og priser på forskellige typer af maskiner og

reservedele hos maskindatabasen.

Navn: Bogholderisystem

Ansvar og færdigheder i forhold til systemet:

Bogholderisystemet skal kunne snakke sammen med servicesystemet, så fakturaer kan

blive skrevet og sendt elektronisk.


Side 25 af 45

12.4 Non funktionelle krav De non funktionelle krav er særdeles vigtige for servicesystemet, da hele Watergroups

setup omkring deres service mere eller mindre vil komme til at afhænge af

servicesystemet. Da service er et vigtigt grundelement i Watergroups forretning, bliver

servicesystemet også en vigtig brik i Watergroups forretning. Derfor er det vigtigt at de

non funktionelle krav er opfyldt til Watergroups tilfredshed og servicesystemet begår

så få fejl som muligt.

12.4.1 Brugervenlighed (Usability)

Servicesystemet er udviklet med henblik på benyttelse af én bestemt virksomhed,

derfor kan brugervenligheden tilpasse Watergroup A/S lige som de vil have det.

Brugervenlighed er betegnelsen for at systemet agere og gør som brugeren tænker det

og vil have det. Derfor er det vigtigt at servicesystemet tilpasses så de forskellige

aktører af servicesystemet kan benytte det på den bedste, letteste og mest

hensigtsmæssige måde. Dette opnås ved at Watergroup A/S og aktørerne bliver

inddraget i udviklingen af servicesystemet, samt at aktørerne får læring i

servicesystemet når det overdrages og altid har en mulighed for at få hjælp til

systemet. For at komme godt rundt om brugervenligheden kan man tage

udgangspunkt i den traditionelle og alment udbredte definition på et brugervenligt

system. Denne definition indeholder fem hovedkriterier, som er listet herunder [17]:

Let at lære

Let at huske

Effektivt at bruge

Forståelig

Tilfredsstillende / rart at bruge


Side 26 af 45

12.4.2 Pålidelighed (Reliability)

Watergroups håndtering af deres service bliver som sagt hængt op på servicesystemet

ved implementering. Servicesystemet vil indeholde mange vigtige data i forhold til at

lave service, samt det er systemet, der skal anskueliggøre og påminde om hvornår de

forskellige servicebesøg skal foretages. Derfor skal systemet have en høj pålidelighed,

der betyder at det skal have stor driftsikkerhed med et minimum af fejl og

reparationer. Altså skal der for eksempel kunne stoles på, at når systemet gives et

retmæssigt input, så bliver dette input behandlet rigtigt, med stor forudsigelighed for

hvordan systemet håndtere dette input.

Pålidelighed kan beskrives ved parameter som for eksempel fejlhyppighed og

middeltid mellem fejl. Specielt ved et nyt system som dette, kan det være svært at

opnå den ønskede pålidelighed, da nye systemer ofte har en del børnesygdomme i

starten, før de virker stabilt. Dette skal der selvfølgelig tages højde for og tænkes på i

projektet og i udviklingen af systemet, samt at systemet senere hen bliver holdt

opdateret, for at undgå driftssvigt.

En foranstaltning man kunne foretage for at øge pålideligheden er, at gøre enkelte

systemdele redundante, det vil for eksempel sige at der kunne gemmes to

kundedatabaser, hvilket kan sikrer fortsat drift, hvis en af dem går ned.

Sikkerhedsmæssigt, for at undgå misbrug af servicesystemet, kan der laves en form for

adgangskontrol. Dette kunne for eksempel være et brugernavn og password, hvis det

ønskes at det kun er de enkelte aktører der må have adgang til de forskellige dele af

servicesystemet, som de skal bruge. Det vil være en let og god foranstaltning at tage,

så uvedkommende ikke kan lave rav i systemet.


Side 27 af 45

12.4.3 Præsterer (Performance)

Det er vigtigt at servicesystemet kører så robust som muligt, så det kan åbnes hver

gang og ej hellere pludselig går ned, når det er åbent. Det er også vigtigt at

servicesystemet leverer informationer relativt hurtigt og præcist, både for at

brugeroplevelsen er god, men også fordi at de informationer der trækkes ud af

servicesystemet, er nogle informationer aktøren har brug for at vide nu og ikke fem

minutter efter. Parameter der derfor skal tages højde for, når systemet skal kunne

præsterer, er [18]:

Responstid

Kapacitet

Nøjagtighed

Tilgængelighed

Ressourceforbrug

Tilgængelighed er for eksempel vigtigt at overveje i forbindelse med den online

indberetning servicemanden Lars skal lave fra anlæggene. Skal servicesystemet kunne

køre uden internetforbindelse, eller skal Lars i tilfælde af manglende forbindelse ringe

til kontoret og indberette sine data. I denne rapport anbefales det at Lars til enhver tid

helst skal kunne indberette sine data via servicesystemet, da at ringe og indberette

data er det Watergroup A/S gør i dag. Det vil sige at servicesystemet derved mister sin

hensigt med at lette arbejdsgangene, da telefonisk indberetning af data beskæftiger to

ansatte i stedet for at systemet kunne nøjes med at beskæftige én. Dette valg har

selvfølgelig indflydelse på hvilken teknologi der kan overvejes og benyttes til

implementering af systemet.

12.4.4 Skalerbarhed

Da Watergroup A/S håber på en kundeudvidelse og ikke er bange for at snakke om

virksomhedsudvidelse, måske med dertil nye serviceområder. Er det vigtigt at der

tages højde for, at aktørerne og servicesystemet kan bakke op om og følge med de

udfordringer og udvidelser Watergroup A/S måtte stå overfor.


Side 28 af 45

13 Use case diagram Ud fra ovenstående afsnit Systemfastlæggelse og -afgrænsning er der lavet et use case

diagram for servicesystemet. Use case diagrammet giver et godt overblik over hvilke

use cases, der er relevante for den enkelte aktør i systemet. I nedenstående diagram

er det antaget at en implementering af servicesystemet, ligeledes vil betyde en

oprettelse af maskindatabasen med tilhørende system, der kan håndtere information

og priser fra leverandører på deres maskiner og reservedele. Et begrænset

bogholderisystem findes allerede i Watergroup A/S, hvorfra de opretter og sender

elektroniske fakturaer.

Figuren viser et use case diagram for servicesystemet


Side 29 af 45

14 Use case beskrivelser For at bevare den iterative tankegang vil der her blive gået i dybden med én eller to

kritiske use cases. Kritisk forstået på den måde at use casen har høje risici, ved at være

kompleks eller omfangsrig og derved er central for at servicesystemet kan komme til at

virke efter hensigten. Sådan en use case er derfor bedst at starte med og teste i den

iterative arbejdsmetode, for kan den use case lade sig gøre at implementere, kan

resten af systemet med stor sandsynlighed også implementeres. Derfra er det bare om

at få lavet de resterende use cases og implementere dem.

I en use case klarlægges det og bliver der givet et detaljeret billede af hvordan de

forskellige aktører og servicesystemet integrerer. Use cases er derfor med til at

anskueliggøre hvordan systemet skal opføre sig. Derfor kan det betegnes som en

beskrivelse af hvordan arbejdsgangene i Watergroup A/S gerne skulle blive med

servicesystemet.

Det skal dog nævnes at brugeroplevelse af et færdigt servicesystem muligvis ikke

”ordret” kan kopiers til de skrevne use cases. Dette skyldes at use cases kun er en

rettesnor når implementeringen går i gang og da man er uvidende i starten af et IT-

projekt, kan det vise sig, at det skal implementeres på en anden måde og forhåbentlig

oftest til det bedre.

For servicesystemet vil følgende use cases betegnes som kritiske:

Use case 1: Opret kundeprofil / serviceaftale

o Begrundelse: Use casen beskriver en central funktionalitet af

servicesystemet, da der uden oprettelse af kundeprofil, serviceaftaler

og servicebesøg ikke vil kunne laves servicesystemet.

Use case 5: Online indberetning

o Begrundelse: Use casen indeholder den kritiske problemstilling om

hvordan Lars får lavet en online indberetning, der er en af

servicesystemets nøglefunktioner.

Use case 7: Betal servicebesøg

o Begrundelse: Use casen beskriver en nøglefunktion hvor både Primary

actor og Supporting actor skal kunne integrere med servicesystemet

samtidig.


Side 30 af 45

Det er valgt at lave en use case beskrivelse af Use case 1, som derved kommer til at

udgøre endnu et lag af ”requirement capture” her i rapporten, primært ved funktions-

og adfærdsmæssige krav. Use casen vil blive lavet så grundigt, at den gerne skulle være

detaljeret og kompleks nok til, at man kan opfange mange af de krav der er forbundet

med funktionalitet af Use case 1.

Use case beskrivelsen er lavet med udgangspunkt fra et eksempel i Greag Larmans bog

APPLYING UML AND PATTERNS [19]. Det anbefales, når de resterende use cases skal

laves, at benytte dette eksempel og lave use case beskrivelser på følgende måde:

14.1 Use case 1: Opret kundeprofil / serviceaftale

Scope: Servicesystem

Level: Brugerens mål (User goal)

Primary Actor: Katrine (Servicekoordinator)

Stakeholders and Interests:

- Katrine (Servicekoordinator): Vil have at det er let og hurtigt at oprette en

kundeprofil, uden nogle systemfejl.

- Kunde: Vil have ordentlig servicehåndtering.

- Watergroup A/S: Vil have styr på sine kunder via kundeprofiler og

dertilhørende historik for service. Vil tilfredsstille sine kunders servicebehov og

tjene penge.

- Erik (Adm. Direktør): Vil sikre sig at servicen håndteres rigtigt. Vil analyser

servicehåndteringen, for på den baggrund at kunne tage fornuftige

beslutninger.


Side 31 af 45

Main Succes Scenario:

1. Katrine åbner servicesystemet.

2. Servicesystemet viser startsiden.

3. Katrine vælger at oprette en kundeprofil.

4. Servicesystemet viser en tom kundeprofilsblanket.

5. Katrine udfylder og gemmer kundeprofilsblanket.

6. Servicesystemet opretter og viser kundeprofil, samt gemmer

kundeprofilsblanket.

7. Katrine vælger at oprette en serviceaftale for kunden.

8. Servicesystemet viser Watergroups standard serviceaftale allerede udfyldt

med noget information fra kundeprofilen.

9. Katrine udfylder resten og gemmer serviceaftalen.

10. Servicesystemet gemmer serviceaftalen og dertilhørende servicebesøg som

vedhæftet til kundeprofilen. Dernæst oprettes servicebesøg jf. serviceaftalen i

systemets kalender.

11. Katrine udskriver to eksemplarer af serviceaftalen og lukker den.

12. Servicesystemet udskriver to eksemplarer og lukker serviceaftalen. Dernæst

vises kundeprofilen med serviceaftalen og de dertilhørende servicebesøg

vedhæftet.

13. Katrine vælger at oprette endnu et servicebesøg for kunden.

14. Servicesystemet viser en blanket allerede udfyldt med information fra

kundeprofilen.

15. Katrine udfylder resten, gemmer og lukker blanketten.

16. Servicesystemet gemmer blanketten vedhæftet til kundeprofilen og opretter

servicebesøget i systemets kalender. Dernæst lukkes blanketten og

kundeprofilen vedhæftet med serviceaftalen og de dertilhørende servicebesøg

vises.

17. Katrine vælger at gå til forsiden og lukke servicesystemet.

18. Servicesystemet viser startsiden og lukker ned.


Side 32 af 45

Extensions:

a. På hvilket som helst tidspunkt hvor servicesystemet går i fejl:

For genoprettelse og korrekt datahåndtering, gør det da muligt at alt data og

hændelser kan genskabes fra alle trin i use casen.

1. Katrine genstarter systemet og beder om genskabelse af tidligere

tilstand.

2. Systemet genskaber tidligere tilstand:

a. Systemet registrerer at afvigelser forhindrer genskabelse.

i. Systemet bringer en fejlmeddelelse til Katrine, notere

fejlen, og går til en ren tilstand.

ii. Katrine opretter en ny kundeprofil.

b. På hvilket som helst tidspunkt hvor Katrine begår en brugerfejl:

1. Servicesystemets ”låses”, fejlen påpeges og bedes at blive rettet.

2. Katrine retter fejlen.

3. Servicesystemet ”låses” op igen.

1a. Servicesystemet kan ikke starte.

2a. Servicesystemet kan ikke vise startsiden og går i fejl.

3a. Servicesystemet opdager fejl ved navigation til kundeprofilsblanket.

1. Systemet viser en fejlmeddelelse og anbefaler at hente blanketten

igen og tjekke at den bliver hentet det rigtige sted af systemet.

4a. Servicesystemet opdager en fejl og kan ikke udfylde kundeprofilsblanketten.



5b. Katrine udfylder kundeprofilsblanketten forkert.

6a. Servicesystemet kan ikke oprette kundeprofilen.

1. Servicesystemet beder om manglende oplysninger for at oprette

kundeprofilen.

2. Katrine indtaster de manglende oplysninger.

3. Servicesystemet opretter kundeprofilen.


Side 33 af 45

6b. Katrine kan ikke gemme kundeprofilen.

1. Servicesystemet beder om pladsfrigørelse, så der er nok plads til at

gennem kundeprofilen.

2. Katrine frigør eller skaffer mere plads.

3. Servicesystemet gemmer kundeprofilen.

7a. Servicesystemet opdager fejl ved navigation til Watergroups standard serviceaftale.

1. Systemet viser en fejlmeddelelse og anbefaler at hente serviceaftalen


8a. Servicesystemet opdager en fejl og kan ikke udfylde Watergroups standard

serviceaftale.

1. Systemet viser en fejlmeddelelse og anbefaler at hente serviceaftalen


2. Servicesystemet kan ikke automatisk udfylde serviceaftalen med

information fra kundeprofilen.

a. Katrine indtaster selv alt information.

9b. Katrine udfylder serviceaftalen forkert.

9c. Katrine kan ikke gemme serviceaftalen.


gennem serviceaftalen.


3. Servicesystemet gemmer serviceaftalen.

10a. Servicesystemet kan ikke oprette servicebesøg jf. serviceaftalen i systemets

kalender.

1. Systemet meddeler at datoerne for servicebesøg er ugyldige.

2. Katrine giver servicebesøgene en ny dato.

3. Systemet opretter servicebesøgene i kalenderen.

11b. Katrine kan ikke udskrive serviceaftalen.

1. Servicesystemet meddeler at den ikke kan få kontakt til printeren.

2. Katrine får skabt kontakt til printeren.

3. Servicesystemet udskriver serviceaftalen.


Side 34 af 45

13a. Servicesystemet opdager fejl ved navigation til blanketten for servicebesøg.



14a. Servicesystemet opdager en fejl og kan ikke udfylde blanketten for servicebesøg.



2. Servicesystemet kan ikke automatisk udfylde blanketten med

information fra kundeprofilen.

a. Katrine indtaster selv alt information.

15b. Katrine udfylder blanketten for servicebesøg forkert.

15c. Katrine kan ikke gemme blanketten for servicebesøg.


gennem blanketten.


3. Servicesystemet gemmer serviceaftalen.

16a. Servicesystemet kan ikke oprette servicebesøget i systemets kalender.

1. Systemet meddeler at datoen for servicebesøget er ugyldigt.

2. Katrine giver servicebesøget en ny dato.

3. Systemet opretter servicebesøget i kalenderen.

17a. Servicesystemet kan ikke navigere til startsiden og går i fejl.

Special Requirements:

- Effektiv computer med en skærm af en vis størrelse.

- Database.

- Hurtig responstid.

- …

Technology and Data Variations List:

b. Katrine skal bruge systemet på en PC.

Open Issues:

- Hvilke input er det præcist servicesystemet skal kunne håndterer?

- Hvilke ændringer er nødvendige for at bruge servicesystemet til anden service?


Side 35 af 45

15 Arkitektur og design Systemets arkitektur, som her i afsnittet søges klarlagt, beskriver den grundlæggende

organisering af systemet. Herunder principper for systemets design og udvikling, som

bruges til kodningen af systemet.

15.1 Domænemodel Formålet med domænemodellen er at danne et overblik over de konceptuelle klasser,

der er tænkt i forhold til systemets opbygning, samt at give en forståelse af klassernes

indbyrdes sammenhæng. Domænemodellen er en repræsentation af begrebsmæssige

klasser hentet fra den virkelige verden, og er derfor en god inspirationskilde til

objekter og navne i systemudviklingen. Hvilket mindsker den repræsentative afstand

mellem system og de begreber vi normalt kender til.

Figuren viser en domænemodel for servicesystemet


Side 36 af 45

Til Domænemodellen kan knyttes følgende kommentarer. De værdier som er angivet

ved hver klasser, viser hvor mange forekomster, af for eksempel klassen Calendar der

kan være forbundet med en instans af klassen Service og omvendt. Det er en værdi,

som er et udtrykt for øjeblikket frem for en længere periode. For eksempel laver Lars

mange services på et år, men han laver kun en service ad gangen. Symbolet stjernen

(*) betyder nul eller flere og det er for eksempel givet ved klassen Service i

forbindelsen med klassen Calendar, da kalenderen kan indeholde mange servicebesøg,

men omvendt er servicebesøgende kun at finde i en kalender og derfor er Calendar

angivet med værdien en (1).

Det er tænkt at klassen ServiceDescription indeholder data, timeforbruget for servicen,

kørselsforbruget i forbindelse med servicen, forbruget af reservedele, samt om der

eventuelt skal bestilles nye reservedele hjem akut eller til næste servicebesøg med

videre.

Ligeledes er det tænkt at klassen CustormerProfile indeholder data om tidlige

servicebesøg, så det kan ses hvad, der er blevet lavet af service og hvad der bør blive

kigget på ved næste servicebesøg. Klassen skal også indeholde information om en

eventuel indgået serviceaftale og praktiske oplysninger, som adresser,

kontaktpersoner med videre.


Side 37 af 45

15.2 Systemsekvensdiagram Der er lavet et systemsekvensdiagram for Use case 1. Et systemsekvensdiagram

illustrerer input- og outputhændelser mellem aktør og system og bruges som

vejledning under implementeringen af systemet.

15.2.1 Use case 1: Opret kundeprofil / serviceaftale


Side 38 af 45

15.3 I dette afsnit vil diagrammer for at beskrive arkitekturen af servicesystemet. Den første

model viser alle overordnede komponenter på et fysiskniveau. Altså er der en server

på Watergroups kontor, hvor Katrine også sidder med klienten, som er

browserbaseret, på en PC. Der er et Local Area Network (LAN) imellem PC og Server.

Lars har et mobile-device (Laptop, Smartphone, iPad, etc.) hvor hans version af

klienten kører. Imellem det mobile-device og serveren er Internettet, hvilket gør at

klienten skal være browserbaseret, for at det kan lade sig gøre. Altså ser et fysiske

diagram, således ud:

Fysisk diagram af servicesystemet

Det næste diagram viser hvordan servicesystemet er bygget op af komponenterne

klient, server og database. Her er det værd at bemærke at der kun er én klient. Altså

skal klienten kunne køre både på en PC og et mobile-device, illusteret ved figuren

ovenfor, hvilket kan lade sig gøre via en browser.

Figuren viser servicesystemets opbygning

Server

Klient:

Mobile-

device

Internet

Watergroups kontor

Klient: PC

LAN

Server Klient Database


Side 39 af 45

Servicesystemet anbefales at blive bygget op af lag, en såkaldt flerlaget arkitektur.

Lagene i sådan en arkitektur indeholder [20]:

User Interface

Application Logic and Domain Objects

Technical Services

Fordelene ved at bygge systemet op ad lag er, at der er en adskillelse af højniveau

ydelser fra lavniveau ydelser, samt en adskillelse af specifikke og generelle ydelser.

Dette reducerer koblingen og afhængigheder i systemet, forbedrer samhørigheden af

systemet, øger muligheden for at genbruge dele af systemet og øger klarheden af

systemet.

Man kan lave en detaljeret modellering af lagene for Application Logic and Domain

Objects ved at beskriv domæne modellen yderligere, så den derved kommer til at

udgøre objektmodellen (Design Class Diagram). Efterfølgende kan der så laves

designsekvensdiagrammer, der viser et detaljeret billede af systemets sammenhæng.

Desuden kan det være en god ide, at tænke over hvordan man vil designe koden,

hvilket designmønster (Design Pattern) vil man opbygge kodningen af servicesystemet

efter.

Ydermere kan et E/R diagram laves, som vil resultere i den relationelle database, som

skal tilgås i Technical Services laget. E/R diagrammet vil komme til at minde om

domænemodellen, men har primærnøgler og fremmednøgler og specielt en-til-mange

eller mange-til-mange relationer der skal modelleres anderledes, hvilket kan resultere i

flere entiteter. Desuden skal entiteterne også normaliseres hvilket også kan resultere i

flere.

15.4 Screen mock-ups I arbejdet af designet kan laves ”screen mock-ups”, det vil sige nogle skærmbilleder af

hvordan servicesystemet udseendemæssigt vil tage sig ud. Det kan der bruges

avancerede tegneprogrammer til, som for eksempel PhotoShop, men mindre skulle

også kunne gøre det. I Appendiks A er findes ”screen mock-ups” af servicesystemet.

”Screen mock-ups” kan siges at være staten på en horisontal prototype af systemet,

hvor det illustreres, hvad systemet skal indeholde. Denne form for prototype er en

rigtig god måde at få en mere detaljeret dialog med brugerne omkring krav til

systemet.


Side 40 af 45

15.5 Prototype Som et led i den iterative arbejdsmetode ved systemudvikling, bør de kritiske use cases

efter at have arbejdet med arkitekturen og designet af systemet, laves som rigtige

prototyper. En prototype kan være en testklasse, som tester use casen via hard-code.

På denne måde sker forudgående test og efterfølgende implementeringen af systemet

med et skridt af gangen. Derved kan der følges med i, at det man gerne vil

implementere faktisk virker efter hensigten. Dette er i stedet for at bygge hele

systemet på engang, og derefter eventuelt at skulle lave en masse svær fejlfinding.

Som tidligere nævnt giver det også mulighed for at analysere implementeringen

undervejs, så et retningsskifte for implementeringen ville kunne finde sted.

16 Udvidet forretningspotentiale Der er nogle muligheder Watergroup A/S kan gøre for at udvikle og dyrke et eventuelt

ekstra forretningspotentiale for produktet service. I selve servicesystemet kunne

kunden inddrages som en aktør til sin egen del af systemet. Hvis sådan en inddragelse

håndteres rigtigt og omgivelserne er parat til det, kan det øge tilfredshed hos kunden.

Watergroup A/S kunne derved præsentere et mere helstøbt produkt, der selv kunne

give kunden mulighed for at holde styr og se information på den service de får lavet,

lave selvbetjening i forhold til at bestille servicebesøg, men samtidig få en bedre og

hurtigere korrespondance med Watergroup A/S omkring service.

16.1 Fjernovervågning og styring Det største forretningspotentiale omkring service i Watergroup A/S omhandler

fjernovervågning og styring af udstyr. I dag findes der mange muligheder for

fjernovervågning og styring som kan integreres i et produkt som service. Dette giver en

række muligheder både for kunden og Watergroup A/S. Fjernovervågning eller

fjernstyring kan ske via Internettet, via mobiltelefon eller radiokommunikation. De

samme funktioner som betjenes umiddelbart på selve maskinen gøres derved

tilgængelige over afstand. Så ved indarbejdelse af fjern-styring og/eller en

fjernovervågning af udstyr, giver det en række nye muligheder.

Ved fjernovervågning opnås:

Driftsstatus på maskiner

Automatisk fejltilkald

Status på forbrugsstoffer

Visuel overvågning (webcam)


Side 41 af 45

Ved fjern-styring kan opnås:

Fjernstyring af maskiner

Tilkobling, frakobling og regulering

Disse muligheder vil gøre Watergroup A/S i stand til, at kunne tilbyde sine kunder et

helstøbt produkt hvad angår service. Watergroup A/S kan fuldstændigt overtage

vedligeholdelsen af maskinen på baggrund af hvor meget den rent faktisk bliver slidt.

Det vil ikke koste Watergroup A/S meget at forsøge sig med dette

forretningspotentiale, da nye forholdsvis billige løsninger findes på markedet. Det

vurderes at det vil koste Watergroup A/S omkring tusind kroner i installation af

fjernovervågning og dataforbrug for en kunde pr. år, som ønsker denne fuldkomne

serviceløsning. På den baggrund vurderes det til at være et forretningspotentiale der

sagtens kan få succes, da de primære kunder af service fra Watergroup A/S er

offentlige rensningsanlæg. Det er bekendt at det offentlige skal spare, således også i

spildevandsbranchen og derfor kunne en udlicitering af deres vedligeholdelse falde i

god jord, så der kun vedligeholdes når der er brug for det og derved kan spare

ressourcer. Optimistisk og visionært med denne service kunne det også tænkes, at

simple dele af kunders drift kunne overtages.


Side 42 af 45

17 Konklusion Via konsulentrollen hos Watergroup A/S er der i denne rapport lavet betragtninger

omkring relevante IT-mæssigt indsatsområder i Watergroup A/S. På den baggrund blev

servicehåndteringen set som et område, der kunne sættes ind på og derved forbedrer

såvel forretning som arbejdsgange.

Altså kan servicehåndteringen forbedres via et servicesystem, der tilgodeser de behov

og krav Watergroup A/S måtte have. I forbindelse med anskaffelse af sådan et system,

vejledes der i hvordan der tages højde for juridiske og kommercielle aspekter.

Kontraktforhandlinger er vigtige at tage seriøst, så der opnås en fælles forståelse af

forventningerne omkring en levering og implementering af servicesystemet.

Rapporten beskriver et internt servicesystem for Watergroup A/S hvor funktionalitet,

brugervenlighed, pålidelighed og præstationsevne er nøgleord. Desuden foreslås det

hvordan servicesystemet skal tage sig ud, samt hvordan systemudviklingen bedst

varetages med en iterativ arbejdsmetode. Disse aspekter bliver belyst via en

systemfastlæggelse og -afgrænsning herunder funktionelle og non funktionelle krav,

use cases, samt arkitektur og design herunder domænemodel, komponenterne i

servicesystemet og prototyper.

Til sidst i rapporten forslås det, at det kan være en god ide at udvide

forretningspotentialet for service med implementering af fjernovervågning, som en del

af produktet Watergroup A/S tilbyder.


Side 43 af 45

18 Appendiks

A Screen mock-ups: Use case 1


Side 44 af 45

19 Litteraturliste

1 Arnfred, Trylle Christa – Danmarks Tekniske Universitet: Uddannelse: Diplomingeniør: Teknologi og økonomi – internetteknologi og økonomi-sporet. [citeret 27.1.2011]. URL: http://www.dtu.dk/Uddannelse/Diplomingenioer/Tek_og_oek_Internettekn_og_Oekono.aspx 2 Baunsgaard, Ane Marie – Watergroup A/S A/S: Firmaprofil. [citeret 27.1.2011]. URL: http://www.Watergroup A/S.dk/firmaprofil.html 3 Baunsgaard, Ane Marie – Watergroup A/S A/S: Forsiden. [citeret 27.1.2011]. URL: http://www.Watergroup A/S.dk/index.html 4 Dahl, Børge – ERHVERVSJURA. 9. udgave. KBH.: Handelshøjskolens Forlag, 2006, s. 27-28. 5 Jensen, Dan – COMPUTERWORLD: Disse ting skal du være opmærksom på. [citeret 27.1.2011]. URL: http://www.computerworld.dk/art/50754?page=2 6 Elkær, Mads – COMPUTERWORLD: Vandfaldsmodellen må dø. [citeret 27.1.2011]. URL: http://www.computerworld.dk/art/55073?page=2 7 Larman, Graig – APPLYING UML AND PATERNS: An Introduction to Object-Oriented

Analysis and Design and Iterative Development: THIRD EDITION. USA, Massachusetts:

Prentice Hall PTR, 2007, s. 23-24.

8 Dahl, Børge – ERHVERVS RETLIGE LOVE. 29. udgave. KBH.: Handelshøjskolens Forlag, 2007, s. 311-312. 9 Jensen, Dan – COMPUTERWORLD: Ni gode råd til forhandling af it-aftaler. [citeret 27.1.2011]. URL: http://www.computerworld.dk/art/50754/ni-gode-raad-til-forhandling-af-it-aftaler?page=1 10 Jensen, Dan – COMPUTERWORLD: Disse ting skal du være opmærksom på. [citeret 27.1.2011]. URL: http://www.computerworld.dk/art/50754?page=2 11 Attrup, Mette Lindegaard & Olsson, John Ryding – Power i projekter og portefølje. 2. udgave. KBH.: Jurist- og Økonomforbundets Forlag, 2008, s. 49-57.

12 Attrup, Mette Lindegaard & Olsson, John Ryding – Power i projekter og portefølje. 2. udgave. KBH.: Jurist- og Økonomforbundets Forlag, 2008, s. 65-68.

13 Attrup, Mette Lindegaard & Olsson, John Ryding – Power i projekter og portefølje. 2. udgave. KBH.: Jurist- og Økonomforbundets Forlag, 2008, s. 67.

http://www.dtu.dk/Uddannelse/Diplomingenioer/Tek_og_oek_Internettekn_og_Oekono.aspx

http://www.dtu.dk/Uddannelse/Diplomingenioer/Tek_og_oek_Internettekn_og_Oekono.aspx

http://www.watergroup.dk/firmaprofil.html

http://www.watergroup.dk/index.html

http://www.computerworld.dk/art/50754?page=2


http://www.computerworld.dk/art/50754/ni-gode-raad-til-forhandling-af-it-aftaler?page=1

http://www.computerworld.dk/art/50754/ni-gode-raad-til-forhandling-af-it-aftaler?page=1



Side 45 af 45

14 Attrup, Mette Lindegaard & Olsson, John Ryding – Power i projekter og portefølje. 2. udgave. KBH.: Jurist- og Økonomforbundets Forlag, 2008, s. 54.

15 Larman, Graig – APPLYING UML AND PATERNS: An Introduction to Object-Oriented Analysis and Design and Iterative Development: THIRD EDITION. USA, Massachusetts: Prentice Hall PTR, 2007. 16 Larman, Graig – APPLYING UML AND PATERNS: An Introduction to Object-Oriented Analysis and Design and Iterative Development: THIRD EDITION. USA, Massachusetts: Prentice Hall PTR, 2007, s 66.

17 Hansen, Henrik – Abilitor: Definition af brugervenlighed / usability. [citeret 28.1.2011]. URL: http://www.abilitor.dk/artikler/definition-brugervenlighed.asp 18 Larman, Graig – APPLYING UML AND PATERNS: An Introduction to Object-Oriented Analysis and Design and Iterative Development: THIRD EDITION. USA, Massachusetts: Prentice Hall PTR, 2007, s. 57.

19 Larman, Graig – APPLYING UML AND PATERNS: An Introduction to Object-Oriented Analysis and Design and Iterative Development: THIRD EDITION. USA, Massachusetts: Prentice Hall PTR, 2007, s. 67-78. 20 Larman, Graig – APPLYING UML AND PATERNS: An Introduction to Object-Oriented Analysis and Design and Iterative Development: THIRD EDITION. USA, Massachusetts: Prentice Hall PTR, 2007, s. 199-204.

http://www.abilitor.dk/artikler/definition-brugervenlighed.asp

servicehåndtering i watergroup a/s - etd.dtu.dketd.dtu.dk/thesis/274602/dip10_53.pdf ·...

Documents