Fremgangsmåde for opbygning af konfigureringssystemer i ...

Fremgangsmåde for opbygning af 

konfigureringssystemer i 

byggebranchen, -erfaringsopsamling 

Proces analyse 

Produkt analyse 

Objekt orienteret 

analyse og design 

Programmering 

Implementering 

Vedligeholdelse/ 

videreudvikling 

Fase 

Benjamin Loer Hansen 

Lars Hvam 

februar 2005 

(sidst editeret 24/2 2005) 

........ 

Version 1. Version 2. 

....... 

Center for Produktmodellering 

Institut for Produktion og Ledelse 

Danmarks Tekniske Universitet 

Version n. 

Tid 

.......

Forord 

Nærværende rapport er udarbejdet af adjunkt Benjamin Loer Hansen og Lektor Lars 

Hvam gennem vinteren 2004-2005. Tak for hjælp og input fra 

eksamensprojektstuderende Jørgen Christiansen og Anders Haug, Jacob Nielsen og 

Christian Christensen, samt parterne i projektet ”Produktkonfigurering i Byggeriet” 

(PKB). 

Rapporten er skrevet i relation til det halvandet år lange udviklingsprojekt 

”Produktkonfigurering i Byggeriet” (PKB). Dette projekt har bl.a. til formål at udvikle 

konkrete digitale modeller hos udvalgte producenter i byggebranchen, samt at 

forbedre metodikken/fremgangsmåden ved opbygning af konfigureringssystemer 

(mere information findes i projektansøgningen [Kortegaard&Hvam, 2003], eller hos 

projektansvarlige lektor Per Kortegaard, Arkitektskolen i Aarhus). 

Formålet med denne rapport er at dokumentere nogle af de erfaringer der er gjort 

med opbygning af 3D modellerings/konfigureringssystemer. Rapporten søger at give 

svar på bl.a. følgende spørgsmål relateret til konfigureringssystemer: 

• Hvilke erfaringer er der gjort med konfigureringssystemer i byggebranchen? Er 

der visse forudsætninger for IT-automatisering, der ikke er opfyldt i samme grad 

som i maskinindustrien? 

• Hvad er de væsentligste erfaringer med den eksisterende fremgangsmåde? 

Målgruppen er primært parterne i PKB-projektet. Sekundært henvender rapporten 

sig til andre interesserede producenter af bygningskomponenter, arkitekter, 

projekterende og udførende, samt universitetsstuderende i relaterede fagområder. 

Rapporten er at betragte som et erfaringsopsamlende arbejdsnotat. 

1 

Fremgangsmåde for opbygning af konfigureringssystemer i byggebranchen, 

-erfaringsopsamling.

Indholdsfortegnelse 

1 Introduktion til problemstillingen .................................................................... 4 

1.1 De to fokusområder i PKB............................................................................... 4 

1.2 Konkretisering af problemstillingen ................................................................. 5 

1.2.1 Industrielle specifikationer................................................................................6 

1.2.2 Industrielle specifikationsprocesser ...................................................................6 

1.2.3 Forudsætningerne for at anvende konfigureringssystemer ..................................8 

1.2.4 Konfigureringssystemer....................................................................................8 

1.3 Tilgangsvinkel og undersøgelsesmetode ........................................................ 9 

2 Fremgangsmåde for opbygning af konfigureringssystemer ...................... 11 

2.1 Introduktion.................................................................................................... 11 

2.1.1 Den objektorienterede projektlivscyklus...........................................................13 

2.1.2 Overblik over fremgangsmåden ......................................................................14 

2.1.3 Iterative forløb ..............................................................................................16 

2.1.4 Roller i udviklingsforløbet ...............................................................................18 

2.2 Fremgangsmådens faser .............................................................................. 20 

2.2.1 Forretningsmæssig analyse ............................................................................20 

2.2.2 Produktanalyse..............................................................................................21 

2.2.3 Objektorienteret analyse og design .................................................................22 

2.2.4 Programmering .............................................................................................26 

2.2.5 Implementering.............................................................................................27 

2.2.6 Vedligeholdelse og videreudvikling ..................................................................27 

2.3 Afrunding....................................................................................................... 29 

3 Erfaringer ......................................................................................................... 30 

3.1 Erfaringer med forudsætninger for konfigureringssystemer .......................... 30 

3.1.1 Produktstandardisering og prædefineret varians...............................................31 

3.1.2 Markedsrationale for at standardisere..............................................................35 

3.1.3 Stor omsætning af tilbud eller ordrer...............................................................36 

3.1.4 Automatiseringsteknologi ...............................................................................37 

3.1.5 Geometri-tilpasning i variantskabelsen og krav om tegninger ............................38 

3.1.6 Afrunding af de generelle erfaringer................................................................40 

3.2 Erfaring med selve fremgangsmåden ........................................................... 42 

3.2.1 Fremgangsmåden og nye forudsætninger........................................................42 

3.2.2 Projekt-”scoping” og iterationer ......................................................................42 

3.2.3 Fase 1: Procesanalyse....................................................................................43 

3.2.4 Fase 2: Produktanalyse..................................................................................47 

3.2.5 Fase 3-4: Objektorienteret Analyse og Design..................................................49 

3.2.6 Fase 5: Programmering..................................................................................55 

3.2.7 Fase 6: Implementering.................................................................................57 

3.2.8 Afslutning på erfaringer med fremgangsmåden ................................................57 


-erfaringsopsamling. 

2

4 Konklusion og perspektivering...................................................................... 58 

4.1 Konklusion..................................................................................................... 58 

4.2 Perspektivering.............................................................................................. 58 

5 Litteraturliste ................................................................................................... 60 

3 



1 Introduktion til problemstillingen 

Der arbejdes generelt med industrialisering af byggeriet og anvendelse af digitale 3D 

modeller gennem flere udviklingsprojekter. I Danmark er det store udviklingsprojekt 

p.t. (2004) ”Det Digitale Byggeri”, der er initieret af Erhvervs- og byggestyrelsens 

sammen med branchens egen organisation: bips (”byggeri, informatik, produktivitet, 

samarbejde”) [bips nyt, 2003]. 

I Finland er der gennem flere år arbejdet målrettet med effektivisering af 

byggebranchen, bl.a. under projektet ProIT [PRO IT News, 2003]. 

Projektet ”Produktkonfigurering i Byggeriet” (PKB) arbejder også med 

industrialisering af byggeriet. Fokusområdet i PKB er skabelsen af digitale 

bygningskomponentmodeller, samt automatisk generering af tilhørende 

specifikationer (dokumenter) så som tilbud, styklister, tegninger, mm. Mere 

information herom findes i projektansøgningen [Kortegaard&Hvam, 2003], eller hos 

projektansvarlige lektor Per Kortegaard fra Arkitektskolen i Aarhus. 

1.1 De to fokusområder i PKB 

I projektet tages der udgangspunkt i to overordnede niveauer i en byggeproces, 

nemlig den tidlige arkitektoniske skitseringsfase (interesseområde for Arkitektskolen i 

Århus), samt den senere gennemførelsesfase (interesseområde for Institut for 

Produktion og Ledelse, DTU). 

De to overordnede fokusområder i PKB er således meget kort skitseret som følgende: 

1. I den tidlige arkitektoniske designfase er det intentionen, at arkitekter gennem 

anvendelse af overordnede produktmodeller vil være i stand til, at foretage bedre 

disponeringer mht. gennemførligheden af byggeriets arkitektur. Forudsætningen for 

at dette kan lade sig gøre er, at arkitekter har de rette IT-værktøjer til at opbygge 

digitale modeller af byggeriet (f.eks. ArchiCAD eller AutoCAD/Architechtural Desktop) 

samt, at arkitekterne i relation hertil har adgang til et stort udvalg af digitale 

komponentmodeller af f.eks. vinduer, døre, trapper mm. Til at understøtte denne 

fase skal komponentleverandører således tilbyde produktmodeller og 

produktinformation, på et overordnet niveau, tilgængeligt for arkitekter mm. 

Antagelsen er, at der her vil kunne anvendes GDL modeller eller lignende, der 

tilbydes i produktkataloger på Internettet. 

Arkitektskolen i Aarhus står for dette fokusområde. Dette er nærmere beskrevet i 

projektansøgningen til PKB (som ”fase 1”). Dette er illustreret i Figur 1 (til venstre i 

figuren) i denne note. 

2A. I byggeriets mere detaljerede designfaser vil der være et behov for mere 

detaljerede digitale produktmodeller, samt hurtig udarbejdelse af kontraktbindende 

tilbud. Antagelsen er, at dette kan imødekommes gennem anvendelsen af 

konfigureringssystemer, der automatisk kan generere digitale 3D modeller, samt 

ønsket produktinformation i dokumentform (tilbudsbreve, tegninger og styklister 

mm.) 

2B. Ved byggeriets gennemførelse, efter kontraktindgåelse, skal der fra 

komponentleverandørernes side udarbejdes det interne produktionsgrundlag. Her 



4

skal der udarbejdes en række produktionsspecifikationer, til internt brug, f.eks. 

produktionstegninger, styklister, rutebeskrivelser mm. Antagelsen er, at dette kan 

understøttes ved konfigureringssystemer, der automatisk genererer de ønskede 

produktionsdokumenter. 

2C. Endelig kan der være tale om, at der til dokumentation og vedligeholdelse af det 

færdige byggeri skal fremstilles detaljerede digitale 3D modeller og tilhørende 

produktinformation. Som for de to foregående faser antages dette at kunne 

understøttes med konfigureringssystemer. 

Figur 1: Skitsering af en digital byggeproces der understøttes med IT (f.eks. GDL 

og 3D konfigureringssystemer). 

De beskrevne faser 2A, 2B og 2C (illustreret i midten og til højre i Figur 1) varetages 

primært af Center for Produktmodellering på DTU. Nærværende rapport er 

udarbejdet i relation hertil. 

1.2 Konkretisering af problemstillingen 

For at give læsere, med begrænset faglig indsigt, en introduktion til emnet gives i 

det følgende en meget kort skitsering af problemdomænet. Dette gøres ved en kort 

gennemgang af: 

• Industrielle specifikationer 

• Industrielle specifikationsprocesser 

• Forudsætninger for elektronisk konfigurering 

• Et eksempel på et konfigureringssystem 

5 



1.2.1 Industrielle specifikationer 

Specifikationer har gennem årtusinder været brugt i forbindelse med 

konstruktionsarbejde. Ved bygningen af de ægyptiske pyramider, romerske 

akvædukter og middelalderlige katedraler er der anvendt diverse tegninger og 

skitser, der alle kan karakteriseres som specifikationer. 

Specifikationer indeholder information, der beskriver hvad der skal udføres og/eller 

hvordan noget skal udføres. I industrielle virksomheder kaldes beskrivelser af 

markedsbehov, produkter, processer, metoder, produktionsudstyr, service mm. for 

industrielle specifikationer. Disse specifikationer anvendes i den fysiske 

fremstillingsproces. En specifikation kan repræsenteres gennem verbale beskrivelser, 

tegninger, diagrammer, fotografier, fysiske repræsentationer (miniaturemodeller), 

digitale modeller etc. 

De mest typiske specifikationstyper, der anvendes i produktionsvirksomheder er 

bl.a.: 

• Behovsspecifikation 

• Ordrespecificering 

• Samlingstegninger 

• Detailtegninger 

• Styklister 

• Materialespecifikationer 

• Processpecifikationer 

• Operationsnetværk 

• Montagespecifikationer 

• etc. 

I nærværende rapports Figur 18 og Figur 19 ses eksempler på styklister og 

tegninger. 

1.2.2 Industrielle specifikationsprocesser 

Skabelsen af specifikationer i industrielle virksomheder foregår på 2 niveauer. Det 

ene niveau er i forbindelse med udvikling af nye produkter og produktionsformer 

forud for kundebehandling. Det andet omfatter specifikationer, der skabes i 

forbindelse med tilbudsgivning og ordregennemførelse i den daglige drift. De 

specifikationer, der skabes i driften (niveau 2) er som regel varianter af de mere 

generelle specifikationer, udformet i udviklingen (niveau 1). Disse 

specifikationsprocesser kan derfor betegnes variant-specifikationsprocesser, men 

som regel udelades variant-betegnelsen. 

Opgaven med at udarbejde kundetilpassede specifikationer kan illustreres gennem 

følgende eksempel: En ikke navngiven producent af industriporte skaber en række 

specifikationer i ordrebehandlingsforløbet (i specifikationsprocesserne). Nogle 

specifikationer udarbejdes til den eksterne kunde, mens andre udarbejdes til 

produktionen. 

I forbindelse med tilbudsgivning skal der typisk fremstilles følgende specifikationer: 

• Behovsspecifikation: Indeholder en kort beskrivelse af de behov kunden har, 

bl.a. ydre dimensioner, krav til døre og vinduer i porten, krav til 

klimaskjold/materialer etc. 

• Budgettilbud: Denne type tilbud indeholder en hovedmålstegning af porten 

og en pris der er +/- 20% nøjagtig. 



6

7 

• Kontrakttilbud: Denne specifikation er det egentlige tilbud, der indeholder 

hovedmålstegning, relevante detailtegninger, tekniske specifikationer, 

juridiske forhold, samt leveringsforhold, samt pris. 

Efter accepteret kontrakttilbud startes processen med at skabe 

produktionsgrundlaget. Dette indbefatter en fremstilling af følgende specifikationer: 

• Produktionsstykliste 

• Diverse produktionstegninger 

• Klippelister for aluminiumsbearbejdning 

• Operationsbeskrivelser med tider 

• Teknisk produktbeskrivelse og servicemanual til kunden 

Udviklingssystem / Forberedende system 

Driftssystem 

Behovsspec 

Produktstandardisering 

Behov Salg 

Konstruktion 

specifikation 

230 

Budgettilbud 

Kontrakttilbud 

Standarder 

Grundtegninger 

Gamle spec. specifikation 

specifikation 

230 

specifikation 

230 

specifikation 

230 

Tegninger 

Tekniske spec. 

Tegninger 

Kons. stykliste 

specifikation 

230 

specifikation 

230 

230 

Metode 

planlæging 

Teknisk 

produktbeskrivelse 

Servicebeskrivelse 

Produktionsteknisk 

udvikling 

Standarder 

Værktøjsspecifikationer 

Layout 

Gamle specifikationer 

Produktion 



specifikation 

230 

Brug 

Produktionsstykliste 

Klippeliste 

Operationsbeskrivelse 

Rutebeskrivelse 

Forsendelsesstykliste 

Produkt 

Figur 2: Eksempel på specifikationer og variantspecifikationsprocesser (markeret 

med gråt) i en virksomhed, der kundetilpassede produkter. 

For næsten alle specifikationers vedkommende er der tale om en tilpasning af 

eksisterende specifikationer, der er skabt i udviklingsafdelingen (se Figur 2). 

En anden virksomhed (Figur 3) vælger at fremstille langt mere standardiserede 

porte. En konsekvens heraf er, at der stort set ikke foretages specificering i 

driftssystemet. Næsten alle specifikationer er defineret forud for kundeordren, og 

skal stort set blot ”tages ned fra hylden” når en ordre indtræffer. Derfor er 

ordrebehandlingen meget hurtigere og nemmere. På den anden side må kunden 

affinde sig med standardløsninger.

Udviklingssystem / Forberedende system 

specifikation 

230 

Produktbrochure 

Prislister 

Driftssystem 

Behov 

specifikation 

230 

Marketing 

Salg 

Ordre 

specifikation 

230 

Tegninger 

Produktudvikling 

specifikation 

230 

specifikation 

230 

Produktionsforberedelse 

Tegninger 

Materialespec. 

Styklister 

Produktionsordre 

Produktionsteknisk 

udvikling 

Produktion 



specifikation 

230 

Produktionsstykliste 

Klippeliste 

Operationsbeskrivelse 

Rutebeskrivelse 

Forsendelsesstykliste 

Brug 

Fra udvikling: 

Teknisk 

produktbeskrivelse 

Servicebeskrivelse 

Figur 3: Eksempel på specifikationer og specifikationsprocesser i en virksomhed, 

der laver meget standardiserede produkter. 

Disse to eksempler illustrerer således forskellige specifikationsprocesser (markeret 

med grå). Endvidere illustreres det, at der kan være tale om forskellige grader af 

variantskabelse. Nogle virksomheder leverer standard produkter, andre laver en 

smule tilpasning, mens andre foretager en stor grad af tilpasning i 

ordrebehandlingen. Graddelingen er central og behandles særskilt senere (ved Figur 

14 og Figur 15). 

1.2.3 Forudsætningerne for at anvende konfigureringssystemer 

Som udgangspunkt er der de samme forudsætninger for at automatisere 

specifikationsprocesser, som fysiske produktionsprocesser: 

• Der skal være ensartede og veldefinerede specifikationsaktiviteter, der 

gentages med en høj hyppighed. 

• Der skal være en velegnet teknologi (konfigureringssoftware), der muliggør 

en lønsom automatisering af specifikationsaktiviteterne. 

Når man ønsker at automatisere specifikationsprocesser er det derfor relevant at 

undersøge: 

• Er der tale om ensartede og veldefinerede specifikationsaktiviteter? I hvilken 

grad er dette overholdt? 

• Er der tale om høj hyppighed? 

• Findes der velegnet software? 

Disse spørgsmål diskuteres løbende i nærværende rapport. 

1.2.4 Konfigureringssystemer 

Begge producenter nævnt ovenfor kan vælge at automatisere 

specifikationsprocesserne med IT. Et konfigureringssystem vil, afhængigt af 

udformningen, kunne udarbejde en eller flere af de specifikationer, der normalt 

udarbejdes i virksomhedens specifikationsprocesser. 

specifikation 

230 

8

Ved anvendelse af et konfigureringssystem kan en ikke-ekspert svare på diverse 

spørgsmål omkring ønskede dimensioner, materialer, farver etc. , mens 

konfigureringssystemet begrænser ulovlige valg. Når brugeren har svaret på alle 

spørgsmålene, vil systemet være i stand til selv, at genere en eller flere af de 

specifikationer, som man ellers ville udarbejde manuelt, f.eks. tilbudsbrev, tegning 

og stykliste. 

Som et eksempel på et konfigureringssystem er der nedenstående vist et simpelt 

system fra Dolle. Ved anvendelse af dette konfigureringssystem kan en slutbruger 

designe sin egen trappe og få et udarbejdet et tilbud automatisk. 

Figur 4: Illustration af et simpelt konfigureringssystem (skærmbillede ved 

indtastning af ønsker, fra www.dolle.dk). 

1.3 Tilgangsvinkel og undersøgelsesmetode 

PKB projektet har haft en praktisk tilgangsvinkel. Fokus har været på at opbygge 

prototyper i de tilknyttede virksomheder og informere om produktkonfigurering og 

3D modellering. Der var ikke opstillet egentlige forskningshypoteser. 

Metodikken til at opnå de erkendelser, der fremgår i nærværende rapport har 

således været følgende: 

• Det er som udgangspunkt antaget, at den eksisterende fremgangsmåde for 

udvikling af konfigureringssystemer er brugbar. 

• Fremgangsmåden er anvendt i en række virksomheder tilknyttet projektet. 

• Erfaringer fra tilsvarende konfigureringsprojekter uden for PKB regi er 

anvendt som et supplement til egne erfaringer. 

9 



• Erfaringer er løbende opnået, analyseret og dokumenteret. 

På baggrund heraf er der udarbejdet nærværende rapport. Rapporten er opdelt som 

følgende: 

• Først gives en kort beskrivelse af den anvendte fremgangsmåde. 

• Herefter beskrives de generelle erfaringer med konfigureringssystemer i 

byggebranchen og forudsætningerne herfor. 

• Derefter beskrives de specifikke erfaringer med fremgangsmåden. 

• Endelig gives en konklusion på erfaringerne. 



10

2 Fremgangsmåde for opbygning af 

konfigureringssystemer 

I dette kapitel gives en kort gennemgang af den fremgangsmåde, der gennem flere 

år har været anvendt i konfigureringsprojekter relaterede til DTU [Hvam et al., 

2004]. 

Hensigten med kapitlet er at give en kort oversigt over fremgangsmåden og dens 

værktøjer, for herefter i de næste kapitler, at gå i detaljer med konkrete erfaringer. 

Det er således i nærværende note besluttet ikke, at lave en ny beskrivelse af 

fremgangsmåden, men at anvende eksisterende beskrivelser. Nærværende kapitel er 

således direkte ”klippet” fra [Hvam et al, 2004] og tilpasset nærværende note, -med 

tilladelse fra forfatterne. For nærmere indsigt i fremgangsmådens værktøjer henvises 

interesserede læsere således til [Hvam et al, 2004]. 

2.1 Introduktion 

Nærværende fremgangsmåde skal bidrage til at strukturere arbejdet med at 

indfange og formalisere viden og information om produkter og deres eventuelle 

livsfasesystemer. Ved at anvende fremgangsmåden skal man kunne: 

• Udlede de forretningsmæssige krav til det konfigureringssystem, der skal 

opbygges. 

• Analysere og definere produkternes funktion, struktur og relevante 

livsfasesystemer. 

• Udtrykke produktviden i en form, så den kan lægges ind i et IT-system. 

• Sikre at det opbyggede konfigureringssystem løbende kan vedligeholdes og 

videreudvikles. 

Desuden skal fremgangsmåden bidrage til at håndtere de organisatoriske ændringer, 

der finder sted når viden formaliseres og lægges ind i et konfigureringssystem. 

Fremgangsmåden bygger på teori og metoder fra en række forskellige fagområder: 

• Mass Customization og modularisering af produkter 

• Rekonstruktion af forretningsprocesser (Business Process Reengineering) 

• Produktudvikling og viden om livsfasesystemer, f.eks. produktion og montage 

• Arkitektur for opbygning af produktmodelsystemer 

• Modelleringsteknikker, f.eks. objektorienteret modellering 

• Metoder for opbygning af IT-systemer, dvs. objektorienteret modellering og 

anvendelse af ekspertsystemer. 

• Organisatoriske forhold ved opbygning af konfigureringssystemer. 

Som en introduktion til fremgangsmåden beskrives kort en generel fremgangsmåde 

for udvikling af IT-systemer. Forløbet ved udvikling og drift af IT-systemer er vist i 

nedenstående Figur 5 i form af den såkaldte projektlivscyklus. 

11 



Vedligeholdelse og 



Vedligehold 

& opfølgning 

Indførelse & 

brugeraccept 

Integration & 

validering 

Programmering 

Problemanalyse 

Konstruktion 

& verifikation 

Analyse 

Kravspecifikation 

Skitsedesign 

Detaildesign 

Design 

Figur 5: Projektlivscyklus ved udvikling af et IT-system. 

Et projekt vedr. udvikling og drift af et IT-system gennemløber hovedfaserne: 

• Analyse og indledende funktionel kravspecifikation 

• Design af løsning/ overordnet skitse af systemet 

• Programmering og test 

• Implementering 

• Vedligeholdelse/ videreudvikling. 

Den viste projektlivscyklus er første gang beskrevet i det amerikanske 

udviklingsprojekt ICAM (Integrated Computer Aided Manufacturing) omkring 1980. I 

ICAM-projektet er der, for at understøtte faserne analyse og design af IT-systemer, 

udviklet teknikker til modellering af aktivitetsforløb (IDEF0) og informationsstruktur 

(IDEF1). 

På den tid anvendtes forskellig struktur og notation i de enkelte faser. I analysefasen 

anvendes funktionsmodellering (IDEF0), mens der i designfasen anvendtes f.eks. 

IDEF1 modellering og traditionel dataflow-diagrammering, og i det detaljerede 

design f.eks. pseudoprogrammering. 

Forløbet er vist som en cyklus ud fra den betragtning, at der ved vedligeholdelse og 

videreudvikling af systemet gennemløbes en ny cyklus i projektlivscyklen, idet der 

gennemføres de samme aktiviteter, som ved opbygning af den første version af 

systemet. Arbejdsforløbet kan således gennemføres vilkårligt mange gange i et givet 

domæne, idet det grundlæggende er de samme aktiviteter, der skal udføres, hvad 

enten det er udvikling af et nyt system eller ændring af et eksisterende system. 

Begrundelsen for at introducere projektlivscyklen var et ønske om, at opnå en mere 

struktureret fremgangsmåde ved udvikling af IT-systemer. Ved projektlivscyklen 

lægges vægt på at der gennemføres analyse og design, hvor systemets indhold og 

struktur fastlægges og evalueres inden det egentlige programmeringsarbejde 

igangsættes. 

Derved reduceres de samlede omkostninger ved udviklingsarbejdet, idet den større 

arbejdsindsats ved analyse og design, som vist i Figur 6 som regel medfører en 

væsentlig reduktion af indsatsen ved programmering, implementering og især 

vedligeholdelse og videreudvikling af systemet. Det bliver ofte umuligt at 

vedligeholde og videreudvikle et IT-system, der ikke er struktureret og 

dokumenteret. 



12

13 

RESSOURCE- 

INDSATS 

Analyser problem 

Problemanalyse 

Kravspecifikation 

Formuler og 

tilpas løsning 

Skitsedesign 

Detaljeret design 

Traditionel 

fremgangsmåde 

Struktureret 

fremgangsmåde 

Byg og indfør løsning 

Opbygning og afprøvning 

Integration og validering 

Implementer og 

vedligehold løsning 



TID 

Implementering og brugeraccept 

Vedligeholdelse og support 

Figur 6: Besparelse ved anvendelse af en struktureret fremgangsmåde. 

Den beskrevne projektlivscyklus bidrager til en strukturering og opdeling af arbejdet 

med udvikling af IT-systemer, og omfatter såvel den tekniske som den 

ledelsesmæssige side af udviklingsarbejdet. Dvs. projektlivscyklen dels understøtter 

de tekniske aktiviteter med udvikling af IT-systemer og dels er et ledelsesredskab til 

styring og organisering af større udviklingsprojekter, idet projekterne kan nedbrydes 

i en række delaktiviteter med et veldefineret resultat, f.eks. udarbejdelse af AS-IS 

model, udarbejdelse af TO-BE model, foreløbigt design osv. 

2.1.1 Den objektorienterede projektlivscyklus 

Det objektorienterede paradigme for systemudvikling søger at integrere de enkelte 

faser i projektlivscyklen, ved, tidligt i analysefasen, at identificere objektklasser i det 

domæne systemet omfatter. En objektklasse kan beskrives som en samling af 

objekter med fælles karakteristika (attributter) og fælles adfærd (metoder). 

Eksempelvis kan objektklassen biler opfattes som en samlet betegnelse for alle biler. 

Klassen biler har en række karakteristika, der identificerer biler, f.eks. fabrikat, 

motorstørrelse, vægt mv. Desuden kan klassen biler tildeles en adfærd, hvor den 

f.eks. kan beregne bilens vægtafgift som funktion af bilens vægt og benzinforbrug. 

Objektklasser repræsenteres IT-mæssigt som et selvstændigt stykke program, der 

indeholder attributter (variable) og metoder (procedurer). 

De identificerede objektklasser udvikles og detaljeres gennem samtlige faser i 

projektlivscyklen, der i øvrigt indeholder de samme faser som ICAM´s 

projektlivscyklus: 

• Analyse 

• Design 

• Udvikling/ implementering 

• Ændring/ vedligeholdelse

I nedenstående Figur 7 er vist den objektorienterede projektlivscyklus, der 

sammenlignet med ICAM´s projektlivscyklus giver mulighed for lettere at springe 

rundt mellem de enkelte faser i systemudviklingen. Dette skyldes at der, i 

modsætning til tidligere, hvor systemudviklere måtte skifte repræsentationsform 

mellem de enkelte faser, anvendes samme opdeling og grundlæggende 

repræsentationsform gennem samtlige faser i systemudviklingen - det er de samme 

objektklasser, der optræder gennem de enkelte faser i projektlivscyklen. 

Analysis 

Design 

Evolution 

Modification 

Figur 7: Den objektorienterede projektlivscyklus. 

Med pilenes overlap og de tilbageførende pile er det forsøgt at vise, at 

systemudvikling baseret på det objektorienterede paradigme, giver bedre mulighed 

for, som nævnt, at springe mellem de enkelte faser i projektlivscyklen. De 

grundlæggende principper ved objektorienteret modellering er uddybende beskrevet 

i de følgende kapitler. 

2.1.2 Overblik over fremgangsmåden 

Med udgangspunkt i den objektorienterede projektlivscyklus beskrives i det følgende 

en fremgangsmåde for opbygning af konfigureringssystemer. Fremgangsmåden 

indeholder bl.a. metoder til at analysere de forretningsprocesser, der skal 

understøttes af konfigureringssystemer, samt metoder til analyse og modellering af 

et produktsortiment. I nedenstående Figur 8 er vist fremgangsmåden for opbygning 

og implementering af konfigureringssystemer. 



14

15 

Fase Indhold Resultat 

Karakteristik af de vigtigste specifikationsprocesser. 

Mål og krav for de enkelte specifikationsprocesser. 

1 Procesanalyse Identifikation og karakteristik af de vigtigste 

specifikationsprocesser. 

Scenarier i form af beskrivelse af fremtidige 

specifikationsprocesser, samt definition af de 

konfigureringssystemer, der skal understøtte de enkelte 

specifikationsprocesser. 

Formulering af mål og krav til de enkelte 

specifikationsprocesser. Måling og gabanalyse. 

Konstruktion af ny specifikationsproces. Definition 

af de (t) konfigureringssystem(er), der skal 

understøtte specifikationsprocessen. 

Evaluering/ måling af de enkelte scenariers effekt. Valg 

af scenario. 

Handlingsplan og plan for organisering af det videre 

arbejde. 

Vurdering og valg af scenario. 

Handlingsplan og organisering af det videre 

arbejde. 

Definition af konfigureringssystemets overordnede 

indhold og struktur. Produktvariantmaster. 

2 Produktanalyse Analyse af produktsortiment. Definition af 

konfigureringssystemets overordnede indhold og 

struktur. Opbygning af produktvariantmaster. 

OOA-model (evt. dynamik). 

Brugergrænseflade. Kravspecifikation. 

Opbygning af objektorienteret analysemodel 

(OOA). 

3 Objektorienteret 

analyse 

Valg af konfigureringssoftware. En tilpasset OOAmodel 

(OOD-model). Kravspecifikation til programmering. 

Valg af konfigureringssoftware. Tilpasning af 

OOA-model til det valgte konfigureringssoftware. 

Opstilling af kravspecifikation til programmering, 

herunder brugergrænseflade, integration til andre 

systemer og programdynamik. 

4 Objektorienteret 

design 

Figur 8: Fremgangsmåden. 



5 Programmering Programmering og test. Et færdigprogrammeret konfigureringssystem. 

Brugervejledning og uddannelsesplan. 

6 Implementering Implementering af konfigureringssystem og den 

fremtidige specifikationsproces. 

Målinger af den nye specifikationsproces’ performans. 

Opdateret OOA-model og programkode. Ansvarlige for 

vedligeholdelse og videreudvikling. 

7 Vedligeholdelse Måling og opfølgning på den nye 

specifikationsproces. Vedligeholdelse og løbende 

videreudvikling af konfigureringssystem. Udpege 

ansvarlige for vedligeholdelse og videreudvikling.

Den første fase i fremgangsmåden omfatter en identifikation af de vigtigste 

specifikationsprocesser og en analyse af mål og øvrige krav til de 

specifikationsprocesser, der skal understøttes af konfigureringssystemer. 

Specifikationsprocesserne beskrives og de forretningsmæssige krav til processerne 

analyseres i forhold til virksomhedens forretningsstrategi. I forlængelse heraf 

udarbejdes scenarier for de fremtidige specifikationsprocesser, og ved anvendelse af 

rammesystemet beskrevet i kapitel 2 [Hvam et. al., 2004] foretages en afgrænsning 

af det overordnede indhold af de konfigureringssystemer, der skal udvikles til at 

understøtte de fremtidige specifikationsprocesser. Dette udgør grundlaget for 

produktanalysen i fase 2, hvor modellernes indhold og struktur beskrives mere 

detaljeret ud fra en analyse af virksomhedens produktsortiment, og eventuelt 

tilhørende livsfase-systemer (f.eks. produktion, montage, forsendelse, anvendelse og 

skrotning). Som afslutning på fase 1 foretages en vurdering af de enkelte scenarier, 

og en udvælgelse af det scenarie man ønsker at arbejde videre med. Som grundlag 

for det videre arbejde opstilles et budget og en handlingsplan for det videre arbejde. 

I fase 2 analyseres produkterne ved at tegne produktsortimentet op i en såkaldt 

produktvariantmaster (en beskrivelse af produktets opbygning i form af 

parter/moduler, variationer indenfor de enkelte parter/ moduler, samt relationer 

mellem parter/ moduler). Formålet med analysen er at opnå et samlet overblik over 

de enkelte produktfamilier og deres mulige variationer. Desuden bidrager 

produktvariantmasteren til at sikre at forskellige personer i virksomheden får en 

fælles opfattelse af produktsortimentets struktur og variationsmuligheder. 

I forbindelse med den detaljerede modellering af selve IT-systemet anvendes 

objektorienteret modellering. Den opbyggede produktvariantmaster tjener som 

grundlag for identificering af objektklasser og klassehierarkier. Detaljer vedr. de 

enkelte objektklasser beskrives vha. såkaldte klasse-beskrivelseskort (CRC-kort). Den 

objektorienterede model danner grundlag for at modellerne kan programmeres. I 

fase 4, objektorienteret design, foretages et valg af konfigureringssoftware. Desuden 

fastlægges øvrige krav i forhold til programmering af konfigureringssystemet som 

eksempelvis programdynamik, brugergrænseflade og integration til øvrige ITsystemer 

som eksempelvis virksomhedens ERP-system. 

Når konfigureringssystemet er programmeret og implementeret i organisationen 

kommer den vanskelige fase med at vedligeholde og løbende videreudvikle 

konfigureringssystemet. 

2.1.3 Iterative forløb 

I nedenstående Figur 9 er vist forløbet ved opbygning af konfigureringssystemer. 

Som det fremgår af figuren vil man normalt gennemløbe fremgangsmådens faser et 

antal gange ved opbygning, implementering og vedligeholdelse af 

konfigureringssystemer. 



16

17 

Proces analyse 

Produkt analyse 

Objekt orienteret 

analyse og design 

Programmering 


Vedligeholdelse/ 


Fase 

Version 1. Version 2. 

Version n. 

Figur 9: Forløbet ved opbygning og implementering af konfigureringssystemer. 

I forbindelse med opstart og gennemførelse af projektet kan man vælge at lave et 

forløb, hvor man gennemløber fremgangsmådens faser 2 til 3 gange. I det første 

gennemløb – prototypefasen - udarbejdes en grov forretningsmæssig analyse og en 

foreløbig afgrænsning af det konfigureringssystem, der skal opbygges. Derefter 

foretages en analyse og modellering af en udvalgt del af virksomhedens 

produktprogram. 

I forbindelse med prototype-fasen foretages en udvælgelse af et 

konfigureringssoftware. Modellen, der er opbygget i fase 2-3 kan danne grundlag for 

at teste forskellige standard konfigureringssystemer i forbindelse med valg af 

software. Som afslutning på det første gennemløb vælges software og der opbygges 

en prototype, der danner grundlag for det næste gennemløb af fremgangsmåden. 

I næste gennemløb foretages en uddybende forretningsmæssig analyse og man 

foretager den endelige afgrænsning af det konfigureringssystem, der skal bygges. 

Derefter opbygges produktvariantmaster og øvrige masters for de produkter og 

eventuelle livsfasesystemer, der skal lægges ind i systemet, og der foretages en 

fastlæggelse af modellernes klassestruktur og alle detaljer beskrives på de tilhørende 

klassebeskrivelseskort. Herefter gennemføres programmeringen af version 2 af 

systemet. 

Ved tredie gennemløb lægges hovedvægten på test og fejlretning af systemet inden 

systemet (version 3) implementeres i organisationen. 

Første gennemløb med udarbejdelse af prototype gennemføres hurtigt, typisk i løbet 

af 1 til 3 uger. Andet gennemløb gennemføres typisk i løbet af 2 til 4 måneder, mens 

tredie gennemløb gennemføres i løbet af 1 til 3 måneder – afhængigt af projektets 

størrelse og bemanding. Ovenstående forløb vil typisk gælde for en virksomhed, der 

ikke tidligere har konfigureringssystemer ved anvendelse af en struktureret 

fremgangsmåde. Hvis man er fortrolig med anvendelse af konfigureringssystemer og 

tidligere har gennemført projekter af denne type kan man evt. springe fasen med 

prototypen over. 

........ 

....... 



Tid 

.......

Efter at version 3 af systemet er implementeret i organisationen går systemet over i 

en driftsfase, hvor der skal lægges vægt på løbende vedligeholdelse og 

videreudvikling. I den forbindelse vil det fortsat være relevant at gennemløbe de 

enkelte faser i fremgangsmåden og løbende analysere de aktuelle 

forretningsmæssige krav til specifikationssystemet og produkternes struktur. 

Desuden er det kritisk at den opbyggede objektorienterede model opdateres 

sideløbende med at programmet rettes. 

2.1.4 Roller i udviklingsforløbet 

Arbejdet med at opbygge og anvende konfigureringssystemer kan opdeles i en 

udviklingsfase og en drifts-/ vedligeholdelsesfase. I udviklingsfasen vil der være 

følgende roller/ opgaver: 

• Projektets sponsor. En person fra virksomhedens ledelse, der har det 

overordnede ansvar for projektet, herunder projektets økonomiske rammer. 

Det er vigtigt at projektets sponsor har en vis indsigt i de tekniske og 

forretningsmæssige problemer og muligheder ved opbygning og anvendelse 

af konfigureringssystemer. Det er sponsorens opgave at indtænke anvendelse 

af produktkonfigurering i virksomhedens forretningsstrategi og i forlængelse 

heraf vurdere projektets relevans og betydning for virksomheden. Med 

udgangspunkt i projektets strategiske betydning er det sponsorens opgave at 

argumentere for tilvejebringelse af de nødvendige ressourcer til udvikling og 

drift af konfigureringssystemer. Desuden er det sponsorens ansvar at sikre at 

projektet følger den opstillede projektplan og at man når de opstillede mål. 

Projektets sponsor følger alle faser i projektet. 

• Projektleder. En person, der har det daglige ansvar for at gennemføre 

projektet. Projektlederen bør have kendskab til fremgangsmåden for 

opbygning konfigureringssystemer. Projektlederen deltager i alle projektets 

faser og varetager den daglige ledelse af projektet, herunder opfølgning og 

eventuelt korrektion af projektets arbejds- og tidsplan. 

• Facilitator. En person, der besidder den nødvendige viden for gennemførelse 

af de enkelte faser i fremgangsmåden. Denne person vil typisk være en 

konsulent eller en medarbejder, der tidligere har gennemført projekter 

vedrørende opbygning af konfigureringssystemer. Hvis det er første gang en 

virksomhed opbygger et konfigureringssystem vil det facilitatoren normalt 

være den eneste, der besidder et detailkendskab til hvorledes man opbygger 

et konfigureringssystem. Det er bl.a. facilitatorens opgave at uddanne 

projektets øvrige medarbejdere til at kunne bidrage til opbygning og 

implementering af et konfigureringssystem. Facilitatoren vil typisk bidrage til 

de første faser i projektet procesanalyse, produktanalyse, samt 

objektorienteret analyse og design. 

• Forandringsleder. En person, der bidrager til at gennemføre de nødvendige 

tiltag for at sikre at organisationen er parat til at gennemføre projektet, og 

tage det endelige system i brug. Forandringslederen bør besidde en 

kompetence om forandringsledelse i forbindelse med gennemførelse af større 



18

19 

tekniske projekter. Forandringslederens opgave er at sikre at medarbejdere, 

der berøres af et projekt vedr. opbygning af anvendelse af et 

konfigureringssystem informeres og motiveres til at bidrage til udvikling og 

drift af konfigureringssystemet. Desuden er det forandringslederens opgave 

at bidrage til løsning af eventuelle konflikter. 

• Modelbygger (model manager). Modelbyggeren har til opgave at indsamle 

viden og opbygge produktvariantmaster, klassemodel og klassebeskrivelseskort, 

som grundlag for programmering af konfigureringssystemet. I 

forbindelse med drift af konfigureringssystemet vil modelbyggeren være 

ansvarlig for opdatering af dokumentationen. En modelbygger kan f.eks. 

være en domæneekspert, der er uddannet af facilitator. 

• Procesbygger (Process manager). Procesbyggeren har til opgave at udvikle 

virksomhedens specifikationsprocesser og at sikre at det udviklede 

konfigureringssystem bliver indbygget i den fremtidige specifikationsproces 

på en hensigtsmæssig måde. Procesbyggeren bør have en god indsigt i 

virksomhedens specifikationsprocesser og de tilgrænsende områder som 

eksempelvis salg, planlægning og produktion. Procesbyggeren bidrager 

primært til procesanalysen, samt til implementering, vedligeholdelse og 

videreudvikling. 

• Domæneekspert. Medarbejdere der besidder viden om produkter og 

relevante livsfasesystemer. Det kan eksempelvis være medarbejdere fra 

produktudvikling eller produktion. Domæneeksperter bidrager med viden om 

dele af produktet eller produktets livsfaser som eksempelvis produktion eller 

montage. Domæneeksperter bidrager til procesanalyse, produktanalyse samt 

vedligeholdelse/ videreudvikling. 

• Programmør. En person, der er i stand til at programmere de opbyggede 

produktmodeller. Programmøren bør have et indgående kendskab til det 

konfigureringssoftware man anvender, samt kendskab til programmering af 

eksempelvis kundemodul eller integration til øvrige systemer i virksomheden. 

Hvis der anvendes et standardsystem til implementering af 

konfigureringssystemet kan programmeringsarbejdet – eller dele af 

programmeringsarbejdet udgøres af modelbyggeren. Programmøren deltager 

i design og programmeringsfasen, samt vedligeholdelse/ videreudvikling af 

systemet. 

Det skal bemærkes, at en enkelt person kan varetage flere roller/ opgaver samtidig, 

f.eks. kan opgaverne som facilitator og forandringsleder udføres af samme person. 

I forbindelse med vedligeholdelse og videreudvikling af modellerne (fase 7) er det 

afgørende at der udpeges en person (modelbygger), der er ansvarlig for 

vedligeholdelse og videreudvikling af modellerne. Denne person kan evt. uddelegere 

ansvaret for opdatering af regler til diverse domæneeksperter, der besidder den 

nødvendige viden. Fase 7 er kritisk i den forstand at arbejdet med opbygning af 

konfigureringssystemer ikke er afsluttet når fase 1 til 6 er gennemløbet. Et 

konfigureringssystem, der ikke løbende opdateres bliver hurtigt værdiløst. Rollerne i 



drifts-/ vedligeholdelsesfasen er uddybende beskrevet i afsnittet ”Vedligeholdelse og 

videreudvikling.” 

2.2 Fremgangsmådens faser 

I det følgende gennemgås fremgangsmådens faser kort. 

2.2.1 Forretningsmæssig analyse 

Den første fase i fremgangsmåden omfatter en analyse af virksomhedens 

specifikationsprocesser. Analysen skal afklare hvad man ønsker at opnå rent 

forretningsmæssigt ved at opbygge og implementere et konfigureringssystem. 

Desuden skal analysen fastlægge de fremtidige specifikationsprocesser og i 

forlængelse heraf definere de konfigureringssystemer, der skal understøtte 

foretningsprocesserne. 

For at afklare hvad man ønsker at opnå ved at opbygge og implementere 

konfigureringssystemer til at understøtte virksomhedens specifikationsprocesser er 

det nødvendigt at indtænke de muligheder, der kan opnås i forhold til virksomhedens 

samlede forretningsstrategi. Hvad betyder det f.eks. for salget, hvis gennemløbstiden 

for udarbejdelse af tilbud og behandling af ordrer reduceres fra 3 uger til 4 timer? 

Eller hvilken strategisk betydning vil det have, hvis produktionsomkostningerne 

reduceres med 10 %, som følge af bedre og mere fejlfrie specifikationer i 

produktionen? For at kunne svare på disse spørgsmål kræves indsigt i virksomhedens 

markedsmæssige position og kundernes krav til virksomheden. 

Disse forhold må så indtænkes i virksomhedens strategiske planlægning, idet 

anvendelse af produktkonfigurering indebærer en række muligheder og risici, der må 

afklares i forhold til virksomhedens strategiske planlægning iøvrigt. I den forbindelse 

henvises til den gængse litteratur indenfor området. 

Udover afklaring af de strategiske forhold skal der i fase 1 gennemføres en analyse 

og redesign af de specifikationsprocesser, der skal understøttes af et 

konfigureringssystem. I forlængelse heraf foretages en afgræsning og definition af 

de konfigureringssystemer, der skal understøtte specifikationsprocesserne. 

Udgangspunktet for arbejdet i fase 1 er en identifikation og karakteristik af de 

vigtigste specifikationsprocesser i virksomheden. Dette kan f.eks. gøres ved at 

identificere de vigtigste specifikationer som eksempelvis tilbud, styklister, 

operationslister eller montagevejledning. Dernæst beskrives og karakteriseres de 

specifikationsprocesser, der fremstiller de pågældende specifikationer. 

Dernæst formuleres mål og krav til de vigtigste specifikationsprocesser og i den 

forbindelse kan der evt. foretages en række målinger på udvalgte 

specifikationsprocesser af eksempelvis gennemløbstid, ressourceforbrug eller kvalitet 

af specifikationer. Ved at sammenligne mål og de faktiske præstationer for de 

enkelte specifikationsprocesser kan man få en første indikation af hvor der er det 

største potentiale i at anvende produktkonfigurering til at udarbejde specifikationer. 

Efter at have analyseret de vigtigste specifikationsprocesser udarbejdes scenarier for 

hvordan den enkelte specifikationsproces fremover kan udvikles ved anvendelse af 

produktkonfigurering. I den forbindelse foretages en definition af de 



20

konfigurationssystemer, der skal opbygges v.h.a. rammesystemet for 

produktkonfigurering [Hvam et. al. 2004]. 

Der foretages en cost/ benefit vurdering af de enkelte scenarier, hvorefter man 

udvælger det scenarie man ønsker at arbejde videre med. Til slut opstilles en plan og 

et budget for det videre arbejde. 

I forbindelse med den forretningsmæssige analyse vil det ofte være nødvendigt at 

analyse virksomhedens produktsortiment. Hvis en virksomhed har komplekse og 

ustrukturerede specifikationsprocesser, hænger det ofte sammen med at 

produktsortimentet er kompliceret og ustruktureret. For at skabe klarhed og struktur 

i virksomhedens specifikationsprocesser og i de konfigureringssystemer, der skal 

understøtte disse forretningsprocesser er det nødvendigt at skabe et overblik over 

virksomhedens produktsortiment. 

2.2.2 Produktanalyse 

Formålet med fremgangsmådens fase 2 er at skabe et overblik over virksomhedens 

produktsortiment, og at definere indhold og strukturen i de konfigureringssystemer, 

der skal opbygges. 

21 

Figur 10: Produktvariantmaster. 

Når man ser på en virksomheds produktsortiment kan det ofte være stort og med et 

uoverskueligt antal varianter. For at få et overblik over produkterne tegnes 

produktprogrammet op i en såkaldt produktvariantmaster (se Figur 10). En 

produktvariantmaster består af to dele. Den første del ”part-of modellen” 

(produktvariantmasterens venstre side) indeholder de moduler eller parts, der indgår 

i hele produktfamilien. En bil består f.eks. af chassis, motor, bremsesystem mv. 

Hvert modul/ part i produktet markeres med en cirkel. De enkelte moduler/ parter 

modelleres desuden med en række attributter, der beskriver deres egenskaber og 

karakteristika. 

Den anden del af produktvariantmasteren (højresiden) indeholder de dele, der kan 

udskiftes i produktet. En motor kan f.eks. være af typen benzin eller diesel. Det vises 

på produktvariantmasteren som en generisk struktur, hvor den generiske part 

hedder motor, og de specifikke parter hedder henholdsvis benzinmotor og 

dieselmotor. De enkelte parter beskrives desuden med attributter som ved part-of 

modellen. I produktvariantmasteren beskrives desuden de vigtigste bindinger mellem 

moduler/ parter, dvs. regler for hvilke moduler/ parter, det er tilladeligt at 

sammensætte. Dette gøres ved at tegne en streg mellem de to moduler/ parter og 

skrive de regler der gælder for sammensætning af de pågældende moduler/ parter. 



På tilsvarende måde kan de livsfasesystemer, der ønskes modelleret beskrives med 

masters, der beskriver f.eks. produktionssystemet eller montagesystemet. 

De enkelte moduler/parter i produktvariantmasteren beskrives yderligere på såkaldte 

klassebeskrivelseskort (se [Hvam et al, 2004]). 

2.2.3 Objektorienteret analyse og design 

I fremgangsmåden for opbygning af konfigureringssystemer, er objektorienteret 

analyse valgt som gennemgående modelleringsteknik fra opbygning af model til 

programmering og vedligeholdelse af systemet. Dette valg er foretaget med 

udgangspunkt i et ønske om: 

• at kunne strukturere kompliceret viden om virksomhedens produktsortiment. 

• at kunne genbruge analyseresultater gennem projektlivs-cyklen fra analyse til 

design, programmering og vedligeholdelse/ videreudvikling af modellen. 

• at sætte domæneeksperter (f.eks. produktudviklere og medarbejdere fra 

produktionsteknisk afdeling) i stand til selv at modellere deres 

arbejdsområde. 

• at muliggøre en mere hensigtsmæssig arbejdsdeling mellem modelbygger 

(domæneekspert) og EDB-systemudvikler (programmør). 

En væsentlig egenskab ved objektorienteret analyse er således muligheden for at 

kunne strukturere et kompleks domæne, ved at opdele domænet i emneområder og 

objektklasser. Den valgte struktur fastholdes gennem alle faser af den 

objektorienterede projektlivscyklus, hvilket letter overgangen mellem de enkelte 

faser, og bidrager til en mere konsistent anvendelse af de resultater, der produceres 

i de enkelte faser. 

Det forhold, at der anvendes samme opdeling og notation gennem de forskellige 

faser i den objektorienterede livscyklus, bidrager til et forbedret samarbejde mellem 

modelbyggere, domæneekspert og programmør samt at der kan foretages en 

arbejdsdeling mellem modelbygger, domæneeksperter og programmør. Eksempelvis 

således at modelbygger og domæneeksperter bygger den objektorienterede model, 

hvorefter programmøren overtager det videre arbejde med at programmere 

modellen. 

Desuden sigter den objektorienterede modelleringsteknik mod at konstruere 

modeller, der er stabile overfor ændringer, ved bl.a. at fokusere på de mest stabile 

elementer i domænet og gøre disse til overordnede objektklasser. Endelig fokuseres 

på at udnytte objekternes fælles træk gennem nedarving af objekternes attributter 

og metoder. 

Der anvendes de grundlæggende principper og notation fra Unified Modelling 

Language (UML). I nedenstående Figur 11 er vist notationen for klasser og relationer 

mellem klasser. Der er tre forskellige typer af relationer mellem klasser; 

generalisering, aggregering og associering. 



22

23 

Subklasse1 

-attribute1 

-attribute2 

+metode1() 

+metode2() 

Superklasse 

-attribute1 

+metode1() 

Klasse 

-attribute1 

-attribute2 

+metode1() 

+metode2() 

Klasse med attributter 

og metoder 

Subklasse2 

-attribute1 

-attribute3 

+metode1() 

+metode3() 

Klasse1 

-attribute1 

+metode1() 

Klasse2 

-attribute2 

+metode2() 

Klynge 



* 

1 

Klynge 

Klasse1 

-attribute1 

+metode1() 

* 

1 

Klasse2 

-attribute1 

+metode2() 

Generaliseringsstruktur Aggregeringsstruktur Assoceringsstruktur 

Figur 11: UML notation for angivelse af objektklasser og deres indbyrdes 

relationer. 

Generaliseringsstrukturer, beskriver objektklasser, der har fælles attributter og 

metoder. Det kan f.eks. være objektklassen bil, der indeholder generelle attributter 

og metoder om biler eksempelvis registreringsnummer og motorstørrelse, mens 

objektklassen lastbiler indeholder attributter og metoder, der er specifikke for 

lastbiler eksempelvis lastevne eller ladopbygning. Generaliseringsstrukturen mellem 

objektklassen biler og objektklassen lastbiler betyder at den specielle objektklasse 

lastbiler arver attributter og metoder fra den generelle objektklasse biler. 

Aggregeringsstrukturer omfatter objektklasser, der tilsammen udgør en helhed, som 

f.eks. dele i en bil; karrosseri, motor, gearkasse, hjul mv. Relationer i 

aggreringsstruktur beskrives desuden med angivelse af kardinaliteten mellem de to 

klasser. Dvs. en angivelse af antallet af objekter i hver ende af relationen, f.eks. at 

en bil har fire hjul. Objektklasser i en aggreringsstruktur kan kommunikere 

indbyrdes, men de arver ikke automatisk attributter og metoder som ved en 

generaliseringsstruktur. 

Associeringsstrukturer beskriver relationer mellem objektklasser, der er relateret til 

hinanden uden at der er tale om objektklasser der udgør en helhed. Et eksempel kan 

være objektklassen bil og objektklassen fører. Associeringsstrukturer beskrives som 

aggreringsstrukturer med angivelse af kardinaliteten mellem de to klasser. 

Udover de nævnte typer af relationer mellem objektklasser kan objektklasser 

grupperes i klynger. En klyngestruktur betegner en grupper af objektklasser, der er 

indbyrdes forbundne. En klyngestruktur vil således normalt omfatte objektklasser, 

der indbyrdes forbundne med generalisering, aggregering eller 

associeringsstrukturer. Modellering af objektklasser og deres relationer er uddybende 

beskrevet i kapitel 6 Objektorienteret modellering.

Den optegnede produktvariantmaster danner grundlag for at definere objektklasser 

og klassestrukturer i produktmodellen. De enkelte knuder i produktvariantmasteren 

kan være objektklasser, mens part-of og kind-of strukturerne genfindes som 

strukturer mellem objektklasserne. 

I produktvariantmasteren anvendes såkaldte part-of og kind-of strukturer. Disse 

begreber er taget fra objektorienteret modellering, som beskrevet ovenfor. Part-of 

strukturen på produkt-variantmasteren svarer således til en aggregeringsstruktur 

mens kind-of strukturen svarer til en specialiseringsstruktur. 

I forbindelse med optegnelse af produktvariantmasteren og den endelige 

objektorienterede klassemodel anvendes såkaldte klassebeskrivelseskort (CRC-kort) 

til at beskrive de enkelte objektklasser. Et klassebeskrivelseskort indeholder udover 

objektklassens navn mv. en beskrivelse af objektklassens mission, objektkassens 

attributter og metoder, samt en beskrivelse af objektklassens relationer til andre 

objektklasser. 

I nedenstående Figur 12 er vist et eksempel på et klassebeskrivelseskort (CRC-kort). 

I forbindelse med modellering af produkter er der tilføjet en skitse af produktdelen 

med angivelse af produktdelens attributter. 

For at sikre en overskuelig model er det hensigtsmæssig at adskille viden om 

produkter og deres livsfasegenskaber (produktviden) fra viden (systemviden) om 

konfigureringssystemets programmering og herunder eksempelvis 

brugergrænseflade og integration til øvrige IT-systemer. Dvs. at man så vidt muligt 

grupperer objektklasser med produktviden i klynger for sig og objektklasser med 

systemviden andre klynger. 

Hvis en objektklasse indeholder både produktviden og systemviden kan man i 

forbindelse med beskrivelse af metoder opdele disse i metoder, der vedrører 

produktviden (produktmetoder) og metoder, der indeholder systemviden 

(systemmetoder). 



24

25 

Klassenavn: Dato: Forfatter/version: 

Klassens opgave (responsibilities): 

Aggregering Generalisering 

Overdele: Overklasser: 

Underdele: Underklasser: 

Skitse: 

Attributter: Klassen samarbejder 

med : 

Systemmetoder: 

Produktmetoder: 

Figur 12: Klassebeskrivelseskort (CRC-kort). 

CRC-kortene udfyldes løbende under den objektorienterede analyse. Formålet med 

CRC-kortene er at dokumentere detaljeret viden om attributter og metoder, under de 

enkelte objektklasser, samt at beskrive klassernes indbyrdes relationer. CRC-kortene 

tjener som dokumentation overfor både domæneeksperter og systemudviklere og 

bliver således sammen med produktvariantmasteren og klassediagrammet et vigtigt 

middel til at kommunikere og dokumentere viden i projektgruppen. 

I [Hvam et al., 2004] er der givet en uddybende beskrivelse af de enkelte felter på 

CRC-kortet og CRC-kortenes anvendelse. 

Udover selve den objektorienterede klassemodel foretages en definition af systemets 

brugergrænseflade, kravspecifikation, dynamik, samt integration til øvrige systemer. 

Den objektorienterede modelleringsteknik er i princippet uafhængig af hvilket 

software det vælges at implementere systemet i, og den opbyggede model kan 

således anvendes som dokumentation uanset valg af implementeringsværktøj. I 

praksis vil det dog ofte være nødvendigt at foretage en række justeringer i modellen 

inden modellen kan implementeres i et konkret konfigureringssoftware. 

Udgangspunktet for valg af konfigureringssoftware er systemets kravspecifikation, 

der udover den opbyggede model omfatter en række krav til systemet og 

leverandøren som eksempelvis mulighed for integration til andre systemer, svartid, 

driftssikkerhed og mulighed for support fra leverandøren. 

De standardsystemer, der idag findes til produktkonfigurering er ikke alle fuldt 

objektorienterede. Det vil derfor ofte være nødvendigt at tilpasse den 

objektorienterede model til de muligheder, der findes for at strukturere modeller i 

det konkrete konfigureringssoftware. I den forbindelse fastlægges hvorledes man 

ønsker at dokumentere eventuelle forskelle mellem strukturen i den opbyggede 

produktmodel og strukturen i konfigureringssystemet 



Den tilrettede objektorienterede model kaldes en objektorienteret design model 

(OOD). Desuden foretages detailspecifikation af brugergrænseflade, dynamik og 

integration til øvrige systemer i forhold til det valgte konfigureringssoftware. 

2.2.4 Programmering 

Den objektorienterede model med klassediagram, klasse-beskrivelseskort og 

beskrivelsen af systemets dynamik og brugergrænseflade mv. danner grundlag for 

programmering af konfigureringssystemet. 

Ofte vil man vælge at implementere modellerne i et standard konfigureringssystem. 

En stor del af de standard konfigureringssystemer, der er tilgængelige på markedet 

idag er videnbaserede systemer, dvs. de indeholder en videnbase og en 

inferensmaskine. 

Programmøren bør have et indgående kendskab til det standardsystem, der 

anvendes. Som nævnt vil det ofte være muligt at uddanne modelbygger eller 

domæneeksperter til at varetage dele af programmeringsarbejdet. Erfaringer viser 

dog at det kan være svært for en ikke programmør effektivt at programmere 

komplekse regler og tilhørende applikationer som eksempelvis kundemodul eller 

integration til øvrige systemer. 

Hvis konfigureringssystemet ikke er objektorienteret kan strukturen i den opbyggede 

produktmodel ikke uden videre implementeres i konfigureringssystemet. Et 

konfigureringssystem, der ikke er objektorienteret understøtter ikke eksempelvis ikke 

indkapsling af objektklasser, relationer mellem objektklasser og nedarving. I stedet 

lægges attributter og metoder i en ”flad” struktur af fil-mapper (folders). 

På baggrund af den opbyggede klassemodel defineres strukturen af de folders, der 

indeholder attributter (defineret som datatyper eksempelvis ”Single”, ”OneOf”, ”At 

Most One” o.s.v.) og deres variationsmuligheder. På samme måde oprettes en 

tilsvarende folder-struktur med metoder, der eksempelvis kan implementeres i form 

af ressourcer og kalkulationer. 

Der findes der idag en række standard konfigureringssystemer, der understøtter 

anvendelse af tabeller til at repræsentere regler i systemet. Ved at anvende tabeller 

til at beskrive regler lettes implementeringen betydeligt. Desuden er det lettere at 

kommunikere mellem modelbygger, domæneeksperter og programmører ved 

anvendelse af tabeller, bl.a. fordi en del af viden om virksomhedens 

produktsortiment allerede er repræsenteret i form af tabeller. 

Hvis konfigureringssystemet er objektorienteret kan den opbyggede klassemodel 

implementeres direkte i systemet. Et objektorienteret ekspertsystem bygger på 

principperne i objektorienteret modellering og kan derved håndtere indkapsling af 

objektklasser, nedarving og relationer mellem objektklasser. Ved programmering af 

et objektorienteret konfigureringssystem oprettes klassestrukturen først, hvorefter 

attributter og metoder programmeres samlet for hver objektklasse. 

Anvendelse af et objektorienteret konfigureringssystem gør det lettere at strukturere 

videnbasen, hvilket gør det betydeligt lettere at vedligeholde og videreudvikle 

konfigureringssystemet. 



26

I forbindelse med programmering af et konfigureringssystem er det vigtigt løbende 

at teste de enkelte dele af konfigureringssystemet dels for at finde eventuelle fejl så 

tidligt som muligt og dels for at teste om det overhovedet kan lade sig gøre at 

implementere de enkelte dele af systemet. Den valgte struktur af klasser, objekter 

attributter og metoder er afgørende for konfigureringssystemets performans i forhold 

til eksempelvis svartider. Det kan derfor ofte være nødvendigt at programmere den 

samme del af systemet på forskellig måde og derefter på baggrund af test af 

delsystemets performans vælge den struktur, der viser den bedste performans. 

Desuden er det vigtigt at gennemføre brugertest af systemet og systemets 

brugergrænseflade allerede af tidlige versioner af konfigureringssystemet dels for at 

sikre input fra brugerne og dels for at sikre at de kommende brugere vil acceptere 

systemet. 

2.2.5 Implementering 

I forbindelse med implementering af systemet er det af afgørende betydning at 

systemets brugere accepterer systemet. Nedenstående er listet forskellige tiltag, der 

kan bidrage til brugernes accept af systemet: 

• Inddrag brugerne tidligt i projektforløbet, f.eks. i forbindelse med diskussion 

af brugergrænseflade og kravene til systemet. 

• Inddrag udvalgte brugere i test af prototype og tidlige versioner af systemet. 

• Motiver brugerne ved bl.a. løbende at informere om det nye system og de 

forretningsmæssige fordele man venter at opnå. 

• Giv en klar beskrivelse af brugernes fremtidige arbejdssituation. 

• Uddan brugerne i anvendelse af systemet. 

Indfør måling og lønsystemer eller rabatsystemer, der belønner brugere, der effektivt 

anvender systemet 

I forbindelse med implementering af et konfigureringssystem er det vigtigt at 

systemet er gennemtestet og fejlfrit inden det sættes i drift. Hvis brugerne af 

konfigureringssystemet få opfattelsen af at systemet er ustabilt og fyldt med fejl 

mister de hurtigt tilliden til systemet. 

Desuden skal man overveje hvorledes man vil implementere systemet. Hvis det at 

anvende et konfigureringssystemer noget nyt for virksomheden kan det være 

hensigtsmæssigt at implementere systemet gradvist. Dvs. man starter eksempelvis 

med at indføre systemet overfor udvalgte kunder/ sælgere. Når systemet er kørt ind 

i forhold til disse medarbejdere og kunder, og de er tilfredse, kan man gradvist 

udvide kredsen af brugere. Derved får man opbygget en kreds af ”supportere”, der 

bakker op om systemet. 

2.2.6 Vedligeholdelse og videreudvikling 

Efter implementering går systemet ind i den egentlige driftsfase. Ved anvendelse af 

konfigureringssystemer bliver viden om produkter og eventuelle livsfasesystemer 

formaliseret og lagt ind i et IT-system. Dette medfører en række ændringer i måden 

hvorpå arbejdet med at specificere produkter og f.eks. produktionsgrundlag udføres 

Anvendelse af konfigureringssystemer medfører, at der opstår en række nye opgaver 

i organisationen, mens andre opgaver forsvinder. En del af de daglige opgaver med 

udarbejdelse af specifikationer i form af f.eks. tilbud og produktionsgrundlag 

27 



forsvinder. Til gengæld skal f.eks. sælgere til at anvende de opbyggede 

konfigureringssystemer til gennemførelse af salgsarbejdet. 

Som tidligere nævnt er det nødvendigt løbende at vedligeholde og videreudvikle de 

opbyggede modeller og konfigureringssystemet, for derved at sikre at 

konfigureringssystemet bevarer sin gyldighed. Det betyder at der opstår en række 

nye opgaver med at vedligeholde og videreudvikle den opbyggede model og det 

tilsvarende konfigureringssystem. Disse opgaver skal typisk udføres af de personer, 

der har den nødvendige viden om produkterne og de relevante livsfasesystemer, 

f.eks. produktion, montage og forsendelse. 

Domæneekspert 

Klassediagram 1 

Konfigureringssystem 

(computermodel) 

Programmør (er) 

Dokumentation 

Klassediagram 2 

Klasse 1 

Klasse 2 

Klasse 1 

Klasse 2 

Klasse 5 

1 

* 

Klasse 5 

1 

Klasse 3 * Klasse 4 

Klasse 3 Klasse 4 

Klassediagrammer 

Modelmanager (s) 


Klassenavn 

Klassenavn 

Klassenavn 

Skitse 

Skitse 

Attributter 

Skitse 

Attributter 

Attributter 

Produktmetoder 


Systemmetoder 


Systemmetoder 

CRC-kort 


Klassen 

samarbejder 

Klassen 

medsam 

arbejder Klassen 

med samarbejder 

med 



Systemmetoder 

Figur 13: Roller i drifts-/ vedligeholdelsesfasen. 

Vedligeholdelse og videreudvikling vil således involvere en række forskellige 

personer. Arbejdet kan eksempelvis organiseres ved, at der er en eller to personer 

(model managers), der er ansvarlige for den samlede model og en eller to personer 

(programmører), der er ansvarlig for opdatering af konfigureringssystemet og selve 

programmet, herunder brugergrænseflade og integration til øvrige systemer. 

De ansvarlige for de samlede modeller (model managers) uddelegerer herefter 

opgaven med vedligeholdelse/ videreudvikling til de enkelte specialister, der hver 

især får ansvaret for vedligeholdelsen af den del af modellen, de har viden om. Dvs. 

at den enkelte specialist typisk får ansvaret for at vedligeholde og videreudvikle en 

række objektklasser og tilhørende klassebeskrivelseskort. 

I forbindelse med udvikling og vedligeholdelse af de opbyggede modeller er det af 

afgørende betydning at der foretages en samtidig opdatering af modeller og 

konfigureringssystem. Et konfigureringssystem, der ikke er dokumenteret bliver 

hurtigt vanskeligt eller helt umulig at vedligeholde og videreudvikle. 

.... 

28

Dokumentationen omfatter i hovedtræk produktvariantmaster, klassediagram og 

klassebeskrivelseskort. 

2.3 Afrunding 

Som det fremgår er nærværende beskrivelse af fremgangsmåden en oversigt. For 

nærmere uddybning af de enkelte faser, samt eksemplificering gennem praktiske 

cases henvises til bogen ”Produktkonfigurering” af Lars Hvam, Niels Henrik 

Mortensen og Jesper Riis [Hvam et al, 2004]. 

I de følgende kapitler foretages en opsamling på de erfaringer, der er opnået 

gennem opbygning af konfigureringssystemer i byggebranchen. Erfaringerne er 

opnået med udgangspunkt i en praktisk anvendelse af den her introducerede 

fremgangsmåde. 

29 



3 Erfaringer 

Dette kapitel opsamler nogle af de erfaringer, der er gjort med 

konfigureringssystemer i relation til PKB projektet. Erfaringerne er opdelt i to 

hovedgrupper: 

• Erfaringer med forudsætninger for konfigureringssystemer i byggebranchen. 

• Erfaringer med anvendelse af fremgangsmåden i byggebranchen. 

3.1 Erfaringer med forudsætninger for 

konfigureringssystemer 

Gennem projektforløbet er der opnået en række generelle erfaringer med anvendelse 

af konfigureringssystemer i byggebranchen. En del af disse omfatter parternes 

generelle modenhed for, at kunne automatisere deres specifikationsprocesser med 

konfigureringssystemer. Disse behandles i nærværende afsnit. 

Som udgangspunkt kan det konstateres, at der i byggebranchen gælder de samme 

forudsætninger for, at kunne automatisere specifikationsprocesser som i andre 

brahcner: 

• Der skal være ensartede og veldefinerede specifikationsaktiviteter, der 

gentages med en høj hyppighed. 

• Der skal være en velegnet teknologi (konfigureringssoftware), der muliggør 

en lønsom automatisering af specifikationsaktiviteterne. 

Disse forudsætninger kan opfyldes hvis følgende forhold gælder: 

• Standardiserede produkter: Gennem anvendelse af produktplatforme, 

moduler, faste produktstrukturer, standardiserede komponenter etc. skabes 

der et grundlag for, at kunne udføre ensartede og veldefinerede 

specifikationsaktiviteter med en høj hyppighed. 

• Markedsrationale for at standardisere: For at kunne sælge standardiserede 

produkter skal kunder være villige til, at give afkald på specielle detaljer til 

fordel for lavere pris. Endvidere skal markedet være tilstrækkeligt 

forudsigeligt således, at man kan regne med at specifikke produkter også i 

fremtiden sælges med en høj hyppighed. 

• Mange tilbud eller ordrer: For at opnå en høj hyppighed i 

specifikationsaktiviteterne skal der udarbejdes mange tilbud eller 

gennemføres mange ordrer. 

• Adgang til velegnet konfiguratorsoftware: For at kunne holde investeringerne 

i ny IT på et lønsomt niveau, skal der være modne IT-systemer, der medfører 

en reduktion af graden af egenudvikling og dermed 

udviklingsomkostningerne. 

Erfaringerne viser, at der i byggebranchen ofte er tale om, at kunderne ikke 

accepterer standardiserede løsninger og, at der ikke er en tilstrækkelig grad af 

prædefineret varians. Dette betyder helt specifikt at variantspecifikationsaktiviteterne 

bliver mere komplekse og at der gælder følgende: 

• Tegninger kontra styklister: I modsætning til rendyrket konfigurering, hvor 

det er nok at generere en stykliste, er der for mange produkter i 

byggebranchen behov for, at udarbejde specielle kundetilpassede geometrier 

og dertil hørende tegninger. 



30

De fire konkretiserede forudsætninger beskrives i det følgende og det diskuteres om 

forudsætningerne opfyldes i byggebranchen. Det femte punkt, omkring specifikke 

erfaringer med udarbejdelse af kundetilpasset geometri og hertil hørende tegninger, 

beskrives som det sidste punkt under de generelle erfaringer. 

3.1.1 Produktstandardisering og prædefineret varians 

I mange mindre virksomheder er tankegangen og arbejdsgangene præget af det, 

der kan karakteriseres som nyudvikling og lappeløsninger. Når en kundeforespørgsel 

indløber skaber man ofte et nyt produkt ved, at man ”lapper” på et tidligere 

fremstillet produkt: Der udskiftes et par komponenter, der ændres nogle dimensioner 

etc. Ønsker kunden ting man ikke har lavet før udvikler man helt nye komponenter, 

eller køber eksisterende komponenter, der gennem lidt tilpasning kan sammensættes 

på en ny måde. 

Når man laver et konfigureringssystem er man nødt til at tænke i andre baner. For at 

konfigureringssystemet skal kunne tage hensyn til alle tænkelige varianter er man 

nødt til at præ-definere produktkomponenter, moduler, regler og beregninger og 

skabe et standardiseret ”super-produkt”, der indeholder viden om alle tænkelige 

produktvarianter. Man er altså nødt til at bevæge sig fra ”lappeløsninger” og 

nyskabelse til prædefineret varians. 

Dette er søgt illustreret i Figur 14. Figuren viser at der forud for kundebehandling 

præ-defineres en mængde information og viden, bl.a. materialer, komponenter, 

regler, beregninger samt skabeloner for udformningen af dokumenter. Denne 

informationsmængde bruges som grundlag i kundebehandlingen til at danne 

varianter af specifikke produkt- og produktionsspecifikationer. 

31 



Development of 

materials, parts, 

modules and products 


manufacturing 

processes 

Development of rules, 

constraints, calculation 

methods, etc. 


document masters/ 

templates 

Specifications of 

materials 

parts 

modules 

products 


equipment 

routings 

processes 

etc. 


rules 

constraints 

calculations 

etc. 

Document templates: 

Quote docs. 

Proposal docs. 

Bill-of-material 

docs. 

etc. 

Creating product 

specifications for individual 

orders 

"Pushing" specifications to "market" "Pulling" specifications to order 

Order Specification Decoupling Line 

Creating process 

(manufacturing and 

delivery) specifications for 

individual orders 


materials 

parts 

modules 

products 


equipment 

routings 

processes 

etc. 

Figur 14: Opdelingen i prædefinet variantskabelsesgrundlag (markeret med hvid) 

og selve variantskabelsen (markeret med grå) [Hansen&Hvam, 2004]. 

I relation hertil er det væsentligt at fastlægge graden af tilladt variantskabelse. Ved 

salg og produktion af et standardprodukt (mobiltelefoner, hårde hvidevarer etc.) er 

der typisk en meget lille eller ingen varians. Ved skabelse af ”one-of-a-kind” 

produkter (bygninger, store procesanlæg, skibe etc.) er der tale om en meget stor 

grad af tilladt variantskabelse. Graden af tilladt variantskabelse kan beskrives ud fra 

begrebet Order Specification Decoupling Line (OSDL) [Hansen&Hvam, 2004]. Dette 

begreb fastlægger hvor meget produktinformation, der er fastlagt forud for en ordre 

kontra den del der fastlægges i det kundespecifikke ordreforløb. 



32

33 

Specifications 

created in 

"development" 

processes 

OSDL 

Norms and 

Standards 

Generic product 

structures 

Standard parts and 

modules 

Standard products 

Specifications 

created in variant 

specification 

processes 

Engineer-to-order 

Modify-to-order 

Configureto-order 

Select 

variant 

0% - 100% 

Degree of completed specifications 

Figur 15: Order Specification Decoupling Line og eksempler på klassificering af 

specifikationsprocesser [Hansen&Hvam, 2004]. 

Som illustreret i Figur 15 kan der karakteriseres en række typiske niveauer i 

variantskabelsen: 

• Engineer-to-order: Her er der kun få prædefinerede specifikationer. 

Udarbejdelsen af varianter er en kompleks opgave, der typisk tager lang tid 

og involverer højt uddannede teknikere og ingeniører. Produkter som 

cementfabrikker, større byggerier, mange mindre byggerier, skibe etc. hører 

til denne kategori. 

• Modify-to-order: Her er der prædefinerede produktstrukturer og en mere 

veldefinerede parametriske komponenter. Diverse stålkonstruktioner, 

industrielle skorstene, skræddersyet tøj, mm. hører til denne kategori. 

• Configure-to-order: Her er der tale om det klassiske ”lego-klods”-eksempel, 

hvor varianter opbygges af prædefinerede komponenter. Varianter af 

køkkener, computere, biler etc. skabes på denne måde. 

• Select-to-order: Ved et stort sortiment af standardprodukter lægger 

specifikationsopgaven i at finde den rette variant. Dette er aktuelt for mange 

forbrugsgoder, f.eks. mobiltelefoner, hårde hvidevarer, møbler, 

køkkenmaskiner etc. 

En væsentlig forudsætning for at kunne opbygge konfigureringssystemer er således, 

at man baserer variantskabelsen på produktfamilier indeholdende prædefinerede 

variansmuligheder, frem for tilpasning af tidligere solgte produkter. 

I meget store produktionsvirksomheder anvender man i dag produktplatforme, der 

kan bruges som grundstruktur til at udvikle nye produktfamilier. F.eks. er mange 

bilmodeller bygget op omkring den samme platform. Tilsvarende anvendes der 

moduler der kan bruges på tværs af produktfamilierne. I bilproduktion giver dette sig 

udtryk i, at f.eks. store dele af instrumentbrædtet består af de samme dele, på tværs 



af de forskellige bilmodeller. Platforme og moduler bidrager til et bedre 

variantskabelsesgrundlag. 

Opbygning af konfigureringssystemer hænger sammen med produktstandardisering, 

og opbygning af platforme, moduler og standardkomponenter. Opbygning af et 

sådant beredskab for variantskabelse betyder, at OSDL kan flyttes (mod højre i Figur 

15), hvilket medfører at der vil være færre (variant-) specifikationsaktiviteter der skal 

lægges ind i et konfigureringssystem. 

3.1.1.1 Hvordan foregår variantskabelsen i byggebranchen? 

En væsentlig erfaring fra PKB projektet er, at producenterne i byggebranchen ofte 

ikke har en standardiseret variantskabelse af typen configure-to-order (køkkener), 

men nærmere er at betegne som modify-to-order (vinduer, døre, porte, simple 

tagkonstruktioner etc.) eller engineer-to-order (råhuse, beton konstruktioner, betonelementer, 

stålkonstruktioner, etc.). 

I PKB projektet er der set eksempler på både engineer-to-order, modify-to-order og 

configure-to-order: 

• Råhuse fra Dalton Betonelementer: Komplekse betonkonstruktioner er af 

typen engineer-to-order. For at kunne lave en beton-bygning, skal der 

foretages styrkeberegninger, og der skal modelleres en ydre 3D geometri af 

bygningen. Til produktionen skal der laves detaljerede specifikationer af hvert 

betonelement, hvilket indebærer diverse snittegninger, klippe-bukke styklister 

samt styklister med prædefinerede indstøbningsdele. Denne opgave er 

kompleks og svær at lave i et konfigureringssystem. Projektgruppen havde 

derfor vanskeligheder med at komme igennem med opgaven. For at opnå 

resultater ændredes fokus fra konfigurering af bygninger til konfigurering af 

enkeltstående elementer, samt 3D modellering af bygningskonstruktioner. 

• Betontrapper fra Dalton Betonelementer: For betontrapper er der tale om en 

større grad af standard end for betonbygninger. Trapperne har en 

veldefineret grundform, hvorfor der er tale om en opgave der minder mere 

om modify-to-order, end egentlig engineer-to-order. For denne opgave var 

det nemmere for virksomheden at opbygge et egentligt konfigureringssystem. 

• Badeværelser fra Modulbad: Hovedparten af badeværelserne fra Modulbad 

opbygges også ud fra en veldefineret platform, med en forholdsvis 

veldefineret varians. Her kan opgaven ligeledes karakteriseres som modify-toorder, 

hvilket gjorde muligt at lave flere konfigureringssystemer (på prototype 

niveau). 

• Blandingsbatterier (varmevekslere) fra Gemina-Termix: En stor del af disse 

produkter er af typen select-to-order, hvorfor det ikke var relevant at lave 

konfigureringssystemer. En anden gruppe var af typen configure-to-order, 

hvilket muliggjorde opbygning af konfigureringssystemer (på 

prototypeniveau). 

Generelt er der en række produkttyper der er oplagte at understøtte med 

konfigureringssystemer: 

• De mest oplagte produkter er køkkener, møbler og standardiserede vinduer 

og døre. 

• Herefter er der en stor mellemgruppe af tilpassede produkter: døre, vinduer, 

trapper, tagkonstruktioner, vægkonstruktioner, betonelementer etc. 

• Endelig er der de meget komplekse produkter så som betonbygninger, 

betonelementer, etc. 



34

Som det vil beskrives senere i dette afsnit medfører ”modify-to-order” og ”engineerto-order” 

processer at der, i langt højere grad end for ”configure-to-order”, bliver 

behov for at specificere 3D geometri og tilhørende 2D tegninger. 

3.1.2 Markedsrationale for at standardisere 

I de industrialiserede forsyningskæder hvor man i dag finder konfigureringssystemer 

gælder der en række forhold, bl.a.: 

1. Markedsbehovene er relativt stabile og forudsigelige. 

2. Der er en fri konkurrence, der betyder at ineffektive arbejdsdelinger og 

ineffektive produktionsmetoder løbende udkonkurreres. 

3. Kunderne vil hellere have billige standardiserede slutprodukter (configure-toorder, 

modify-to-order), end specialtilpassede og dyrere produkter 

(engineer-to-order, develop-to-order) eller helt standardiserede produkter 

(select-to-order). 

Disse faktorer betyder at der er et grundlag for, at den enkelte virksomhed 

producerer produktfamilier under effektive industrialiserede produktionsformer, 

herunder en automatisering af specifikationsprocesserne ved tilbudsgivning og 

ordregennemførelse. 

3.1.2.1 Opfylder virksomhederne i byggebranchen disse forudsætninger? 

For at vurdere hvor vidt byggebranchen lever op til de ovenfor skitserede 

forudsætninger, kræves der en indsigt i byggebranchen som de færreste, herunder 

forfatterne til nærværende note, besidder. Det er således med et forbehold om 

manglende indsigt i branchen, at forudsætningerne diskuteres i det følgende. 

Markedsbehovene er relativt stabile og forudsigelige. 

Konjunkturfølsomhed betyder at markedsbehovene (for f.eks. ”almindelige” opgaver 

som renovering, parcelhuse, mindre hal og kontorbygninger mm.) sandsynligvis er 

mere ustabile end i den øvrige industri. Tilsvarende er der en række meget store 

byggerier (broer, hospitaler, amtsgymnasier, mm.) der skaber et svingende og 

mindre forudsigeligt behov. Hvor vidt disse forhold egentligt påvirker forudsætningen 

om stabile og forudsigelige markedsbehov er svært at sige, uden nærmere 

undersøgelser. 

Der er en fri konkurrence, der betyder at ineffektive arbejdsdelinger og ineffektive 

produktionsmetoder løbende udkonkurreres. 

Konkurrencesituationen i byggebranchen debatteres tilsyneladende ofte. Hvor vidt 

aftaler og faglige opdelinger indebærer strukturelle barrierer kan der ikke gives noget 

svar på i denne rapport. 

Kunderne vil hellere have billige standardiserede slutprodukter (configure-to-order, 

modify-to-order), end specialtilpassede og dyrere produkter (engineer-to-order, 

develop-to-order) eller helt standardiserede produkter (select-to-order). 

Byggerier er som regel at karakterisere som unikke enkeltstyksproduktioner frem for 

typificerede serieproduktioner til en lav pris. Dette kan skyldes, at kunderne ikke er 

villige til at give afkald på unikke arkitektoniske udtryk, til fordel for en lavere 

købspris. Omvendt er der mange licitationer hvor netop prisen er en meget væsentlig 

parameter, hvilket peger på, at der burde være en markedsmæssig accept af 

standardiserede løsninger. 

35 



3.1.3 Stor omsætning af tilbud eller ordrer 

Prædefineret produktvarians er, som beskrevet, en teknisk forudsætning for at 

kunne lave konfigureringssystemer. Som økonomisk forudsætning gælder, at 

specfikationsaktiviteterne skal gentages i en høj hyppighed, således at 

kapitalinvesteringer kan tjenes hjem gennem besparelser på driften. 

Det økonomiske rationale er ganske parallelt med en hvilken som helst anden 

investering i automatisering af produktion. Som illustreret i Figur 16 kan der ved en 

investering i produktionsudstyr opnås en reduktion af variable omkostninger. For 

alternative produktionssystemer kan der således optegnes alternative kurver for de 

totale produktionsomkostninger for en given omsætning. Ved at estimere den 

fremtidige omsætning kan man herved estimere hvilket produktionsapparat der giver 

den laveste totale omkostning. 

Omkostninger 

ved investering i 

automatisering 

Totale 

omkostninger 

Anvend 

manuelt 

arbejde 

Omkostninger for 

manuelt system 

Variable 

omk. 

Anvend delvis 



delvist-automatisk 

system 

Anvend fuld 



fuldautomatisk 

system 

Omsætning 

Figur 16: Totale omkostninger som funktion af omsætningsstørrelsen, for tre 

alternative produktionssystemer. 

Det økonomiske rationale er helt tilsvarende for konfigureringssystemer, omend der 

her er flere andre forhold at tage hensyn til. Et konfigureringssystem er at betragte 

som et fuldautomatisk system, der giver en række besparelser og fordele. Til 

gengæld er der tale om en stor initial investering. Derfor skal der være en betydelig 

omsætning af tilbud eller ordrer før de totale omkostninger ved et 

konfigureringssystem er lavere end ved et manuelt system (mennesker og simple 

redskaber) eller ved et delvist automatiseret system (mennesker, regneark, CAD 

mm.). 

3.1.3.1 Opfylder byggebranchen denne forudsætning? 

Brancheforeningen ”Dansk Byggeri” oplyser at medlemmerne står for ca. 7% af den 

totale danske produktion, omsætter for ca. 20 mia. kroner om året, beskæftiger 

70.000 ansatte fordelt på ca. 5800 virksomheder. Af disse er der 47 virksomheder 

der har mere end 100 ansatte (kilde: Dansk Byggeri). 

Branchen er således karakteriseret af mange små virksomheder. En lille virksomhed 

godt kan sælge ét produkt i høj hyppighed uden, at have mange ansatte eller en stor 

omsætning i kroner og øre. Derfor er det, ud fra omsætning og antal ansatte, svært 

at vurdere hvornår der er en stor gentagelsesgrad i antallet af tilbud og ordrer. 



36

Imidlertid kan det observeres i den øvrige industri, at der som regel mindst er 5-10 

funktionærer inden konfigureringssystemer kommer på tale, -ofte væsentligt flere 

(forfatterens skøn). 

For de virksomheder der har deltaget i PKB-projektet har der, stort set uden 

undtagelse, været tale om relativt små virksomheder. Dette har betydet visse 

udfordringer mht. virksomhedernes muligheder for at fritage ressourcepersoner fra 

den daglige drift til udviklingsarbejdet. 

• Dalton Betonelementer (der er en af branchens store virksomheder), har med 

ca. 40 funktionærer set en tydelig mulighed i konfigureringssystemer. Her er 

der opbygget en række prototyper, der sandsynliggør at der kan 

gennemføres et fuldskalaprojekt. 

• Gemina Termix har med ca. 50-60 ansatte ligget i gruppen af mindre 

virksomheder. Her har mangel på medarbejderes projekttid, samt det at 

virksomheden blev opkøbt af Danfoss, betydet en forsinket opstart af 

konfigureringsprojektet. Grundet et veldokumenteret og standardiseret 

produktprogram har det alligevel været muligt at lave en prototype. 

3.1.4 Automatiseringsteknologi 

Opbygning af konfigureringssystemer er i dag blevet væsentligt nemmere end for ti 

år siden. Dette skyldes bl.a. at der i dag findes en stor gruppe af 

softwareleverandører, der leverer standardiseret udviklingssoftware. Dette gør det 

muligt at opbygge konfigureringssystemer med en relativt lille anvendelse af egentlig 

programmering. Fremfor programmering indtastes produktdata, regler og 

beregninger i brugervenlige udviklingsmiljøer. 

Eksempler på disse er Cincom KnowledgeBuilder, SSA Global Modeler/Configurator, 

Oracle Modeler/Configurator etc. 

3.1.4.1 Specielle forhold i byggebranchen 

En stor del af konfigureringssystemerne fokuser på configure-to-order segmentet, 

hvor en ny produktvariant kan beskrives ved en stykliste alene. Dette betyder at et 

tekstbaseret output er tilstrækkeligt, f.eks. en liste af varenumre. De 

konfigureringssystemer, der i dag eksisterer i større industrivirksomheder (f.eks. 

Cincom KnowledgeBuilder hos APC eller SSA-Global hos F.L.Smidth etc.) håndterer 

således logik og tekstbaseret output, men ikke geometriske relationer og et grafisk 

output. 

Betragtes engineer-to-order segmentet findes en række IT-systemer, der kan 

betegnes som modne. Det gælder f.eks. for CAD-systemerne, som kan bruges til at 

understøtte arbejdsprocesser, der involverer fremstilling af tegninger og digitale 3Dmodeller 

mm. 

For konfigurering i byggebranchen er udfordringen, at der, som omtalt tidligere, ofte 

ikke er tale om blot configure-ro-order, men også om modify-to-order og engineerto-order. 

Dette betyder, at der er behov for håndtering af geometri og udarbejdelse 

af tegninger. Kombineres dette med et krav om håndtering af logik og udarbejdelse 

af styklister begrænses listen af modne standardiserede udviklingsmiljøer 

betragteligt. 

Som en del af PKB-projektet er der udarbejdet en analyse af softwaresystemer til 

visuel konfigurering. Der er opstillet en liste med beskrivelsespunkter, der 

37 



karakteriserer softwaresystemerne og deres leverandører, hvorudfra de enkelte 

systemer kommenteres. Gennem analysearbejdet blev eksisterende 

strandardsoftware opdelt i nogle overordnede grupper (som illustreret i Figur 17). 

Høj 

Omfang af 

videnmodellering 

Lav 

A: Standardsoftware B: Branche-dedikeret 

standardsoftware 

A1: 

Cincom 

Oracle 

SSA 

etc. 

A3: 

VirtuBuild 

Intent 

IPC 

etc. 

A2: 

AutoCAD 

UGII 

Inventor 

etc. 

Lav 

Høj 

Omfang af grafikmodellering 

Omfang af 

videnmodellering 



B3: 

AcadWand 

Impact 

FurnishPro 

etc. 

B2: 

Architectural 

Desktop 

etc. 

Omfang af grafikmodellering 

Figur 17: klassificering af standardsoftware ud fra de tre beskrivelsespunkter: 

omfang af videnmodellering, omfang af grafikmodellering og om hvor vidt der er 

tale om branchededikeret software [Hansen&Hvam, 2004b]. 

Analysen viste at der ikke findes et bredt udvalg af standardsoftware, der 

understøtter problemstillingen med at håndtere både logik og geometriske relationer, 

og udarbejdelsen af både styklister og tegninger. De systemer der findes er endnu 

relativt nye og har alle deres mangler. På den anden side er det p.t. det bedste 

grundlag man har at støtte sig til hvis udviklingen skal baseres på standardsystemer. 

Nogle eksempler på systemer fra denne gruppe er: 

• Engineering Intent (forhandles i DK af Factotech) 

• VirtuBUILD (forhandles og udvikles i DK af 3Dfacto) 

• KnowledgeFusion (forhandles i DK af Unigraphics) 

• Inventor Product Configurator (forhandles og udvikles i DK af Betechdata) 

Konklusionen er: Der findes standardsoftware, der kan anvendes til at understøtte 

konfigureringsproblematikken i byggebranchen. Imidlertid er der ofte behov for både 

geometrihåndtering og logikhåndtering, hvilket reducerer udbuddet af 

standardsoftware betragteligt. Det software der findes i dette segment er endnu 

relativt umodent (sammenlignet med modne konfigureringssystemer og modne CADsystemer). 

Der vil sandsynligvis gå 3-5 år før der er bredt udvalg af 

indlæringsnemme standardsystemer i dette segment (forfatterens vurdering). 

3.1.5 Geometri-tilpasning i variantskabelsen og krav om tegninger 

Et konfigureringssystem vil af mange betragtes som et system, der konfigurerer 

prædefinerede ”byggeklodser” og således understøtter ”configure-to-order” 

processer. Udarbejdelse af varianter på baggrund af prædefinerede varenumre, har 

den store fordel, at det primære output fra et konfigureringssystem kan begrænses 

til primært en stykliste (og eventuelt sekundært en samlingstegning, operationsforløb 

mm.). Da varenumrene er kendte er det typisk muligt, at give et tilbud og 

gennemføre produktionen på baggrund af det ”simple” output: en stykliste (se 

eksempel i Figur 18). 

Høj 

Lav 

B1: 

? 

Lav 

Høj 

38

Figur 18: Typisk stykliste-output. Data genereret i Cincom og fremvist i HTML i en 

browser (fra APC, 2001). 

Som beskrevet ovenfor er der ofte tale om ”engineer-to-order” og ”modify-to-order” i 

byggebranchen. I disse tilfælde er det pr. definition ikke tilstrækkeligt, at specificere 

nye produktvarianter med en stykliste. 

Her skabes der nye ”byggeklodser” (komponenter og moduler) i kundebehandlingen, 

f.eks. en ny udformning af rør, nye geometrier for vindueslister, nye udformninger af 

armeringsjern til betonelementer etc. I disse tilfælde bliver specificering af de nye 

geometrier nødvendige. Derfor skal der skabes en ny gruppe specifikationer, nemlig 

detailtegninger af komponenter, samt samlingstegninger (se eksempel i Figur 19). 

Hos Dalton Betonelementer er tegninger en forudsætning for, at kunne beskrive 

varianter af betonelementer, både hvad angår trapper og vægelementer. For 

vægelementer skal der udarbejdes tegninger af den ydre geometri, snittegninger af 

detaljer samt ”mini”-tegninger af klippet og bukket armeringsjern (se eksempel i 

Figur 19). 

Dette forhold betyder at specifikationsopgaven er mere kompleks, hvorfor det også 

bliver mere komplekst, at opbygge et konfigureringssystem til understøttelse heraf. 

Denne problemstilling er således en eksemplificering af konceptet fra Figur 14 og 

Figur 15 om OSDL: Når ”det grå område” (opgaven, der ligger i at udarbejde 

specifikationer i kundebehandlingen) bliver større (flere typer output-specifikationer, 

f.eks. flere tegninger) bliver det også mere vanskeligt at lave et 

konfigureringssystem, der automatisk udarbejder outputtet. 

39 

Item Description 

Area name: Area 1 

QTY 

FM35-50 NetworkAIR FM Series 35-50 KW 1 

FM35-50 COMMON PARTS FM35-50 COMMON PARTS 1 

0M-74281 Sheet Metal Cabinet Common 35-50kW 1 

0M-74282 Refrigeration Common Parts 1 

0M-74202 Electrical Common Parts 20-50kW 1 

FM35-50SHEETMETAL FM35-50 SHEET METAL 1 

0M-74284 Sheet Metal Parts Up Discharge 1 

FM35-40 ELECTRICAL FM35-40 ELECTRICAL 1 

0M-74376 Elect panel FM40 208/230 Ht Hu 1 

FM35-50 COILS FM35-50 COILS 1 

0M-74298 DX & Econ/MultiCool Coil Assembly Up Discharge 40kW 1 

FM35-50 PANEL KITS FM35-50 PANEL KITS 1 

0M-74315 Panel Kit, Up Discharge Expansion 35-50kW BLK 1 

FM35-50 BLOWER FM35-50 BLOWER 1 

0M-74318 Blower Assembly 35-50kW 1 

FM35-50 COMPRESSORS FM35-50 COMPRESSORS 1 

0M-74320 Compressor 208/230 Voltage Parts 60Hz 40kW 1 

FM20-50 OPTIONAL FM20-50 OPTIONAL 1 

0M-74244 Detector, Water Cable 2 

0M-74243 Detector, Water Spot 1 

0M-74242 Detector, Smoke 1 

FM35-50 LIQUID LINE ASSEMBLY FM35-50 LIQUID LINE ASSEMBLY 1 

0M-1800 Liquid Line Assembly 7/8" Rec In (Water/Glycol) 1 

FM35-50 DISCHARGE LINE ASSY FM35-50 DISCHARGE LINE ASSEMBLY 1 

0M-1716 Discharge Line Assembly 1-1/8" (Water/Glycol) 35-40kW 1 

FM35-50 COIL PACK PIPING FM35-50 COIL PACK REFRIGERANT PIPING 1 

0M-74394 Piping DX Only Coil Assembly Up Discharge 40kW 1 

FM35-50 REHEAT FM35-50 REHEAT 1 

0M-74338 Electric Reheat 200-240 Volts 1 

FM20-50 HUMIDIFICATION FM20-50 HUMIDIFICATION 1 

0M-75000 FM35 CONDENSER 95 230/1/60 SINGLE 1 

FM35-50 HEAT EXCHANGER FM35-50 HEAT EXCHANGER 1 



Figur 19: Udsnit af produktionstegning med todelt stykliste og minitegninger i 

styklisten (fra Dalton Betonelementer, 2004). 

Tilsyneladende er der i byggebranchen en tendens til ”engineer-to-order” og 

”modify-to-order” frem for ”configure-to-order”. Dette betyder at der alt andet lige 

må påberegnes en ekstra grad af kompleksitet ved opbygningen af 

konfigureringssystemer. Alternativt skal der foretages en standardisering af 

produkterne, således at man bevæger sig i retningen fra ”engineer-to-order” mod 

”configure-to-order”. 

3.1.6 Afrunding af de generelle erfaringer 

De generelle erfaringer påpeger således nogle helt fundamentale forhold. 

I de tilfælde hvor der mangler en prædefineret varians kan det skyldes, at kunderne 

simpelt hen ikke ønsker det samt, at markedet kan være for svære at forudsige. En 

anden mulig forklaring er strukturelle bindinger branchen. 

Hvis der ikke er en prædefineret produktvarians kan variantspecifikationsopgaven 

være kompleks og omfatte udarbejdelsen af kundetilpassede komponentgeometrier 

og samlingsstrukturer. Dette medfører skrappere krav til konfigureringssystemerne, 

der nu skal være i stand til at håndtere geometri. 

De skrappere krav til konfigureringssystemerne gør det vanskeligere at opbygge 

systemerne, primært i de tilfælde hvor der skal være en håndtering af geometri og 

udarbejdelse af tegninger. 



40

Branchens mange små virksomheder har muligvis ikke et tilstrækkeligt volumen til, 

at det vil være lønsomt at investere i konfigureringssystemer. 

Erfaringerne fra PKB-projektet peger dog også på, at der er en række virksomheder, 

der forsøger at udvikle sig for, at kunne opfylde de forudsætninger der gælder for 

industrialisering. 

Mange af de implicerede virksomheder arbejder både med, at forbedre 

forudsætningerne for konfigureringssystemer og med at opbygge 

konfigureringssystemer. Arbejdet med at opbygge konfigureringssystemer har bragt 

en masse manglende forudsætninger frem i lyset, hvilket burde medføre at disse 

diskuteres og behandles ude i virksomhederne. 

41 



3.2 Erfaring med selve fremgangsmåden 

Den i kapitel 2 skitserede fremgangsmåde er blevet anvendt i tre virksomheder, 

gennem flere prototype forløb. Erfaringerne hermed er beskrevet i dette kapitel. 

3.2.1 Fremgangsmåden og nye forudsætninger 

Baseret på erfaringerne i PKB-projektet kan det siges, at fremgangsmåden i store 

træk er hensigtsmæssig. På de fleste områder er der ikke de store forskelle 

sammenlignet med projekter udført i maskinindustrien. 

Forskellene og udfordringerne kommer, ikke uventet, på de områder hvor 

forudsætningerne er anderledes. I forlængelse af forrige afsnit kan der derfor 

påpeges en række områder med nye udfordringer grundet specielle eller manglende 

forudsætninger: 

• Projekt-”scoping” og iterativ anvendelse af fremgangsmåden bliver vigtigere i 

grad med stigende usikkerhed omkring projektforløbet. 

• Forretningsprocesanalysen bliver mere vanskelig, når der er en større 

kompleksitet i samarbejdsrelationerne i værdikæden. 

• ”Cost-benefit-risk”-analyser bliver mere vanskelige, når opgaven generelt 

bliver mere kompleks. 

• Produktanalysen og objektorienteret analyse og design bliver mere vanskelig 

når der er en større produktkompleksitet. 

• Des mere man bevæger sig væk fra den traditionelle problemstilling, fra 

configure-to-order mod engineer-to-order, des mere kompleks bliver 

opgaven, og des flere problemer løber man ind i. Der bliver f.eks. behov for 

at håndtere geometri og generere tegninger. 

• Ved et behov for udarbejdelse af tegninger og håndtering af geometriske 

relationer er der væsentlig mere viden der skal dokumenteres, hvilket 

bevirker at man ”presser” de eksisterende modelleringsteknikker 

(produktvariantmaster og CRC-kort) til det yderste. 

• Udvælgelsen af software bliver mere vanskelig, når der er flere krav og 

udvalget bliver mindre. 

Disse erfaringer behandles i det følgende. Først diskuteres projekt-”scoping”. 

Herefter diskuteres erfaringerne ud fra hver fase af fremgangsmåden. 

3.2.2 Projekt-”scoping” og iterationer 

Princippet om iterative udviklingsforløb understøttes klart af de erfaringer der er gjort 

i PKB projektet. Erfaringerne er, at det har været meget komplekst, at overskue hele 

fuldskalaprojekter, teknologien, organisering, potentielle gevinster, omkostninger og 

ricisi. For at gøre projektforløbene mere overskuelige har det derfor været 

nødvendigt, at ”scope” projekterne i mindre bidder. Denne erkendelse er kommet 

hen ad vejen for de implicerede parter. Enkelte af de deltagende virksomheder har 

faktisk været for ambitiøse og har ikke ønsket at starte med mindre omfattende 

konfigureringssystemer. Først senere er det erkendt at man ”skal kravle før man kan 

gå”. 

De helt konkrete erfaringer er således: 



42

43 

• Man skal passe på med at være alt for ambitiøs i det første projektforløb. Det 

er godt at have en ambitiøs vision, men det er uhensigtsmæssigt at forsøge 

at nå det hele i første omgang. 

• Projekter risikerer at trække i langdrag, hvis der ikke ”scopes” ned til mindre 

bidder. Man risikerer at der går for lang tid inden der opnås resultater og at 

folk mister tilliden til projektet. 

• Skær projektet ned i mindre bidder, f.eks.: Fokuser på én produktfamilie 

fremfor flere, vælg et isoleret område hvor behovet som udgangspunkt er 

størst, fravælg noget funktionalitet, start med f.eks. kun én type output, etc. 

Opdelingen i iterative projektforløb betyder, at man opdeler udgifter, gevinster og 

risici i mindre bidder. Alt andet lige vil man i de første gennemløb opleve relativt lave 

direkte gevinster. Til gengæld er sandsynligheden for at gennemføre et kort 

delprojekt langt større end for et stort. Omkostningerne er tilsvarende væsentligt 

lavere. Endelig kan erfaringerne fra det første projektforløb bruges konstruktivt til at 

styre næste gennemløb bedre. 

3.2.3 Fase 1: Procesanalyse 

Fremgangsmådens fase 1 ”procesanalyse” har været anvendt uden større problemer. 

I de udvalgte virksomheder har der været optegnet procesdiagrammer, der har 

været anvendt som udgangspunkt for en identifikation af problemer og mulige 

fokusområder. Endvidere har en identifikation af nøgletal dannet grundlag for en 

identifikation af den potentielle gevinst ved at IT-automatisere processerne. 

Fasen har, som for konfigureringsprojekter i maskinindustrien, vist sig behjælpsom 

ved identifikation af behovene for et fremtidigt konfigureringssystem, og for 

fastlæggelsen af en kravspecifikation hertil. 

Der er imidlertid et par områder, hvor der er særlige forhold. Disse er: 

• Behov for en bedre afklaring af interessenter 

• Behov for bedre cost-benefit analyser 

Disse to punkter kommenteres særskilt i det følgende. 

3.2.3.1 Interessent- og netværksanalyser 

For leverandører i byggebranchen vil de interne forretningsprocesser ofte interagere 

med eksterne interessenter. De eksterne interessenter kan befinde sig forskellige 

steder i det samlede byggeris værdikæde og samarbejde i mere eller mindre formelle 

netværk. I forbindelse med en forestående automatisering af forretningsgange bør 

virksomheden søge at forstå de gevinster, omkostninger og risici, og dermed 

incitamenter, som aktørerne i disse værdikæder og netværk står overfor. 

Eksempler på mulige problemstillinger, der kan være værd at identificere er bl.a.: 

• Komponentleverandører kan bevæge sig opad i værdikæden: Hvis der 

skabes konfigureringssystemer og digitale bygningsmodeller med 

ekspertviden, overflødiggøres dele af arkitekters, rådgivende ingeniørers og 

entreprenørers arbejde. I den ultimative situation kan man uden større 

teknisk indsigt designe en hel bygning ned til mindste detalje og udskrive 

store dele af produktionsgrundlaget automatisk. 

• Komponentleverandører kan presses på indtjening: IT-systemer muliggør en 

større grad af sammenligning af forskellige komponenter. Alternative 

løsninger kan hurtigt skabes og evalueres, hvilket skaber en større 

konkurrence og prispres mellem leverandører. 



• Større grad af industrialisering og investeringer kan tvinge leverandører til at 

samarbejde: Investeringer i maskiner og IT betyder, at der skal et større 

salgsvolumen til betale investeringerne hjem. Dette kan betyde, at 

leverandører skal se sig om efter samarbejdspartnere for at skabe et større 

volumen i omsætningen. 

• Arkitekters jobbeskrivelse kan ændres: konfigureringssystemer og digitale 

bygningsmodeller kan betyde at en del af arkitekternes tekniske 

arbejdsopgaver formindskes, og fokus flyttes mod de egentlige kreative 

opgaver. På den anden side stilles der måske krav om, at arkitekter 

overtager dele af ingeniørernes arbejde, fordi dette bliver teknisk muligt. 

Hvis komponentleverandører samarbejder med arkitekter og rådgivende om 

nye IT-systemer, er det vigtigt at kende disses incitamenter for at hjælpe 

eller modarbejde udviklingsprocessen. 

• Teknikeres jobbeskrivelse hos komponentleverandørerne kan ændres: ITsystemer 

betyder at tekniske tegnere, salgssupportører, sælgere, ingeniører, 

designere får en ændret jobbeskrivelse. Tekniske tegnere skal måske til at 

fungere mere som ingeniører, mens designere måske skal fokusere endnu 

mere på det kreative, eller omstilles til det mere tekniske, fordi en del af 

designfunktionen automatiseres. 

For at forstå de potentielle forandringer der kan, eller bør, gennemføres i 

værdikæden kan det være en idé, at identificere hvilke samarbejdende netværk en 

virksomhed indgår i og hvilke interessenter der er i netværkene. 

Resultatet af analysen skal være en identifikation af de ønsker og krav 

interessenterne har til fremtidige nye forretningsprocesser, f.eks.: 

• Hvordan kan der laves en mere effektiv arbejdsdeling? 

• Kan der med fordel laves systemleverancer? 

• Hvem vil være vindere og tabere ved en forandring af de eksisterende 

forretningsprocesser? Er der nogle funktioner, der bliver overflødige? 

Oprettes der nye funktioner? 

• Hvilke forretningsmæssige performancekrav vil der være til produktkvalitet, 

grad af kundetilpasning (engineer-to-order eller configure-to-order) 

gennemløbstider, priser, leveringssikkerhed etc.? 

• Vil der være særlige krav til formater ved udveksling af data, f.eks. krav til filformater 

ved udveksling af CAD-modeller. 

• Etc. 

For det fremtidige konfigureringssystem skal der endvidere identificeres følgende 

krav: 

• Hvilke andre systemer hos de andre interessenter skal systemet udveksle 

data med? 

• Hvilke muligheder er der for at interessenter kan gå sammen om at opbygge 

systemer? 

• Kan der med fordel vælges samme softwareplatform? 

• Hvem skal arbejde sammen om at opbygge systemet? 

• Hvem skal stå for drift og vedligeholdelse af de forskellige delsystemer? 

3.2.3.2 ”Cost-benefit-risk” vurderinger 

Den anden udfordring, der er observeret under procesanalyserne er vurderingen af 

de potentielle gevinster, omkostninger og ricisi. Disse ”return on investment” 



44

etragtninger er traditionelt vanskelige, men i byggebranchen kan de være endnu 

mere udfordrende af de årsager der er diskuteret i starten af nærværende kapitel: 

• Byggebranchen kan være mere konjunkturfølsom. 

• Produkterne er ofte mere komplekse (mere engineer-to-order end configureto-order) 

end for de mere standardiserede maskinprodukter. 

• Man har måske ikke så mange erfaringer med automatisering i almindelighed, 

og mangler hermed et erfaringsgrundlag for at diskutere automatisering af 

salgs- og ordrebehandlingsprocesser. 

• Softwareteknologien er endnu ikke moden på mange af de områder, som 

byggebranchen ønsker (håndtering af både geometri og logik). 

• Mange af de mindre virksomheder har ikke den IT-ekspertise der skal til for 

at vurdere teknologien. 

Nogle er de erfaringer der er gjort i PKB kan bruges til at opstille checklister med 

potentielle gevinster, omkostninger og risici. Dette er forsøgt i det følgende. 

Typiske 

gevinstpunkter 

Besparelse af 

direkte 

interne timer 

Besparelse af 

indirekte 

timer 

Digitale 3D 

modeller 

45 

Beskrivelse Erfaringer 

De direkte arbejdstimer dækker den tid der 

bruges til udarbejdelsen af dokumenter i 

tilbudsgivning og ordrebehandling, f.eks. 

tegninger, styklister og prisberegninger. 

De indirekte timer, dækker over den tid der 

anvendes i produktionen. Denne tid 

afhænger af kvaliteten af 

produktionsgrundlaget, samt af 

produktionsplanlægningen. Hurtigere tilgang 

til produktionsdokumenterne medfører en 

bedre planlægning og dermed en bedre 

kapacitets- og materialeudnyttelse. 

Tilsvarende kan en bedre kvalitet af 

produktionsgrundlaget betyde et lavere spild 

i produktionen. 

Digitale 3D modeller af virksomhedens 

produkter betyder at arkitekter, rådgivende 

og entreprenører kan lave mere nøjagtige 

digitale modeller af det færdige byggeri. 

Dette giver en række fordele, hvorfor man 

til en vis grad vil foretrække leverandører, 

der stiller digitale 3D modeller til rådighed. 

Her har der været en del besparelse at 

hente hos de implicerede parter, 

specielt ved udarbejdelsen af 

produktionstegninger og styklister. 

Dette punkt syntes at være et af de 

primære gevinstområder hos flere af 

de implicerede parter. 

Blandt parterne i PKB var denne 

tendens ikke så udbredt som ventet. 

Gevinster synes nemmere at estimere, fordi der ofte er tale om en besparelse af 

kendte udgifter, eller en forbedring af kendte måltal, f.eks. leveringstid. 

Omkostningerne ved konfigureringsprojekter er sværere at forudsige fordi man her 

bevæger sig ud på ukendt grund, både hvad angår den nye teknologi, men også 

hvad angår hele projektforløbet. 

Typiske 

omkostningspunkter 

Restrukturering af 

produktsortiment 


Forudsætningerne for konfigurering og 

industrialisering er at der anvendes 

relativt standardiserede produktfamilier. 

Derfor kan det være nødvendigt at 

gennemtænke produktsortimentet og 

Der var ikke fokus på dette område. 

Dog har virksomhederne generelt 

løbende beskæftiget sig hermed. 

Under dokumentationsforløbet blev 

der truffet nogle valg, der 



Indsamling og 

dokumentation af 

viden 

skabe mere standardiserede 

produktkomponenter. I realiteten er der 

tale om at flytte ”order specification 

decoupling line” i retning fra engineerto-order 

mod configure-to-order. 

Dette omfatter en beskrivelse af 

hvordan en ny produktvariant skabes: 

hvilke dele eksisterer der som 

udgangspunkt for variantskabelsen? 

Hvilke regler gælder for delenes nye 

sammensætning etc. Meget af denne 

viden eksisterer inde i hovederne på 

sælgere, teknikere og ingeniører, 

hvorfor det koster analyse-arbejde at få 

det nedfældet på papir. 

Køb af software Softwareudgifter opdeles typisk i en 

engangsbetaling og en årlig 

licensbetaling. 

Opbygning af 

konfigureringssystem 

(programmering) 

Dette omfatter oprettelsen af 

produktkomponenter, variable, regler, 

beregninger etc. inde i det valgte 

softwaresystem. Anvendelsen af 

standardsystemer betyder at der i 

mindre grad er tale om egentlig 

programmering og mere om indtastning 

og strukturering af data og viden. 

simplificerede nogle regelsæt. 

Denne opgave har som 

udgangspunkt været tidskrævende i 

de implicerede virksomheder. 

Dog har software-udfordringer 

flyttet en del af fokus fra dette 

område til systemudviklingen. 

De totale udgifter over 5 år løber 

typisk op i en halv til to millioner 

kroner, dog meget afhængigt af 

antallet af brugere. Se mere i PKB’s 

softwareanalyserapport 

[Hansen&Hvam, 2004 b]. 

Dette punkt har voldt de største 

problemer i PKB-projektet. Dette 

skyldes bl.a., at problemstillingerne 

var meget komplekse, at der ikke 

tilsyneladende ikke kunne findes det 

ønskede standardsoftware, samt at 

virksomhederne var tilbageholdende 

med at købe ekspertbistand. 

De potentielle risici er sandsynligvis blandt de største barrierer mod 

konfigureringsprojekter i byggebranchen. Disse er svære at overskue, og manglen på 

”frontløbere/fyrtårne” gør det sværere, at eftervise, at det er muligt at gennemføre 

projekter med succes. 

Typiske 

risikopunkter 

Accepterer 

kunderne 

standardiserede 

produkter? 

Omkostninger 

kan 

undervurderes 


Ved overgangen til en 

industrialiseret produktion og 

anvendelsen af 

konfigureringssystemer, vil man 

ofte være nødt til at gå på 

kompromis med den grad hvormed 

man kan tilfredsstille individuelle 

kundebehov. Hvis man begrænser 

kundernes valg for meget, i relation 

til den besparelse som kunden 

opnår, risikerer man at kunderne 

finder andre leverandører. 

Udviklingsomkostningerne kan være 

svære at estimere, både hvad angår 

tid til videnindsamling og 

programmering. Des mere der er 

tale stor kompleksitet og mere 

engineer-to-order end configure-toorder, 

des sværere bliver det at 

estimere automatiseringsomkostningerne. 

Dette punkt var en væsentlig risikoparameter 

for nogle af virksomhederne i PKB-projektet. 

Der er ikke lavet sammenlignende præ- og 

efterkalkulationer. Erfaringen var dog at 

virksomhederne har meget svært med at 

vurdere korrektheden af det estimerede 

omkostningsniveau. Man er tilsyneladende 

ofte nødt til at stole på sit instinkt og mere 

strategiske vurderinger om hvordan 

forretningen ønskes at være i fremtiden. En 

løsning kan være at lave scenarier og 

følsomhedsanalyser. 

Projektfolk kan Dette punkt gælder for alle Dette punkt var meget relevant, specielt i de 



46

forlade projektet projekter. Hvis en eller flere af de 

centrale personer forlader projektet, 

kan det bremse udviklingsforløbet 

betragteligt. 

Man kan vælge 

den forkerte 

softwareplatform 

47 

Ved valget af software binder man 

sig til de muligheder og 

begrænsninger, der er i et konkret 

stykke software. I yderste 

konsekvens kan man vælge en 

softwareplatform, der ikke gør det 

muligt at gennemføre projektet på 

en rentabel måde. 

mindre PKB-involverede virksomheder. Små 

virksomheder er mere afhængige af 

enkeltpersoner. 

Korte iterative projektforløb er en væsentlig 

måde at reducere denne risiko på. En anden 

løsning er at købe ekspertise udefra, fra 

større softwareleverandører eller 

konsulenthuse. Denne løsning blev 

tilsyneladende foretrukket i flere tilfælde, 

men det er vigtigt at gøre sig klart at der her 

opstår andre risici, f.eks. afhængighed af 

dyre eksterne konsulenter. 

Virksomhederne havde generelt meget svært 

ved at vælge en softwareplatform, primært 

fordi det tilsyneladende næsten er umuligt at 

overskue mulighederne og begrænsningerne 

i de forskellige systemer. Indtil der er flere 

vellykkede projekter at sammenligne sig med 

må man tage en chance i valget af software. 

Generelt er procesanalysen blevet anvendt meget lig tidligere anvendelser i tidligere 

konfigureringsprojekter. Kun omkring netværk- og interessentanalyserne og costbenefit-analyserne 

synes der at være nogle særlige udfordringer. 

3.2.4 Fase 2: Produktanalyse 

Fremgangsmådens fase 2 har i store træk vist sin anvendelighed, også for 

konfigureringsprojekter i byggebranchen. Gennem optegning af 

produktvariantmastere er der opnået overblik over den konkrete produktviden. Dette 

er gjort både for betontrapper, betonelementer, betonhaller, blandingsbatterier, 

badekabiner mm. (se eksempel i Figur 20). 



Figur 20: Udsnit af en produktvariantmaster for betonkonstruktioner (fra Dalton 

Betonelementer). 

Erfaringerne fra de forskellige projekter er at produktvariantmastere er gode til at 

starte analysen af produktviden, og gode at anvende som udgangspunkt for den 

mere detaljerede dokumentationsfase (fase 3-4: objektorienteret analyse og design). 



48

3.2.5 Fase 3-4: Objektorienteret Analyse og Design 

I store træk er erfaringerne med denne fase, at den er nyttig og anvendelig, også i 

bygge-relaterede konfigureringsprojekter. En detaljeret dokumentation af de 

anvendte objekter betyder, at det bliver nemmere, at implementere produktviden i 

det udvalgte konfigureringssoftware. 

Som beskrevet tidligere er der imidlertid nogle forhold der i denne fase begynder at 

give udfordringer. Disse er primært: 

• En større grad af ”engineer-to-order” fremfor ”configure-to-order” betyder at 

variantskabelsen er mere kompleks. 

• Et behov for at tage hensyn til geometri i konfigureringsprocessen, herunder 

håndtering af parametriske 3D objekter og eventuelt generering af relaterede 

2D tegninger. 

Denne problemstilling er behandlet gennem flere konfigureringsprojekter i relation til 

PKB-projektet. Erfaringerne er bl.a. dokumenteret i en række DTUeksamensprojekter 

[Christensen, 2004], [Haug&Christiansen, 2004], samt [Nielsen, 

2004]. De fire væsentligste erfaringer og udvidelser til den eksisterende 

fremgangsmåde er: 

• For at få et forbedret overblik over de geometriobjekter der skal modelleres 

kan man anvende et ekstra trin til fremgangsmåden (fase 2B) samt en 

geometri-variantmaster. Hermed skabes der et bedre udgangspunkt for den 

detaljerede objektorienterede model og implementering [Haug&Christiansen, 

2004]. 

• CRC-kortene tilpasses behovet for at modellere viden om geometriske 

objekter, der er definerede i form af CAD baserede part-filer. 

• Der er et behov for et IT-baseret dokumentationssystem, hvor de enkelte 

CRC-kort er tilgængelige via et Intranet, og hvor der er en form for 

versionsstyring og adgangskontrol. 

• Valget af hensigtsmæssigt standardsoftware synes vanskeligt. Derfor er der 

tilføjet en række beskrivelsespunkter til fremgangsmåden, og der er lavet en 

særskilt analyse af softwaremarkedet [Hansen&Hvam, 2004b] 

Disse 4 erfaringer diskuteres i det følgende. 

3.2.5.1 Fase 2B: Geometrivariantmaster og modellering af 3D-objekter 

Forud for den helt detaljerede modellering på CRC-kortene kan der med fordel 

indskydes en fase 2B, der fokuserer på at identificere hvilke produktdele, der skal 

modelleres som digitale 3D modeller. Målet er at fastlægge den mest 

hensigtsmæssige bruttoliste med de grundlæggende 3D objekter. 

Udfordringen kan illustreres ved et eksempel: Rørføringer kan på det laveste niveau 

bestå af lige cylinderstykker med variabel diameter og længde, buede cylinderstykker 

med variabel diameter, bukkeradius og længde, overgangsstykker der gør det muligt 

at samle to rør med forskellige diametre etc. Rørføringerne kan imidlertid også 

modelleres på et lidt højere niveau, bestående af undersamlinger, f.eks. rørsektion 

A,B,C, der alle har visse parametre, f.eks. varierende længder. For at sikre et 

optimalt genbrug af 3D CAD-modeller og minimere brugen af redundante modeller, 

må en undersamling, der består af dele, der bruges i andre undersamlinger, opdeles 

for at de anvendte dele ikke tegnes igen og igen i de forskellige undersamlinger. 

49 



Modsat kan det tænkes at der er to eller tre dele, der altid bruges i sammenhæng. I 

så fald vil det være nemmere at håndtere disse dele som en undersamling, frem for 

som enkeltstående dele. 

Fase 2B omfatter således de centrale punkter identificering og navngivning af 

geometriobjekter, strukturering af geometriobjekter samt opbygning af 3D modeller. 

Optegningen af en geometri-variantmaster understøtter således identificering og 

strukturering af 3D CAD modeller. Et herpå ses i Figur 21. 

Figur 21: Del af geometrivariantmaster for et sandwichelement 

[Haug&Christiansen, 2004]. 



50

3D CAD modellerne modelleres herefter løbende i overgangen til den detaljerede 

objektorienterede analyse og design fase. Resultatet vil være en struktureret samling 

af 3D CAD-modeller i stil med den, der vises på Figur 22. 

51 



Figur 22: CAD-modeller struktureret i en lagringsstruktur, på baggrund af den 

geomtriske variantmaster [Haug&Christiansen, 2004]. 



52

3.2.5.2 Detaljerede objektbeskrivelser (CRC-kort) og topologiske data 

Den centrale del af fasen objektorienteret analyse og design er dokumentationen af 

detailviden på CRC-kort (class-responsibility-collaborations). Disse indeholder den 

detaljerede dokumentation af variable, regler, beregninger, geometri mm. for de 

definerede produktdele. 

Klasse navn: 

Bib. Placering: Forfatter: 

LodretArmeringsRippe 

Ansvar ( Overordnet beskrivelse af klassen ): 

Model C. S. Christensen 

Laver en lodret rippe til bagplade armeringen Er lavet af 4 stænger 1 i hvert hjørne og optil 4 ”løse” 

stænger der er placeret inden i bøjler. 

Nedarvet fra ”Egne” klasser: 

Evt. tegning: 

Nedarver 

klasser: 

BooleanSolid 

BlockMixin 

fra standard Intent 

Rippen ligger Her ned men bund er mod højre side af papiret, og der er 2 løse stænger 

Variabler Type 

AntalSekunndaereStænger Integer (Default 0) 

Boejle String (Default ”F60”) 

Hoejde Integer default 2000 

PrimaerStangDiameter Integer (Default 16) 

SekundaerStangDiameter Integer (Default 10) 

Funktioner Værdi Type 

BøjleAfstand 15*StangDiameter Integer 

Bredde Værdi hentes nede i subKlassen Bøjler hvor 

den defineres afhængig af den valgte bøjletype 

Integer 

Dybde Værdi hentes nede i subKlassen Bøjler hvor 

den defineres afhængig af den valgte bøjletype 

Integer 

TykkesteDiameter Den værdi af Primær – eller sekundær 

stangdiameter der er tykkest *3 dog mindst 50. 

Integer 

Height BagpladeHoejde Integer 

Length ElementTykkelse-BagpladeTykkelse-70 Integer 

Width ElementBredde Integer 

Klasser Værdi 

Armeringsstang (Armeringsstang) 

Lodrette stænger der ligger i hjørnerne på 

4 instanser af hver 1 stang 

bøjlerne 

Bøjler (RippeBøjle) 

De bøjler der holder stænger sammen Afstand 

Det antal instanser af denne klasse der skal til for mellem bøjler diff. Bøjleafstand. 1 bøjle sidder ½ 

at der er bøjler nok 

afstand oppe. 

SekundæreArmeringsstang (Armeringsstang) Evt. sekundære stænger placeret langs lange sider 

Mellem 0 og 4 instanser af hver 1 stang 

af bøjler med en afstand diff. I TykkesteDiameter 

Afhængig af det valgte antal. 

fra nærmeste Primære stang. 

Figur 23: CRC-kort anvendt hos Dalton Betonelementer [Christensen, 2004] 

Anvendelsen af CRC-kort er forløbet uden større principielle problemer. Den 

væsentligste forskel er behovet for at kunne beskrive information om geometriers 

overflader, kanter, indsætningspunkter, parametriske relationer etc. Dette har 

53 



medført at der i forskellige projekter er foretaget forskellige tilpasninger af CRCkortets 

grundstruktur, f.eks. fra den første prototype, der blev lavet hos Dalton 

(Figur 23). 

Ved modellering af geometri på CRC-kort blev det fundet hensigtsmæssigt, at 

anvende referencer til eksterne 3D CAD-modeller. Altså at man fra CRC-kortene 

refererer til et katalog med alle de nødvendige CAD-filer. 

Denne problemstilling rejser problematikken der diskuteres i næste sektion, nemlig 

behovet for et IT-baseret dokumentationssystem, hvor en bruger kan klikke på en 

reference til en CAD-model og få den vist frem. Herved vil man også kunne undgå at 

de samme data beskrives to steder. 

3.2.5.3 Behov for et IT-baseret dokumentationssystem 

Anvendelsen af CRC-kort har i flere tilfælde givet anledning til anvendelse af ITbaserede 

dokumentationssystemer. Sådanne anvendes bl.a. APC og GEA-Niro, hvor 

Lotus Notes anvendes som platform for at dele CRC-kort på virksomhederne intranet. 

I relation til PKB-projektet var der et udpræget behov for at anvende IT-baserede 

dokumentationssystemer. Disse blev dog ikke opbygget, da projekterne endnu ikke 

var fuldskala-projekter, og fordi der ikke findes standardiserede 

dokumentationssystemer. Anvendelsen af et sådant system ville sandsynligvis 

understøtte en forbedret dokumentation og videnindsamlingsproces, bl.a. fordi: 

• Det vil være lettere for alle at tilgå og vedligeholde information. Dermed er 

en strukturel barriere elimineret. 

• Man vil kunne overvåge og styre, at de forskellige personer lægger den 

krævede information ind i dokumentationssystemet. 

• Man vil eliminere en del dataredundans, ved at kunne lave elektroniske links 

og referencer. Dette vil specielt være en stor styrke ved dokumentation af 

geometri, hvor topologiske data bør ligge i selve CAD-modellerne. 

3.2.5.4 Valg af software 

I forbindelse med de konfigureringsprojekter, der er udført i relation til nærværende 

projekt (PKB) er det erfaret, at valget af software ikke er let. 

Som beskrevet i foregående afsnit skyldes en del af udfordringerne, at der 

tilsyneladende ikke findes et bredt udvalg af modent software, der håndterer 

modellering af både geometri og viden. 

For at hjælpe med at skabe klarhed over softwaremarkedet er der lavet en særskilt 

rapport med beskrivelsespunkter og en klassificering af software [Hansen&Hvam, 

2004b]. 

En række softwaresystemer er klassificeret (gengivet i Figur 17) og karakteriseret ud 

fra listen, der her er gengivet i Tabel 1. 



54

Tabel 1: Analysepunkter for valg af software 

Gruppe Analysepunkt 

Anvendelsesfunktionalitet 

(input/output) 


(hvordan støttes 

frembringelse af 

output) 


(styring) 

Opbygning/ 

modellering og 

programmering 

55 

• Output 

• Grafisk repræsentation (af output) 

• Grafisk interaktion (ved input) 

• Kvalitet af grafik 

• Data- og filformater (af output) 

• Ekspertfunktionalitet/Intelligens 

• Dynamisk konfigurering (inferenskerne) 

• Dynamisk geometrirendering 

• Runtime svartider (performance) 

• Skalerbar grafikdetaljering 

• Client-server funktionalitet (browserbaseret?) 

• Kollisionskontrol 

• Driftsstabilitet 

• Administration af brugere og produktdata 

• Modellering af viden 

• Modellering af geometri 

• Parametriske relationer mellem dimensioner 

• Geometri-kobling mellem objekter 

• Submodeller (objektorienteret modellering) 

• Medfølgende biblioteker med submodeller 

• Programmeringssprog / indlæringslethed 

• Programmerings-effektivitet (modelleringshastighed) 

• Versionsstyring af modeller 

• Versionskompatibilitet (opgraderingslethed) 

Leverandørforhold • Support og service 

• Referencer 

• Branchekendskab 

• Leverandørstabilitet og troværdighed 

• Fremtidig teknologiudvikling 

• Priser for licenser og support 

Der blev ikke fundet systemer, der i tilfredsstillende grad opfyldte alle punkter på 

listen. Man er således p.t. nødt til at prioritere sine behov og finde det system, der 

tilfredsstiller flest af de væsentligste punkter. 

For nærmere diskussion herom henvises til softwarerapporten [Hansen&Hvam, 

2004b]. 

3.2.6 Fase 5: Programmering 

Der er programmeret en række forskellige prototyper i forbindelse med PKBprojektet: 



• Betonhal i Inventor Product Configurator. 

• Betonelement i Engineering Intent (se Figur 24). 

• Sandwich-betonelement i Engineering Intent. 

• Betonhal i Engineering Intent. 

• Betontrappe i Inventor. 

• Badeværelse i VirtuBUILD. 

• Badeværelse i GDL. 

• Skydeport i GDL. 

Figur 24: Skærmbillede fra en prototype udviklet hos Dalton Betonelementer i 

Engineering Intent. 

Erfaringerne har vist, som nævnt flere gange, at der ikke eksisterer et 

standardværktøj, hvor man på en nem måde kan opbygge et konfigureringssystem 

indeholdende 3D geometri og 2D tegninger. Alle systemerne har en række 

begrænsninger, både hvad angår funktionalitet og hvad angår brugervenlighed. 

En væsentlig erfaring er den beslutning virksomhederne må træffe mht. ”make or 

buy”: 

• Hvis man selv vælger at opbygge/programmere systemerne er der en lang 

indlæringskurve. Dette betyder at der skal investeres i oplæring af 

medarbejdere. 

• Hvis man køber programmeringen udefra kommer man meget hurtigere 

frem til et synligt resultat. Til gengæld bliver man afhængig af eksterne 

partnere ved fortsat vedligehold og videreudvikling. 

Erfaringerne er, at der i PKB-projektet blev brugt (for) meget tid på indlæring af nye 

systemer og det ”at prøve sig frem”. Dette skyldtes til dels en generel interesse for 

at afprøve forskellige systemer (fra Universiteterne), dels en manglende vilje til at 

købe professionel hjælp (fra virksomhederne). Set i bakspejlet må det konstateres, 



56

at udviklingsforløbene ville have været væsentligt hurtigere, hvis virksomhederne i 

højere grad havde købt professionel rådgivning fra softwareleverandørerne. 

3.2.7 Fase 6: Implementering 

Formålet med PKB-projektet har været, at opbygge konfigureringssystemer på 

prototypeniveau og udbrede viden om produktkonfigurering i byggebranchen. Det 

har ikke været målet at implementere systemer i driften. 

Prototypeprojekterne har betydet at der p.t. er fuldskalaprojekter igang i to af PKBvirksomhederne. 

Der er derfor ikke erfaringer med egentlig indkøring af færdige systemer i driften. 

Det kan dog konstateres at begge virksomheder selv ønsker at stå for drift og 

vedligehold af konfigureringssystemet. Derfor satses på en aktiv involvering i 

systemopbygningen, fremfor en ensidig satsning på eksterne konsulenter. 

3.2.8 Afslutning på erfaringer med fremgangsmåden 

Gennem nærværende kapitel er erfaringerne med fremgangsmåden beskrevet og 

diskuteret. 

I store træk peger erfaringerne på at fremgangsmåden er anvendelig, også i 

byggebranchen og projekter med et større indhold af geometri-aspekter. 

Fremgangsmåden bidrager til et mere struktureret udviklingsforløb, ligesom der 

gennem de opstillede værktøjer skabes en hjælp til de enkelte faser. 

Der er påpeget nogle områder hvor fremgangsmåden kan forbedres, bl.a. ved: 

• Analyse af værdikæden og interessenter 

• Cost-benefit-analyser 

• Geometri-aspekter 

• Udvælgelse af software 

Hertil er der taget nogle tiltag i retning af en forbedring, bl.a. dokumenteret gennem 

nærværende rapport og PKB-softwarerapporten [Hansen&Hvam, 2004b] samt 

eksamensprojekterne fra DTU [Haug&Christiansen, 2004], [Nielsen, 2004] og 

[Christensen, 2004]. 

57 



4 Konklusion og perspektivering 

PKB projektet har haft som det primære mål, at udbrede viden omkring opbygning af 

konfigureringssystemer og gennemføre prototypeprojekter i udvalgte virksomheder. 

Sekundært har målsætningen været, at anvise en fremgangsmåde for opbygning af 

konfigureringssystemer. 

Udgangspunktet her for har været en eksisterende fremgangsmåde og tilhørende 

modelleringsteknikker. Disse er beskrevet kort i denne rapports kapitel 2. Det 

eksisterende grundlag er derefter blevet brugt og udvidet gennem praktiske 

prototypeprojekter. 

4.1 Konklusion 

PÅ baggrund af projektforløbet kan der opridses en række konklusioner: 

1. Det viste det sig at fremgangsmåden, også i byggebranchen, er anvendelig 

og at den understøtter en struktureret udvikling af konfigureringsprojekter. 

2. Det viste sig gennem projektforløbet, at forudsætningerne for 

konfigureringssystemer er mindst lige så centrale for succes som 

fremgangsmåde og projektstyring. Des større forretningsmæssige rationale, 

der er for konfigureringssystemer, des større er sandsynligheden for succes, - 

uanset fremgangsmåde. En struktureret fremgangsmåde kan dog bidrage til, 

at forudsætningerne og mangler herfor identificeres tidligt, bl.a. ved at der 

laves proces og produktanalyser forud for systemopbygningen. 

3. Forudsætningerne for konfigureringssystemer er til stede for mange 

virksomheder i byggebranchen, men der er også mange der ikke opfylder de 

mest basale krav: standardiserede produktfamilier, stor omsætning af tilbud 

og ordrer, markedsmæssige muligheder for at udvikle standardiserede 

løsninger, en hensigtsmæssig arbejdsdeling i værdikæden, adgang til 

automatiseringsteknologi etc. Flere af de udvalgte virksomheder i PKBprojektet 

ligger på grænsen til at opfylde de væsentligste forudsætninger. 

4. Ved opbygning af konfigureringssystemer, der skal kunne skabe tegninger, 

bevæger man sig ud i et grænseområde, som de færreste nuværende 

konfigureringssystemer kan håndtere. Der er her færre udviklingsmiljøer, der 

understøtter udviklingsarbejdet hermed, ligesom der er færre ”frontløbere” 

der allerede har vist vejen. Der er således i flere tilfælde tale om svære og 

nyskabende projekter. I disse tilfælde er der også områder i 

fremgangsmåden, der har mangler. Specielt er der mangler omkring 

geometrimodellering. 

5. Der er tilføjet nogle elementer til den eksisterende fremgangsmåde, bl.a. 

interessentanalyser, geometriproduktvariantmaster og geometritilpassede 

versioner af CRC-kortene. 

4.2 Perspektivering 

Som påpeget flere steder i rapporten er der visse forudsætninger for 

konfigureringssystemer, der ikke opfyldes af mange parter i byggebranchen. Gennem 

PKB projektforløbet viste det sig gradvist at konfigureringssystemer måske endnu er 

en anelse for visionære i byggebranchen. 



58

Nogle af de initiativer der sandsynligvis skal ske for, at konfigureringssystemer vil 

vinde bred udbredelse i byggebranchen kan være følgende: 

1. Bedre arbejdsdeling i værdikæden og skabelsen af større virksomheder, 

hvilket kan give stordriftsfordele. 

2. En generel forskydning fra ”engineer-to-order” mod ”configure-to-order”, 

hvilket ligeledes vil betyde standardisering og en nemmere variantproduktionsopgave 

(herunder variantspecificering, hvilket muliggør 

automatisering gennem konfigureringssystemer). 

3. Systemleverencer, der understøtter kravet om standardiserede produkter og 

stort salgsvolumen. 

4. En digitalisering af bygningens livscyklus, fra skitsedesign til brug og 

vedligehold. Dette vil kunne påvirke behovet for digitale modeller af 

produktvarianter og muligheden for hurtigt at kunne lave varianter og 

alternative designs for bygningens dele (vinduer, døre, trapper, elementer 

etc.) 

5. Opbygning af kompetence inden for digital 3D-modellering, herunder 

konfigureringssystemer. En større national kompetence vil gøre det lettere for 

flere virksomheder at gennemføre konfigureringsprojekter. 

59 



5 Litteraturliste 

[bips nyt, 2003] Jensen, Svend Erik; bips nyt 1; fagbladet for 

brancheforeningen “byggeri, informatik, produktivitet, 

samarbejde (bips)”; www.bips.dk; 2003. 

[Christensen, 2004] Christian Stilling Christensen; Udvikling af software til 

automatisk CAD tegningsgenerering; 

diplomingeniørafhandling, DTU, 2004. 

[Haug&Christiansen, 2004] Jørgen Christiansen, Anders Haug; Opbygning af 3Dkonfigureringssystemer, 

-med fokus på producenter af 

bygningskomponenter; Civilingeniørafhandling, DTU, 

2004 

[Hansen&Hvam, 2004] Hansen, Benjamin Loer; Hvam, Lars; The Order 

Specification Decoupling Line; Conference Proceedings; 

International Conference on Economic, Technical and 

Organisational aspects of Product Configuration 

Systems; Technical University of Denmark, June 28th- 

29th, 2004. 

[Hansen&Hvam, 2004b] Hansen, Benjamin Loer; Hvam, Lars; Software til 

konfigurering i byggebranchen, -erfaringsopsamling; 

Arbejdsnotat udarbejdet i relation til PKB projektet, 

DTU, 2004. 

[Hvam et al. 2004] Hvam, Lars; Mortensen, Niels Henrik; Riis, Jesper; 

Produktkonfigurering; Undervisningsnote, DTU, 2004. 

[Kortegaard&Hvam, 2003] Kortegaard, Per; Hvam, Lars; Jørgensen, Kaj; (mfl.); 

Projektansøgning til ”Den jysk-fynske IT-korridor” om 

”Produktkonfigurering i Byggeriet”; Arkitektskolen i 

Aarhus, 2003. 

[Nielsen, 2004] Jacob Sværke Nielsen; Visuel Konfigurering; 

Civilingeniør eksamensprojekt, DTU, 2004 

[PRO IT News, 2003] Romo, Ilkka; PRO IT Product Model Data in the 

Construction Process; Confederation of Finnish 

Construction Industries; 

(http://www.rakennusteollisuus.fi/english/) Finland 

2003. 



60

Fremgangsmåde for opbygning af konfigureringssystemer i ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?