Fremgangsmåde for opbygning af konfigureringssystemer i ...
Fremgangsmåde for opbygning af konfigureringssystemer i ...
Fremgangsmåde for opbygning af konfigureringssystemer i ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong><br />
<strong>konfigureringssystemer</strong> i<br />
byggebranchen, -erfaringsopsamling<br />
Proces analyse<br />
Produkt analyse<br />
Objekt orienteret<br />
analyse og design<br />
Programmering<br />
Implementering<br />
Vedligeholdelse/<br />
videreudvikling<br />
Fase<br />
Benjamin Loer Hansen<br />
Lars Hvam<br />
februar 2005<br />
(sidst editeret 24/2 2005)<br />
........<br />
Version 1. Version 2.<br />
.......<br />
Center <strong>for</strong> Produktmodellering<br />
Institut <strong>for</strong> Produktion og Ledelse<br />
Danmarks Tekniske Universitet<br />
Version n.<br />
Tid<br />
.......
Forord<br />
Nærværende rapport er udarbejdet <strong>af</strong> adjunkt Benjamin Loer Hansen og Lektor Lars<br />
Hvam gennem vinteren 2004-2005. Tak <strong>for</strong> hjælp og input fra<br />
eksamensprojektstuderende Jørgen Christiansen og Anders Haug, Jacob Nielsen og<br />
Christian Christensen, samt parterne i projektet ”Produktkonfigurering i Byggeriet”<br />
(PKB).<br />
Rapporten er skrevet i relation til det halvandet år lange udviklingsprojekt<br />
”Produktkonfigurering i Byggeriet” (PKB). Dette projekt har bl.a. til <strong>for</strong>mål at udvikle<br />
konkrete digitale modeller hos udvalgte producenter i byggebranchen, samt at<br />
<strong>for</strong>bedre metodikken/fremgangsmåden ved <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong><br />
(mere in<strong>for</strong>mation findes i projektansøgningen [Kortegaard&Hvam, 2003], eller hos<br />
projektansvarlige lektor Per Kortegaard, Arkitektskolen i Aarhus).<br />
Formålet med denne rapport er at dokumentere nogle <strong>af</strong> de erfaringer der er gjort<br />
med <strong>opbygning</strong> <strong>af</strong> 3D modellerings/<strong>konfigureringssystemer</strong>. Rapporten søger at give<br />
svar på bl.a. følgende spørgsmål relateret til <strong>konfigureringssystemer</strong>:<br />
• Hvilke erfaringer er der gjort med <strong>konfigureringssystemer</strong> i byggebranchen? Er<br />
der visse <strong>for</strong>udsætninger <strong>for</strong> IT-automatisering, der ikke er opfyldt i samme grad<br />
som i maskinindustrien?<br />
• Hvad er de væsentligste erfaringer med den eksisterende fremgangsmåde?<br />
Målgruppen er primært parterne i PKB-projektet. Sekundært henvender rapporten<br />
sig til andre interesserede producenter <strong>af</strong> bygningskomponenter, arkitekter,<br />
projekterende og udførende, samt universitetsstuderende i relaterede fagområder.<br />
Rapporten er at betragte som et erfaringsopsamlende arbejdsnotat.<br />
1<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Indholds<strong>for</strong>tegnelse<br />
1 Introduktion til problemstillingen .................................................................... 4<br />
1.1 De to fokusområder i PKB............................................................................... 4<br />
1.2 Konkretisering <strong>af</strong> problemstillingen ................................................................. 5<br />
1.2.1 Industrielle specifikationer................................................................................6<br />
1.2.2 Industrielle specifikationsprocesser ...................................................................6<br />
1.2.3 Forudsætningerne <strong>for</strong> at anvende <strong>konfigureringssystemer</strong> ..................................8<br />
1.2.4 Konfigureringssystemer....................................................................................8<br />
1.3 Tilgangsvinkel og undersøgelsesmetode ........................................................ 9<br />
2 <strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> ...................... 11<br />
2.1 Introduktion.................................................................................................... 11<br />
2.1.1 Den objektorienterede projektlivscyklus...........................................................13<br />
2.1.2 Overblik over fremgangsmåden ......................................................................14<br />
2.1.3 Iterative <strong>for</strong>løb ..............................................................................................16<br />
2.1.4 Roller i udviklings<strong>for</strong>løbet ...............................................................................18<br />
2.2 <strong>Fremgangsmåde</strong>ns faser .............................................................................. 20<br />
2.2.1 Forretningsmæssig analyse ............................................................................20<br />
2.2.2 Produktanalyse..............................................................................................21<br />
2.2.3 Objektorienteret analyse og design .................................................................22<br />
2.2.4 Programmering .............................................................................................26<br />
2.2.5 Implementering.............................................................................................27<br />
2.2.6 Vedligeholdelse og videreudvikling ..................................................................27<br />
2.3 Afrunding....................................................................................................... 29<br />
3 Erfaringer ......................................................................................................... 30<br />
3.1 Erfaringer med <strong>for</strong>udsætninger <strong>for</strong> <strong>konfigureringssystemer</strong> .......................... 30<br />
3.1.1 Produktstandardisering og prædefineret varians...............................................31<br />
3.1.2 Markedsrationale <strong>for</strong> at standardisere..............................................................35<br />
3.1.3 Stor omsætning <strong>af</strong> tilbud eller ordrer...............................................................36<br />
3.1.4 Automatiseringsteknologi ...............................................................................37<br />
3.1.5 Geometri-tilpasning i variantskabelsen og krav om tegninger ............................38<br />
3.1.6 Afrunding <strong>af</strong> de generelle erfaringer................................................................40<br />
3.2 Erfaring med selve fremgangsmåden ........................................................... 42<br />
3.2.1 <strong>Fremgangsmåde</strong>n og nye <strong>for</strong>udsætninger........................................................42<br />
3.2.2 Projekt-”scoping” og iterationer ......................................................................42<br />
3.2.3 Fase 1: Procesanalyse....................................................................................43<br />
3.2.4 Fase 2: Produktanalyse..................................................................................47<br />
3.2.5 Fase 3-4: Objektorienteret Analyse og Design..................................................49<br />
3.2.6 Fase 5: Programmering..................................................................................55<br />
3.2.7 Fase 6: Implementering.................................................................................57<br />
3.2.8 Afslutning på erfaringer med fremgangsmåden ................................................57<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
2
4 Konklusion og perspektivering...................................................................... 58<br />
4.1 Konklusion..................................................................................................... 58<br />
4.2 Perspektivering.............................................................................................. 58<br />
5 Litteraturliste ................................................................................................... 60<br />
3<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
1 Introduktion til problemstillingen<br />
Der arbejdes generelt med industrialisering <strong>af</strong> byggeriet og anvendelse <strong>af</strong> digitale 3D<br />
modeller gennem flere udviklingsprojekter. I Danmark er det store udviklingsprojekt<br />
p.t. (2004) ”Det Digitale Byggeri”, der er initieret <strong>af</strong> Erhvervs- og byggestyrelsens<br />
sammen med branchens egen organisation: bips (”byggeri, in<strong>for</strong>matik, produktivitet,<br />
samarbejde”) [bips nyt, 2003].<br />
I Finland er der gennem flere år arbejdet målrettet med effektivisering <strong>af</strong><br />
byggebranchen, bl.a. under projektet ProIT [PRO IT News, 2003].<br />
Projektet ”Produktkonfigurering i Byggeriet” (PKB) arbejder også med<br />
industrialisering <strong>af</strong> byggeriet. Fokusområdet i PKB er skabelsen <strong>af</strong> digitale<br />
bygningskomponentmodeller, samt automatisk generering <strong>af</strong> tilhørende<br />
specifikationer (dokumenter) så som tilbud, styklister, tegninger, mm. Mere<br />
in<strong>for</strong>mation herom findes i projektansøgningen [Kortegaard&Hvam, 2003], eller hos<br />
projektansvarlige lektor Per Kortegaard fra Arkitektskolen i Aarhus.<br />
1.1 De to fokusområder i PKB<br />
I projektet tages der udgangspunkt i to overordnede niveauer i en byggeproces,<br />
nemlig den tidlige arkitektoniske skitseringsfase (interesseområde <strong>for</strong> Arkitektskolen i<br />
Århus), samt den senere gennemførelsesfase (interesseområde <strong>for</strong> Institut <strong>for</strong><br />
Produktion og Ledelse, DTU).<br />
De to overordnede fokusområder i PKB er således meget kort skitseret som følgende:<br />
1. I den tidlige arkitektoniske designfase er det intentionen, at arkitekter gennem<br />
anvendelse <strong>af</strong> overordnede produktmodeller vil være i stand til, at <strong>for</strong>etage bedre<br />
disponeringer mht. gennemførligheden <strong>af</strong> byggeriets arkitektur. Forudsætningen <strong>for</strong><br />
at dette kan lade sig gøre er, at arkitekter har de rette IT-værktøjer til at opbygge<br />
digitale modeller <strong>af</strong> byggeriet (f.eks. ArchiCAD eller AutoCAD/Architechtural Desktop)<br />
samt, at arkitekterne i relation hertil har adgang til et stort udvalg <strong>af</strong> digitale<br />
komponentmodeller <strong>af</strong> f.eks. vinduer, døre, trapper mm. Til at understøtte denne<br />
fase skal komponentleverandører således tilbyde produktmodeller og<br />
produktin<strong>for</strong>mation, på et overordnet niveau, tilgængeligt <strong>for</strong> arkitekter mm.<br />
Antagelsen er, at der her vil kunne anvendes GDL modeller eller lignende, der<br />
tilbydes i produktkataloger på Internettet.<br />
Arkitektskolen i Aarhus står <strong>for</strong> dette fokusområde. Dette er nærmere beskrevet i<br />
projektansøgningen til PKB (som ”fase 1”). Dette er illustreret i Figur 1 (til venstre i<br />
figuren) i denne note.<br />
2A. I byggeriets mere detaljerede designfaser vil der være et behov <strong>for</strong> mere<br />
detaljerede digitale produktmodeller, samt hurtig udarbejdelse <strong>af</strong> kontraktbindende<br />
tilbud. Antagelsen er, at dette kan imødekommes gennem anvendelsen <strong>af</strong><br />
<strong>konfigureringssystemer</strong>, der automatisk kan generere digitale 3D modeller, samt<br />
ønsket produktin<strong>for</strong>mation i dokument<strong>for</strong>m (tilbudsbreve, tegninger og styklister<br />
mm.)<br />
2B. Ved byggeriets gennemførelse, efter kontraktindgåelse, skal der fra<br />
komponentleverandørernes side udarbejdes det interne produktionsgrundlag. Her<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
4
skal der udarbejdes en række produktionsspecifikationer, til internt brug, f.eks.<br />
produktionstegninger, styklister, rutebeskrivelser mm. Antagelsen er, at dette kan<br />
understøttes ved <strong>konfigureringssystemer</strong>, der automatisk genererer de ønskede<br />
produktionsdokumenter.<br />
2C. Endelig kan der være tale om, at der til dokumentation og vedligeholdelse <strong>af</strong> det<br />
færdige byggeri skal fremstilles detaljerede digitale 3D modeller og tilhørende<br />
produktin<strong>for</strong>mation. Som <strong>for</strong> de to <strong>for</strong>egående faser antages dette at kunne<br />
understøttes med <strong>konfigureringssystemer</strong>.<br />
Figur 1: Skitsering <strong>af</strong> en digital byggeproces der understøttes med IT (f.eks. GDL<br />
og 3D <strong>konfigureringssystemer</strong>).<br />
De beskrevne faser 2A, 2B og 2C (illustreret i midten og til højre i Figur 1) varetages<br />
primært <strong>af</strong> Center <strong>for</strong> Produktmodellering på DTU. Nærværende rapport er<br />
udarbejdet i relation hertil.<br />
1.2 Konkretisering <strong>af</strong> problemstillingen<br />
For at give læsere, med begrænset faglig indsigt, en introduktion til emnet gives i<br />
det følgende en meget kort skitsering <strong>af</strong> problemdomænet. Dette gøres ved en kort<br />
gennemgang <strong>af</strong>:<br />
• Industrielle specifikationer<br />
• Industrielle specifikationsprocesser<br />
• Forudsætninger <strong>for</strong> elektronisk konfigurering<br />
• Et eksempel på et konfigureringssystem<br />
5<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
1.2.1 Industrielle specifikationer<br />
Specifikationer har gennem årtusinder været brugt i <strong>for</strong>bindelse med<br />
konstruktionsarbejde. Ved bygningen <strong>af</strong> de ægyptiske pyramider, romerske<br />
akvædukter og middelalderlige katedraler er der anvendt diverse tegninger og<br />
skitser, der alle kan karakteriseres som specifikationer.<br />
Specifikationer indeholder in<strong>for</strong>mation, der beskriver hvad der skal udføres og/eller<br />
hvordan noget skal udføres. I industrielle virksomheder kaldes beskrivelser <strong>af</strong><br />
markedsbehov, produkter, processer, metoder, produktionsudstyr, service mm. <strong>for</strong><br />
industrielle specifikationer. Disse specifikationer anvendes i den fysiske<br />
fremstillingsproces. En specifikation kan repræsenteres gennem verbale beskrivelser,<br />
tegninger, diagrammer, fotogr<strong>af</strong>ier, fysiske repræsentationer (miniaturemodeller),<br />
digitale modeller etc.<br />
De mest typiske specifikationstyper, der anvendes i produktionsvirksomheder er<br />
bl.a.:<br />
• Behovsspecifikation<br />
• Ordrespecificering<br />
• Samlingstegninger<br />
• Detailtegninger<br />
• Styklister<br />
• Materialespecifikationer<br />
• Processpecifikationer<br />
• Operationsnetværk<br />
• Montagespecifikationer<br />
• etc.<br />
I nærværende rapports Figur 18 og Figur 19 ses eksempler på styklister og<br />
tegninger.<br />
1.2.2 Industrielle specifikationsprocesser<br />
Skabelsen <strong>af</strong> specifikationer i industrielle virksomheder <strong>for</strong>egår på 2 niveauer. Det<br />
ene niveau er i <strong>for</strong>bindelse med udvikling <strong>af</strong> nye produkter og produktions<strong>for</strong>mer<br />
<strong>for</strong>ud <strong>for</strong> kundebehandling. Det andet omfatter specifikationer, der skabes i<br />
<strong>for</strong>bindelse med tilbudsgivning og ordregennemførelse i den daglige drift. De<br />
specifikationer, der skabes i driften (niveau 2) er som regel varianter <strong>af</strong> de mere<br />
generelle specifikationer, ud<strong>for</strong>met i udviklingen (niveau 1). Disse<br />
specifikationsprocesser kan der<strong>for</strong> betegnes variant-specifikationsprocesser, men<br />
som regel udelades variant-betegnelsen.<br />
Opgaven med at udarbejde kundetilpassede specifikationer kan illustreres gennem<br />
følgende eksempel: En ikke navngiven producent <strong>af</strong> industriporte skaber en række<br />
specifikationer i ordrebehandlings<strong>for</strong>løbet (i specifikationsprocesserne). Nogle<br />
specifikationer udarbejdes til den eksterne kunde, mens andre udarbejdes til<br />
produktionen.<br />
I <strong>for</strong>bindelse med tilbudsgivning skal der typisk fremstilles følgende specifikationer:<br />
• Behovsspecifikation: Indeholder en kort beskrivelse <strong>af</strong> de behov kunden har,<br />
bl.a. ydre dimensioner, krav til døre og vinduer i porten, krav til<br />
klimaskjold/materialer etc.<br />
• Budgettilbud: Denne type tilbud indeholder en hovedmålstegning <strong>af</strong> porten<br />
og en pris der er +/- 20% nøjagtig.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
6
7<br />
• Kontrakttilbud: Denne specifikation er det egentlige tilbud, der indeholder<br />
hovedmålstegning, relevante detailtegninger, tekniske specifikationer,<br />
juridiske <strong>for</strong>hold, samt leverings<strong>for</strong>hold, samt pris.<br />
Efter accepteret kontrakttilbud startes processen med at skabe<br />
produktionsgrundlaget. Dette indbefatter en fremstilling <strong>af</strong> følgende specifikationer:<br />
• Produktionsstykliste<br />
• Diverse produktionstegninger<br />
• Klippelister <strong>for</strong> aluminiumsbearbejdning<br />
• Operationsbeskrivelser med tider<br />
• Teknisk produktbeskrivelse og servicemanual til kunden<br />
Udviklingssystem / Forberedende system<br />
Driftssystem<br />
Behovsspec<br />
Produktstandardisering<br />
Behov Salg<br />
Konstruktion<br />
specifikation<br />
230<br />
Budgettilbud<br />
Kontrakttilbud<br />
Standarder<br />
Grundtegninger<br />
Gamle spec. specifikation<br />
specifikation<br />
230<br />
specifikation<br />
230<br />
specifikation<br />
230<br />
Tegninger<br />
Tekniske spec.<br />
Tegninger<br />
Kons. stykliste<br />
specifikation<br />
230<br />
specifikation<br />
230<br />
230<br />
Metode<br />
planlæging<br />
Teknisk<br />
produktbeskrivelse<br />
Servicebeskrivelse<br />
Produktionsteknisk<br />
udvikling<br />
Standarder<br />
Værktøjsspecifikationer<br />
Layout<br />
Gamle specifikationer<br />
Produktion<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
specifikation<br />
230<br />
Brug<br />
Produktionsstykliste<br />
Klippeliste<br />
Operationsbeskrivelse<br />
Rutebeskrivelse<br />
Forsendelsesstykliste<br />
Produkt<br />
Figur 2: Eksempel på specifikationer og variantspecifikationsprocesser (markeret<br />
med gråt) i en virksomhed, der kundetilpassede produkter.<br />
For næsten alle specifikationers vedkommende er der tale om en tilpasning <strong>af</strong><br />
eksisterende specifikationer, der er skabt i udviklings<strong>af</strong>delingen (se Figur 2).<br />
En anden virksomhed (Figur 3) vælger at fremstille langt mere standardiserede<br />
porte. En konsekvens her<strong>af</strong> er, at der stort set ikke <strong>for</strong>etages specificering i<br />
driftssystemet. Næsten alle specifikationer er defineret <strong>for</strong>ud <strong>for</strong> kundeordren, og<br />
skal stort set blot ”tages ned fra hylden” når en ordre indtræffer. Der<strong>for</strong> er<br />
ordrebehandlingen meget hurtigere og nemmere. På den anden side må kunden<br />
<strong>af</strong>finde sig med standardløsninger.
Udviklingssystem / Forberedende system<br />
specifikation<br />
230<br />
Produktbrochure<br />
Prislister<br />
Driftssystem<br />
Behov<br />
specifikation<br />
230<br />
Marketing<br />
Salg<br />
Ordre<br />
specifikation<br />
230<br />
Tegninger<br />
Produktudvikling<br />
specifikation<br />
230<br />
specifikation<br />
230<br />
Produktions<strong>for</strong>beredelse<br />
Tegninger<br />
Materialespec.<br />
Styklister<br />
Produktionsordre<br />
Produktionsteknisk<br />
udvikling<br />
Produktion<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
specifikation<br />
230<br />
Produktionsstykliste<br />
Klippeliste<br />
Operationsbeskrivelse<br />
Rutebeskrivelse<br />
Forsendelsesstykliste<br />
Brug<br />
Fra udvikling:<br />
Teknisk<br />
produktbeskrivelse<br />
Servicebeskrivelse<br />
Figur 3: Eksempel på specifikationer og specifikationsprocesser i en virksomhed,<br />
der laver meget standardiserede produkter.<br />
Disse to eksempler illustrerer således <strong>for</strong>skellige specifikationsprocesser (markeret<br />
med grå). Endvidere illustreres det, at der kan være tale om <strong>for</strong>skellige grader <strong>af</strong><br />
variantskabelse. Nogle virksomheder leverer standard produkter, andre laver en<br />
smule tilpasning, mens andre <strong>for</strong>etager en stor grad <strong>af</strong> tilpasning i<br />
ordrebehandlingen. Graddelingen er central og behandles særskilt senere (ved Figur<br />
14 og Figur 15).<br />
1.2.3 Forudsætningerne <strong>for</strong> at anvende <strong>konfigureringssystemer</strong><br />
Som udgangspunkt er der de samme <strong>for</strong>udsætninger <strong>for</strong> at automatisere<br />
specifikationsprocesser, som fysiske produktionsprocesser:<br />
• Der skal være ensartede og veldefinerede specifikationsaktiviteter, der<br />
gentages med en høj hyppighed.<br />
• Der skal være en velegnet teknologi (konfigureringssoftware), der muliggør<br />
en lønsom automatisering <strong>af</strong> specifikationsaktiviteterne.<br />
Når man ønsker at automatisere specifikationsprocesser er det der<strong>for</strong> relevant at<br />
undersøge:<br />
• Er der tale om ensartede og veldefinerede specifikationsaktiviteter? I hvilken<br />
grad er dette overholdt?<br />
• Er der tale om høj hyppighed?<br />
• Findes der velegnet software?<br />
Disse spørgsmål diskuteres løbende i nærværende rapport.<br />
1.2.4 Konfigureringssystemer<br />
Begge producenter nævnt oven<strong>for</strong> kan vælge at automatisere<br />
specifikationsprocesserne med IT. Et konfigureringssystem vil, <strong>af</strong>hængigt <strong>af</strong><br />
ud<strong>for</strong>mningen, kunne udarbejde en eller flere <strong>af</strong> de specifikationer, der normalt<br />
udarbejdes i virksomhedens specifikationsprocesser.<br />
specifikation<br />
230<br />
8
Ved anvendelse <strong>af</strong> et konfigureringssystem kan en ikke-ekspert svare på diverse<br />
spørgsmål omkring ønskede dimensioner, materialer, farver etc. , mens<br />
konfigureringssystemet begrænser ulovlige valg. Når brugeren har svaret på alle<br />
spørgsmålene, vil systemet være i stand til selv, at genere en eller flere <strong>af</strong> de<br />
specifikationer, som man ellers ville udarbejde manuelt, f.eks. tilbudsbrev, tegning<br />
og stykliste.<br />
Som et eksempel på et konfigureringssystem er der nedenstående vist et simpelt<br />
system fra Dolle. Ved anvendelse <strong>af</strong> dette konfigureringssystem kan en slutbruger<br />
designe sin egen trappe og få et udarbejdet et tilbud automatisk.<br />
Figur 4: Illustration <strong>af</strong> et simpelt konfigureringssystem (skærmbillede ved<br />
indtastning <strong>af</strong> ønsker, fra www.dolle.dk).<br />
1.3 Tilgangsvinkel og undersøgelsesmetode<br />
PKB projektet har h<strong>af</strong>t en praktisk tilgangsvinkel. Fokus har været på at opbygge<br />
prototyper i de tilknyttede virksomheder og in<strong>for</strong>mere om produktkonfigurering og<br />
3D modellering. Der var ikke opstillet egentlige <strong>for</strong>skningshypoteser.<br />
Metodikken til at opnå de erkendelser, der fremgår i nærværende rapport har<br />
således været følgende:<br />
• Det er som udgangspunkt antaget, at den eksisterende fremgangsmåde <strong>for</strong><br />
udvikling <strong>af</strong> <strong>konfigureringssystemer</strong> er brugbar.<br />
• <strong>Fremgangsmåde</strong>n er anvendt i en række virksomheder tilknyttet projektet.<br />
• Erfaringer fra tilsvarende konfigureringsprojekter uden <strong>for</strong> PKB regi er<br />
anvendt som et supplement til egne erfaringer.<br />
9<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
• Erfaringer er løbende opnået, analyseret og dokumenteret.<br />
På baggrund her<strong>af</strong> er der udarbejdet nærværende rapport. Rapporten er opdelt som<br />
følgende:<br />
• Først gives en kort beskrivelse <strong>af</strong> den anvendte fremgangsmåde.<br />
• Herefter beskrives de generelle erfaringer med <strong>konfigureringssystemer</strong> i<br />
byggebranchen og <strong>for</strong>udsætningerne her<strong>for</strong>.<br />
• Derefter beskrives de specifikke erfaringer med fremgangsmåden.<br />
• Endelig gives en konklusion på erfaringerne.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
10
2 <strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong><br />
<strong>konfigureringssystemer</strong><br />
I dette kapitel gives en kort gennemgang <strong>af</strong> den fremgangsmåde, der gennem flere<br />
år har været anvendt i konfigureringsprojekter relaterede til DTU [Hvam et al.,<br />
2004].<br />
Hensigten med kapitlet er at give en kort oversigt over fremgangsmåden og dens<br />
værktøjer, <strong>for</strong> herefter i de næste kapitler, at gå i detaljer med konkrete erfaringer.<br />
Det er således i nærværende note besluttet ikke, at lave en ny beskrivelse <strong>af</strong><br />
fremgangsmåden, men at anvende eksisterende beskrivelser. Nærværende kapitel er<br />
således direkte ”klippet” fra [Hvam et al, 2004] og tilpasset nærværende note, -med<br />
tilladelse fra <strong>for</strong>fatterne. For nærmere indsigt i fremgangsmådens værktøjer henvises<br />
interesserede læsere således til [Hvam et al, 2004].<br />
2.1 Introduktion<br />
Nærværende fremgangsmåde skal bidrage til at strukturere arbejdet med at<br />
indfange og <strong>for</strong>malisere viden og in<strong>for</strong>mation om produkter og deres eventuelle<br />
livsfasesystemer. Ved at anvende fremgangsmåden skal man kunne:<br />
• Udlede de <strong>for</strong>retningsmæssige krav til det konfigureringssystem, der skal<br />
opbygges.<br />
• Analysere og definere produkternes funktion, struktur og relevante<br />
livsfasesystemer.<br />
• Udtrykke produktviden i en <strong>for</strong>m, så den kan lægges ind i et IT-system.<br />
• Sikre at det opbyggede konfigureringssystem løbende kan vedligeholdes og<br />
videreudvikles.<br />
Desuden skal fremgangsmåden bidrage til at håndtere de organisatoriske ændringer,<br />
der finder sted når viden <strong>for</strong>maliseres og lægges ind i et konfigureringssystem.<br />
<strong>Fremgangsmåde</strong>n bygger på teori og metoder fra en række <strong>for</strong>skellige fagområder:<br />
• Mass Customization og modularisering <strong>af</strong> produkter<br />
• Rekonstruktion <strong>af</strong> <strong>for</strong>retningsprocesser (Business Process Reengineering)<br />
• Produktudvikling og viden om livsfasesystemer, f.eks. produktion og montage<br />
• Arkitektur <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> produktmodelsystemer<br />
• Modelleringsteknikker, f.eks. objektorienteret modellering<br />
• Metoder <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> IT-systemer, dvs. objektorienteret modellering og<br />
anvendelse <strong>af</strong> ekspertsystemer.<br />
• Organisatoriske <strong>for</strong>hold ved <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong>.<br />
Som en introduktion til fremgangsmåden beskrives kort en generel fremgangsmåde<br />
<strong>for</strong> udvikling <strong>af</strong> IT-systemer. Forløbet ved udvikling og drift <strong>af</strong> IT-systemer er vist i<br />
nedenstående Figur 5 i <strong>for</strong>m <strong>af</strong> den såkaldte projektlivscyklus.<br />
11<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Vedligeholdelse og<br />
videreudvikling<br />
Implementering<br />
Vedligehold<br />
& opfølgning<br />
Indførelse &<br />
brugeraccept<br />
Integration &<br />
validering<br />
Programmering<br />
Problemanalyse<br />
Konstruktion<br />
& verifikation<br />
Analyse<br />
Kravspecifikation<br />
Skitsedesign<br />
Detaildesign<br />
Design<br />
Figur 5: Projektlivscyklus ved udvikling <strong>af</strong> et IT-system.<br />
Et projekt vedr. udvikling og drift <strong>af</strong> et IT-system gennemløber hovedfaserne:<br />
• Analyse og indledende funktionel kravspecifikation<br />
• Design <strong>af</strong> løsning/ overordnet skitse <strong>af</strong> systemet<br />
• Programmering og test<br />
• Implementering<br />
• Vedligeholdelse/ videreudvikling.<br />
Den viste projektlivscyklus er første gang beskrevet i det amerikanske<br />
udviklingsprojekt ICAM (Integrated Computer Aided Manufacturing) omkring 1980. I<br />
ICAM-projektet er der, <strong>for</strong> at understøtte faserne analyse og design <strong>af</strong> IT-systemer,<br />
udviklet teknikker til modellering <strong>af</strong> aktivitets<strong>for</strong>løb (IDEF0) og in<strong>for</strong>mationsstruktur<br />
(IDEF1).<br />
På den tid anvendtes <strong>for</strong>skellig struktur og notation i de enkelte faser. I analysefasen<br />
anvendes funktionsmodellering (IDEF0), mens der i designfasen anvendtes f.eks.<br />
IDEF1 modellering og traditionel dat<strong>af</strong>low-diagrammering, og i det detaljerede<br />
design f.eks. pseudoprogrammering.<br />
Forløbet er vist som en cyklus ud fra den betragtning, at der ved vedligeholdelse og<br />
videreudvikling <strong>af</strong> systemet gennemløbes en ny cyklus i projektlivscyklen, idet der<br />
gennemføres de samme aktiviteter, som ved <strong>opbygning</strong> <strong>af</strong> den første version <strong>af</strong><br />
systemet. Arbejds<strong>for</strong>løbet kan således gennemføres vilkårligt mange gange i et givet<br />
domæne, idet det grundlæggende er de samme aktiviteter, der skal udføres, hvad<br />
enten det er udvikling <strong>af</strong> et nyt system eller ændring <strong>af</strong> et eksisterende system.<br />
Begrundelsen <strong>for</strong> at introducere projektlivscyklen var et ønske om, at opnå en mere<br />
struktureret fremgangsmåde ved udvikling <strong>af</strong> IT-systemer. Ved projektlivscyklen<br />
lægges vægt på at der gennemføres analyse og design, hvor systemets indhold og<br />
struktur fastlægges og evalueres inden det egentlige programmeringsarbejde<br />
igangsættes.<br />
Derved reduceres de samlede omkostninger ved udviklingsarbejdet, idet den større<br />
arbejdsindsats ved analyse og design, som vist i Figur 6 som regel medfører en<br />
væsentlig reduktion <strong>af</strong> indsatsen ved programmering, implementering og især<br />
vedligeholdelse og videreudvikling <strong>af</strong> systemet. Det bliver ofte umuligt at<br />
vedligeholde og videreudvikle et IT-system, der ikke er struktureret og<br />
dokumenteret.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
12
13<br />
RESSOURCE-<br />
INDSATS<br />
Analyser problem<br />
Problemanalyse<br />
Kravspecifikation<br />
Formuler og<br />
tilpas løsning<br />
Skitsedesign<br />
Detaljeret design<br />
Traditionel<br />
fremgangsmåde<br />
Struktureret<br />
fremgangsmåde<br />
Byg og indfør løsning<br />
Opbygning og <strong>af</strong>prøvning<br />
Integration og validering<br />
Implementer og<br />
vedligehold løsning<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
TID<br />
Implementering og brugeraccept<br />
Vedligeholdelse og support<br />
Figur 6: Besparelse ved anvendelse <strong>af</strong> en struktureret fremgangsmåde.<br />
Den beskrevne projektlivscyklus bidrager til en strukturering og opdeling <strong>af</strong> arbejdet<br />
med udvikling <strong>af</strong> IT-systemer, og omfatter såvel den tekniske som den<br />
ledelsesmæssige side <strong>af</strong> udviklingsarbejdet. Dvs. projektlivscyklen dels understøtter<br />
de tekniske aktiviteter med udvikling <strong>af</strong> IT-systemer og dels er et ledelsesredskab til<br />
styring og organisering <strong>af</strong> større udviklingsprojekter, idet projekterne kan nedbrydes<br />
i en række delaktiviteter med et veldefineret resultat, f.eks. udarbejdelse <strong>af</strong> AS-IS<br />
model, udarbejdelse <strong>af</strong> TO-BE model, <strong>for</strong>eløbigt design osv.<br />
2.1.1 Den objektorienterede projektlivscyklus<br />
Det objektorienterede paradigme <strong>for</strong> systemudvikling søger at integrere de enkelte<br />
faser i projektlivscyklen, ved, tidligt i analysefasen, at identificere objektklasser i det<br />
domæne systemet omfatter. En objektklasse kan beskrives som en samling <strong>af</strong><br />
objekter med fælles karakteristika (attributter) og fælles adfærd (metoder).<br />
Eksempelvis kan objektklassen biler opfattes som en samlet betegnelse <strong>for</strong> alle biler.<br />
Klassen biler har en række karakteristika, der identificerer biler, f.eks. fabrikat,<br />
motorstørrelse, vægt mv. Desuden kan klassen biler tildeles en adfærd, hvor den<br />
f.eks. kan beregne bilens vægt<strong>af</strong>gift som funktion <strong>af</strong> bilens vægt og benzin<strong>for</strong>brug.<br />
Objektklasser repræsenteres IT-mæssigt som et selvstændigt stykke program, der<br />
indeholder attributter (variable) og metoder (procedurer).<br />
De identificerede objektklasser udvikles og detaljeres gennem samtlige faser i<br />
projektlivscyklen, der i øvrigt indeholder de samme faser som ICAM´s<br />
projektlivscyklus:<br />
• Analyse<br />
• Design<br />
• Udvikling/ implementering<br />
• Ændring/ vedligeholdelse
I nedenstående Figur 7 er vist den objektorienterede projektlivscyklus, der<br />
sammenlignet med ICAM´s projektlivscyklus giver mulighed <strong>for</strong> lettere at springe<br />
rundt mellem de enkelte faser i systemudviklingen. Dette skyldes at der, i<br />
modsætning til tidligere, hvor systemudviklere måtte skifte repræsentations<strong>for</strong>m<br />
mellem de enkelte faser, anvendes samme opdeling og grundlæggende<br />
repræsentations<strong>for</strong>m gennem samtlige faser i systemudviklingen - det er de samme<br />
objektklasser, der optræder gennem de enkelte faser i projektlivscyklen.<br />
Analysis<br />
Design<br />
Evolution<br />
Modification<br />
Figur 7: Den objektorienterede projektlivscyklus.<br />
Med pilenes overlap og de tilbageførende pile er det <strong>for</strong>søgt at vise, at<br />
systemudvikling baseret på det objektorienterede paradigme, giver bedre mulighed<br />
<strong>for</strong>, som nævnt, at springe mellem de enkelte faser i projektlivscyklen. De<br />
grundlæggende principper ved objektorienteret modellering er uddybende beskrevet<br />
i de følgende kapitler.<br />
2.1.2 Overblik over fremgangsmåden<br />
Med udgangspunkt i den objektorienterede projektlivscyklus beskrives i det følgende<br />
en fremgangsmåde <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong>. <strong>Fremgangsmåde</strong>n<br />
indeholder bl.a. metoder til at analysere de <strong>for</strong>retningsprocesser, der skal<br />
understøttes <strong>af</strong> <strong>konfigureringssystemer</strong>, samt metoder til analyse og modellering <strong>af</strong><br />
et produktsortiment. I nedenstående Figur 8 er vist fremgangsmåden <strong>for</strong> <strong>opbygning</strong><br />
og implementering <strong>af</strong> <strong>konfigureringssystemer</strong>.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
14
15<br />
Fase Indhold Resultat<br />
Karakteristik <strong>af</strong> de vigtigste specifikationsprocesser.<br />
Mål og krav <strong>for</strong> de enkelte specifikationsprocesser.<br />
1 Procesanalyse Identifikation og karakteristik <strong>af</strong> de vigtigste<br />
specifikationsprocesser.<br />
Scenarier i <strong>for</strong>m <strong>af</strong> beskrivelse <strong>af</strong> fremtidige<br />
specifikationsprocesser, samt definition <strong>af</strong> de<br />
<strong>konfigureringssystemer</strong>, der skal understøtte de enkelte<br />
specifikationsprocesser.<br />
Formulering <strong>af</strong> mål og krav til de enkelte<br />
specifikationsprocesser. Måling og gabanalyse.<br />
Konstruktion <strong>af</strong> ny specifikationsproces. Definition<br />
<strong>af</strong> de (t) konfigureringssystem(er), der skal<br />
understøtte specifikationsprocessen.<br />
Evaluering/ måling <strong>af</strong> de enkelte scenariers effekt. Valg<br />
<strong>af</strong> scenario.<br />
Handlingsplan og plan <strong>for</strong> organisering <strong>af</strong> det videre<br />
arbejde.<br />
Vurdering og valg <strong>af</strong> scenario.<br />
Handlingsplan og organisering <strong>af</strong> det videre<br />
arbejde.<br />
Definition <strong>af</strong> konfigureringssystemets overordnede<br />
indhold og struktur. Produktvariantmaster.<br />
2 Produktanalyse Analyse <strong>af</strong> produktsortiment. Definition <strong>af</strong><br />
konfigureringssystemets overordnede indhold og<br />
struktur. Opbygning <strong>af</strong> produktvariantmaster.<br />
OOA-model (evt. dynamik).<br />
Brugergrænseflade. Kravspecifikation.<br />
Opbygning <strong>af</strong> objektorienteret analysemodel<br />
(OOA).<br />
3 Objektorienteret<br />
analyse<br />
Valg <strong>af</strong> konfigureringssoftware. En tilpasset OOAmodel<br />
(OOD-model). Kravspecifikation til programmering.<br />
Valg <strong>af</strong> konfigureringssoftware. Tilpasning <strong>af</strong><br />
OOA-model til det valgte konfigureringssoftware.<br />
Opstilling <strong>af</strong> kravspecifikation til programmering,<br />
herunder brugergrænseflade, integration til andre<br />
systemer og programdynamik.<br />
4 Objektorienteret<br />
design<br />
Figur 8: <strong>Fremgangsmåde</strong>n.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
5 Programmering Programmering og test. Et færdigprogrammeret konfigureringssystem.<br />
Brugervejledning og uddannelsesplan.<br />
6 Implementering Implementering <strong>af</strong> konfigureringssystem og den<br />
fremtidige specifikationsproces.<br />
Målinger <strong>af</strong> den nye specifikationsproces’ per<strong>for</strong>mans.<br />
Opdateret OOA-model og programkode. Ansvarlige <strong>for</strong><br />
vedligeholdelse og videreudvikling.<br />
7 Vedligeholdelse Måling og opfølgning på den nye<br />
specifikationsproces. Vedligeholdelse og løbende<br />
videreudvikling <strong>af</strong> konfigureringssystem. Udpege<br />
ansvarlige <strong>for</strong> vedligeholdelse og videreudvikling.
Den første fase i fremgangsmåden omfatter en identifikation <strong>af</strong> de vigtigste<br />
specifikationsprocesser og en analyse <strong>af</strong> mål og øvrige krav til de<br />
specifikationsprocesser, der skal understøttes <strong>af</strong> <strong>konfigureringssystemer</strong>.<br />
Specifikationsprocesserne beskrives og de <strong>for</strong>retningsmæssige krav til processerne<br />
analyseres i <strong>for</strong>hold til virksomhedens <strong>for</strong>retningsstrategi. I <strong>for</strong>længelse her<strong>af</strong><br />
udarbejdes scenarier <strong>for</strong> de fremtidige specifikationsprocesser, og ved anvendelse <strong>af</strong><br />
rammesystemet beskrevet i kapitel 2 [Hvam et. al., 2004] <strong>for</strong>etages en <strong>af</strong>grænsning<br />
<strong>af</strong> det overordnede indhold <strong>af</strong> de <strong>konfigureringssystemer</strong>, der skal udvikles til at<br />
understøtte de fremtidige specifikationsprocesser. Dette udgør grundlaget <strong>for</strong><br />
produktanalysen i fase 2, hvor modellernes indhold og struktur beskrives mere<br />
detaljeret ud fra en analyse <strong>af</strong> virksomhedens produktsortiment, og eventuelt<br />
tilhørende livsfase-systemer (f.eks. produktion, montage, <strong>for</strong>sendelse, anvendelse og<br />
skrotning). Som <strong>af</strong>slutning på fase 1 <strong>for</strong>etages en vurdering <strong>af</strong> de enkelte scenarier,<br />
og en udvælgelse <strong>af</strong> det scenarie man ønsker at arbejde videre med. Som grundlag<br />
<strong>for</strong> det videre arbejde opstilles et budget og en handlingsplan <strong>for</strong> det videre arbejde.<br />
I fase 2 analyseres produkterne ved at tegne produktsortimentet op i en såkaldt<br />
produktvariantmaster (en beskrivelse <strong>af</strong> produktets <strong>opbygning</strong> i <strong>for</strong>m <strong>af</strong><br />
parter/moduler, variationer inden<strong>for</strong> de enkelte parter/ moduler, samt relationer<br />
mellem parter/ moduler). Formålet med analysen er at opnå et samlet overblik over<br />
de enkelte produktfamilier og deres mulige variationer. Desuden bidrager<br />
produktvariantmasteren til at sikre at <strong>for</strong>skellige personer i virksomheden får en<br />
fælles opfattelse <strong>af</strong> produktsortimentets struktur og variationsmuligheder.<br />
I <strong>for</strong>bindelse med den detaljerede modellering <strong>af</strong> selve IT-systemet anvendes<br />
objektorienteret modellering. Den opbyggede produktvariantmaster tjener som<br />
grundlag <strong>for</strong> identificering <strong>af</strong> objektklasser og klassehierarkier. Detaljer vedr. de<br />
enkelte objektklasser beskrives vha. såkaldte klasse-beskrivelseskort (CRC-kort). Den<br />
objektorienterede model danner grundlag <strong>for</strong> at modellerne kan programmeres. I<br />
fase 4, objektorienteret design, <strong>for</strong>etages et valg <strong>af</strong> konfigureringssoftware. Desuden<br />
fastlægges øvrige krav i <strong>for</strong>hold til programmering <strong>af</strong> konfigureringssystemet som<br />
eksempelvis programdynamik, brugergrænseflade og integration til øvrige ITsystemer<br />
som eksempelvis virksomhedens ERP-system.<br />
Når konfigureringssystemet er programmeret og implementeret i organisationen<br />
kommer den vanskelige fase med at vedligeholde og løbende videreudvikle<br />
konfigureringssystemet.<br />
2.1.3 Iterative <strong>for</strong>løb<br />
I nedenstående Figur 9 er vist <strong>for</strong>løbet ved <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong>.<br />
Som det fremgår <strong>af</strong> figuren vil man normalt gennemløbe fremgangsmådens faser et<br />
antal gange ved <strong>opbygning</strong>, implementering og vedligeholdelse <strong>af</strong><br />
<strong>konfigureringssystemer</strong>.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
16
17<br />
Proces analyse<br />
Produkt analyse<br />
Objekt orienteret<br />
analyse og design<br />
Programmering<br />
Implementering<br />
Vedligeholdelse/<br />
videreudvikling<br />
Fase<br />
Version 1. Version 2.<br />
Version n.<br />
Figur 9: Forløbet ved <strong>opbygning</strong> og implementering <strong>af</strong> <strong>konfigureringssystemer</strong>.<br />
I <strong>for</strong>bindelse med opstart og gennemførelse <strong>af</strong> projektet kan man vælge at lave et<br />
<strong>for</strong>løb, hvor man gennemløber fremgangsmådens faser 2 til 3 gange. I det første<br />
gennemløb – prototypefasen - udarbejdes en grov <strong>for</strong>retningsmæssig analyse og en<br />
<strong>for</strong>eløbig <strong>af</strong>grænsning <strong>af</strong> det konfigureringssystem, der skal opbygges. Derefter<br />
<strong>for</strong>etages en analyse og modellering <strong>af</strong> en udvalgt del <strong>af</strong> virksomhedens<br />
produktprogram.<br />
I <strong>for</strong>bindelse med prototype-fasen <strong>for</strong>etages en udvælgelse <strong>af</strong> et<br />
konfigureringssoftware. Modellen, der er opbygget i fase 2-3 kan danne grundlag <strong>for</strong><br />
at teste <strong>for</strong>skellige standard <strong>konfigureringssystemer</strong> i <strong>for</strong>bindelse med valg <strong>af</strong><br />
software. Som <strong>af</strong>slutning på det første gennemløb vælges software og der opbygges<br />
en prototype, der danner grundlag <strong>for</strong> det næste gennemløb <strong>af</strong> fremgangsmåden.<br />
I næste gennemløb <strong>for</strong>etages en uddybende <strong>for</strong>retningsmæssig analyse og man<br />
<strong>for</strong>etager den endelige <strong>af</strong>grænsning <strong>af</strong> det konfigureringssystem, der skal bygges.<br />
Derefter opbygges produktvariantmaster og øvrige masters <strong>for</strong> de produkter og<br />
eventuelle livsfasesystemer, der skal lægges ind i systemet, og der <strong>for</strong>etages en<br />
fastlæggelse <strong>af</strong> modellernes klassestruktur og alle detaljer beskrives på de tilhørende<br />
klassebeskrivelseskort. Herefter gennemføres programmeringen <strong>af</strong> version 2 <strong>af</strong><br />
systemet.<br />
Ved tredie gennemløb lægges hovedvægten på test og fejlretning <strong>af</strong> systemet inden<br />
systemet (version 3) implementeres i organisationen.<br />
Første gennemløb med udarbejdelse <strong>af</strong> prototype gennemføres hurtigt, typisk i løbet<br />
<strong>af</strong> 1 til 3 uger. Andet gennemløb gennemføres typisk i løbet <strong>af</strong> 2 til 4 måneder, mens<br />
tredie gennemløb gennemføres i løbet <strong>af</strong> 1 til 3 måneder – <strong>af</strong>hængigt <strong>af</strong> projektets<br />
størrelse og bemanding. Ovenstående <strong>for</strong>løb vil typisk gælde <strong>for</strong> en virksomhed, der<br />
ikke tidligere har <strong>konfigureringssystemer</strong> ved anvendelse <strong>af</strong> en struktureret<br />
fremgangsmåde. Hvis man er <strong>for</strong>trolig med anvendelse <strong>af</strong> <strong>konfigureringssystemer</strong> og<br />
tidligere har gennemført projekter <strong>af</strong> denne type kan man evt. springe fasen med<br />
prototypen over.<br />
........<br />
.......<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
Tid<br />
.......
Efter at version 3 <strong>af</strong> systemet er implementeret i organisationen går systemet over i<br />
en driftsfase, hvor der skal lægges vægt på løbende vedligeholdelse og<br />
videreudvikling. I den <strong>for</strong>bindelse vil det <strong>for</strong>tsat være relevant at gennemløbe de<br />
enkelte faser i fremgangsmåden og løbende analysere de aktuelle<br />
<strong>for</strong>retningsmæssige krav til specifikationssystemet og produkternes struktur.<br />
Desuden er det kritisk at den opbyggede objektorienterede model opdateres<br />
sideløbende med at programmet rettes.<br />
2.1.4 Roller i udviklings<strong>for</strong>løbet<br />
Arbejdet med at opbygge og anvende <strong>konfigureringssystemer</strong> kan opdeles i en<br />
udviklingsfase og en drifts-/ vedligeholdelsesfase. I udviklingsfasen vil der være<br />
følgende roller/ opgaver:<br />
• Projektets sponsor. En person fra virksomhedens ledelse, der har det<br />
overordnede ansvar <strong>for</strong> projektet, herunder projektets økonomiske rammer.<br />
Det er vigtigt at projektets sponsor har en vis indsigt i de tekniske og<br />
<strong>for</strong>retningsmæssige problemer og muligheder ved <strong>opbygning</strong> og anvendelse<br />
<strong>af</strong> <strong>konfigureringssystemer</strong>. Det er sponsorens opgave at indtænke anvendelse<br />
<strong>af</strong> produktkonfigurering i virksomhedens <strong>for</strong>retningsstrategi og i <strong>for</strong>længelse<br />
her<strong>af</strong> vurdere projektets relevans og betydning <strong>for</strong> virksomheden. Med<br />
udgangspunkt i projektets strategiske betydning er det sponsorens opgave at<br />
argumentere <strong>for</strong> tilvejebringelse <strong>af</strong> de nødvendige ressourcer til udvikling og<br />
drift <strong>af</strong> <strong>konfigureringssystemer</strong>. Desuden er det sponsorens ansvar at sikre at<br />
projektet følger den opstillede projektplan og at man når de opstillede mål.<br />
Projektets sponsor følger alle faser i projektet.<br />
• Projektleder. En person, der har det daglige ansvar <strong>for</strong> at gennemføre<br />
projektet. Projektlederen bør have kendskab til fremgangsmåden <strong>for</strong><br />
<strong>opbygning</strong> <strong>konfigureringssystemer</strong>. Projektlederen deltager i alle projektets<br />
faser og varetager den daglige ledelse <strong>af</strong> projektet, herunder opfølgning og<br />
eventuelt korrektion <strong>af</strong> projektets arbejds- og tidsplan.<br />
• Facilitator. En person, der besidder den nødvendige viden <strong>for</strong> gennemførelse<br />
<strong>af</strong> de enkelte faser i fremgangsmåden. Denne person vil typisk være en<br />
konsulent eller en medarbejder, der tidligere har gennemført projekter<br />
vedrørende <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong>. Hvis det er første gang en<br />
virksomhed opbygger et konfigureringssystem vil det facilitatoren normalt<br />
være den eneste, der besidder et detailkendskab til hvorledes man opbygger<br />
et konfigureringssystem. Det er bl.a. facilitatorens opgave at uddanne<br />
projektets øvrige medarbejdere til at kunne bidrage til <strong>opbygning</strong> og<br />
implementering <strong>af</strong> et konfigureringssystem. Facilitatoren vil typisk bidrage til<br />
de første faser i projektet procesanalyse, produktanalyse, samt<br />
objektorienteret analyse og design.<br />
• Forandringsleder. En person, der bidrager til at gennemføre de nødvendige<br />
tiltag <strong>for</strong> at sikre at organisationen er parat til at gennemføre projektet, og<br />
tage det endelige system i brug. Forandringslederen bør besidde en<br />
kompetence om <strong>for</strong>andringsledelse i <strong>for</strong>bindelse med gennemførelse <strong>af</strong> større<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
18
19<br />
tekniske projekter. Forandringslederens opgave er at sikre at medarbejdere,<br />
der berøres <strong>af</strong> et projekt vedr. <strong>opbygning</strong> <strong>af</strong> anvendelse <strong>af</strong> et<br />
konfigureringssystem in<strong>for</strong>meres og motiveres til at bidrage til udvikling og<br />
drift <strong>af</strong> konfigureringssystemet. Desuden er det <strong>for</strong>andringslederens opgave<br />
at bidrage til løsning <strong>af</strong> eventuelle konflikter.<br />
• Modelbygger (model manager). Modelbyggeren har til opgave at indsamle<br />
viden og opbygge produktvariantmaster, klassemodel og klassebeskrivelseskort,<br />
som grundlag <strong>for</strong> programmering <strong>af</strong> konfigureringssystemet. I<br />
<strong>for</strong>bindelse med drift <strong>af</strong> konfigureringssystemet vil modelbyggeren være<br />
ansvarlig <strong>for</strong> opdatering <strong>af</strong> dokumentationen. En modelbygger kan f.eks.<br />
være en domæneekspert, der er uddannet <strong>af</strong> facilitator.<br />
• Procesbygger (Process manager). Procesbyggeren har til opgave at udvikle<br />
virksomhedens specifikationsprocesser og at sikre at det udviklede<br />
konfigureringssystem bliver indbygget i den fremtidige specifikationsproces<br />
på en hensigtsmæssig måde. Procesbyggeren bør have en god indsigt i<br />
virksomhedens specifikationsprocesser og de tilgrænsende områder som<br />
eksempelvis salg, planlægning og produktion. Procesbyggeren bidrager<br />
primært til procesanalysen, samt til implementering, vedligeholdelse og<br />
videreudvikling.<br />
• Domæneekspert. Medarbejdere der besidder viden om produkter og<br />
relevante livsfasesystemer. Det kan eksempelvis være medarbejdere fra<br />
produktudvikling eller produktion. Domæneeksperter bidrager med viden om<br />
dele <strong>af</strong> produktet eller produktets livsfaser som eksempelvis produktion eller<br />
montage. Domæneeksperter bidrager til procesanalyse, produktanalyse samt<br />
vedligeholdelse/ videreudvikling.<br />
• Programmør. En person, der er i stand til at programmere de opbyggede<br />
produktmodeller. Programmøren bør have et indgående kendskab til det<br />
konfigureringssoftware man anvender, samt kendskab til programmering <strong>af</strong><br />
eksempelvis kundemodul eller integration til øvrige systemer i virksomheden.<br />
Hvis der anvendes et standardsystem til implementering <strong>af</strong><br />
konfigureringssystemet kan programmeringsarbejdet – eller dele <strong>af</strong><br />
programmeringsarbejdet udgøres <strong>af</strong> modelbyggeren. Programmøren deltager<br />
i design og programmeringsfasen, samt vedligeholdelse/ videreudvikling <strong>af</strong><br />
systemet.<br />
Det skal bemærkes, at en enkelt person kan varetage flere roller/ opgaver samtidig,<br />
f.eks. kan opgaverne som facilitator og <strong>for</strong>andringsleder udføres <strong>af</strong> samme person.<br />
I <strong>for</strong>bindelse med vedligeholdelse og videreudvikling <strong>af</strong> modellerne (fase 7) er det<br />
<strong>af</strong>gørende at der udpeges en person (modelbygger), der er ansvarlig <strong>for</strong><br />
vedligeholdelse og videreudvikling <strong>af</strong> modellerne. Denne person kan evt. uddelegere<br />
ansvaret <strong>for</strong> opdatering <strong>af</strong> regler til diverse domæneeksperter, der besidder den<br />
nødvendige viden. Fase 7 er kritisk i den <strong>for</strong>stand at arbejdet med <strong>opbygning</strong> <strong>af</strong><br />
<strong>konfigureringssystemer</strong> ikke er <strong>af</strong>sluttet når fase 1 til 6 er gennemløbet. Et<br />
konfigureringssystem, der ikke løbende opdateres bliver hurtigt værdiløst. Rollerne i<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
drifts-/ vedligeholdelsesfasen er uddybende beskrevet i <strong>af</strong>snittet ”Vedligeholdelse og<br />
videreudvikling.”<br />
2.2 <strong>Fremgangsmåde</strong>ns faser<br />
I det følgende gennemgås fremgangsmådens faser kort.<br />
2.2.1 Forretningsmæssig analyse<br />
Den første fase i fremgangsmåden omfatter en analyse <strong>af</strong> virksomhedens<br />
specifikationsprocesser. Analysen skal <strong>af</strong>klare hvad man ønsker at opnå rent<br />
<strong>for</strong>retningsmæssigt ved at opbygge og implementere et konfigureringssystem.<br />
Desuden skal analysen fastlægge de fremtidige specifikationsprocesser og i<br />
<strong>for</strong>længelse her<strong>af</strong> definere de <strong>konfigureringssystemer</strong>, der skal understøtte<br />
<strong>for</strong>etningsprocesserne.<br />
For at <strong>af</strong>klare hvad man ønsker at opnå ved at opbygge og implementere<br />
<strong>konfigureringssystemer</strong> til at understøtte virksomhedens specifikationsprocesser er<br />
det nødvendigt at indtænke de muligheder, der kan opnås i <strong>for</strong>hold til virksomhedens<br />
samlede <strong>for</strong>retningsstrategi. Hvad betyder det f.eks. <strong>for</strong> salget, hvis gennemløbstiden<br />
<strong>for</strong> udarbejdelse <strong>af</strong> tilbud og behandling <strong>af</strong> ordrer reduceres fra 3 uger til 4 timer?<br />
Eller hvilken strategisk betydning vil det have, hvis produktionsomkostningerne<br />
reduceres med 10 %, som følge <strong>af</strong> bedre og mere fejlfrie specifikationer i<br />
produktionen? For at kunne svare på disse spørgsmål kræves indsigt i virksomhedens<br />
markedsmæssige position og kundernes krav til virksomheden.<br />
Disse <strong>for</strong>hold må så indtænkes i virksomhedens strategiske planlægning, idet<br />
anvendelse <strong>af</strong> produktkonfigurering indebærer en række muligheder og risici, der må<br />
<strong>af</strong>klares i <strong>for</strong>hold til virksomhedens strategiske planlægning iøvrigt. I den <strong>for</strong>bindelse<br />
henvises til den gængse litteratur inden<strong>for</strong> området.<br />
Udover <strong>af</strong>klaring <strong>af</strong> de strategiske <strong>for</strong>hold skal der i fase 1 gennemføres en analyse<br />
og redesign <strong>af</strong> de specifikationsprocesser, der skal understøttes <strong>af</strong> et<br />
konfigureringssystem. I <strong>for</strong>længelse her<strong>af</strong> <strong>for</strong>etages en <strong>af</strong>græsning og definition <strong>af</strong><br />
de <strong>konfigureringssystemer</strong>, der skal understøtte specifikationsprocesserne.<br />
Udgangspunktet <strong>for</strong> arbejdet i fase 1 er en identifikation og karakteristik <strong>af</strong> de<br />
vigtigste specifikationsprocesser i virksomheden. Dette kan f.eks. gøres ved at<br />
identificere de vigtigste specifikationer som eksempelvis tilbud, styklister,<br />
operationslister eller montagevejledning. Dernæst beskrives og karakteriseres de<br />
specifikationsprocesser, der fremstiller de pågældende specifikationer.<br />
Dernæst <strong>for</strong>muleres mål og krav til de vigtigste specifikationsprocesser og i den<br />
<strong>for</strong>bindelse kan der evt. <strong>for</strong>etages en række målinger på udvalgte<br />
specifikationsprocesser <strong>af</strong> eksempelvis gennemløbstid, ressource<strong>for</strong>brug eller kvalitet<br />
<strong>af</strong> specifikationer. Ved at sammenligne mål og de faktiske præstationer <strong>for</strong> de<br />
enkelte specifikationsprocesser kan man få en første indikation <strong>af</strong> hvor der er det<br />
største potentiale i at anvende produktkonfigurering til at udarbejde specifikationer.<br />
Efter at have analyseret de vigtigste specifikationsprocesser udarbejdes scenarier <strong>for</strong><br />
hvordan den enkelte specifikationsproces fremover kan udvikles ved anvendelse <strong>af</strong><br />
produktkonfigurering. I den <strong>for</strong>bindelse <strong>for</strong>etages en definition <strong>af</strong> de<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
20
konfigurationssystemer, der skal opbygges v.h.a. rammesystemet <strong>for</strong><br />
produktkonfigurering [Hvam et. al. 2004].<br />
Der <strong>for</strong>etages en cost/ benefit vurdering <strong>af</strong> de enkelte scenarier, hvorefter man<br />
udvælger det scenarie man ønsker at arbejde videre med. Til slut opstilles en plan og<br />
et budget <strong>for</strong> det videre arbejde.<br />
I <strong>for</strong>bindelse med den <strong>for</strong>retningsmæssige analyse vil det ofte være nødvendigt at<br />
analyse virksomhedens produktsortiment. Hvis en virksomhed har komplekse og<br />
ustrukturerede specifikationsprocesser, hænger det ofte sammen med at<br />
produktsortimentet er kompliceret og ustruktureret. For at skabe klarhed og struktur<br />
i virksomhedens specifikationsprocesser og i de <strong>konfigureringssystemer</strong>, der skal<br />
understøtte disse <strong>for</strong>retningsprocesser er det nødvendigt at skabe et overblik over<br />
virksomhedens produktsortiment.<br />
2.2.2 Produktanalyse<br />
Formålet med fremgangsmådens fase 2 er at skabe et overblik over virksomhedens<br />
produktsortiment, og at definere indhold og strukturen i de <strong>konfigureringssystemer</strong>,<br />
der skal opbygges.<br />
21<br />
Figur 10: Produktvariantmaster.<br />
Når man ser på en virksomheds produktsortiment kan det ofte være stort og med et<br />
uoverskueligt antal varianter. For at få et overblik over produkterne tegnes<br />
produktprogrammet op i en såkaldt produktvariantmaster (se Figur 10). En<br />
produktvariantmaster består <strong>af</strong> to dele. Den første del ”part-of modellen”<br />
(produktvariantmasterens venstre side) indeholder de moduler eller parts, der indgår<br />
i hele produktfamilien. En bil består f.eks. <strong>af</strong> chassis, motor, bremsesystem mv.<br />
Hvert modul/ part i produktet markeres med en cirkel. De enkelte moduler/ parter<br />
modelleres desuden med en række attributter, der beskriver deres egenskaber og<br />
karakteristika.<br />
Den anden del <strong>af</strong> produktvariantmasteren (højresiden) indeholder de dele, der kan<br />
udskiftes i produktet. En motor kan f.eks. være <strong>af</strong> typen benzin eller diesel. Det vises<br />
på produktvariantmasteren som en generisk struktur, hvor den generiske part<br />
hedder motor, og de specifikke parter hedder henholdsvis benzinmotor og<br />
dieselmotor. De enkelte parter beskrives desuden med attributter som ved part-of<br />
modellen. I produktvariantmasteren beskrives desuden de vigtigste bindinger mellem<br />
moduler/ parter, dvs. regler <strong>for</strong> hvilke moduler/ parter, det er tilladeligt at<br />
sammensætte. Dette gøres ved at tegne en streg mellem de to moduler/ parter og<br />
skrive de regler der gælder <strong>for</strong> sammensætning <strong>af</strong> de pågældende moduler/ parter.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
På tilsvarende måde kan de livsfasesystemer, der ønskes modelleret beskrives med<br />
masters, der beskriver f.eks. produktionssystemet eller montagesystemet.<br />
De enkelte moduler/parter i produktvariantmasteren beskrives yderligere på såkaldte<br />
klassebeskrivelseskort (se [Hvam et al, 2004]).<br />
2.2.3 Objektorienteret analyse og design<br />
I fremgangsmåden <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong>, er objektorienteret<br />
analyse valgt som gennemgående modelleringsteknik fra <strong>opbygning</strong> <strong>af</strong> model til<br />
programmering og vedligeholdelse <strong>af</strong> systemet. Dette valg er <strong>for</strong>etaget med<br />
udgangspunkt i et ønske om:<br />
• at kunne strukturere kompliceret viden om virksomhedens produktsortiment.<br />
• at kunne genbruge analyseresultater gennem projektlivs-cyklen fra analyse til<br />
design, programmering og vedligeholdelse/ videreudvikling <strong>af</strong> modellen.<br />
• at sætte domæneeksperter (f.eks. produktudviklere og medarbejdere fra<br />
produktionsteknisk <strong>af</strong>deling) i stand til selv at modellere deres<br />
arbejdsområde.<br />
• at muliggøre en mere hensigtsmæssig arbejdsdeling mellem modelbygger<br />
(domæneekspert) og EDB-systemudvikler (programmør).<br />
En væsentlig egenskab ved objektorienteret analyse er således muligheden <strong>for</strong> at<br />
kunne strukturere et kompleks domæne, ved at opdele domænet i emneområder og<br />
objektklasser. Den valgte struktur fastholdes gennem alle faser <strong>af</strong> den<br />
objektorienterede projektlivscyklus, hvilket letter overgangen mellem de enkelte<br />
faser, og bidrager til en mere konsistent anvendelse <strong>af</strong> de resultater, der produceres<br />
i de enkelte faser.<br />
Det <strong>for</strong>hold, at der anvendes samme opdeling og notation gennem de <strong>for</strong>skellige<br />
faser i den objektorienterede livscyklus, bidrager til et <strong>for</strong>bedret samarbejde mellem<br />
modelbyggere, domæneekspert og programmør samt at der kan <strong>for</strong>etages en<br />
arbejdsdeling mellem modelbygger, domæneeksperter og programmør. Eksempelvis<br />
således at modelbygger og domæneeksperter bygger den objektorienterede model,<br />
hvorefter programmøren overtager det videre arbejde med at programmere<br />
modellen.<br />
Desuden sigter den objektorienterede modelleringsteknik mod at konstruere<br />
modeller, der er stabile over<strong>for</strong> ændringer, ved bl.a. at fokusere på de mest stabile<br />
elementer i domænet og gøre disse til overordnede objektklasser. Endelig fokuseres<br />
på at udnytte objekternes fælles træk gennem nedarving <strong>af</strong> objekternes attributter<br />
og metoder.<br />
Der anvendes de grundlæggende principper og notation fra Unified Modelling<br />
Language (UML). I nedenstående Figur 11 er vist notationen <strong>for</strong> klasser og relationer<br />
mellem klasser. Der er tre <strong>for</strong>skellige typer <strong>af</strong> relationer mellem klasser;<br />
generalisering, aggregering og associering.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
22
23<br />
Subklasse1<br />
-attribute1<br />
-attribute2<br />
+metode1()<br />
+metode2()<br />
Superklasse<br />
-attribute1<br />
+metode1()<br />
Klasse<br />
-attribute1<br />
-attribute2<br />
+metode1()<br />
+metode2()<br />
Klasse med attributter<br />
og metoder<br />
Subklasse2<br />
-attribute1<br />
-attribute3<br />
+metode1()<br />
+metode3()<br />
Klasse1<br />
-attribute1<br />
+metode1()<br />
Klasse2<br />
-attribute2<br />
+metode2()<br />
Klynge<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
*<br />
1<br />
Klynge<br />
Klasse1<br />
-attribute1<br />
+metode1()<br />
*<br />
1<br />
Klasse2<br />
-attribute1<br />
+metode2()<br />
Generaliseringsstruktur Aggregeringsstruktur Assoceringsstruktur<br />
Figur 11: UML notation <strong>for</strong> angivelse <strong>af</strong> objektklasser og deres indbyrdes<br />
relationer.<br />
Generaliseringsstrukturer, beskriver objektklasser, der har fælles attributter og<br />
metoder. Det kan f.eks. være objektklassen bil, der indeholder generelle attributter<br />
og metoder om biler eksempelvis registreringsnummer og motorstørrelse, mens<br />
objektklassen lastbiler indeholder attributter og metoder, der er specifikke <strong>for</strong><br />
lastbiler eksempelvis lastevne eller lad<strong>opbygning</strong>. Generaliseringsstrukturen mellem<br />
objektklassen biler og objektklassen lastbiler betyder at den specielle objektklasse<br />
lastbiler arver attributter og metoder fra den generelle objektklasse biler.<br />
Aggregeringsstrukturer omfatter objektklasser, der tilsammen udgør en helhed, som<br />
f.eks. dele i en bil; karrosseri, motor, gearkasse, hjul mv. Relationer i<br />
aggreringsstruktur beskrives desuden med angivelse <strong>af</strong> kardinaliteten mellem de to<br />
klasser. Dvs. en angivelse <strong>af</strong> antallet <strong>af</strong> objekter i hver ende <strong>af</strong> relationen, f.eks. at<br />
en bil har fire hjul. Objektklasser i en aggreringsstruktur kan kommunikere<br />
indbyrdes, men de arver ikke automatisk attributter og metoder som ved en<br />
generaliseringsstruktur.<br />
Associeringsstrukturer beskriver relationer mellem objektklasser, der er relateret til<br />
hinanden uden at der er tale om objektklasser der udgør en helhed. Et eksempel kan<br />
være objektklassen bil og objektklassen fører. Associeringsstrukturer beskrives som<br />
aggreringsstrukturer med angivelse <strong>af</strong> kardinaliteten mellem de to klasser.<br />
Udover de nævnte typer <strong>af</strong> relationer mellem objektklasser kan objektklasser<br />
grupperes i klynger. En klyngestruktur betegner en grupper <strong>af</strong> objektklasser, der er<br />
indbyrdes <strong>for</strong>bundne. En klyngestruktur vil således normalt omfatte objektklasser,<br />
der indbyrdes <strong>for</strong>bundne med generalisering, aggregering eller<br />
associeringsstrukturer. Modellering <strong>af</strong> objektklasser og deres relationer er uddybende<br />
beskrevet i kapitel 6 Objektorienteret modellering.
Den optegnede produktvariantmaster danner grundlag <strong>for</strong> at definere objektklasser<br />
og klassestrukturer i produktmodellen. De enkelte knuder i produktvariantmasteren<br />
kan være objektklasser, mens part-of og kind-of strukturerne genfindes som<br />
strukturer mellem objektklasserne.<br />
I produktvariantmasteren anvendes såkaldte part-of og kind-of strukturer. Disse<br />
begreber er taget fra objektorienteret modellering, som beskrevet oven<strong>for</strong>. Part-of<br />
strukturen på produkt-variantmasteren svarer således til en aggregeringsstruktur<br />
mens kind-of strukturen svarer til en specialiseringsstruktur.<br />
I <strong>for</strong>bindelse med optegnelse <strong>af</strong> produktvariantmasteren og den endelige<br />
objektorienterede klassemodel anvendes såkaldte klassebeskrivelseskort (CRC-kort)<br />
til at beskrive de enkelte objektklasser. Et klassebeskrivelseskort indeholder udover<br />
objektklassens navn mv. en beskrivelse <strong>af</strong> objektklassens mission, objektkassens<br />
attributter og metoder, samt en beskrivelse <strong>af</strong> objektklassens relationer til andre<br />
objektklasser.<br />
I nedenstående Figur 12 er vist et eksempel på et klassebeskrivelseskort (CRC-kort).<br />
I <strong>for</strong>bindelse med modellering <strong>af</strong> produkter er der tilføjet en skitse <strong>af</strong> produktdelen<br />
med angivelse <strong>af</strong> produktdelens attributter.<br />
For at sikre en overskuelig model er det hensigtsmæssig at adskille viden om<br />
produkter og deres livsfasegenskaber (produktviden) fra viden (systemviden) om<br />
konfigureringssystemets programmering og herunder eksempelvis<br />
brugergrænseflade og integration til øvrige IT-systemer. Dvs. at man så vidt muligt<br />
grupperer objektklasser med produktviden i klynger <strong>for</strong> sig og objektklasser med<br />
systemviden andre klynger.<br />
Hvis en objektklasse indeholder både produktviden og systemviden kan man i<br />
<strong>for</strong>bindelse med beskrivelse <strong>af</strong> metoder opdele disse i metoder, der vedrører<br />
produktviden (produktmetoder) og metoder, der indeholder systemviden<br />
(systemmetoder).<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
24
25<br />
Klassenavn: Dato: Forfatter/version:<br />
Klassens opgave (responsibilities):<br />
Aggregering Generalisering<br />
Overdele: Overklasser:<br />
Underdele: Underklasser:<br />
Skitse:<br />
Attributter: Klassen samarbejder<br />
med :<br />
Systemmetoder:<br />
Produktmetoder:<br />
Figur 12: Klassebeskrivelseskort (CRC-kort).<br />
CRC-kortene udfyldes løbende under den objektorienterede analyse. Formålet med<br />
CRC-kortene er at dokumentere detaljeret viden om attributter og metoder, under de<br />
enkelte objektklasser, samt at beskrive klassernes indbyrdes relationer. CRC-kortene<br />
tjener som dokumentation over<strong>for</strong> både domæneeksperter og systemudviklere og<br />
bliver således sammen med produktvariantmasteren og klassediagrammet et vigtigt<br />
middel til at kommunikere og dokumentere viden i projektgruppen.<br />
I [Hvam et al., 2004] er der givet en uddybende beskrivelse <strong>af</strong> de enkelte felter på<br />
CRC-kortet og CRC-kortenes anvendelse.<br />
Udover selve den objektorienterede klassemodel <strong>for</strong>etages en definition <strong>af</strong> systemets<br />
brugergrænseflade, kravspecifikation, dynamik, samt integration til øvrige systemer.<br />
Den objektorienterede modelleringsteknik er i princippet u<strong>af</strong>hængig <strong>af</strong> hvilket<br />
software det vælges at implementere systemet i, og den opbyggede model kan<br />
således anvendes som dokumentation uanset valg <strong>af</strong> implementeringsværktøj. I<br />
praksis vil det dog ofte være nødvendigt at <strong>for</strong>etage en række justeringer i modellen<br />
inden modellen kan implementeres i et konkret konfigureringssoftware.<br />
Udgangspunktet <strong>for</strong> valg <strong>af</strong> konfigureringssoftware er systemets kravspecifikation,<br />
der udover den opbyggede model omfatter en række krav til systemet og<br />
leverandøren som eksempelvis mulighed <strong>for</strong> integration til andre systemer, svartid,<br />
driftssikkerhed og mulighed <strong>for</strong> support fra leverandøren.<br />
De standardsystemer, der idag findes til produktkonfigurering er ikke alle fuldt<br />
objektorienterede. Det vil der<strong>for</strong> ofte være nødvendigt at tilpasse den<br />
objektorienterede model til de muligheder, der findes <strong>for</strong> at strukturere modeller i<br />
det konkrete konfigureringssoftware. I den <strong>for</strong>bindelse fastlægges hvorledes man<br />
ønsker at dokumentere eventuelle <strong>for</strong>skelle mellem strukturen i den opbyggede<br />
produktmodel og strukturen i konfigureringssystemet<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Den tilrettede objektorienterede model kaldes en objektorienteret design model<br />
(OOD). Desuden <strong>for</strong>etages detailspecifikation <strong>af</strong> brugergrænseflade, dynamik og<br />
integration til øvrige systemer i <strong>for</strong>hold til det valgte konfigureringssoftware.<br />
2.2.4 Programmering<br />
Den objektorienterede model med klassediagram, klasse-beskrivelseskort og<br />
beskrivelsen <strong>af</strong> systemets dynamik og brugergrænseflade mv. danner grundlag <strong>for</strong><br />
programmering <strong>af</strong> konfigureringssystemet.<br />
Ofte vil man vælge at implementere modellerne i et standard konfigureringssystem.<br />
En stor del <strong>af</strong> de standard <strong>konfigureringssystemer</strong>, der er tilgængelige på markedet<br />
idag er videnbaserede systemer, dvs. de indeholder en videnbase og en<br />
inferensmaskine.<br />
Programmøren bør have et indgående kendskab til det standardsystem, der<br />
anvendes. Som nævnt vil det ofte være muligt at uddanne modelbygger eller<br />
domæneeksperter til at varetage dele <strong>af</strong> programmeringsarbejdet. Erfaringer viser<br />
dog at det kan være svært <strong>for</strong> en ikke programmør effektivt at programmere<br />
komplekse regler og tilhørende applikationer som eksempelvis kundemodul eller<br />
integration til øvrige systemer.<br />
Hvis konfigureringssystemet ikke er objektorienteret kan strukturen i den opbyggede<br />
produktmodel ikke uden videre implementeres i konfigureringssystemet. Et<br />
konfigureringssystem, der ikke er objektorienteret understøtter ikke eksempelvis ikke<br />
indkapsling <strong>af</strong> objektklasser, relationer mellem objektklasser og nedarving. I stedet<br />
lægges attributter og metoder i en ”flad” struktur <strong>af</strong> fil-mapper (folders).<br />
På baggrund <strong>af</strong> den opbyggede klassemodel defineres strukturen <strong>af</strong> de folders, der<br />
indeholder attributter (defineret som datatyper eksempelvis ”Single”, ”OneOf”, ”At<br />
Most One” o.s.v.) og deres variationsmuligheder. På samme måde oprettes en<br />
tilsvarende folder-struktur med metoder, der eksempelvis kan implementeres i <strong>for</strong>m<br />
<strong>af</strong> ressourcer og kalkulationer.<br />
Der findes der idag en række standard <strong>konfigureringssystemer</strong>, der understøtter<br />
anvendelse <strong>af</strong> tabeller til at repræsentere regler i systemet. Ved at anvende tabeller<br />
til at beskrive regler lettes implementeringen betydeligt. Desuden er det lettere at<br />
kommunikere mellem modelbygger, domæneeksperter og programmører ved<br />
anvendelse <strong>af</strong> tabeller, bl.a. <strong>for</strong>di en del <strong>af</strong> viden om virksomhedens<br />
produktsortiment allerede er repræsenteret i <strong>for</strong>m <strong>af</strong> tabeller.<br />
Hvis konfigureringssystemet er objektorienteret kan den opbyggede klassemodel<br />
implementeres direkte i systemet. Et objektorienteret ekspertsystem bygger på<br />
principperne i objektorienteret modellering og kan derved håndtere indkapsling <strong>af</strong><br />
objektklasser, nedarving og relationer mellem objektklasser. Ved programmering <strong>af</strong><br />
et objektorienteret konfigureringssystem oprettes klassestrukturen først, hvorefter<br />
attributter og metoder programmeres samlet <strong>for</strong> hver objektklasse.<br />
Anvendelse <strong>af</strong> et objektorienteret konfigureringssystem gør det lettere at strukturere<br />
videnbasen, hvilket gør det betydeligt lettere at vedligeholde og videreudvikle<br />
konfigureringssystemet.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
26
I <strong>for</strong>bindelse med programmering <strong>af</strong> et konfigureringssystem er det vigtigt løbende<br />
at teste de enkelte dele <strong>af</strong> konfigureringssystemet dels <strong>for</strong> at finde eventuelle fejl så<br />
tidligt som muligt og dels <strong>for</strong> at teste om det overhovedet kan lade sig gøre at<br />
implementere de enkelte dele <strong>af</strong> systemet. Den valgte struktur <strong>af</strong> klasser, objekter<br />
attributter og metoder er <strong>af</strong>gørende <strong>for</strong> konfigureringssystemets per<strong>for</strong>mans i <strong>for</strong>hold<br />
til eksempelvis svartider. Det kan der<strong>for</strong> ofte være nødvendigt at programmere den<br />
samme del <strong>af</strong> systemet på <strong>for</strong>skellig måde og derefter på baggrund <strong>af</strong> test <strong>af</strong><br />
delsystemets per<strong>for</strong>mans vælge den struktur, der viser den bedste per<strong>for</strong>mans.<br />
Desuden er det vigtigt at gennemføre brugertest <strong>af</strong> systemet og systemets<br />
brugergrænseflade allerede <strong>af</strong> tidlige versioner <strong>af</strong> konfigureringssystemet dels <strong>for</strong> at<br />
sikre input fra brugerne og dels <strong>for</strong> at sikre at de kommende brugere vil acceptere<br />
systemet.<br />
2.2.5 Implementering<br />
I <strong>for</strong>bindelse med implementering <strong>af</strong> systemet er det <strong>af</strong> <strong>af</strong>gørende betydning at<br />
systemets brugere accepterer systemet. Nedenstående er listet <strong>for</strong>skellige tiltag, der<br />
kan bidrage til brugernes accept <strong>af</strong> systemet:<br />
• Inddrag brugerne tidligt i projekt<strong>for</strong>løbet, f.eks. i <strong>for</strong>bindelse med diskussion<br />
<strong>af</strong> brugergrænseflade og kravene til systemet.<br />
• Inddrag udvalgte brugere i test <strong>af</strong> prototype og tidlige versioner <strong>af</strong> systemet.<br />
• Motiver brugerne ved bl.a. løbende at in<strong>for</strong>mere om det nye system og de<br />
<strong>for</strong>retningsmæssige <strong>for</strong>dele man venter at opnå.<br />
• Giv en klar beskrivelse <strong>af</strong> brugernes fremtidige arbejdssituation.<br />
• Uddan brugerne i anvendelse <strong>af</strong> systemet.<br />
Indfør måling og lønsystemer eller rabatsystemer, der belønner brugere, der effektivt<br />
anvender systemet<br />
I <strong>for</strong>bindelse med implementering <strong>af</strong> et konfigureringssystem er det vigtigt at<br />
systemet er gennemtestet og fejlfrit inden det sættes i drift. Hvis brugerne <strong>af</strong><br />
konfigureringssystemet få opfattelsen <strong>af</strong> at systemet er ustabilt og fyldt med fejl<br />
mister de hurtigt tilliden til systemet.<br />
Desuden skal man overveje hvorledes man vil implementere systemet. Hvis det at<br />
anvende et <strong>konfigureringssystemer</strong> noget nyt <strong>for</strong> virksomheden kan det være<br />
hensigtsmæssigt at implementere systemet gradvist. Dvs. man starter eksempelvis<br />
med at indføre systemet over<strong>for</strong> udvalgte kunder/ sælgere. Når systemet er kørt ind<br />
i <strong>for</strong>hold til disse medarbejdere og kunder, og de er tilfredse, kan man gradvist<br />
udvide kredsen <strong>af</strong> brugere. Derved får man opbygget en kreds <strong>af</strong> ”supportere”, der<br />
bakker op om systemet.<br />
2.2.6 Vedligeholdelse og videreudvikling<br />
Efter implementering går systemet ind i den egentlige driftsfase. Ved anvendelse <strong>af</strong><br />
<strong>konfigureringssystemer</strong> bliver viden om produkter og eventuelle livsfasesystemer<br />
<strong>for</strong>maliseret og lagt ind i et IT-system. Dette medfører en række ændringer i måden<br />
hvorpå arbejdet med at specificere produkter og f.eks. produktionsgrundlag udføres<br />
Anvendelse <strong>af</strong> <strong>konfigureringssystemer</strong> medfører, at der opstår en række nye opgaver<br />
i organisationen, mens andre opgaver <strong>for</strong>svinder. En del <strong>af</strong> de daglige opgaver med<br />
udarbejdelse <strong>af</strong> specifikationer i <strong>for</strong>m <strong>af</strong> f.eks. tilbud og produktionsgrundlag<br />
27<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
<strong>for</strong>svinder. Til gengæld skal f.eks. sælgere til at anvende de opbyggede<br />
<strong>konfigureringssystemer</strong> til gennemførelse <strong>af</strong> salgsarbejdet.<br />
Som tidligere nævnt er det nødvendigt løbende at vedligeholde og videreudvikle de<br />
opbyggede modeller og konfigureringssystemet, <strong>for</strong> derved at sikre at<br />
konfigureringssystemet bevarer sin gyldighed. Det betyder at der opstår en række<br />
nye opgaver med at vedligeholde og videreudvikle den opbyggede model og det<br />
tilsvarende konfigureringssystem. Disse opgaver skal typisk udføres <strong>af</strong> de personer,<br />
der har den nødvendige viden om produkterne og de relevante livsfasesystemer,<br />
f.eks. produktion, montage og <strong>for</strong>sendelse.<br />
Domæneekspert<br />
Klassediagram 1<br />
Konfigureringssystem<br />
(computermodel)<br />
Programmør (er)<br />
Dokumentation<br />
Klassediagram 2<br />
Klasse 1<br />
Klasse 2<br />
Klasse 1<br />
Klasse 2<br />
Klasse 5<br />
1<br />
*<br />
Klasse 5<br />
1<br />
Klasse 3 * Klasse 4<br />
Klasse 3 Klasse 4<br />
Klassediagrammer<br />
Modelmanager (s)<br />
Domæneekspert<br />
Klassenavn<br />
Klassenavn<br />
Klassenavn<br />
Skitse<br />
Skitse<br />
Attributter<br />
Skitse<br />
Attributter<br />
Attributter<br />
Produktmetoder<br />
Produktmetoder<br />
Systemmetoder<br />
Produktmetoder<br />
Systemmetoder<br />
CRC-kort<br />
Domæneekspert<br />
Klassen<br />
samarbejder<br />
Klassen<br />
medsam<br />
arbejder Klassen<br />
med samarbejder<br />
med<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
Systemmetoder<br />
Figur 13: Roller i drifts-/ vedligeholdelsesfasen.<br />
Vedligeholdelse og videreudvikling vil således involvere en række <strong>for</strong>skellige<br />
personer. Arbejdet kan eksempelvis organiseres ved, at der er en eller to personer<br />
(model managers), der er ansvarlige <strong>for</strong> den samlede model og en eller to personer<br />
(programmører), der er ansvarlig <strong>for</strong> opdatering <strong>af</strong> konfigureringssystemet og selve<br />
programmet, herunder brugergrænseflade og integration til øvrige systemer.<br />
De ansvarlige <strong>for</strong> de samlede modeller (model managers) uddelegerer herefter<br />
opgaven med vedligeholdelse/ videreudvikling til de enkelte specialister, der hver<br />
især får ansvaret <strong>for</strong> vedligeholdelsen <strong>af</strong> den del <strong>af</strong> modellen, de har viden om. Dvs.<br />
at den enkelte specialist typisk får ansvaret <strong>for</strong> at vedligeholde og videreudvikle en<br />
række objektklasser og tilhørende klassebeskrivelseskort.<br />
I <strong>for</strong>bindelse med udvikling og vedligeholdelse <strong>af</strong> de opbyggede modeller er det <strong>af</strong><br />
<strong>af</strong>gørende betydning at der <strong>for</strong>etages en samtidig opdatering <strong>af</strong> modeller og<br />
konfigureringssystem. Et konfigureringssystem, der ikke er dokumenteret bliver<br />
hurtigt vanskeligt eller helt umulig at vedligeholde og videreudvikle.<br />
....<br />
28
Dokumentationen omfatter i hovedtræk produktvariantmaster, klassediagram og<br />
klassebeskrivelseskort.<br />
2.3 Afrunding<br />
Som det fremgår er nærværende beskrivelse <strong>af</strong> fremgangsmåden en oversigt. For<br />
nærmere uddybning <strong>af</strong> de enkelte faser, samt eksemplificering gennem praktiske<br />
cases henvises til bogen ”Produktkonfigurering” <strong>af</strong> Lars Hvam, Niels Henrik<br />
Mortensen og Jesper Riis [Hvam et al, 2004].<br />
I de følgende kapitler <strong>for</strong>etages en opsamling på de erfaringer, der er opnået<br />
gennem <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen. Erfaringerne er<br />
opnået med udgangspunkt i en praktisk anvendelse <strong>af</strong> den her introducerede<br />
fremgangsmåde.<br />
29<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
3 Erfaringer<br />
Dette kapitel opsamler nogle <strong>af</strong> de erfaringer, der er gjort med<br />
<strong>konfigureringssystemer</strong> i relation til PKB projektet. Erfaringerne er opdelt i to<br />
hovedgrupper:<br />
• Erfaringer med <strong>for</strong>udsætninger <strong>for</strong> <strong>konfigureringssystemer</strong> i byggebranchen.<br />
• Erfaringer med anvendelse <strong>af</strong> fremgangsmåden i byggebranchen.<br />
3.1 Erfaringer med <strong>for</strong>udsætninger <strong>for</strong><br />
<strong>konfigureringssystemer</strong><br />
Gennem projekt<strong>for</strong>løbet er der opnået en række generelle erfaringer med anvendelse<br />
<strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen. En del <strong>af</strong> disse omfatter parternes<br />
generelle modenhed <strong>for</strong>, at kunne automatisere deres specifikationsprocesser med<br />
<strong>konfigureringssystemer</strong>. Disse behandles i nærværende <strong>af</strong>snit.<br />
Som udgangspunkt kan det konstateres, at der i byggebranchen gælder de samme<br />
<strong>for</strong>udsætninger <strong>for</strong>, at kunne automatisere specifikationsprocesser som i andre<br />
brahcner:<br />
• Der skal være ensartede og veldefinerede specifikationsaktiviteter, der<br />
gentages med en høj hyppighed.<br />
• Der skal være en velegnet teknologi (konfigureringssoftware), der muliggør<br />
en lønsom automatisering <strong>af</strong> specifikationsaktiviteterne.<br />
Disse <strong>for</strong>udsætninger kan opfyldes hvis følgende <strong>for</strong>hold gælder:<br />
• Standardiserede produkter: Gennem anvendelse <strong>af</strong> produktplat<strong>for</strong>me,<br />
moduler, faste produktstrukturer, standardiserede komponenter etc. skabes<br />
der et grundlag <strong>for</strong>, at kunne udføre ensartede og veldefinerede<br />
specifikationsaktiviteter med en høj hyppighed.<br />
• Markedsrationale <strong>for</strong> at standardisere: For at kunne sælge standardiserede<br />
produkter skal kunder være villige til, at give <strong>af</strong>kald på specielle detaljer til<br />
<strong>for</strong>del <strong>for</strong> lavere pris. Endvidere skal markedet være tilstrækkeligt<br />
<strong>for</strong>udsigeligt således, at man kan regne med at specifikke produkter også i<br />
fremtiden sælges med en høj hyppighed.<br />
• Mange tilbud eller ordrer: For at opnå en høj hyppighed i<br />
specifikationsaktiviteterne skal der udarbejdes mange tilbud eller<br />
gennemføres mange ordrer.<br />
• Adgang til velegnet konfiguratorsoftware: For at kunne holde investeringerne<br />
i ny IT på et lønsomt niveau, skal der være modne IT-systemer, der medfører<br />
en reduktion <strong>af</strong> graden <strong>af</strong> egenudvikling og dermed<br />
udviklingsomkostningerne.<br />
Erfaringerne viser, at der i byggebranchen ofte er tale om, at kunderne ikke<br />
accepterer standardiserede løsninger og, at der ikke er en tilstrækkelig grad <strong>af</strong><br />
prædefineret varians. Dette betyder helt specifikt at variantspecifikationsaktiviteterne<br />
bliver mere komplekse og at der gælder følgende:<br />
• Tegninger kontra styklister: I modsætning til rendyrket konfigurering, hvor<br />
det er nok at generere en stykliste, er der <strong>for</strong> mange produkter i<br />
byggebranchen behov <strong>for</strong>, at udarbejde specielle kundetilpassede geometrier<br />
og dertil hørende tegninger.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
30
De fire konkretiserede <strong>for</strong>udsætninger beskrives i det følgende og det diskuteres om<br />
<strong>for</strong>udsætningerne opfyldes i byggebranchen. Det femte punkt, omkring specifikke<br />
erfaringer med udarbejdelse <strong>af</strong> kundetilpasset geometri og hertil hørende tegninger,<br />
beskrives som det sidste punkt under de generelle erfaringer.<br />
3.1.1 Produktstandardisering og prædefineret varians<br />
I mange mindre virksomheder er tankegangen og arbejdsgangene præget <strong>af</strong> det,<br />
der kan karakteriseres som nyudvikling og lappeløsninger. Når en kunde<strong>for</strong>espørgsel<br />
indløber skaber man ofte et nyt produkt ved, at man ”lapper” på et tidligere<br />
fremstillet produkt: Der udskiftes et par komponenter, der ændres nogle dimensioner<br />
etc. Ønsker kunden ting man ikke har lavet før udvikler man helt nye komponenter,<br />
eller køber eksisterende komponenter, der gennem lidt tilpasning kan sammensættes<br />
på en ny måde.<br />
Når man laver et konfigureringssystem er man nødt til at tænke i andre baner. For at<br />
konfigureringssystemet skal kunne tage hensyn til alle tænkelige varianter er man<br />
nødt til at præ-definere produktkomponenter, moduler, regler og beregninger og<br />
skabe et standardiseret ”super-produkt”, der indeholder viden om alle tænkelige<br />
produktvarianter. Man er altså nødt til at bevæge sig fra ”lappeløsninger” og<br />
nyskabelse til prædefineret varians.<br />
Dette er søgt illustreret i Figur 14. Figuren viser at der <strong>for</strong>ud <strong>for</strong> kundebehandling<br />
præ-defineres en mængde in<strong>for</strong>mation og viden, bl.a. materialer, komponenter,<br />
regler, beregninger samt skabeloner <strong>for</strong> ud<strong>for</strong>mningen <strong>af</strong> dokumenter. Denne<br />
in<strong>for</strong>mationsmængde bruges som grundlag i kundebehandlingen til at danne<br />
varianter <strong>af</strong> specifikke produkt- og produktionsspecifikationer.<br />
31<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Development of<br />
materials, parts,<br />
modules and products<br />
Development of<br />
manufacturing<br />
processes<br />
Development of rules,<br />
constraints, calculation<br />
methods, etc.<br />
Development of<br />
document masters/<br />
templates<br />
Specifications of<br />
materials<br />
parts<br />
modules<br />
products<br />
Specifications of<br />
equipment<br />
routings<br />
processes<br />
etc.<br />
Specifications of<br />
rules<br />
constraints<br />
calculations<br />
etc.<br />
Document templates:<br />
Quote docs.<br />
Proposal docs.<br />
Bill-of-material<br />
docs.<br />
etc.<br />
Creating product<br />
specifications <strong>for</strong> individual<br />
orders<br />
"Pushing" specifications to "market" "Pulling" specifications to order<br />
Order Specification Decoupling Line<br />
Creating process<br />
(manufacturing and<br />
delivery) specifications <strong>for</strong><br />
individual orders<br />
Specifications of<br />
materials<br />
parts<br />
modules<br />
products<br />
Specifications of<br />
equipment<br />
routings<br />
processes<br />
etc.<br />
Figur 14: Opdelingen i prædefinet variantskabelsesgrundlag (markeret med hvid)<br />
og selve variantskabelsen (markeret med grå) [Hansen&Hvam, 2004].<br />
I relation hertil er det væsentligt at fastlægge graden <strong>af</strong> tilladt variantskabelse. Ved<br />
salg og produktion <strong>af</strong> et standardprodukt (mobiltelefoner, hårde hvidevarer etc.) er<br />
der typisk en meget lille eller ingen varians. Ved skabelse <strong>af</strong> ”one-of-a-kind”<br />
produkter (bygninger, store procesanlæg, skibe etc.) er der tale om en meget stor<br />
grad <strong>af</strong> tilladt variantskabelse. Graden <strong>af</strong> tilladt variantskabelse kan beskrives ud fra<br />
begrebet Order Specification Decoupling Line (OSDL) [Hansen&Hvam, 2004]. Dette<br />
begreb fastlægger hvor meget produktin<strong>for</strong>mation, der er fastlagt <strong>for</strong>ud <strong>for</strong> en ordre<br />
kontra den del der fastlægges i det kundespecifikke ordre<strong>for</strong>løb.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
32
33<br />
Specifications<br />
created in<br />
"development"<br />
processes<br />
OSDL<br />
Norms and<br />
Standards<br />
Generic product<br />
structures<br />
Standard parts and<br />
modules<br />
Standard products<br />
Specifications<br />
created in variant<br />
specification<br />
processes<br />
Engineer-to-order<br />
Modify-to-order<br />
Configureto-order<br />
Select<br />
variant<br />
0% - 100%<br />
Degree of completed specifications<br />
Figur 15: Order Specification Decoupling Line og eksempler på klassificering <strong>af</strong><br />
specifikationsprocesser [Hansen&Hvam, 2004].<br />
Som illustreret i Figur 15 kan der karakteriseres en række typiske niveauer i<br />
variantskabelsen:<br />
• Engineer-to-order: Her er der kun få prædefinerede specifikationer.<br />
Udarbejdelsen <strong>af</strong> varianter er en kompleks opgave, der typisk tager lang tid<br />
og involverer højt uddannede teknikere og ingeniører. Produkter som<br />
cementfabrikker, større byggerier, mange mindre byggerier, skibe etc. hører<br />
til denne kategori.<br />
• Modify-to-order: Her er der prædefinerede produktstrukturer og en mere<br />
veldefinerede parametriske komponenter. Diverse stålkonstruktioner,<br />
industrielle skorstene, skræddersyet tøj, mm. hører til denne kategori.<br />
• Configure-to-order: Her er der tale om det klassiske ”lego-klods”-eksempel,<br />
hvor varianter opbygges <strong>af</strong> prædefinerede komponenter. Varianter <strong>af</strong><br />
køkkener, computere, biler etc. skabes på denne måde.<br />
• Select-to-order: Ved et stort sortiment <strong>af</strong> standardprodukter lægger<br />
specifikationsopgaven i at finde den rette variant. Dette er aktuelt <strong>for</strong> mange<br />
<strong>for</strong>brugsgoder, f.eks. mobiltelefoner, hårde hvidevarer, møbler,<br />
køkkenmaskiner etc.<br />
En væsentlig <strong>for</strong>udsætning <strong>for</strong> at kunne opbygge <strong>konfigureringssystemer</strong> er således,<br />
at man baserer variantskabelsen på produktfamilier indeholdende prædefinerede<br />
variansmuligheder, frem <strong>for</strong> tilpasning <strong>af</strong> tidligere solgte produkter.<br />
I meget store produktionsvirksomheder anvender man i dag produktplat<strong>for</strong>me, der<br />
kan bruges som grundstruktur til at udvikle nye produktfamilier. F.eks. er mange<br />
bilmodeller bygget op omkring den samme plat<strong>for</strong>m. Tilsvarende anvendes der<br />
moduler der kan bruges på tværs <strong>af</strong> produktfamilierne. I bilproduktion giver dette sig<br />
udtryk i, at f.eks. store dele <strong>af</strong> instrumentbrædtet består <strong>af</strong> de samme dele, på tværs<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
<strong>af</strong> de <strong>for</strong>skellige bilmodeller. Plat<strong>for</strong>me og moduler bidrager til et bedre<br />
variantskabelsesgrundlag.<br />
Opbygning <strong>af</strong> <strong>konfigureringssystemer</strong> hænger sammen med produktstandardisering,<br />
og <strong>opbygning</strong> <strong>af</strong> plat<strong>for</strong>me, moduler og standardkomponenter. Opbygning <strong>af</strong> et<br />
sådant beredskab <strong>for</strong> variantskabelse betyder, at OSDL kan flyttes (mod højre i Figur<br />
15), hvilket medfører at der vil være færre (variant-) specifikationsaktiviteter der skal<br />
lægges ind i et konfigureringssystem.<br />
3.1.1.1 Hvordan <strong>for</strong>egår variantskabelsen i byggebranchen?<br />
En væsentlig erfaring fra PKB projektet er, at producenterne i byggebranchen ofte<br />
ikke har en standardiseret variantskabelse <strong>af</strong> typen configure-to-order (køkkener),<br />
men nærmere er at betegne som modify-to-order (vinduer, døre, porte, simple<br />
tagkonstruktioner etc.) eller engineer-to-order (råhuse, beton konstruktioner, betonelementer,<br />
stålkonstruktioner, etc.).<br />
I PKB projektet er der set eksempler på både engineer-to-order, modify-to-order og<br />
configure-to-order:<br />
• Råhuse fra Dalton Betonelementer: Komplekse betonkonstruktioner er <strong>af</strong><br />
typen engineer-to-order. For at kunne lave en beton-bygning, skal der<br />
<strong>for</strong>etages styrkeberegninger, og der skal modelleres en ydre 3D geometri <strong>af</strong><br />
bygningen. Til produktionen skal der laves detaljerede specifikationer <strong>af</strong> hvert<br />
betonelement, hvilket indebærer diverse snittegninger, klippe-bukke styklister<br />
samt styklister med prædefinerede indstøbningsdele. Denne opgave er<br />
kompleks og svær at lave i et konfigureringssystem. Projektgruppen havde<br />
der<strong>for</strong> vanskeligheder med at komme igennem med opgaven. For at opnå<br />
resultater ændredes fokus fra konfigurering <strong>af</strong> bygninger til konfigurering <strong>af</strong><br />
enkeltstående elementer, samt 3D modellering <strong>af</strong> bygningskonstruktioner.<br />
• Betontrapper fra Dalton Betonelementer: For betontrapper er der tale om en<br />
større grad <strong>af</strong> standard end <strong>for</strong> betonbygninger. Trapperne har en<br />
veldefineret grund<strong>for</strong>m, hvor<strong>for</strong> der er tale om en opgave der minder mere<br />
om modify-to-order, end egentlig engineer-to-order. For denne opgave var<br />
det nemmere <strong>for</strong> virksomheden at opbygge et egentligt konfigureringssystem.<br />
• Badeværelser fra Modulbad: Hovedparten <strong>af</strong> badeværelserne fra Modulbad<br />
opbygges også ud fra en veldefineret plat<strong>for</strong>m, med en <strong>for</strong>holdsvis<br />
veldefineret varians. Her kan opgaven ligeledes karakteriseres som modify-toorder,<br />
hvilket gjorde muligt at lave flere <strong>konfigureringssystemer</strong> (på prototype<br />
niveau).<br />
• Blandingsbatterier (varmevekslere) fra Gemina-Termix: En stor del <strong>af</strong> disse<br />
produkter er <strong>af</strong> typen select-to-order, hvor<strong>for</strong> det ikke var relevant at lave<br />
<strong>konfigureringssystemer</strong>. En anden gruppe var <strong>af</strong> typen configure-to-order,<br />
hvilket muliggjorde <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> (på<br />
prototypeniveau).<br />
Generelt er der en række produkttyper der er oplagte at understøtte med<br />
<strong>konfigureringssystemer</strong>:<br />
• De mest oplagte produkter er køkkener, møbler og standardiserede vinduer<br />
og døre.<br />
• Herefter er der en stor mellemgruppe <strong>af</strong> tilpassede produkter: døre, vinduer,<br />
trapper, tagkonstruktioner, vægkonstruktioner, betonelementer etc.<br />
• Endelig er der de meget komplekse produkter så som betonbygninger,<br />
betonelementer, etc.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
34
Som det vil beskrives senere i dette <strong>af</strong>snit medfører ”modify-to-order” og ”engineerto-order”<br />
processer at der, i langt højere grad end <strong>for</strong> ”configure-to-order”, bliver<br />
behov <strong>for</strong> at specificere 3D geometri og tilhørende 2D tegninger.<br />
3.1.2 Markedsrationale <strong>for</strong> at standardisere<br />
I de industrialiserede <strong>for</strong>syningskæder hvor man i dag finder <strong>konfigureringssystemer</strong><br />
gælder der en række <strong>for</strong>hold, bl.a.:<br />
1. Markedsbehovene er relativt stabile og <strong>for</strong>udsigelige.<br />
2. Der er en fri konkurrence, der betyder at ineffektive arbejdsdelinger og<br />
ineffektive produktionsmetoder løbende udkonkurreres.<br />
3. Kunderne vil hellere have billige standardiserede slutprodukter (configure-toorder,<br />
modify-to-order), end specialtilpassede og dyrere produkter<br />
(engineer-to-order, develop-to-order) eller helt standardiserede produkter<br />
(select-to-order).<br />
Disse faktorer betyder at der er et grundlag <strong>for</strong>, at den enkelte virksomhed<br />
producerer produktfamilier under effektive industrialiserede produktions<strong>for</strong>mer,<br />
herunder en automatisering <strong>af</strong> specifikationsprocesserne ved tilbudsgivning og<br />
ordregennemførelse.<br />
3.1.2.1 Opfylder virksomhederne i byggebranchen disse <strong>for</strong>udsætninger?<br />
For at vurdere hvor vidt byggebranchen lever op til de oven<strong>for</strong> skitserede<br />
<strong>for</strong>udsætninger, kræves der en indsigt i byggebranchen som de færreste, herunder<br />
<strong>for</strong>fatterne til nærværende note, besidder. Det er således med et <strong>for</strong>behold om<br />
manglende indsigt i branchen, at <strong>for</strong>udsætningerne diskuteres i det følgende.<br />
Markedsbehovene er relativt stabile og <strong>for</strong>udsigelige.<br />
Konjunkturfølsomhed betyder at markedsbehovene (<strong>for</strong> f.eks. ”almindelige” opgaver<br />
som renovering, parcelhuse, mindre hal og kontorbygninger mm.) sandsynligvis er<br />
mere ustabile end i den øvrige industri. Tilsvarende er der en række meget store<br />
byggerier (broer, hospitaler, amtsgymnasier, mm.) der skaber et svingende og<br />
mindre <strong>for</strong>udsigeligt behov. Hvor vidt disse <strong>for</strong>hold egentligt påvirker <strong>for</strong>udsætningen<br />
om stabile og <strong>for</strong>udsigelige markedsbehov er svært at sige, uden nærmere<br />
undersøgelser.<br />
Der er en fri konkurrence, der betyder at ineffektive arbejdsdelinger og ineffektive<br />
produktionsmetoder løbende udkonkurreres.<br />
Konkurrencesituationen i byggebranchen debatteres tilsyneladende ofte. Hvor vidt<br />
<strong>af</strong>taler og faglige opdelinger indebærer strukturelle barrierer kan der ikke gives noget<br />
svar på i denne rapport.<br />
Kunderne vil hellere have billige standardiserede slutprodukter (configure-to-order,<br />
modify-to-order), end specialtilpassede og dyrere produkter (engineer-to-order,<br />
develop-to-order) eller helt standardiserede produkter (select-to-order).<br />
Byggerier er som regel at karakterisere som unikke enkeltstyksproduktioner frem <strong>for</strong><br />
typificerede serieproduktioner til en lav pris. Dette kan skyldes, at kunderne ikke er<br />
villige til at give <strong>af</strong>kald på unikke arkitektoniske udtryk, til <strong>for</strong>del <strong>for</strong> en lavere<br />
købspris. Omvendt er der mange licitationer hvor netop prisen er en meget væsentlig<br />
parameter, hvilket peger på, at der burde være en markedsmæssig accept <strong>af</strong><br />
standardiserede løsninger.<br />
35<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
3.1.3 Stor omsætning <strong>af</strong> tilbud eller ordrer<br />
Prædefineret produktvarians er, som beskrevet, en teknisk <strong>for</strong>udsætning <strong>for</strong> at<br />
kunne lave <strong>konfigureringssystemer</strong>. Som økonomisk <strong>for</strong>udsætning gælder, at<br />
specfikationsaktiviteterne skal gentages i en høj hyppighed, således at<br />
kapitalinvesteringer kan tjenes hjem gennem besparelser på driften.<br />
Det økonomiske rationale er ganske parallelt med en hvilken som helst anden<br />
investering i automatisering <strong>af</strong> produktion. Som illustreret i Figur 16 kan der ved en<br />
investering i produktionsudstyr opnås en reduktion <strong>af</strong> variable omkostninger. For<br />
alternative produktionssystemer kan der således optegnes alternative kurver <strong>for</strong> de<br />
totale produktionsomkostninger <strong>for</strong> en given omsætning. Ved at estimere den<br />
fremtidige omsætning kan man herved estimere hvilket produktionsapparat der giver<br />
den laveste totale omkostning.<br />
Omkostninger<br />
ved investering i<br />
automatisering<br />
Totale<br />
omkostninger<br />
Anvend<br />
manuelt<br />
arbejde<br />
Omkostninger <strong>for</strong><br />
manuelt system<br />
Variable<br />
omk.<br />
Anvend delvis<br />
automatisering<br />
Omkostninger <strong>for</strong><br />
delvist-automatisk<br />
system<br />
Anvend fuld<br />
automatisering<br />
Omkostninger <strong>for</strong><br />
fuldautomatisk<br />
system<br />
Omsætning<br />
Figur 16: Totale omkostninger som funktion <strong>af</strong> omsætningsstørrelsen, <strong>for</strong> tre<br />
alternative produktionssystemer.<br />
Det økonomiske rationale er helt tilsvarende <strong>for</strong> <strong>konfigureringssystemer</strong>, omend der<br />
her er flere andre <strong>for</strong>hold at tage hensyn til. Et konfigureringssystem er at betragte<br />
som et fuldautomatisk system, der giver en række besparelser og <strong>for</strong>dele. Til<br />
gengæld er der tale om en stor initial investering. Der<strong>for</strong> skal der være en betydelig<br />
omsætning <strong>af</strong> tilbud eller ordrer før de totale omkostninger ved et<br />
konfigureringssystem er lavere end ved et manuelt system (mennesker og simple<br />
redskaber) eller ved et delvist automatiseret system (mennesker, regneark, CAD<br />
mm.).<br />
3.1.3.1 Opfylder byggebranchen denne <strong>for</strong>udsætning?<br />
Branche<strong>for</strong>eningen ”Dansk Byggeri” oplyser at medlemmerne står <strong>for</strong> ca. 7% <strong>af</strong> den<br />
totale danske produktion, omsætter <strong>for</strong> ca. 20 mia. kroner om året, beskæftiger<br />
70.000 ansatte <strong>for</strong>delt på ca. 5800 virksomheder. Af disse er der 47 virksomheder<br />
der har mere end 100 ansatte (kilde: Dansk Byggeri).<br />
Branchen er således karakteriseret <strong>af</strong> mange små virksomheder. En lille virksomhed<br />
godt kan sælge ét produkt i høj hyppighed uden, at have mange ansatte eller en stor<br />
omsætning i kroner og øre. Der<strong>for</strong> er det, ud fra omsætning og antal ansatte, svært<br />
at vurdere hvornår der er en stor gentagelsesgrad i antallet <strong>af</strong> tilbud og ordrer.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
36
Imidlertid kan det observeres i den øvrige industri, at der som regel mindst er 5-10<br />
funktionærer inden <strong>konfigureringssystemer</strong> kommer på tale, -ofte væsentligt flere<br />
(<strong>for</strong>fatterens skøn).<br />
For de virksomheder der har deltaget i PKB-projektet har der, stort set uden<br />
undtagelse, været tale om relativt små virksomheder. Dette har betydet visse<br />
ud<strong>for</strong>dringer mht. virksomhedernes muligheder <strong>for</strong> at fritage ressourcepersoner fra<br />
den daglige drift til udviklingsarbejdet.<br />
• Dalton Betonelementer (der er en <strong>af</strong> branchens store virksomheder), har med<br />
ca. 40 funktionærer set en tydelig mulighed i <strong>konfigureringssystemer</strong>. Her er<br />
der opbygget en række prototyper, der sandsynliggør at der kan<br />
gennemføres et fuldskalaprojekt.<br />
• Gemina Termix har med ca. 50-60 ansatte ligget i gruppen <strong>af</strong> mindre<br />
virksomheder. Her har mangel på medarbejderes projekttid, samt det at<br />
virksomheden blev opkøbt <strong>af</strong> Danfoss, betydet en <strong>for</strong>sinket opstart <strong>af</strong><br />
konfigureringsprojektet. Grundet et veldokumenteret og standardiseret<br />
produktprogram har det alligevel været muligt at lave en prototype.<br />
3.1.4 Automatiseringsteknologi<br />
Opbygning <strong>af</strong> <strong>konfigureringssystemer</strong> er i dag blevet væsentligt nemmere end <strong>for</strong> ti<br />
år siden. Dette skyldes bl.a. at der i dag findes en stor gruppe <strong>af</strong><br />
softwareleverandører, der leverer standardiseret udviklingssoftware. Dette gør det<br />
muligt at opbygge <strong>konfigureringssystemer</strong> med en relativt lille anvendelse <strong>af</strong> egentlig<br />
programmering. Frem<strong>for</strong> programmering indtastes produktdata, regler og<br />
beregninger i brugervenlige udviklingsmiljøer.<br />
Eksempler på disse er Cincom KnowledgeBuilder, SSA Global Modeler/Configurator,<br />
Oracle Modeler/Configurator etc.<br />
3.1.4.1 Specielle <strong>for</strong>hold i byggebranchen<br />
En stor del <strong>af</strong> <strong>konfigureringssystemer</strong>ne fokuser på configure-to-order segmentet,<br />
hvor en ny produktvariant kan beskrives ved en stykliste alene. Dette betyder at et<br />
tekstbaseret output er tilstrækkeligt, f.eks. en liste <strong>af</strong> varenumre. De<br />
<strong>konfigureringssystemer</strong>, der i dag eksisterer i større industrivirksomheder (f.eks.<br />
Cincom KnowledgeBuilder hos APC eller SSA-Global hos F.L.Smidth etc.) håndterer<br />
således logik og tekstbaseret output, men ikke geometriske relationer og et gr<strong>af</strong>isk<br />
output.<br />
Betragtes engineer-to-order segmentet findes en række IT-systemer, der kan<br />
betegnes som modne. Det gælder f.eks. <strong>for</strong> CAD-systemerne, som kan bruges til at<br />
understøtte arbejdsprocesser, der involverer fremstilling <strong>af</strong> tegninger og digitale 3Dmodeller<br />
mm.<br />
For konfigurering i byggebranchen er ud<strong>for</strong>dringen, at der, som omtalt tidligere, ofte<br />
ikke er tale om blot configure-ro-order, men også om modify-to-order og engineerto-order.<br />
Dette betyder, at der er behov <strong>for</strong> håndtering <strong>af</strong> geometri og udarbejdelse<br />
<strong>af</strong> tegninger. Kombineres dette med et krav om håndtering <strong>af</strong> logik og udarbejdelse<br />
<strong>af</strong> styklister begrænses listen <strong>af</strong> modne standardiserede udviklingsmiljøer<br />
betragteligt.<br />
Som en del <strong>af</strong> PKB-projektet er der udarbejdet en analyse <strong>af</strong> softwaresystemer til<br />
visuel konfigurering. Der er opstillet en liste med beskrivelsespunkter, der<br />
37<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
karakteriserer softwaresystemerne og deres leverandører, hvorudfra de enkelte<br />
systemer kommenteres. Gennem analysearbejdet blev eksisterende<br />
strandardsoftware opdelt i nogle overordnede grupper (som illustreret i Figur 17).<br />
Høj<br />
Omfang <strong>af</strong><br />
videnmodellering<br />
Lav<br />
A: Standardsoftware B: Branche-dedikeret<br />
standardsoftware<br />
A1:<br />
Cincom<br />
Oracle<br />
SSA<br />
etc.<br />
A3:<br />
VirtuBuild<br />
Intent<br />
IPC<br />
etc.<br />
A2:<br />
AutoCAD<br />
UGII<br />
Inventor<br />
etc.<br />
Lav<br />
Høj<br />
Omfang <strong>af</strong> gr<strong>af</strong>ikmodellering<br />
Omfang <strong>af</strong><br />
videnmodellering<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
B3:<br />
AcadWand<br />
Impact<br />
FurnishPro<br />
etc.<br />
B2:<br />
Architectural<br />
Desktop<br />
etc.<br />
Omfang <strong>af</strong> gr<strong>af</strong>ikmodellering<br />
Figur 17: klassificering <strong>af</strong> standardsoftware ud fra de tre beskrivelsespunkter:<br />
omfang <strong>af</strong> videnmodellering, omfang <strong>af</strong> gr<strong>af</strong>ikmodellering og om hvor vidt der er<br />
tale om branchededikeret software [Hansen&Hvam, 2004b].<br />
Analysen viste at der ikke findes et bredt udvalg <strong>af</strong> standardsoftware, der<br />
understøtter problemstillingen med at håndtere både logik og geometriske relationer,<br />
og udarbejdelsen <strong>af</strong> både styklister og tegninger. De systemer der findes er endnu<br />
relativt nye og har alle deres mangler. På den anden side er det p.t. det bedste<br />
grundlag man har at støtte sig til hvis udviklingen skal baseres på standardsystemer.<br />
Nogle eksempler på systemer fra denne gruppe er:<br />
• Engineering Intent (<strong>for</strong>handles i DK <strong>af</strong> Factotech)<br />
• VirtuBUILD (<strong>for</strong>handles og udvikles i DK <strong>af</strong> 3Dfacto)<br />
• KnowledgeFusion (<strong>for</strong>handles i DK <strong>af</strong> Unigraphics)<br />
• Inventor Product Configurator (<strong>for</strong>handles og udvikles i DK <strong>af</strong> Betechdata)<br />
Konklusionen er: Der findes standardsoftware, der kan anvendes til at understøtte<br />
konfigureringsproblematikken i byggebranchen. Imidlertid er der ofte behov <strong>for</strong> både<br />
geometrihåndtering og logikhåndtering, hvilket reducerer udbuddet <strong>af</strong><br />
standardsoftware betragteligt. Det software der findes i dette segment er endnu<br />
relativt umodent (sammenlignet med modne <strong>konfigureringssystemer</strong> og modne CADsystemer).<br />
Der vil sandsynligvis gå 3-5 år før der er bredt udvalg <strong>af</strong><br />
indlæringsnemme standardsystemer i dette segment (<strong>for</strong>fatterens vurdering).<br />
3.1.5 Geometri-tilpasning i variantskabelsen og krav om tegninger<br />
Et konfigureringssystem vil <strong>af</strong> mange betragtes som et system, der konfigurerer<br />
prædefinerede ”byggeklodser” og således understøtter ”configure-to-order”<br />
processer. Udarbejdelse <strong>af</strong> varianter på baggrund <strong>af</strong> prædefinerede varenumre, har<br />
den store <strong>for</strong>del, at det primære output fra et konfigureringssystem kan begrænses<br />
til primært en stykliste (og eventuelt sekundært en samlingstegning, operations<strong>for</strong>løb<br />
mm.). Da varenumrene er kendte er det typisk muligt, at give et tilbud og<br />
gennemføre produktionen på baggrund <strong>af</strong> det ”simple” output: en stykliste (se<br />
eksempel i Figur 18).<br />
Høj<br />
Lav<br />
B1:<br />
?<br />
Lav<br />
Høj<br />
38
Figur 18: Typisk stykliste-output. Data genereret i Cincom og fremvist i HTML i en<br />
browser (fra APC, 2001).<br />
Som beskrevet oven<strong>for</strong> er der ofte tale om ”engineer-to-order” og ”modify-to-order” i<br />
byggebranchen. I disse tilfælde er det pr. definition ikke tilstrækkeligt, at specificere<br />
nye produktvarianter med en stykliste.<br />
Her skabes der nye ”byggeklodser” (komponenter og moduler) i kundebehandlingen,<br />
f.eks. en ny ud<strong>for</strong>mning <strong>af</strong> rør, nye geometrier <strong>for</strong> vindueslister, nye ud<strong>for</strong>mninger <strong>af</strong><br />
armeringsjern til betonelementer etc. I disse tilfælde bliver specificering <strong>af</strong> de nye<br />
geometrier nødvendige. Der<strong>for</strong> skal der skabes en ny gruppe specifikationer, nemlig<br />
detailtegninger <strong>af</strong> komponenter, samt samlingstegninger (se eksempel i Figur 19).<br />
Hos Dalton Betonelementer er tegninger en <strong>for</strong>udsætning <strong>for</strong>, at kunne beskrive<br />
varianter <strong>af</strong> betonelementer, både hvad angår trapper og vægelementer. For<br />
vægelementer skal der udarbejdes tegninger <strong>af</strong> den ydre geometri, snittegninger <strong>af</strong><br />
detaljer samt ”mini”-tegninger <strong>af</strong> klippet og bukket armeringsjern (se eksempel i<br />
Figur 19).<br />
Dette <strong>for</strong>hold betyder at specifikationsopgaven er mere kompleks, hvor<strong>for</strong> det også<br />
bliver mere komplekst, at opbygge et konfigureringssystem til understøttelse her<strong>af</strong>.<br />
Denne problemstilling er således en eksemplificering <strong>af</strong> konceptet fra Figur 14 og<br />
Figur 15 om OSDL: Når ”det grå område” (opgaven, der ligger i at udarbejde<br />
specifikationer i kundebehandlingen) bliver større (flere typer output-specifikationer,<br />
f.eks. flere tegninger) bliver det også mere vanskeligt at lave et<br />
konfigureringssystem, der automatisk udarbejder outputtet.<br />
39<br />
Item Description<br />
Area name: Area 1<br />
QTY<br />
FM35-50 NetworkAIR FM Series 35-50 KW 1<br />
FM35-50 COMMON PARTS FM35-50 COMMON PARTS 1<br />
0M-74281 Sheet Metal Cabinet Common 35-50kW 1<br />
0M-74282 Refrigeration Common Parts 1<br />
0M-74202 Electrical Common Parts 20-50kW 1<br />
FM35-50SHEETMETAL FM35-50 SHEET METAL 1<br />
0M-74284 Sheet Metal Parts Up Discharge 1<br />
FM35-40 ELECTRICAL FM35-40 ELECTRICAL 1<br />
0M-74376 Elect panel FM40 208/230 Ht Hu 1<br />
FM35-50 COILS FM35-50 COILS 1<br />
0M-74298 DX & Econ/MultiCool Coil Assembly Up Discharge 40kW 1<br />
FM35-50 PANEL KITS FM35-50 PANEL KITS 1<br />
0M-74315 Panel Kit, Up Discharge Expansion 35-50kW BLK 1<br />
FM35-50 BLOWER FM35-50 BLOWER 1<br />
0M-74318 Blower Assembly 35-50kW 1<br />
FM35-50 COMPRESSORS FM35-50 COMPRESSORS 1<br />
0M-74320 Compressor 208/230 Voltage Parts 60Hz 40kW 1<br />
FM20-50 OPTIONAL FM20-50 OPTIONAL 1<br />
0M-74244 Detector, Water Cable 2<br />
0M-74243 Detector, Water Spot 1<br />
0M-74242 Detector, Smoke 1<br />
FM35-50 LIQUID LINE ASSEMBLY FM35-50 LIQUID LINE ASSEMBLY 1<br />
0M-1800 Liquid Line Assembly 7/8" Rec In (Water/Glycol) 1<br />
FM35-50 DISCHARGE LINE ASSY FM35-50 DISCHARGE LINE ASSEMBLY 1<br />
0M-1716 Discharge Line Assembly 1-1/8" (Water/Glycol) 35-40kW 1<br />
FM35-50 COIL PACK PIPING FM35-50 COIL PACK REFRIGERANT PIPING 1<br />
0M-74394 Piping DX Only Coil Assembly Up Discharge 40kW 1<br />
FM35-50 REHEAT FM35-50 REHEAT 1<br />
0M-74338 Electric Reheat 200-240 Volts 1<br />
FM20-50 HUMIDIFICATION FM20-50 HUMIDIFICATION 1<br />
0M-75000 FM35 CONDENSER 95 230/1/60 SINGLE 1<br />
FM35-50 HEAT EXCHANGER FM35-50 HEAT EXCHANGER 1<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Figur 19: Udsnit <strong>af</strong> produktionstegning med todelt stykliste og minitegninger i<br />
styklisten (fra Dalton Betonelementer, 2004).<br />
Tilsyneladende er der i byggebranchen en tendens til ”engineer-to-order” og<br />
”modify-to-order” frem <strong>for</strong> ”configure-to-order”. Dette betyder at der alt andet lige<br />
må påberegnes en ekstra grad <strong>af</strong> kompleksitet ved <strong>opbygning</strong>en <strong>af</strong><br />
<strong>konfigureringssystemer</strong>. Alternativt skal der <strong>for</strong>etages en standardisering <strong>af</strong><br />
produkterne, således at man bevæger sig i retningen fra ”engineer-to-order” mod<br />
”configure-to-order”.<br />
3.1.6 Afrunding <strong>af</strong> de generelle erfaringer<br />
De generelle erfaringer påpeger således nogle helt fundamentale <strong>for</strong>hold.<br />
I de tilfælde hvor der mangler en prædefineret varians kan det skyldes, at kunderne<br />
simpelt hen ikke ønsker det samt, at markedet kan være <strong>for</strong> svære at <strong>for</strong>udsige. En<br />
anden mulig <strong>for</strong>klaring er strukturelle bindinger branchen.<br />
Hvis der ikke er en prædefineret produktvarians kan variantspecifikationsopgaven<br />
være kompleks og omfatte udarbejdelsen <strong>af</strong> kundetilpassede komponentgeometrier<br />
og samlingsstrukturer. Dette medfører skrappere krav til <strong>konfigureringssystemer</strong>ne,<br />
der nu skal være i stand til at håndtere geometri.<br />
De skrappere krav til <strong>konfigureringssystemer</strong>ne gør det vanskeligere at opbygge<br />
systemerne, primært i de tilfælde hvor der skal være en håndtering <strong>af</strong> geometri og<br />
udarbejdelse <strong>af</strong> tegninger.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
40
Branchens mange små virksomheder har muligvis ikke et tilstrækkeligt volumen til,<br />
at det vil være lønsomt at investere i <strong>konfigureringssystemer</strong>.<br />
Erfaringerne fra PKB-projektet peger dog også på, at der er en række virksomheder,<br />
der <strong>for</strong>søger at udvikle sig <strong>for</strong>, at kunne opfylde de <strong>for</strong>udsætninger der gælder <strong>for</strong><br />
industrialisering.<br />
Mange <strong>af</strong> de implicerede virksomheder arbejder både med, at <strong>for</strong>bedre<br />
<strong>for</strong>udsætningerne <strong>for</strong> <strong>konfigureringssystemer</strong> og med at opbygge<br />
<strong>konfigureringssystemer</strong>. Arbejdet med at opbygge <strong>konfigureringssystemer</strong> har bragt<br />
en masse manglende <strong>for</strong>udsætninger frem i lyset, hvilket burde medføre at disse<br />
diskuteres og behandles ude i virksomhederne.<br />
41<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
3.2 Erfaring med selve fremgangsmåden<br />
Den i kapitel 2 skitserede fremgangsmåde er blevet anvendt i tre virksomheder,<br />
gennem flere prototype <strong>for</strong>løb. Erfaringerne hermed er beskrevet i dette kapitel.<br />
3.2.1 <strong>Fremgangsmåde</strong>n og nye <strong>for</strong>udsætninger<br />
Baseret på erfaringerne i PKB-projektet kan det siges, at fremgangsmåden i store<br />
træk er hensigtsmæssig. På de fleste områder er der ikke de store <strong>for</strong>skelle<br />
sammenlignet med projekter udført i maskinindustrien.<br />
Forskellene og ud<strong>for</strong>dringerne kommer, ikke uventet, på de områder hvor<br />
<strong>for</strong>udsætningerne er anderledes. I <strong>for</strong>længelse <strong>af</strong> <strong>for</strong>rige <strong>af</strong>snit kan der der<strong>for</strong><br />
påpeges en række områder med nye ud<strong>for</strong>dringer grundet specielle eller manglende<br />
<strong>for</strong>udsætninger:<br />
• Projekt-”scoping” og iterativ anvendelse <strong>af</strong> fremgangsmåden bliver vigtigere i<br />
grad med stigende usikkerhed omkring projekt<strong>for</strong>løbet.<br />
• Forretningsprocesanalysen bliver mere vanskelig, når der er en større<br />
kompleksitet i samarbejdsrelationerne i værdikæden.<br />
• ”Cost-benefit-risk”-analyser bliver mere vanskelige, når opgaven generelt<br />
bliver mere kompleks.<br />
• Produktanalysen og objektorienteret analyse og design bliver mere vanskelig<br />
når der er en større produktkompleksitet.<br />
• Des mere man bevæger sig væk fra den traditionelle problemstilling, fra<br />
configure-to-order mod engineer-to-order, des mere kompleks bliver<br />
opgaven, og des flere problemer løber man ind i. Der bliver f.eks. behov <strong>for</strong><br />
at håndtere geometri og generere tegninger.<br />
• Ved et behov <strong>for</strong> udarbejdelse <strong>af</strong> tegninger og håndtering <strong>af</strong> geometriske<br />
relationer er der væsentlig mere viden der skal dokumenteres, hvilket<br />
bevirker at man ”presser” de eksisterende modelleringsteknikker<br />
(produktvariantmaster og CRC-kort) til det yderste.<br />
• Udvælgelsen <strong>af</strong> software bliver mere vanskelig, når der er flere krav og<br />
udvalget bliver mindre.<br />
Disse erfaringer behandles i det følgende. Først diskuteres projekt-”scoping”.<br />
Herefter diskuteres erfaringerne ud fra hver fase <strong>af</strong> fremgangsmåden.<br />
3.2.2 Projekt-”scoping” og iterationer<br />
Princippet om iterative udviklings<strong>for</strong>løb understøttes klart <strong>af</strong> de erfaringer der er gjort<br />
i PKB projektet. Erfaringerne er, at det har været meget komplekst, at overskue hele<br />
fuldskalaprojekter, teknologien, organisering, potentielle gevinster, omkostninger og<br />
ricisi. For at gøre projekt<strong>for</strong>løbene mere overskuelige har det der<strong>for</strong> været<br />
nødvendigt, at ”scope” projekterne i mindre bidder. Denne erkendelse er kommet<br />
hen ad vejen <strong>for</strong> de implicerede parter. Enkelte <strong>af</strong> de deltagende virksomheder har<br />
faktisk været <strong>for</strong> ambitiøse og har ikke ønsket at starte med mindre omfattende<br />
<strong>konfigureringssystemer</strong>. Først senere er det erkendt at man ”skal kravle før man kan<br />
gå”.<br />
De helt konkrete erfaringer er således:<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
42
43<br />
• Man skal passe på med at være alt <strong>for</strong> ambitiøs i det første projekt<strong>for</strong>løb. Det<br />
er godt at have en ambitiøs vision, men det er uhensigtsmæssigt at <strong>for</strong>søge<br />
at nå det hele i første omgang.<br />
• Projekter risikerer at trække i langdrag, hvis der ikke ”scopes” ned til mindre<br />
bidder. Man risikerer at der går <strong>for</strong> lang tid inden der opnås resultater og at<br />
folk mister tilliden til projektet.<br />
• Skær projektet ned i mindre bidder, f.eks.: Fokuser på én produktfamilie<br />
frem<strong>for</strong> flere, vælg et isoleret område hvor behovet som udgangspunkt er<br />
størst, fravælg noget funktionalitet, start med f.eks. kun én type output, etc.<br />
Opdelingen i iterative projekt<strong>for</strong>løb betyder, at man opdeler udgifter, gevinster og<br />
risici i mindre bidder. Alt andet lige vil man i de første gennemløb opleve relativt lave<br />
direkte gevinster. Til gengæld er sandsynligheden <strong>for</strong> at gennemføre et kort<br />
delprojekt langt større end <strong>for</strong> et stort. Omkostningerne er tilsvarende væsentligt<br />
lavere. Endelig kan erfaringerne fra det første projekt<strong>for</strong>løb bruges konstruktivt til at<br />
styre næste gennemløb bedre.<br />
3.2.3 Fase 1: Procesanalyse<br />
<strong>Fremgangsmåde</strong>ns fase 1 ”procesanalyse” har været anvendt uden større problemer.<br />
I de udvalgte virksomheder har der været optegnet procesdiagrammer, der har<br />
været anvendt som udgangspunkt <strong>for</strong> en identifikation <strong>af</strong> problemer og mulige<br />
fokusområder. Endvidere har en identifikation <strong>af</strong> nøgletal dannet grundlag <strong>for</strong> en<br />
identifikation <strong>af</strong> den potentielle gevinst ved at IT-automatisere processerne.<br />
Fasen har, som <strong>for</strong> konfigureringsprojekter i maskinindustrien, vist sig behjælpsom<br />
ved identifikation <strong>af</strong> behovene <strong>for</strong> et fremtidigt konfigureringssystem, og <strong>for</strong><br />
fastlæggelsen <strong>af</strong> en kravspecifikation hertil.<br />
Der er imidlertid et par områder, hvor der er særlige <strong>for</strong>hold. Disse er:<br />
• Behov <strong>for</strong> en bedre <strong>af</strong>klaring <strong>af</strong> interessenter<br />
• Behov <strong>for</strong> bedre cost-benefit analyser<br />
Disse to punkter kommenteres særskilt i det følgende.<br />
3.2.3.1 Interessent- og netværksanalyser<br />
For leverandører i byggebranchen vil de interne <strong>for</strong>retningsprocesser ofte interagere<br />
med eksterne interessenter. De eksterne interessenter kan befinde sig <strong>for</strong>skellige<br />
steder i det samlede byggeris værdikæde og samarbejde i mere eller mindre <strong>for</strong>melle<br />
netværk. I <strong>for</strong>bindelse med en <strong>for</strong>estående automatisering <strong>af</strong> <strong>for</strong>retningsgange bør<br />
virksomheden søge at <strong>for</strong>stå de gevinster, omkostninger og risici, og dermed<br />
incitamenter, som aktørerne i disse værdikæder og netværk står over<strong>for</strong>.<br />
Eksempler på mulige problemstillinger, der kan være værd at identificere er bl.a.:<br />
• Komponentleverandører kan bevæge sig opad i værdikæden: Hvis der<br />
skabes <strong>konfigureringssystemer</strong> og digitale bygningsmodeller med<br />
ekspertviden, overflødiggøres dele <strong>af</strong> arkitekters, rådgivende ingeniørers og<br />
entreprenørers arbejde. I den ultimative situation kan man uden større<br />
teknisk indsigt designe en hel bygning ned til mindste detalje og udskrive<br />
store dele <strong>af</strong> produktionsgrundlaget automatisk.<br />
• Komponentleverandører kan presses på indtjening: IT-systemer muliggør en<br />
større grad <strong>af</strong> sammenligning <strong>af</strong> <strong>for</strong>skellige komponenter. Alternative<br />
løsninger kan hurtigt skabes og evalueres, hvilket skaber en større<br />
konkurrence og prispres mellem leverandører.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
• Større grad <strong>af</strong> industrialisering og investeringer kan tvinge leverandører til at<br />
samarbejde: Investeringer i maskiner og IT betyder, at der skal et større<br />
salgsvolumen til betale investeringerne hjem. Dette kan betyde, at<br />
leverandører skal se sig om efter samarbejdspartnere <strong>for</strong> at skabe et større<br />
volumen i omsætningen.<br />
• Arkitekters jobbeskrivelse kan ændres: <strong>konfigureringssystemer</strong> og digitale<br />
bygningsmodeller kan betyde at en del <strong>af</strong> arkitekternes tekniske<br />
arbejdsopgaver <strong>for</strong>mindskes, og fokus flyttes mod de egentlige kreative<br />
opgaver. På den anden side stilles der måske krav om, at arkitekter<br />
overtager dele <strong>af</strong> ingeniørernes arbejde, <strong>for</strong>di dette bliver teknisk muligt.<br />
Hvis komponentleverandører samarbejder med arkitekter og rådgivende om<br />
nye IT-systemer, er det vigtigt at kende disses incitamenter <strong>for</strong> at hjælpe<br />
eller modarbejde udviklingsprocessen.<br />
• Teknikeres jobbeskrivelse hos komponentleverandørerne kan ændres: ITsystemer<br />
betyder at tekniske tegnere, salgssupportører, sælgere, ingeniører,<br />
designere får en ændret jobbeskrivelse. Tekniske tegnere skal måske til at<br />
fungere mere som ingeniører, mens designere måske skal fokusere endnu<br />
mere på det kreative, eller omstilles til det mere tekniske, <strong>for</strong>di en del <strong>af</strong><br />
designfunktionen automatiseres.<br />
For at <strong>for</strong>stå de potentielle <strong>for</strong>andringer der kan, eller bør, gennemføres i<br />
værdikæden kan det være en idé, at identificere hvilke samarbejdende netværk en<br />
virksomhed indgår i og hvilke interessenter der er i netværkene.<br />
Resultatet <strong>af</strong> analysen skal være en identifikation <strong>af</strong> de ønsker og krav<br />
interessenterne har til fremtidige nye <strong>for</strong>retningsprocesser, f.eks.:<br />
• Hvordan kan der laves en mere effektiv arbejdsdeling?<br />
• Kan der med <strong>for</strong>del laves systemleverancer?<br />
• Hvem vil være vindere og tabere ved en <strong>for</strong>andring <strong>af</strong> de eksisterende<br />
<strong>for</strong>retningsprocesser? Er der nogle funktioner, der bliver overflødige?<br />
Oprettes der nye funktioner?<br />
• Hvilke <strong>for</strong>retningsmæssige per<strong>for</strong>mancekrav vil der være til produktkvalitet,<br />
grad <strong>af</strong> kundetilpasning (engineer-to-order eller configure-to-order)<br />
gennemløbstider, priser, leveringssikkerhed etc.?<br />
• Vil der være særlige krav til <strong>for</strong>mater ved udveksling <strong>af</strong> data, f.eks. krav til fil<strong>for</strong>mater<br />
ved udveksling <strong>af</strong> CAD-modeller.<br />
• Etc.<br />
For det fremtidige konfigureringssystem skal der endvidere identificeres følgende<br />
krav:<br />
• Hvilke andre systemer hos de andre interessenter skal systemet udveksle<br />
data med?<br />
• Hvilke muligheder er der <strong>for</strong> at interessenter kan gå sammen om at opbygge<br />
systemer?<br />
• Kan der med <strong>for</strong>del vælges samme softwareplat<strong>for</strong>m?<br />
• Hvem skal arbejde sammen om at opbygge systemet?<br />
• Hvem skal stå <strong>for</strong> drift og vedligeholdelse <strong>af</strong> de <strong>for</strong>skellige delsystemer?<br />
3.2.3.2 ”Cost-benefit-risk” vurderinger<br />
Den anden ud<strong>for</strong>dring, der er observeret under procesanalyserne er vurderingen <strong>af</strong><br />
de potentielle gevinster, omkostninger og ricisi. Disse ”return on investment”<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
44
etragtninger er traditionelt vanskelige, men i byggebranchen kan de være endnu<br />
mere ud<strong>for</strong>drende <strong>af</strong> de årsager der er diskuteret i starten <strong>af</strong> nærværende kapitel:<br />
• Byggebranchen kan være mere konjunkturfølsom.<br />
• Produkterne er ofte mere komplekse (mere engineer-to-order end configureto-order)<br />
end <strong>for</strong> de mere standardiserede maskinprodukter.<br />
• Man har måske ikke så mange erfaringer med automatisering i almindelighed,<br />
og mangler hermed et erfaringsgrundlag <strong>for</strong> at diskutere automatisering <strong>af</strong><br />
salgs- og ordrebehandlingsprocesser.<br />
• Softwareteknologien er endnu ikke moden på mange <strong>af</strong> de områder, som<br />
byggebranchen ønsker (håndtering <strong>af</strong> både geometri og logik).<br />
• Mange <strong>af</strong> de mindre virksomheder har ikke den IT-ekspertise der skal til <strong>for</strong><br />
at vurdere teknologien.<br />
Nogle er de erfaringer der er gjort i PKB kan bruges til at opstille checklister med<br />
potentielle gevinster, omkostninger og risici. Dette er <strong>for</strong>søgt i det følgende.<br />
Typiske<br />
gevinstpunkter<br />
Besparelse <strong>af</strong><br />
direkte<br />
interne timer<br />
Besparelse <strong>af</strong><br />
indirekte<br />
timer<br />
Digitale 3D<br />
modeller<br />
45<br />
Beskrivelse Erfaringer<br />
De direkte arbejdstimer dækker den tid der<br />
bruges til udarbejdelsen <strong>af</strong> dokumenter i<br />
tilbudsgivning og ordrebehandling, f.eks.<br />
tegninger, styklister og prisberegninger.<br />
De indirekte timer, dækker over den tid der<br />
anvendes i produktionen. Denne tid<br />
<strong>af</strong>hænger <strong>af</strong> kvaliteten <strong>af</strong><br />
produktionsgrundlaget, samt <strong>af</strong><br />
produktionsplanlægningen. Hurtigere tilgang<br />
til produktionsdokumenterne medfører en<br />
bedre planlægning og dermed en bedre<br />
kapacitets- og materialeudnyttelse.<br />
Tilsvarende kan en bedre kvalitet <strong>af</strong><br />
produktionsgrundlaget betyde et lavere spild<br />
i produktionen.<br />
Digitale 3D modeller <strong>af</strong> virksomhedens<br />
produkter betyder at arkitekter, rådgivende<br />
og entreprenører kan lave mere nøjagtige<br />
digitale modeller <strong>af</strong> det færdige byggeri.<br />
Dette giver en række <strong>for</strong>dele, hvor<strong>for</strong> man<br />
til en vis grad vil <strong>for</strong>etrække leverandører,<br />
der stiller digitale 3D modeller til rådighed.<br />
Her har der været en del besparelse at<br />
hente hos de implicerede parter,<br />
specielt ved udarbejdelsen <strong>af</strong><br />
produktionstegninger og styklister.<br />
Dette punkt syntes at være et <strong>af</strong> de<br />
primære gevinstområder hos flere <strong>af</strong><br />
de implicerede parter.<br />
Blandt parterne i PKB var denne<br />
tendens ikke så udbredt som ventet.<br />
Gevinster synes nemmere at estimere, <strong>for</strong>di der ofte er tale om en besparelse <strong>af</strong><br />
kendte udgifter, eller en <strong>for</strong>bedring <strong>af</strong> kendte måltal, f.eks. leveringstid.<br />
Omkostningerne ved konfigureringsprojekter er sværere at <strong>for</strong>udsige <strong>for</strong>di man her<br />
bevæger sig ud på ukendt grund, både hvad angår den nye teknologi, men også<br />
hvad angår hele projekt<strong>for</strong>løbet.<br />
Typiske<br />
omkostningspunkter<br />
Restrukturering <strong>af</strong><br />
produktsortiment<br />
Beskrivelse Erfaringer<br />
Forudsætningerne <strong>for</strong> konfigurering og<br />
industrialisering er at der anvendes<br />
relativt standardiserede produktfamilier.<br />
Der<strong>for</strong> kan det være nødvendigt at<br />
gennemtænke produktsortimentet og<br />
Der var ikke fokus på dette område.<br />
Dog har virksomhederne generelt<br />
løbende beskæftiget sig hermed.<br />
Under dokumentations<strong>for</strong>løbet blev<br />
der truffet nogle valg, der<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Indsamling og<br />
dokumentation <strong>af</strong><br />
viden<br />
skabe mere standardiserede<br />
produktkomponenter. I realiteten er der<br />
tale om at flytte ”order specification<br />
decoupling line” i retning fra engineerto-order<br />
mod configure-to-order.<br />
Dette omfatter en beskrivelse <strong>af</strong><br />
hvordan en ny produktvariant skabes:<br />
hvilke dele eksisterer der som<br />
udgangspunkt <strong>for</strong> variantskabelsen?<br />
Hvilke regler gælder <strong>for</strong> delenes nye<br />
sammensætning etc. Meget <strong>af</strong> denne<br />
viden eksisterer inde i hovederne på<br />
sælgere, teknikere og ingeniører,<br />
hvor<strong>for</strong> det koster analyse-arbejde at få<br />
det nedfældet på papir.<br />
Køb <strong>af</strong> software Softwareudgifter opdeles typisk i en<br />
engangsbetaling og en årlig<br />
licensbetaling.<br />
Opbygning <strong>af</strong><br />
konfigureringssystem<br />
(programmering)<br />
Dette omfatter oprettelsen <strong>af</strong><br />
produktkomponenter, variable, regler,<br />
beregninger etc. inde i det valgte<br />
softwaresystem. Anvendelsen <strong>af</strong><br />
standardsystemer betyder at der i<br />
mindre grad er tale om egentlig<br />
programmering og mere om indtastning<br />
og strukturering <strong>af</strong> data og viden.<br />
simplificerede nogle regelsæt.<br />
Denne opgave har som<br />
udgangspunkt været tidskrævende i<br />
de implicerede virksomheder.<br />
Dog har software-ud<strong>for</strong>dringer<br />
flyttet en del <strong>af</strong> fokus fra dette<br />
område til systemudviklingen.<br />
De totale udgifter over 5 år løber<br />
typisk op i en halv til to millioner<br />
kroner, dog meget <strong>af</strong>hængigt <strong>af</strong><br />
antallet <strong>af</strong> brugere. Se mere i PKB’s<br />
softwareanalyserapport<br />
[Hansen&Hvam, 2004 b].<br />
Dette punkt har voldt de største<br />
problemer i PKB-projektet. Dette<br />
skyldes bl.a., at problemstillingerne<br />
var meget komplekse, at der ikke<br />
tilsyneladende ikke kunne findes det<br />
ønskede standardsoftware, samt at<br />
virksomhederne var tilbageholdende<br />
med at købe ekspertbistand.<br />
De potentielle risici er sandsynligvis blandt de største barrierer mod<br />
konfigureringsprojekter i byggebranchen. Disse er svære at overskue, og manglen på<br />
”frontløbere/fyrtårne” gør det sværere, at eftervise, at det er muligt at gennemføre<br />
projekter med succes.<br />
Typiske<br />
risikopunkter<br />
Accepterer<br />
kunderne<br />
standardiserede<br />
produkter?<br />
Omkostninger<br />
kan<br />
undervurderes<br />
Beskrivelse Erfaringer<br />
Ved overgangen til en<br />
industrialiseret produktion og<br />
anvendelsen <strong>af</strong><br />
<strong>konfigureringssystemer</strong>, vil man<br />
ofte være nødt til at gå på<br />
kompromis med den grad hvormed<br />
man kan tilfredsstille individuelle<br />
kundebehov. Hvis man begrænser<br />
kundernes valg <strong>for</strong> meget, i relation<br />
til den besparelse som kunden<br />
opnår, risikerer man at kunderne<br />
finder andre leverandører.<br />
Udviklingsomkostningerne kan være<br />
svære at estimere, både hvad angår<br />
tid til videnindsamling og<br />
programmering. Des mere der er<br />
tale stor kompleksitet og mere<br />
engineer-to-order end configure-toorder,<br />
des sværere bliver det at<br />
estimere automatiseringsomkostningerne.<br />
Dette punkt var en væsentlig risikoparameter<br />
<strong>for</strong> nogle <strong>af</strong> virksomhederne i PKB-projektet.<br />
Der er ikke lavet sammenlignende præ- og<br />
efterkalkulationer. Erfaringen var dog at<br />
virksomhederne har meget svært med at<br />
vurdere korrektheden <strong>af</strong> det estimerede<br />
omkostningsniveau. Man er tilsyneladende<br />
ofte nødt til at stole på sit instinkt og mere<br />
strategiske vurderinger om hvordan<br />
<strong>for</strong>retningen ønskes at være i fremtiden. En<br />
løsning kan være at lave scenarier og<br />
følsomhedsanalyser.<br />
Projektfolk kan Dette punkt gælder <strong>for</strong> alle Dette punkt var meget relevant, specielt i de<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
46
<strong>for</strong>lade projektet projekter. Hvis en eller flere <strong>af</strong> de<br />
centrale personer <strong>for</strong>lader projektet,<br />
kan det bremse udviklings<strong>for</strong>løbet<br />
betragteligt.<br />
Man kan vælge<br />
den <strong>for</strong>kerte<br />
softwareplat<strong>for</strong>m<br />
47<br />
Ved valget <strong>af</strong> software binder man<br />
sig til de muligheder og<br />
begrænsninger, der er i et konkret<br />
stykke software. I yderste<br />
konsekvens kan man vælge en<br />
softwareplat<strong>for</strong>m, der ikke gør det<br />
muligt at gennemføre projektet på<br />
en rentabel måde.<br />
mindre PKB-involverede virksomheder. Små<br />
virksomheder er mere <strong>af</strong>hængige <strong>af</strong><br />
enkeltpersoner.<br />
Korte iterative projekt<strong>for</strong>løb er en væsentlig<br />
måde at reducere denne risiko på. En anden<br />
løsning er at købe ekspertise udefra, fra<br />
større softwareleverandører eller<br />
konsulenthuse. Denne løsning blev<br />
tilsyneladende <strong>for</strong>etrukket i flere tilfælde,<br />
men det er vigtigt at gøre sig klart at der her<br />
opstår andre risici, f.eks. <strong>af</strong>hængighed <strong>af</strong><br />
dyre eksterne konsulenter.<br />
Virksomhederne havde generelt meget svært<br />
ved at vælge en softwareplat<strong>for</strong>m, primært<br />
<strong>for</strong>di det tilsyneladende næsten er umuligt at<br />
overskue mulighederne og begrænsningerne<br />
i de <strong>for</strong>skellige systemer. Indtil der er flere<br />
vellykkede projekter at sammenligne sig med<br />
må man tage en chance i valget <strong>af</strong> software.<br />
Generelt er procesanalysen blevet anvendt meget lig tidligere anvendelser i tidligere<br />
konfigureringsprojekter. Kun omkring netværk- og interessentanalyserne og costbenefit-analyserne<br />
synes der at være nogle særlige ud<strong>for</strong>dringer.<br />
3.2.4 Fase 2: Produktanalyse<br />
<strong>Fremgangsmåde</strong>ns fase 2 har i store træk vist sin anvendelighed, også <strong>for</strong><br />
konfigureringsprojekter i byggebranchen. Gennem optegning <strong>af</strong><br />
produktvariantmastere er der opnået overblik over den konkrete produktviden. Dette<br />
er gjort både <strong>for</strong> betontrapper, betonelementer, betonhaller, blandingsbatterier,<br />
badekabiner mm. (se eksempel i Figur 20).<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Figur 20: Udsnit <strong>af</strong> en produktvariantmaster <strong>for</strong> betonkonstruktioner (fra Dalton<br />
Betonelementer).<br />
Erfaringerne fra de <strong>for</strong>skellige projekter er at produktvariantmastere er gode til at<br />
starte analysen <strong>af</strong> produktviden, og gode at anvende som udgangspunkt <strong>for</strong> den<br />
mere detaljerede dokumentationsfase (fase 3-4: objektorienteret analyse og design).<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
48
3.2.5 Fase 3-4: Objektorienteret Analyse og Design<br />
I store træk er erfaringerne med denne fase, at den er nyttig og anvendelig, også i<br />
bygge-relaterede konfigureringsprojekter. En detaljeret dokumentation <strong>af</strong> de<br />
anvendte objekter betyder, at det bliver nemmere, at implementere produktviden i<br />
det udvalgte konfigureringssoftware.<br />
Som beskrevet tidligere er der imidlertid nogle <strong>for</strong>hold der i denne fase begynder at<br />
give ud<strong>for</strong>dringer. Disse er primært:<br />
• En større grad <strong>af</strong> ”engineer-to-order” frem<strong>for</strong> ”configure-to-order” betyder at<br />
variantskabelsen er mere kompleks.<br />
• Et behov <strong>for</strong> at tage hensyn til geometri i konfigureringsprocessen, herunder<br />
håndtering <strong>af</strong> parametriske 3D objekter og eventuelt generering <strong>af</strong> relaterede<br />
2D tegninger.<br />
Denne problemstilling er behandlet gennem flere konfigureringsprojekter i relation til<br />
PKB-projektet. Erfaringerne er bl.a. dokumenteret i en række DTUeksamensprojekter<br />
[Christensen, 2004], [Haug&Christiansen, 2004], samt [Nielsen,<br />
2004]. De fire væsentligste erfaringer og udvidelser til den eksisterende<br />
fremgangsmåde er:<br />
• For at få et <strong>for</strong>bedret overblik over de geometriobjekter der skal modelleres<br />
kan man anvende et ekstra trin til fremgangsmåden (fase 2B) samt en<br />
geometri-variantmaster. Hermed skabes der et bedre udgangspunkt <strong>for</strong> den<br />
detaljerede objektorienterede model og implementering [Haug&Christiansen,<br />
2004].<br />
• CRC-kortene tilpasses behovet <strong>for</strong> at modellere viden om geometriske<br />
objekter, der er definerede i <strong>for</strong>m <strong>af</strong> CAD baserede part-filer.<br />
• Der er et behov <strong>for</strong> et IT-baseret dokumentationssystem, hvor de enkelte<br />
CRC-kort er tilgængelige via et Intranet, og hvor der er en <strong>for</strong>m <strong>for</strong><br />
versionsstyring og adgangskontrol.<br />
• Valget <strong>af</strong> hensigtsmæssigt standardsoftware synes vanskeligt. Der<strong>for</strong> er der<br />
tilføjet en række beskrivelsespunkter til fremgangsmåden, og der er lavet en<br />
særskilt analyse <strong>af</strong> softwaremarkedet [Hansen&Hvam, 2004b]<br />
Disse 4 erfaringer diskuteres i det følgende.<br />
3.2.5.1 Fase 2B: Geometrivariantmaster og modellering <strong>af</strong> 3D-objekter<br />
Forud <strong>for</strong> den helt detaljerede modellering på CRC-kortene kan der med <strong>for</strong>del<br />
indskydes en fase 2B, der fokuserer på at identificere hvilke produktdele, der skal<br />
modelleres som digitale 3D modeller. Målet er at fastlægge den mest<br />
hensigtsmæssige bruttoliste med de grundlæggende 3D objekter.<br />
Ud<strong>for</strong>dringen kan illustreres ved et eksempel: Rørføringer kan på det laveste niveau<br />
bestå <strong>af</strong> lige cylinderstykker med variabel diameter og længde, buede cylinderstykker<br />
med variabel diameter, bukkeradius og længde, overgangsstykker der gør det muligt<br />
at samle to rør med <strong>for</strong>skellige diametre etc. Rørføringerne kan imidlertid også<br />
modelleres på et lidt højere niveau, bestående <strong>af</strong> undersamlinger, f.eks. rørsektion<br />
A,B,C, der alle har visse parametre, f.eks. varierende længder. For at sikre et<br />
optimalt genbrug <strong>af</strong> 3D CAD-modeller og minimere brugen <strong>af</strong> redundante modeller,<br />
må en undersamling, der består <strong>af</strong> dele, der bruges i andre undersamlinger, opdeles<br />
<strong>for</strong> at de anvendte dele ikke tegnes igen og igen i de <strong>for</strong>skellige undersamlinger.<br />
49<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Modsat kan det tænkes at der er to eller tre dele, der altid bruges i sammenhæng. I<br />
så fald vil det være nemmere at håndtere disse dele som en undersamling, frem <strong>for</strong><br />
som enkeltstående dele.<br />
Fase 2B omfatter således de centrale punkter identificering og navngivning <strong>af</strong><br />
geometriobjekter, strukturering <strong>af</strong> geometriobjekter samt <strong>opbygning</strong> <strong>af</strong> 3D modeller.<br />
Optegningen <strong>af</strong> en geometri-variantmaster understøtter således identificering og<br />
strukturering <strong>af</strong> 3D CAD modeller. Et herpå ses i Figur 21.<br />
Figur 21: Del <strong>af</strong> geometrivariantmaster <strong>for</strong> et sandwichelement<br />
[Haug&Christiansen, 2004].<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
50
3D CAD modellerne modelleres herefter løbende i overgangen til den detaljerede<br />
objektorienterede analyse og design fase. Resultatet vil være en struktureret samling<br />
<strong>af</strong> 3D CAD-modeller i stil med den, der vises på Figur 22.<br />
51<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
Figur 22: CAD-modeller struktureret i en lagringsstruktur, på baggrund <strong>af</strong> den<br />
geomtriske variantmaster [Haug&Christiansen, 2004].<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
52
3.2.5.2 Detaljerede objektbeskrivelser (CRC-kort) og topologiske data<br />
Den centrale del <strong>af</strong> fasen objektorienteret analyse og design er dokumentationen <strong>af</strong><br />
detailviden på CRC-kort (class-responsibility-collaborations). Disse indeholder den<br />
detaljerede dokumentation <strong>af</strong> variable, regler, beregninger, geometri mm. <strong>for</strong> de<br />
definerede produktdele.<br />
Klasse navn:<br />
Bib. Placering: Forfatter:<br />
LodretArmeringsRippe<br />
Ansvar ( Overordnet beskrivelse <strong>af</strong> klassen ):<br />
Model C. S. Christensen<br />
Laver en lodret rippe til bagplade armeringen Er lavet <strong>af</strong> 4 stænger 1 i hvert hjørne og optil 4 ”løse”<br />
stænger der er placeret inden i bøjler.<br />
Nedarvet fra ”Egne” klasser:<br />
Evt. tegning:<br />
Nedarver<br />
klasser:<br />
BooleanSolid<br />
BlockMixin<br />
fra standard Intent<br />
Rippen ligger Her ned men bund er mod højre side <strong>af</strong> papiret, og der er 2 løse stænger<br />
Variabler Type<br />
AntalSekunndaereStænger Integer (Default 0)<br />
Boejle String (Default ”F60”)<br />
Hoejde Integer default 2000<br />
PrimaerStangDiameter Integer (Default 16)<br />
SekundaerStangDiameter Integer (Default 10)<br />
Funktioner Værdi Type<br />
BøjleAfstand 15*StangDiameter Integer<br />
Bredde Værdi hentes nede i subKlassen Bøjler hvor<br />
den defineres <strong>af</strong>hængig <strong>af</strong> den valgte bøjletype<br />
Integer<br />
Dybde Værdi hentes nede i subKlassen Bøjler hvor<br />
den defineres <strong>af</strong>hængig <strong>af</strong> den valgte bøjletype<br />
Integer<br />
TykkesteDiameter Den værdi <strong>af</strong> Primær – eller sekundær<br />
stangdiameter der er tykkest *3 dog mindst 50.<br />
Integer<br />
Height BagpladeHoejde Integer<br />
Length ElementTykkelse-BagpladeTykkelse-70 Integer<br />
Width ElementBredde Integer<br />
Klasser Værdi<br />
Armeringsstang (Armeringsstang)<br />
Lodrette stænger der ligger i hjørnerne på<br />
4 instanser <strong>af</strong> hver 1 stang<br />
bøjlerne<br />
Bøjler (RippeBøjle)<br />
De bøjler der holder stænger sammen Afstand<br />
Det antal instanser <strong>af</strong> denne klasse der skal til <strong>for</strong> mellem bøjler diff. Bøjle<strong>af</strong>stand. 1 bøjle sidder ½<br />
at der er bøjler nok<br />
<strong>af</strong>stand oppe.<br />
SekundæreArmeringsstang (Armeringsstang) Evt. sekundære stænger placeret langs lange sider<br />
Mellem 0 og 4 instanser <strong>af</strong> hver 1 stang<br />
<strong>af</strong> bøjler med en <strong>af</strong>stand diff. I TykkesteDiameter<br />
Afhængig <strong>af</strong> det valgte antal.<br />
fra nærmeste Primære stang.<br />
Figur 23: CRC-kort anvendt hos Dalton Betonelementer [Christensen, 2004]<br />
Anvendelsen <strong>af</strong> CRC-kort er <strong>for</strong>løbet uden større principielle problemer. Den<br />
væsentligste <strong>for</strong>skel er behovet <strong>for</strong> at kunne beskrive in<strong>for</strong>mation om geometriers<br />
overflader, kanter, indsætningspunkter, parametriske relationer etc. Dette har<br />
53<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
medført at der i <strong>for</strong>skellige projekter er <strong>for</strong>etaget <strong>for</strong>skellige tilpasninger <strong>af</strong> CRCkortets<br />
grundstruktur, f.eks. fra den første prototype, der blev lavet hos Dalton<br />
(Figur 23).<br />
Ved modellering <strong>af</strong> geometri på CRC-kort blev det fundet hensigtsmæssigt, at<br />
anvende referencer til eksterne 3D CAD-modeller. Altså at man fra CRC-kortene<br />
refererer til et katalog med alle de nødvendige CAD-filer.<br />
Denne problemstilling rejser problematikken der diskuteres i næste sektion, nemlig<br />
behovet <strong>for</strong> et IT-baseret dokumentationssystem, hvor en bruger kan klikke på en<br />
reference til en CAD-model og få den vist frem. Herved vil man også kunne undgå at<br />
de samme data beskrives to steder.<br />
3.2.5.3 Behov <strong>for</strong> et IT-baseret dokumentationssystem<br />
Anvendelsen <strong>af</strong> CRC-kort har i flere tilfælde givet anledning til anvendelse <strong>af</strong> ITbaserede<br />
dokumentationssystemer. Sådanne anvendes bl.a. APC og GEA-Niro, hvor<br />
Lotus Notes anvendes som plat<strong>for</strong>m <strong>for</strong> at dele CRC-kort på virksomhederne intranet.<br />
I relation til PKB-projektet var der et udpræget behov <strong>for</strong> at anvende IT-baserede<br />
dokumentationssystemer. Disse blev dog ikke opbygget, da projekterne endnu ikke<br />
var fuldskala-projekter, og <strong>for</strong>di der ikke findes standardiserede<br />
dokumentationssystemer. Anvendelsen <strong>af</strong> et sådant system ville sandsynligvis<br />
understøtte en <strong>for</strong>bedret dokumentation og videnindsamlingsproces, bl.a. <strong>for</strong>di:<br />
• Det vil være lettere <strong>for</strong> alle at tilgå og vedligeholde in<strong>for</strong>mation. Dermed er<br />
en strukturel barriere elimineret.<br />
• Man vil kunne overvåge og styre, at de <strong>for</strong>skellige personer lægger den<br />
krævede in<strong>for</strong>mation ind i dokumentationssystemet.<br />
• Man vil eliminere en del dataredundans, ved at kunne lave elektroniske links<br />
og referencer. Dette vil specielt være en stor styrke ved dokumentation <strong>af</strong><br />
geometri, hvor topologiske data bør ligge i selve CAD-modellerne.<br />
3.2.5.4 Valg <strong>af</strong> software<br />
I <strong>for</strong>bindelse med de konfigureringsprojekter, der er udført i relation til nærværende<br />
projekt (PKB) er det erfaret, at valget <strong>af</strong> software ikke er let.<br />
Som beskrevet i <strong>for</strong>egående <strong>af</strong>snit skyldes en del <strong>af</strong> ud<strong>for</strong>dringerne, at der<br />
tilsyneladende ikke findes et bredt udvalg <strong>af</strong> modent software, der håndterer<br />
modellering <strong>af</strong> både geometri og viden.<br />
For at hjælpe med at skabe klarhed over softwaremarkedet er der lavet en særskilt<br />
rapport med beskrivelsespunkter og en klassificering <strong>af</strong> software [Hansen&Hvam,<br />
2004b].<br />
En række softwaresystemer er klassificeret (gengivet i Figur 17) og karakteriseret ud<br />
fra listen, der her er gengivet i Tabel 1.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
54
Tabel 1: Analysepunkter <strong>for</strong> valg <strong>af</strong> software<br />
Gruppe Analysepunkt<br />
Anvendelsesfunktionalitet<br />
(input/output)<br />
Anvendelsesfunktionalitet<br />
(hvordan støttes<br />
frembringelse <strong>af</strong><br />
output)<br />
Anvendelsesfunktionalitet<br />
(styring)<br />
Opbygning/<br />
modellering og<br />
programmering<br />
55<br />
• Output<br />
• Gr<strong>af</strong>isk repræsentation (<strong>af</strong> output)<br />
• Gr<strong>af</strong>isk interaktion (ved input)<br />
• Kvalitet <strong>af</strong> gr<strong>af</strong>ik<br />
• Data- og fil<strong>for</strong>mater (<strong>af</strong> output)<br />
• Ekspertfunktionalitet/Intelligens<br />
• Dynamisk konfigurering (inferenskerne)<br />
• Dynamisk geometrirendering<br />
• Runtime svartider (per<strong>for</strong>mance)<br />
• Skalerbar gr<strong>af</strong>ikdetaljering<br />
• Client-server funktionalitet (browserbaseret?)<br />
• Kollisionskontrol<br />
• Driftsstabilitet<br />
• Administration <strong>af</strong> brugere og produktdata<br />
• Modellering <strong>af</strong> viden<br />
• Modellering <strong>af</strong> geometri<br />
• Parametriske relationer mellem dimensioner<br />
• Geometri-kobling mellem objekter<br />
• Submodeller (objektorienteret modellering)<br />
• Medfølgende biblioteker med submodeller<br />
• Programmeringssprog / indlæringslethed<br />
• Programmerings-effektivitet (modelleringshastighed)<br />
• Versionsstyring <strong>af</strong> modeller<br />
• Versionskompatibilitet (opgraderingslethed)<br />
Leverandør<strong>for</strong>hold • Support og service<br />
• Referencer<br />
• Branchekendskab<br />
• Leverandørstabilitet og troværdighed<br />
• Fremtidig teknologiudvikling<br />
• Priser <strong>for</strong> licenser og support<br />
Der blev ikke fundet systemer, der i tilfredsstillende grad opfyldte alle punkter på<br />
listen. Man er således p.t. nødt til at prioritere sine behov og finde det system, der<br />
tilfredsstiller flest <strong>af</strong> de væsentligste punkter.<br />
For nærmere diskussion herom henvises til softwarerapporten [Hansen&Hvam,<br />
2004b].<br />
3.2.6 Fase 5: Programmering<br />
Der er programmeret en række <strong>for</strong>skellige prototyper i <strong>for</strong>bindelse med PKBprojektet:<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
• Betonhal i Inventor Product Configurator.<br />
• Betonelement i Engineering Intent (se Figur 24).<br />
• Sandwich-betonelement i Engineering Intent.<br />
• Betonhal i Engineering Intent.<br />
• Betontrappe i Inventor.<br />
• Badeværelse i VirtuBUILD.<br />
• Badeværelse i GDL.<br />
• Skydeport i GDL.<br />
Figur 24: Skærmbillede fra en prototype udviklet hos Dalton Betonelementer i<br />
Engineering Intent.<br />
Erfaringerne har vist, som nævnt flere gange, at der ikke eksisterer et<br />
standardværktøj, hvor man på en nem måde kan opbygge et konfigureringssystem<br />
indeholdende 3D geometri og 2D tegninger. Alle systemerne har en række<br />
begrænsninger, både hvad angår funktionalitet og hvad angår brugervenlighed.<br />
En væsentlig erfaring er den beslutning virksomhederne må træffe mht. ”make or<br />
buy”:<br />
• Hvis man selv vælger at opbygge/programmere systemerne er der en lang<br />
indlæringskurve. Dette betyder at der skal investeres i oplæring <strong>af</strong><br />
medarbejdere.<br />
• Hvis man køber programmeringen udefra kommer man meget hurtigere<br />
frem til et synligt resultat. Til gengæld bliver man <strong>af</strong>hængig <strong>af</strong> eksterne<br />
partnere ved <strong>for</strong>tsat vedligehold og videreudvikling.<br />
Erfaringerne er, at der i PKB-projektet blev brugt (<strong>for</strong>) meget tid på indlæring <strong>af</strong> nye<br />
systemer og det ”at prøve sig frem”. Dette skyldtes til dels en generel interesse <strong>for</strong><br />
at <strong>af</strong>prøve <strong>for</strong>skellige systemer (fra Universiteterne), dels en manglende vilje til at<br />
købe professionel hjælp (fra virksomhederne). Set i bakspejlet må det konstateres,<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
56
at udviklings<strong>for</strong>løbene ville have været væsentligt hurtigere, hvis virksomhederne i<br />
højere grad havde købt professionel rådgivning fra softwareleverandørerne.<br />
3.2.7 Fase 6: Implementering<br />
Formålet med PKB-projektet har været, at opbygge <strong>konfigureringssystemer</strong> på<br />
prototypeniveau og udbrede viden om produktkonfigurering i byggebranchen. Det<br />
har ikke været målet at implementere systemer i driften.<br />
Prototypeprojekterne har betydet at der p.t. er fuldskalaprojekter igang i to <strong>af</strong> PKBvirksomhederne.<br />
Der er der<strong>for</strong> ikke erfaringer med egentlig indkøring <strong>af</strong> færdige systemer i driften.<br />
Det kan dog konstateres at begge virksomheder selv ønsker at stå <strong>for</strong> drift og<br />
vedligehold <strong>af</strong> konfigureringssystemet. Der<strong>for</strong> satses på en aktiv involvering i<br />
system<strong>opbygning</strong>en, frem<strong>for</strong> en ensidig satsning på eksterne konsulenter.<br />
3.2.8 Afslutning på erfaringer med fremgangsmåden<br />
Gennem nærværende kapitel er erfaringerne med fremgangsmåden beskrevet og<br />
diskuteret.<br />
I store træk peger erfaringerne på at fremgangsmåden er anvendelig, også i<br />
byggebranchen og projekter med et større indhold <strong>af</strong> geometri-aspekter.<br />
<strong>Fremgangsmåde</strong>n bidrager til et mere struktureret udviklings<strong>for</strong>løb, ligesom der<br />
gennem de opstillede værktøjer skabes en hjælp til de enkelte faser.<br />
Der er påpeget nogle områder hvor fremgangsmåden kan <strong>for</strong>bedres, bl.a. ved:<br />
• Analyse <strong>af</strong> værdikæden og interessenter<br />
• Cost-benefit-analyser<br />
• Geometri-aspekter<br />
• Udvælgelse <strong>af</strong> software<br />
Hertil er der taget nogle tiltag i retning <strong>af</strong> en <strong>for</strong>bedring, bl.a. dokumenteret gennem<br />
nærværende rapport og PKB-softwarerapporten [Hansen&Hvam, 2004b] samt<br />
eksamensprojekterne fra DTU [Haug&Christiansen, 2004], [Nielsen, 2004] og<br />
[Christensen, 2004].<br />
57<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
4 Konklusion og perspektivering<br />
PKB projektet har h<strong>af</strong>t som det primære mål, at udbrede viden omkring <strong>opbygning</strong> <strong>af</strong><br />
<strong>konfigureringssystemer</strong> og gennemføre prototypeprojekter i udvalgte virksomheder.<br />
Sekundært har målsætningen været, at anvise en fremgangsmåde <strong>for</strong> <strong>opbygning</strong> <strong>af</strong><br />
<strong>konfigureringssystemer</strong>.<br />
Udgangspunktet her <strong>for</strong> har været en eksisterende fremgangsmåde og tilhørende<br />
modelleringsteknikker. Disse er beskrevet kort i denne rapports kapitel 2. Det<br />
eksisterende grundlag er derefter blevet brugt og udvidet gennem praktiske<br />
prototypeprojekter.<br />
4.1 Konklusion<br />
PÅ baggrund <strong>af</strong> projekt<strong>for</strong>løbet kan der opridses en række konklusioner:<br />
1. Det viste det sig at fremgangsmåden, også i byggebranchen, er anvendelig<br />
og at den understøtter en struktureret udvikling <strong>af</strong> konfigureringsprojekter.<br />
2. Det viste sig gennem projekt<strong>for</strong>løbet, at <strong>for</strong>udsætningerne <strong>for</strong><br />
<strong>konfigureringssystemer</strong> er mindst lige så centrale <strong>for</strong> succes som<br />
fremgangsmåde og projektstyring. Des større <strong>for</strong>retningsmæssige rationale,<br />
der er <strong>for</strong> <strong>konfigureringssystemer</strong>, des større er sandsynligheden <strong>for</strong> succes, -<br />
uanset fremgangsmåde. En struktureret fremgangsmåde kan dog bidrage til,<br />
at <strong>for</strong>udsætningerne og mangler her<strong>for</strong> identificeres tidligt, bl.a. ved at der<br />
laves proces og produktanalyser <strong>for</strong>ud <strong>for</strong> system<strong>opbygning</strong>en.<br />
3. Forudsætningerne <strong>for</strong> <strong>konfigureringssystemer</strong> er til stede <strong>for</strong> mange<br />
virksomheder i byggebranchen, men der er også mange der ikke opfylder de<br />
mest basale krav: standardiserede produktfamilier, stor omsætning <strong>af</strong> tilbud<br />
og ordrer, markedsmæssige muligheder <strong>for</strong> at udvikle standardiserede<br />
løsninger, en hensigtsmæssig arbejdsdeling i værdikæden, adgang til<br />
automatiseringsteknologi etc. Flere <strong>af</strong> de udvalgte virksomheder i PKBprojektet<br />
ligger på grænsen til at opfylde de væsentligste <strong>for</strong>udsætninger.<br />
4. Ved <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong>, der skal kunne skabe tegninger,<br />
bevæger man sig ud i et grænseområde, som de færreste nuværende<br />
<strong>konfigureringssystemer</strong> kan håndtere. Der er her færre udviklingsmiljøer, der<br />
understøtter udviklingsarbejdet hermed, ligesom der er færre ”frontløbere”<br />
der allerede har vist vejen. Der er således i flere tilfælde tale om svære og<br />
nyskabende projekter. I disse tilfælde er der også områder i<br />
fremgangsmåden, der har mangler. Specielt er der mangler omkring<br />
geometrimodellering.<br />
5. Der er tilføjet nogle elementer til den eksisterende fremgangsmåde, bl.a.<br />
interessentanalyser, geometriproduktvariantmaster og geometritilpassede<br />
versioner <strong>af</strong> CRC-kortene.<br />
4.2 Perspektivering<br />
Som påpeget flere steder i rapporten er der visse <strong>for</strong>udsætninger <strong>for</strong><br />
<strong>konfigureringssystemer</strong>, der ikke opfyldes <strong>af</strong> mange parter i byggebranchen. Gennem<br />
PKB projekt<strong>for</strong>løbet viste det sig gradvist at <strong>konfigureringssystemer</strong> måske endnu er<br />
en anelse <strong>for</strong> visionære i byggebranchen.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
58
Nogle <strong>af</strong> de initiativer der sandsynligvis skal ske <strong>for</strong>, at <strong>konfigureringssystemer</strong> vil<br />
vinde bred udbredelse i byggebranchen kan være følgende:<br />
1. Bedre arbejdsdeling i værdikæden og skabelsen <strong>af</strong> større virksomheder,<br />
hvilket kan give stordrifts<strong>for</strong>dele.<br />
2. En generel <strong>for</strong>skydning fra ”engineer-to-order” mod ”configure-to-order”,<br />
hvilket ligeledes vil betyde standardisering og en nemmere variantproduktionsopgave<br />
(herunder variantspecificering, hvilket muliggør<br />
automatisering gennem <strong>konfigureringssystemer</strong>).<br />
3. Systemleverencer, der understøtter kravet om standardiserede produkter og<br />
stort salgsvolumen.<br />
4. En digitalisering <strong>af</strong> bygningens livscyklus, fra skitsedesign til brug og<br />
vedligehold. Dette vil kunne påvirke behovet <strong>for</strong> digitale modeller <strong>af</strong><br />
produktvarianter og muligheden <strong>for</strong> hurtigt at kunne lave varianter og<br />
alternative designs <strong>for</strong> bygningens dele (vinduer, døre, trapper, elementer<br />
etc.)<br />
5. Opbygning <strong>af</strong> kompetence inden <strong>for</strong> digital 3D-modellering, herunder<br />
<strong>konfigureringssystemer</strong>. En større national kompetence vil gøre det lettere <strong>for</strong><br />
flere virksomheder at gennemføre konfigureringsprojekter.<br />
59<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.
5 Litteraturliste<br />
[bips nyt, 2003] Jensen, Svend Erik; bips nyt 1; fagbladet <strong>for</strong><br />
branche<strong>for</strong>eningen “byggeri, in<strong>for</strong>matik, produktivitet,<br />
samarbejde (bips)”; www.bips.dk; 2003.<br />
[Christensen, 2004] Christian Stilling Christensen; Udvikling <strong>af</strong> software til<br />
automatisk CAD tegningsgenerering;<br />
diplomingeniør<strong>af</strong>handling, DTU, 2004.<br />
[Haug&Christiansen, 2004] Jørgen Christiansen, Anders Haug; Opbygning <strong>af</strong> 3D<strong>konfigureringssystemer</strong>,<br />
-med fokus på producenter <strong>af</strong><br />
bygningskomponenter; Civilingeniør<strong>af</strong>handling, DTU,<br />
2004<br />
[Hansen&Hvam, 2004] Hansen, Benjamin Loer; Hvam, Lars; The Order<br />
Specification Decoupling Line; Conference Proceedings;<br />
International Conference on Economic, Technical and<br />
Organisational aspects of Product Configuration<br />
Systems; Technical University of Denmark, June 28th-<br />
29th, 2004.<br />
[Hansen&Hvam, 2004b] Hansen, Benjamin Loer; Hvam, Lars; Software til<br />
konfigurering i byggebranchen, -erfaringsopsamling;<br />
Arbejdsnotat udarbejdet i relation til PKB projektet,<br />
DTU, 2004.<br />
[Hvam et al. 2004] Hvam, Lars; Mortensen, Niels Henrik; Riis, Jesper;<br />
Produktkonfigurering; Undervisningsnote, DTU, 2004.<br />
[Kortegaard&Hvam, 2003] Kortegaard, Per; Hvam, Lars; Jørgensen, Kaj; (mfl.);<br />
Projektansøgning til ”Den jysk-fynske IT-korridor” om<br />
”Produktkonfigurering i Byggeriet”; Arkitektskolen i<br />
Aarhus, 2003.<br />
[Nielsen, 2004] Jacob Sværke Nielsen; Visuel Konfigurering;<br />
Civilingeniør eksamensprojekt, DTU, 2004<br />
[PRO IT News, 2003] Romo, Ilkka; PRO IT Product Model Data in the<br />
Construction Process; Confederation of Finnish<br />
Construction Industries;<br />
(http://www.rakennusteollisuus.fi/english/) Finland<br />
2003.<br />
<strong>Fremgangsmåde</strong> <strong>for</strong> <strong>opbygning</strong> <strong>af</strong> <strong>konfigureringssystemer</strong> i byggebranchen,<br />
-erfaringsopsamling.<br />
60