Øvelse A: Konfigurering af ur

Transkript

1 Øvelse A: Konfigurering af ur Danmarks Tekniske Universitet 14. November 2008

2 Øvelse A: Konfigurering af ur Danmarks Tekniske Universitet 14. November 2008 Gruppe 3 S Helene Møller Jensen S Allan Lester Kierkegaard S Daniel David Hougaard S Marinus Nejrup S Peter Nielsen

3 Indholdsfortegnelse Forord... 4 Introduktion til Clockwork A/S... 5 Procesanalyse... 6 Den nuværende proces... 6 Problemer ved den nuværende proces... 7 Den fremtidige proces... 7 Opstilling af scenarier... 7 Valg af scenarie... 8 Beskrivelse af den fremtidige proces... 8 Definition af konfigurationssystemet... 9 Rammesystem... 9 Produktanalyse Produkt Variant Master Master for urenes produktionsforløb Objektorienteret analyse Klassediagram CRC kort Objektorienteret design Brugergrænseflader Brugergrænseflade Brugergrænseflade Forbedringsforslag Kravspecifikation Krav identificeret i det valgte scenarie Krav vedrørende brugervenlighed Krav vedr. brugerinterface Krav til supportfunktioner Uddybende tanker omkring brugervenlighed Side 3

4 Forord Dette er 1. delrapport udarbejdet i forbindelse med kurset Mass Customization anvendelse af produktkonfigurering på Danmarks Tekniske Universitet. Rapporten dokumenterer det hidtidige arbejde i forbindelse med Øvelse A: Konfigurering af ur, og indeholder overordnet følgende: Procesanalyse Produktanalyse OOA model, herunder klassediagram og CRC kort Kravspecifikation, herunder fastlæggelse af brugergrænseflade Der skal rettes en tak til Lars Hvam og Erik Haastrup Müller for vejledning under arbejdet med de herover nævnte punkter. Side 4

5 Introduktion til Clockwork A/S Virksomheden Clockwork A/S er en mindre jysk produktionsvirksomhed med et halvt hundrede ansatte, der producerer og sælger universalure til det europæiske marked. Urfabrikken har i mange år solgt ure i 4 forskellige produktfamilier, A (store standardure), B (store specialure), C (små standardure) og D (små specialure). Virksomheden er organiseret i en række afdelinger, og i relation til salgs og ingeniørarbejde er specielt afdelingerne Salg, Produktkonstruktion, Produktionsforberedelse og Logistikplanlægning interessante. Det er disse afdelinger, der tager hånd om salg og marketing, samt udvikling og specificering af nye varianter. Den funktionsprægede organisering har fungeret nogenlunde tilfredsstillende i en årrække, men efterhånden som virksomheden er vokset, er det blevet mere og mere klart, at der er alt for meget unødigt papirarbejde, der er mange fejl, der skal rettes, og gennemløbstiden er ganske høj. Det er blevet påpeget, at virksomheden skal arbejde mere procesorienteret, og det er blevet besluttet at analysere salg og specifikation af produktfamilie D med henblik på et redesign af den nuværende proces. Den nye proces ønskes understøttet af et konfigurationssystem, således at en bedre specifikationsproces opnås. Den ønskede proces for salg og specifikation af urfamilie D, fremgår af figur 1 herunder. Specifikation af små specialure (Familie D) Salg Produkttilpasning Produktionstilpasning Logistikplanlægning Produkt- og produktrelaterede modeller Figur 1 - Ønsket proces for salg og specifikation af urfamilie D. Side 5

6 Procesanalyse For bedre at kunne forstå og forbedre den nuværende proces, er det vigtigt at lave en procesanalyse. En måde at modellere processen på, er ved at lave et IDEF0 diagram. IDEF0 diagrammet giver mulighed for at afbillede valg, processer og aktiviteter i en organisation. Altså kan et IDEF0 diagram hjælpe en organisation med at analysere et system og kan f.eks. hjælpe med at forbedre kommunikation mellem kunde og sælger. Den nuværende proces I det følgende vil den nuværende proces blive beskrevet, og på baggrund af den nuværende proces, er et IDEF0 diagram blevet udarbejdet. Se bilag 1 for IDEF0 diagram for den nuværende proces. Det første der sker i den nuværende proces er, at kunden henvender sig til en sælger med en forespørgsel omkring et muligt køb af et eller flere ure. Sælgeren kigger forespørgslen igennem og henvender sig evt. til kunden, hvis kundens beskrivelse af det ønskede ur/ure ikke er god nok. Sælgeren laver på baggrund af dette et groft prisestimat., som sendes til kunden. Kunden kan på baggrund af dette acceptere tilbuddet, afkaste tilbuddet, eller bede om et nyt tilbud. Hvis kunden accepterer, udarbejder sælgeren en kundeformular med kundens ønsker. Formularen sendes til konstruktionsafdelingen. Hos konstruktionsafdelingen udleverer afdelingslederen opgaven til en tilfældig konstruktør, som kigger formularen igennem, evt. spørgsmål rettes til sælgeren. Der laves en skitse af den nye urvariant. Konstruktøren undersøger om komponenterne til den nye urvariant allerede findes, eller om de skal konstrueres. Når alle komponenter til uret eksisterer, laver konstruktøren en stykliste til den nye urvariant. Den samlede produktionsbeskrivelse sendes derefter til produktionsafdelingen. Produktionsafdelingen kigger de modtagende specifikationer igennem, og retter evt. spørgsmål til konstruktionsafdelingen. Produktionsafdelingen udarbejder operationskort på baggrund af specifikationerne. Derefter sendes de samlede formularer videre til salgssupport. Salgssupport kigger de modtagende specifikationer igennem, og retter evt. spørgsmål til produktionsafdelingen. På baggrund af modtagende specifikationer udregner salgssupport en kostpris. De samlede specifikationer samt kostprisen, bliver samlet til en tilbudsspecifikation. Tilbudsspecifikationerne redigeres, så kun de nødvendige informationer er tilgængelige for kunden. Den redigerede version sendes derefter til sælger. Sælgeren udregner i fællesskab med salgschefen en salgspris, evt. spørgsmål rettes til konstruktionsafdelingen, produktionsafdelingen eller salgssupport. Når salgsprisen er udregnet udarbejdes et tilbudsbrev, som sendes til kunden. Kunden kan så acceptere tilbuddet, afkaste tilbuddet, eller bede om et nyt tilbud. Acceptere kunden, udarbejder sælgeren en ordrebekræftelse, som sendes til konstruktionsafdelingen. Her foregår samme procedure som under tilbud, blot mere detaljeret. Side 6

7 Problemer ved den nuværende proces I det følgende gennemgås en række af de problemer der er forbundet med den nuværende proces. Den samlede gennemløbstid for tilbud er på 2 20 dage, med et gennemsnit på 7, hvilket kunderne er meget utilfredse med. Specifikation af urene efter en ordre er afgivet tager ligeledes tid og bidrager med 2 3 uger af leveringstiden på 3 4 uger. Clockworks medarbejdere bruger i dag ca. 2 timer på at udarbejde et tilbud og ca. 3 timer på at udarbejde styk og operationslister til produktionen. Tilbuddene er ofte fejlbehæftede (en måling har vist, at der fejl i mere end hvert fjerde tilbud) hvilket dels medfører at den beregnede pris er forkert, samt at der skal foretages rettelser ved ordregennemførelsen. Den lange leveringstid skyldes meget spild og mange fejl i processen. Dette kan ses på IDEF0 diagrammet, hvor der f.eks. kan være op til 8 afklaringer (spørgsmål og kommunikation i organisationen) i den simple proces at konstruere og producere et ur. Der bliver desuden spildt utroligt meget tid på kommunikation mellem kunden og sælgeren, da sælgeren skal have alle informationen af kunden mundtligt. Da firmaet ikke bruger standardkomponenter, bruger de derfor ofte tid på at konstruere nye dele til en ny urvariant. Dette er en kostelig og unødig proces, som på ingen måde kommer kunden til gode. Som tidligere nævnt er der mange fejl i tilbuddene (25 %), mange af disse fejl opdages først meget sent i processen. Disse fejl kan i værste tilfælde, føre til at kunden i sidste ende ikke ønsker produktet alligevel. Det vil sige, at hele den langtrukne og besværlige proces giver et afkast på 0 kroner. Der er altså tale om direkte spildte omkostninger for firmaet. Den fremtidige proces Med henblik på at eliminere de netop beskrevne problemer ved den nuværende proces, er der i det følgende beskrevet to mulige scenarier for, hvordan den fremtidige proces for salg og specifikation af urfamilie D kan understøttes af et konfigurationssystem. Opstilling af scenarier Første mulige scenarie er, at salg og specifikation udelukkende er kundeinitialiseret. I dette scenarie konfigurerer og bestiller kunden selv sit ur uden support fra en sælger. Dette kunne f.eks. foregå via en webbaseret konfigurator. Konfiguratoren genererer alle projektpapirer så salget er klar til at gå i ordre uden ekstra kommunikation mellem sælger og kunde. Konfiguratoren overflødiggør at konstruktion, produktion og salgssupport involveres i konfigurationen af uret. Konfiguratoren skal være meget brugervenlig, og det skal være umuligt at sammensætte en konfiguration, der ikke kan lade sig gøre. Side 7

8 Andet mulige scenarie er, at salg og specifikation foregår ved, at kunden henvender sig til sælger, men at sælgeren nu har konfigurationssystemet som et værktøj til hurtigt at kunne udarbejde et mere nøjagtigt tilbud. I dette scenarie indtaster sælgeren oplysninger i konfiguratoren, parallelt med eller efter samtale med kunden. Dette gør sælgeren i stand til hurtigt, hvis ikke med det samme, at give den potentielle køber et tilbud, uden unødig pause fra henvendelse til tilbudsgivning. Hvis kundens efterspørgsel er dækket af konfiguratoren, vil salget kunne gå i ordre med det samme. Konfiguratoren overflødiggør at konstruktion, produktion og salgssupport involveres i konfigurationen af uret. Konfiguratoren kan laves som en ekspert konfigurator, da sælgeren må forventes at have noget specialviden mht. hvad der kan lade sig gøre. Valg af scenarie Ud af de netop beskrevne scenarier for den fremtidige proces for salg og specifikation af urfamilie D, vil der i det følgende blive arbejdet videre med kundeinitialiseret salg, hvor kunden selv konfigurerer sit ur vha. en internetbaseret konfigurator. Beskrivelse af den fremtidige proces En optegning af den fremtidige proces findes i bilag 2. Den fremtidige proces tager som sagt udgangspunkt i kundeinitialiseret salg, hvor kunden selv konfigurerer sit ur vha. en internetbaseret konfigurator. Konfiguratoren tager udgangspunkt i en standardkonfiguration af uret (f.eks. den mest populære konfiguration), hvorefter kunden aktivt kan ændre på de enkelte parametre og konfigurere uret efter eget valg. Ved de valg kunden træffer, skal det være umuligt at sammensætte en konfiguration, der ikke kan lade sig gøre. For at øge brugervenligheden, indeholder konfiguratoren en visuel præsentation af uret, samt en beregning af prisen på den aktuelle konfiguration. Begge dele opdateres hver gang der foretager et nyt valg, hvormed kunden hele tiden kan følge med i, hvilken indflydelse de enkelte valg har på urets udseende og pris. Har kunden brug for hjælp under konfigurationen, indeholder konfiguratoren en hjælp og supportfunktion. Når kunden har fundet frem til det ønskede ur, og aktivt bekræftet den valgte konfiguration, føres kunden videre til en side, hvor brugeroplysninger såsom navn, adresse, betalingsoplysninger m.m. indtastes. Herefter bekræftes ordren i konfiguratoren, der dels sender ordrebekræftelse til kunden via e mail (inden for maks. 5 min.), og dels videregiver ordren til produktionen indeholdende en komplet bill of material, tegninger af de enkelte komponenter, samt øvrige oplysninger vedrørende produktionen og montagen af uret. Side 8

9 Sammenlignet med den nuværende proces, medfører konfiguratoren, at det nu er overflødigt at involvere konstruktion, produktion og salgssupport i selve konfigurationen af uret. Herved spares en masse tid og ressourcer, og mange af de fejl og misforståelser, der ellers ville kunne opstå i de mange led, undgås. Definition af konfigurationssystemet I dette afsnit defineres konfigurationssystemet, hvor rammesystemet for produktmodeller benyttes til at definere hvilke typer produktmodeller der indgår. Rammesystem Inden et egentligt konfigurationssystem bliver opbygget, er det nødvendigt at definere nogle grænser og indføre en struktur for hvor meget viden omkring produktsortimentet, der skal inkorporeres i systemet. Da viden omkring produktsortimentet hurtig kan blive enorm, er det nødvendigt at prioritere hvilken viden, der skal repræsenteres. Dette har også betydning for en senere vedligeholdelse af systemet. Til at definere disse grænser og indføre en struktur anvendes et såkaldt rammesystem, jf. Product Customization, Lars Hvam et. Al. Page. 38. Rammesystemet for det fremtidige konfigurationssystem, vil se ud som det fremgår af figur 2 herunder. Figur 2 - Rammesystemet for det fremtidige konfigurationssystem Rammesystemet er opdelt i tre hovedkategorier: Egenskabsmodeller, Produktstruktur Model, og Modeller over produktets møde med livsfasesystemet. Det generiske niveau består af definition af regler og indeholder viden omkring hvordan data skal behandles, mens instansniveauet beskriver hvilket output der opnås. F.eks. en stykliste, kostpris etc. Side 9

10 Under Egenskabsmodeller og de interne/eksterne egenskaber, der beskriver konsekvenserne af mødet mellem produktet og livsfasesystemet, er der på generisk niveau opstillet regler for beregning af en kostpris. På instansniveau giver dette en liste med priser for de anvendte parter, samt en angivelse af den samlede kostpris på baggrund af den endelige udførelse af uret. I Produktstruktur Modellen beskrives produktets bestanddele i Partmodellen. Her er opstillet regler for de enkelte parter og hvorledes disse kan kombineres. Det er i disse regler at lovlige kombinationer defineres, og andre kombinationer udelukkes. F.eks. hvis der vælges konsoltype 3, kan der kun vælges urskivetype 2 etc. Disse regler er ligeledes med til at reducere antallet af kombinationsmuligheder i konfigurationssystemet. Konfigurationssystemet indeholder ligeledes en viden, således at systemet kan beregne tidsforbruget ved fremstilling af det endelige produkt på baggrund af det anvendte udstyr. Dette er angivet på generisk niveau i Fabriksmodellen under livsfasesystemet, hvor regler for valg af produktionsudstyr samt regler for beregning af det samlede tidsforbrug er opstillet. Ligeledes er der i Montagemodellen under livsfasesystemet, angivet regler for beregning af montagetid, der således er afgørende for angivelse af den samlede montagetid for den valgte urkombination. Produktanalyse Som udgangspunkt for produktanalysen, er udarbejdet en Produkt Variant Master, samt en master for urenes produktionsforløb. Produkt Variant Master Til at opnå et overblik over det samlede produktsortiment, er en Produkt Variant Master (PVM) blevet udarbejdet. Denne PVM findes i bilag 3. En Produkt Variant Master udarbejdes for at opnå et overblik over de forskellige varianter, der findes i en given produktfamilie, og beskriver ligeledes den produktviden, som skal inkorporeres i et kommende konfigurationssystem. PVM en danner ydermere grundlaget for forestående beslutninger vedrørende det fremtidige produktudbud. Udarbejdelsen af PVM en bliver oftest foretaget i tæt samarbejde med domæneeksperter, dvs. personer der bærer på vigtig og dyrebar viden omkring produktfamilien som f.eks. salgspersonale, produktudviklere, produktionsfolk etc. På denne måde sikre man, at viden omkring produktet bliver inddraget i PVM en. PVM en indeholder en komplet oversigt over de moduler og enkelte komponenter, der indgår i produktet, og består grundlæggende af to dele. En part of struktur (venstre side), der består af alle moduler og komponenter, og en kind of struktur (højre side), som beskriver, hvordan en del af produktet kan antage forskellig varians. F.eks. eksisterer der et konsolmodul, der er angivet som en del af det samlede ur ( partof ), mens det ligeledes er vist, at dette modul kan forekomme i tre forskellige varianter ( kind of ). Side 10

11 De enkelte dele er beskrevet med såkaldte attributter, som beskriver mulige dimensioner, farver etc. Ligeledes er der angivet regler for, hvordan de enkelte moduler og parter henholdsvis udelukker hinanden eller kræver kombination. Master for urenes produktionsforløb For at skabe overblik over produktionen af urene med de forskellige operationer og operationstider, er der udarbejdet en master over urenes produktionsforløb. Denne master over urenes produktionsforløb findes i bilag 4. Opbygningen af masteren tager udgangspunkt i de forskellige komponenter uret består af, og herunder de operationer, der hører til produktionen af de enkelte komponenter. Endelig angives operationstiderne, afhængig af hvilken type der er tale om. Objektorienteret analyse Den objekt orienterede analyse bruges til at modellere et givent problemdomæne, hvorved der skabes et overblik med henblik på at kunne implementere / programmere det givne problem i et konfigurationssystem. Resultatet af den objektorienterede analyse er en ny visualisering af problemdomænet vist i PVM en, i form af et klassediagram samt CRC kort, der beskriver de enkelte klasser fra klassediagrammet. Klassediagram Klassediagrammet er opbygget ved hjælp af klasser, hvor en klasse er en samling af objekter, der deler samme handlemuligheder og har ens struktur. Klasserne er derefter forbundet afhængigt af deres tilhørsforhold, hvilket de kan være på de tre følgende måder: Generalisering Der er kun den ene af subklasserne der inkluderes i systemet Aggregering Alle klasserne er inkluderes i systemet via nedarvningen Associering To klasse er associerede, og der er en form for link uden at det nødvendigvis er en aggregering. F.eks. kender den ene klasse en værdi af den andens parameter. Klassediagrammet har overordnet samme struktur og opdeling som PVM en. I klassediagrammet er Ur (Superpart for den fysiske del) associeret med klasserne BOM, Operation og Tilbudsbrev, som er de klasser, hvor diverse attributter, som skal indgå i tilbudsbrevet, beregnes. Klassediagrammet er illustreret i figur 3 herunder. Side 11

12 Figur 3 Klassediagram Klasse diagrammet er lavet for at skabe et overblik før udfyldelse af CRC kortene, der vil sørge for systematisk programmering af konfiguratoren. Der er taget udgangspunkt i selve uret, der er superparten i aggregeringsstrukturen. Da en aggregeringsstruktur kan sammenlignes med strukturen i en BOM, kom næste niveau i strukturen til at indeholde de dele, der til sammen ville kunne konstruere uret ( part of struktur). Disse sub parter indeholder hver især deres egen typer, dvs. fod indeholder fodtype 1,2 og 3. Disse er beholdt som attributter i klasserne for overskuelighedens skyld, da en opdeling af en sammenhængende struktur kan føre til kobling, der mindsker læsbarheden af klassediagrammet. Det er muligt at beholde typerne som attributter, da der i klasserne ikke knytter sig specifikke udregninger til hver af typerne, men i stedet kun er generelle metoder, der knytter sig overordnet til attributterne i klassen. Havde dette ikke været tilfældet, ville det have været oplagt at trække typerne ud af klasserne i en generaliseringsstruktur. CRC kort CRC kortene beskriver de enkelte klasser fra klassediagrammet vist i figur 3. Hver klasses attributter og metoder / handlinger, samt relationer til andre klasser, beskrives med henblik på den efterfølgende programmering. Derudover er klassen beskrevet i tekst, hvoraf det fremgår hvad dens opgave er. Endelig indeholder CRC kortene en evt. skitse, som kan vise de involverede attributter grafisk. CRC kortene skal gøre det muligt for programmøren af konfigurationssystemet, at programmere uden hjælp fra domæne eksperterne. Hvert CRC kort er lavet med udgangspunkt i den CRC skabelon der fremgår af figur 4 herunder. Side 12

13 Figur 4 - CRC-kort skabelon De fulde CRC kort kan ses i bilag 5. I de nedenstående punkter er nævnt nogle af de vigtige overvejelser og relationer, der gør sig gældende for de enkelte klasser, på baggrund af det valgte klassediagrams opbygning. Ur - Samler alle oplysninger der er i klasserne under sig, og videregiver dem til BOM, Operation og Tilbudsbrev. Konsol - Flere af konsollens attributter er stærkt koblet til Fod, Urskive og Visere med hensyn til størrelse. Det er valgt at lægge den bestemmende faktor på konsollen, da den betragtes som hovedkomponent. Side 13

14 Fod - Konsol bestemmer sidehulsdiameteren samt fodbredden, så derfor udfører Fod bare en metode som beregner sidehulsdiameter og fodbredden på baggrund af Konsollens attributter. Urskive - Konsol bestemmer Urskivetypen og indvirker på Urskivetypen på baggrund af nogle af Konsollens attributter. Urværk - Urværkstypen samt om der skal være en polystyrenklods er uafhængigt af resten. Visere - Visernes maksimale længder er begrænset med nogle relationer startende med at viserne ikke må være så lange at de stikker ud over urskiven, på baggrund af konsolbredden samt størrelsesforholdet viserne imellem. BOM - Fra Ur fås hvilke valg der er gjort, hvorpå BOM laver en materialeliste samt en pris for materialer. De enkelte materialers stykpriser hentes fra en ekstern prisliste f.eks. en kommaseperareret tekstfil. Dette gør det muligt at opdatere priser uden at skulle have hjælp af en programmør. BOM sender den samlede materialepris videre til Tilbudsbrev. Operation - Fra Ur fås hvilke valg der er gjort, hvorpå Operation beregner operationspris. De enkelte operationspriser hentes fra en ekstern prisliste f.eks. en kommaseperareret tekstfil. Dette gør det muligt at opdatere priser uden at skulle have hjælp af en programmør. Operation sender den samlede operationspris videre til Tilbudsbrev. Tilbudsbrev - Beregner den samlede pris til brug i tilbudsbrev, på baggrund af materialeprisen og operationsprisen. Dettes gøres på baggrund af en tilbudspris kalkulationsmodel. Side 14

15 Objektorienteret design Brugergrænseflader Der er udarbejdet 2 forskellige forslag til brugergrænseflader til konfiguratoren. Disse to brugergrænseflader, samt deres dynamik, vil blive beskrevet i detaljer nedenfor. Herefter udvælges ét forslag og eventuelle forbedringsforslag vil blive givet. Brugergrænseflade 1 Layoutet af den første brugergrænseflade, fremgår af figur 5 herunder. Figur 5 Brugergrænseflade 1 I denne brugergrænseflade er det muligt, at sammensætte en urvariant ved slavisk at gennemgå seks punkter. Punkterne / drop down menuerne indeholder ingen defaultværdier, og vinduet til højre i konfiguratoren viser ikke nogle urdele, før disse bliver valgt. Drop down menuerne skal følges slavisk, da et valg gjort i punkt 1 kan sætte begrænsninger i de efterfølgende punkter. Når en drop down menu udfyldes med et valg, godkender / afviser systemet valget, og urdelen tilføjes grafisk i vinduet til højre i konfiguratoren (hvis valget godkendes). Side 15

16 Når sjette og sidste drop down menu er udfyldt, og godkendt af systemet, er uret færdigt, og prisen på det konfigurerede ur vil fremgå. Er kunden tilfreds, accepteres købet ved at trykke på knappen Accepter. Når dette sker, vil kunden ledes videre til en side, hvor de fornødne kundeoplysninger indtastes. Herefter får kunden tilsendt en ordrebekræftelse via e mail. Brugergrænseflade 2 Layoutet af den anden brugergrænseflade, fremgår af figur 6 herunder. Figur 6 Brugergrænseflade 2 Dette forslag til en brugergrænseflade adskiller sig fra det foregående forslag på flere punkter. Det er nu muligt at vælge frit / iterativt, dog er der stadig anbefalet en rækkefølge indikeret med tal. Der er desuden sat defaultværdier i drop down menuerne (f.eks. den mest populære konfiguration). Dette bevirker, at der vil være et billede af uret i grafik området fra starten, der ændres løbende på baggrund af kundens valg. Der er tilføjet en kort beskrivelse af, hvad hjemmesiden muliggør for kunden øverst på siden. Til hvert valg følger desuden en forklaring, der kan hentes frem ved at klikke på eksempelvis Urskive linket. Side 16

17 Under urskive skal det være muligt at uploade ens eget billede, hvilket gøres ved at klikke på Gennemse knappen. Når billedet er valgt, bliver dette naturligvis en del af grafikken. Under punkt 5 (visere) er det valgt, at det vil lette overskueligheden, hvis denne er delt op i separate minut, time og sekundvisermenuer. Når man har gjort et valg, vil dette blive indikeret ved, at der ud for hver drop down knap, vises et grønt flueben. Det er muligt for brugeren at få hjælp undervejs, hvilket sker ved at klikke på hjælp linket nederst på siden: klik HER hvis du har brug for hjælp. Dette link fører brugeren til en side, hvor kontaktoplysninger til kundesupport vil være vist, såvel som endnu et link, der fører videre til en brugervejledning. Efter det 6. punkt kan konfigurationen accepteres ved at trykke på Accepter. Prisen opdateres løbende, og før der accepteres, er det nødvendigt at specificere, hvor mange emner der ønskes. Dette gøres i Pris for feltet. Efter der er trykket på Accepter, vil kunden ledes videre til en side hvor de fornødne kundeoplysninger indtastes. Herefter får kunden tilsendt en ordrebekræftelse via e mail. Forbedringsforslag For brugergrænseflade 2 kan placeringen af Accepter og antal ure funktionerne virke en smule forvirrende. Det kan evt. skyldes at Accepter knappen visuelt kommer før kunden har haft mulighed for at vælge antal ure. Det kan naturligvis afhjælpes ved, at Accepter knappen ikke kan aktiveres, uden at antal ure er sat, dog ville en visuel afhjælpning kun tilføje brugervenlighed til systemet. En løsning kunne derfor med fordel være en kombination. Nedenfor er systemdynamikken set fra brugerens synspunkt forsøgt illustreret i figur 7. Da brugeren kun interagerer med systemet, indtil han / hun har fået tilsendt tilbudsbrevet. Konfigureringen af urkomponenterne skal ske, før det ønskede antal kan sættes, og dette skal, som diskuteret ovenfor, muliggøre acceptfunktionen. Figur 7 - Systemdynamik Placeringen af grafikvinduet kunne også genovervejes, så det er placeret bedst i forhold til eksempelvis de resterende elementer på siden eller brugerens læselinie. Det kunne evt. overvejes, om det skulle være Side 17

18 muligt at navigere i grafikken altså rotere og rykke rundt med modellen for herigennem at give brugeren større beslutningsgrundlag. Det endelige brugerinterface kan have en startside, hvor brugeren skal indikere, om han/hun er privat eller virksomhedskunde. Valget kunne føre til andre valgparametre eller mængderabatter til store ordrer fra virksomheder. Foruden dette kunne det tilføre Clockwork indblik i deres kundesegment, der kunne benyttes i marketing og/eller design. Da Clokwork agerer på et europæisk marked, skal det i en forbedret version af brugerinterfacet være muligt at vælge engelsk som et alternativt sprog til dansk. Kravspecifikation De opstillede krav til konfigurationssystemet er listet herunder. Krav identificeret i det valgte scenarie Skal kunne tilgås via www Fuldstændig BOM skal laves til produktion Ordrebekræftelse skal sendes via mail inden for max 5 min Krav vedrørende brugervenlighed Skal starte med default ur, der ændres hvis nye valg bryder opsatte regler Konfigurator skal være intuitiv, gøres vha. brugerinterface Krav vedr. brugerinterface Kunden skal guides igennem nødvendige trin vha. nummerering Anbefalet rækkefølge: urskive, urværk, konsol, fod, viser, urværk, dreje led, accept, kundeoplysning Under urskive, skal det være muligt at oploade et billede, eller vælge standart billede Valg skal kunne ses på grafik, der løbende opdateres (< 1sek) Valg foretages i drop down menuer Indikation af at valg i en given drop down menu er foretaget Prisvindue opdateres løbende efter hvert valg (< 1sek) Gråtoning af valg der ikke kan foretages i den pågældende konfiguration Ved valg af en ikke mulig konfiguration, popper et vindue op der fortæller hvad der skal ændres for at ønskede konfiguration bliver mulig Krav til supportfunktioner Telefonnummer til kundesupport skal fremgå Link til brugervejledning skal være tilgængeligt Side 18

19 Uddybende tanker omkring brugervenlighed Med den i scenariet valgte bruger i tankerne, blev systemets brugervenlighed adresseret, for herigennem at sørge for, at systemet vil blive brugt optimalt, og at brugeren får det ønskede ud af systemet. Defaultværdier vil sørge for, at brugeren ikke skal starte helt fra bunden, men kan nøjes med at ændre de parametre, der ønskes anderledes (kan dog i visse tilfælde være alle). Valget af defaultværdier kan eksempelvis afspejle det mest solgte, billigste eller dyreste ur. Når konfiguratoren benyttes, skal der være en anbefaling af hvilken rækkefølge valgene kan foretages i, dette gøres eksempelvis via en nummerering af skridtende 1 6. Når valget til en given del af uret er foretaget, skal dette indikeres således, at brugeren er bevidst om, hvilke valg der er foretaget, og hvilke der stadig skal tages stilling til. Den anbefalede valgrækkefølgen er vist nedenfor: Rækkefølgen er baseret på reglerne knyttet til konfiguratoren. Da det er valgt, at systemet skal indeholde defaultværdier, vil valgene når foretaget i rækkefølge, ikke forårsage en ændring af defaultværdierne før disse evt. ændres af brugeren. Hermed er der gjort et forsøg på at holde defaulturet konstant, til der laves en aktiv ændring i defaultværdierne. Dette er især vigtigt, da brugeren vil kunne se sine egne ændringer på en grafik, der vil blive opdateret efter vært foretagne valg. Grafikken starter naturligvis med at vise defaulturet. Ændres grafikken på et område, hvor kunden endnu ikke har foretaget nogen værdiændring, på baggrund af modstridende regler og det foregående valg, kan grafikken være til mere gene end gavn. Det er tiltænkt, at en løbende visualisering af uret vil kunne hjælpe kunden med at foretage valg i konfiguratoren, da det hermed bliver muligt at forsøge alle givne muligheder, indtil kunden er tilfreds med det vedkommende ser. Der vil på baggrund af reglerne i systemet være konfigurationer, der ikke vil være mulige. Disse vil blive nedtonet (eksempelvis grå skrift) for at indikere, at de ikke er valgbare. Vælges disse alligevel, vil en popup menu informere om, at konfigurationen ikke er mulig, dertil vil følge en anbefaling af, hvad der kunne ændres, for at valget kan foretages. For at holde kunden opdateret om hvad de foretagne ændringer har af konsekvens på prisen af det endelige produkt, vil der være en løbende opdatering af det viste urs pris. Med både pris og grafisk opdatering vil ét enkelt brugerinterface være det optimale. Dette vil skabe et overblik over, hvor langt kunden er i konfigurationen og lette en evt. iterativ proces. Side 19

20 Bilag 1 IDEF0 diagram Side 1

21 Bilag 2 Fremtidig proces Den fremtidige proces Side 1

22 Bilag 3 PVM Produkt Variant Master Side 1

23 Bilag 4 Produktionsforløb Side 1

24 Bilag 5 CRC Kort CRC Kort Side 1

25 Bilag 5 CRC Kort Side 2

26 Bilag 5 CRC Kort Side 3

27 Bilag 5 CRC Kort Side 4

28 Bilag 5 CRC Kort Side 5

29 Bilag 5 CRC Kort Side 6

30 Bilag 5 CRC Kort Side 7

31 Bilag 5 CRC Kort Side 8

32 Bilag 5 CRC Kort Side 9