Affärsmodell för lean produktutveckling hos två

Download Report

Transcript Affärsmodell för lean produktutveckling hos två

Slutrapport 201303
Affärsmodell för lean
produktutveckling
hos två underleverantörer
2013-03-28
Mikael Ström, Swerea IVF
Göran Gustafsson, Chalmers
Om Swerea IVF
Swerea IVF är ett ledande svenskt industriforskningsinstitut inom
material-, process-, produkt- och produktionsteknik. Vårt mål är
att skapa affärsmässig nytta och att stärka våra medlemmars och
kunders konkurrens- och innovationsförmåga. Swerea IVF
bedriver industrinära forskning och utveckling i samarbete med
såväl industri som högskola, i Sverige och internationellt.
Våra cirka 150 högt kvalificerade medarbetare med bas i Mölndal
och Stockholm arbetar inom följande områden:
–
–
–
–
–
Arbetsliv, miljö och energi
Industriella tillverkningsmetoder
Material- och teknikutveckling
Polymerer och textil
Verksamhetsutveckling och effektivisering
Vi arbetar ofta med tillämpade lösningar på konkreta industriella
behov. Våra industrierfarna forskare och konsulter kan leverera
de snabba och handfasta resultat som företag behöver för att säkra
sin konkurrenskraft på marknaden.
Swerea IVF ingår i Swerea-koncernen, som består av fem
forskningsbolag inom material- och verkstadsteknik: Swerea IVF,
Swerea KIMAB, Swerea MEFOS, Swerea SICOMP och Swerea
SWECAST. Swerea-koncernen ägs gemensamt av industrin och
statliga RISE Holding AB.
Swerea IVF AB
Box 104
431 22 Mölndal
Telefon 031-706 60 00
Telefax 031-27 61 30
www.swereaivf.se
Slutrapport 201303
© Swerea IVF AB
Slutrapport
Förord
Denna rapport är slutrapport från projektet ”Integrerad affärs- och
produktutvecklingsmodell hos första nivåns leverantörer”. Projektet är finansierat
av Vinnova och har diarienumret: 2009-03676. Projektet har löpt från 2009-12-01
till 2013-03-31. I projektet har företag deltagit både som referensföretag och som
deltagare i forskningsprojektet. De företag som deltagit som referensföretag är:
•
•
•
Volvo Personvagnar AB
Scania CV AB
Autoliv Sverige AB
Dessa benämns referensföretag i fortsättningen.
De företag som deltagit i forskningsprojektet är:
•
•
Kongsberg Automotive AB
Autotube AB
Dessa benämnes huvudföretag i fortsättningen.
Forskningsutförare har varit:
•
•
Swerea IVF AB
Chalmers Tekniska Högskola, Avdelningen för Produkt och
Produktionsutveckling
Denna rapport är en populär beskrivning av de resultat som kommit fram i
rubricerat projekt. Mer vetenskapligt inriktade resultat återfinns i de tre
vetenskapliga publiceringar som gjorts (Ström et.al 2012, Ström et.al 2013) samt
Ström (2013). Dessa har laddats upp på Vinnovas portal i samband med
slutredovisningen som separata dokument förutom den sistnämnda som är en
licentiatavhandling som en av projektdeltagarna skrivit som en del av
projektarbetet. På grund av att en lärare i forskningsmetodik varit
långtidssjukskriven har denna blivit försenad och kommer att publiceras först i
maj 2013. Ström et.al (2012) är en vetenskaplig publicering av de observationer
som gjorts före och under transformationsprocessen mot en implementering av
lean produktutveckling (LPU) som huvudföretagen genomgått. Ström et.al (2013)
är resultat från ett examensarbete som genomförts i projektet (Fritzell &
Göransson 2012). Examensarbetet är även det uppladdat på portalen liksom en
presentation i ämnet Set-Based design som gjorts under projektet.
Tanken med rubricerad rapport är att i lättläst form på svenska beskriva de
kunskaper och erfarenheter som kommit fram i projektet. Delar av innehållet
grundar sig på upplevelsebaserade iakttagelse som gjorts i projektet och alla delar
Slutrapport
av den populära rapporteringen har inte genomgått en vetenskaplig granskning av
utomstående part (peer review).
Slutrapport
Innehåll
1
Inledning
7
2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.7.1
2.7.2
2.8
Lean produktutveckling
Projektorganisation
Visuell planering
Strukturerad problemlösning
A3or
Kundönskemål, kunskapsgap och konstruktörsarbete
Integration Event
Multilösningsteknik svenska för Set-Based Design
Bakgrund
Alternativ metodik
Avvägningskurvor och begränsningskurvor
8
8
9
11
12
14
14
15
15
16
22
3
3.1
Affärsmodeller
Mätning av projektuppfyllelse under produktutveckling
29
31
4
4.1
4.2
4.3
Metoder som använts under arbetet
Stå-upp enkät
Coachning och utbildning
Kontinuerlig uppföljning
31
32
36
37
5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.2
5.3
5.4
5.5
5.6
5.7
5.7.1
5.8
Resultat
Affärs- och produktframtagningsmodeller
Att följa OEM företagens strategier
Att syssla med egen innovation
Att göra värdebaserad försäljning
Utvecklingsprojekt som kunskapsuppbyggnad och exekvering
Strategisk affärsutveckling
Kundönskemål och kunskapsluckor
Visuell planering
Strukturerad problemlösning
A3or
Avvägningskurvor och begränsningskurvor
Integration event (IE)
Mätning av produktutveckling
Uppföljning av kunskapsluckorna
Införande av lean produktutveckling
37
37
37
38
38
38
38
39
40
42
43
44
45
48
51
53
6
Diskussion
53
7
Slutsatser
53
3
Slutrapport
8
Referenser
54
4
Slutrapport
Sammanfattning
Rubricerat projekt har genomförts i samarbete med två huvudföretag som varit
Kongsberg Automotive och Autotube AB. Som referensföretag har Autoliv
Sverige AB, Volvo Personvagnar AB och Scania CV AB varit. Studier för
datainsamling har bedrivits på huvudföretagen. Doktorandstudier har bedrivits av
Mikael Ström med målet att avlägga en licentiatexamen (det egentiga målet i
ansökan till Vinnova var att påbörja dessa studier inom ramen för projektet).
Examen är planerad till den 31 maj 2013 då en licentiatavhandling ska läggas
fram. Som ett led i dessa studier har Mikael Ström varit handledare för ett
examensarbete (Fritzell & Göransson 2012).
Resultaten har redovisats i två vetenskapliga artiklar (Ström et.al 2012, Ström et.al
2013) samt på de projektmöten som hållits i projektet. Forskningsutförare har
varit Swerea IVF AB och Chalmers Tekniska Högskola.
Några av de viktigaste resultaten är:
-
-
Kongsberg Automotive AB har realiserat den vision av en integrerad
affärs och produktutvecklingsmodell som beskrevs i ansökan till projektet.
Autotube AB har införts ett antal komponenter av lean produktutveckling i
sitt arbetssätt.
Genom deltagande i doktorandkursen Set-Based design av professor
Durward Sokek som innehade en gästprofessur på Chalmers har kunskaper
om Set-Based design inhämtats och spridits inom och utom projektet.
Ett nytt koncept för ett mobilt obeya (projektrum) har tagits fram i
projektet och testats med framgång på Autotube AB.
En ny ansats för att mäta läget i pågående produktutveckling har tagits
fram. Här krävs dock mer forskning.
En form för stå-upp enkät för att bestämma nuläge och önskat läge för ett
företag har testats med framgång.
Grundliga tester av koncept från lean produktutveckling har testats på
Kongeberg automotive AB och på Autotube AB med goda resultat.
Införandet av lean produktutveckling har studerats på två företag och en
jämförande fallstudie har kunnat genomföras.
Följande slutsatser kan dras:
-
Strukturerad problemlösning med PDCA eller LAMDA är kraftfulla
metoder för problemlösning
Visuell planering av olika slag är kraftfulla metoder för att planera och
samordna projekt
Det är en fördel att ha en god bild av kundens prioriterade önskningar och
jämföra denna med befintliga lösningar och befintlig kunskap för att
identifiera kunskapsluckor.
5
Slutrapport
-
Det finns ansatser till att mäta läget i ett produktutvecklingsprojekt med
återkopplat lärande.
Den typ av stå-upp enkät som använts i projektet gav en bra start till ett
förändringsarbete.
Coachning med varvad uppföljning, målformulering och undervisning var
ett bra sätt att driva på utvecklingen i kombination med datainsamling.
6
Slutrapport
1 Inledning
Många av fordonsindustrins underleverantörer befinner sig i en affärssituation
som är typisk för denna industrigren. I detta arbete har två företag betraktats som
utför utvecklingsprojekt mot order. Det vill säga att OEM (Original Equipment
Manufacturer) företag (fordonsleverantör som tex Volvo Personvagnar AB och
Scania CV AB) beställer leverans av fordonskomponenter som kräver
konstruktions och utvecklingsarbete för att kunna produceras. Ett typiskt projekt
innehåller följande faser:
-
Säljarbete
Förutveckling
Offerering
Order
Produktutveckling
Ändringshantering
Produktionsberedning/ produktionsutveckling
Inköpsarbete
Produktionsprov
Produktion
Leverans
Tiden för första leveransen är näst intill alltid sammankopplad med
produktionsstarten hos OEM-företaget. Att försena denna är något som sällan görs
eftersom det låser upp stora investeringar, kräver omfattande planering och
försenar marknadsintroduktionen av ett nytt fordon. Perioden från order till första
leverans är oftast tidsbegränsad och bestäms ofta innan vidden av
produktutvecklingsuppgiften är helt känd och möjlig att bedöma med hänsyn till
tid och pris. I många fall är kravbilden inte statisk d.v.s. de krav som
underleverantören får i form av utrymme för inbyggnad och presentanda är sällan
samma under hela projektet. I många fall så ändras denna kravbild p.g.a. att
produktutvecklingsuppgiften inte är helt klar hos OEM-företaget. Uppgiften som
underleverantören ställs inför är med andra ord att utveckla en ny produkt eller en
variant på en tidigare till fast pris på en bestämd tid med rörlig kravbild.
Situationen som beskrivs skulle av många beskrivas som orimlig och uppgiften
omöjlig att genomföra. Trots detta är det denna verklighet som denna rapport och
det bakomliggande projektet adresserar.
Marknaden för fordonskomponenter är global vilket medför att även
konkurrensen är global. OEM-företagen kan göra prisjämförelser mellan
leverantörer från olika delar av världen. Detta och den hårda konkurrensen på
fordonsmarknaden leder till ständig prispress.
Det faktum att informations strömmar över oss från världens alla hörn gör att
sökandet efter en lösning på ovan beskrivna problem sker globalt. De
7
Slutrapport
fordonstillverkare och underleverantörer som är mest lyckosamma bildar skola för
resten. Det alternativ till lösning som seglade upp under slutet av nittonhundratalet
var de arbetsmetoder som användes av Toyota Motor Corporation och dess
underleverantörer. Toyotas processer och dess underleverantörers processer har
studerats av forskare världen över. Några av de mest kända publikationerna är:
The Machine that changed the world av Womak and Jones (1990), The Toyota
Way av Liker (2004), The Toyota Product Development System Morgan & Liker
(2006), Lean Product Development av Ward (2007), The Lean Development
Skills Book av Ward (2002). Andra författare som bidragit till att sprida dessa
tankar är Sobek, Kennedy, Modig & Åhlström och Mascatelli. Fler exempel finns.
Den metodik som beskrivs som lean produktutveckling (LPU) eller Lean Product
Development (LPD) på engelska påbjuder enligt mitt sätt att se på saken en
samtidig förändring hur man ska uppfatta kunden, kundens behov och hur dessa
ska mötas. Av detta skäl har vi funnit det lämpligt att formulera en
forskningsuppgift som gick ut på att finna möjligheter att på något sätt integrera
en modell för produktutveckling med affärsmodell för denna typ av affärer för att
skapa ett effektivt värdeflöde.
2 Lean produktutveckling
Lean produktutveckling är inte enbart en process för att produktutveckla. Lean
produktutveckling är ett system av samverkande delar. Delarna kan beskrivas var
för sig eller som principer för hur man ska utföra produktutveckling. En samling
av principer är Morga & Likers (2006) 13 principer för lean produktutveckling.
Neda följer en beskrivning av några av komponenterna i lean produktutveckling.
2.1 Projektorganisation
Produktutvecklingsprojekt har traditionellt organiserats enligt några varianter. En
projektledare tillsätts och projektet bemannas med personal som finns i
linjeorganisationens funktionella grupper. Linjen har erbjudit projekten resurser.
När projektet tagit slut återgår resursen till linjen. Varianter finns där
projektledaren kan vara antingen en medlem i någon funktionell grupp utan
chefsansvar (lättviktsprojektledare) eller där projektledaren kommer från någon
ledarnivå i linjeorganisationen (gruppchef, avdelningschef eller dyligt)
(tungviktsprojektledare) (Ulrich & Eppinger 2012). Projekten kan ges en mer eller
mindre autonom roll i förhållande till företaget i övrigt. Några nackdelar med
dessa typer av projektorganisationer är:
-
Projektledaren har vanligtvis inget ansvar för individens
kunskapsuppbyggnad.
Linjechefer vet för lite om vad som sker i projekten och den kunskap som
projektmedlemmarna erhåller.
Projektledaren får ofta resursen till en viss nivå tex halvtid eller heltid och
när arbetsmängden varierar är det svårt att anpassa resurserna genom
omfördelningar
8
Slutrapport
Ett annat sätt all organisera ett projekt är att projektet köper resultat eller utfört
arbete av linjeorganisationen. Projektledaren förhandlar då med linjecheferna om
resultat till projektet. Dessa får sedan i uppgift att allokera rätt person för
uppgiften och följa upp att arbetet blir gjort. Linjechefen får större insikt i vad
projekten gör och vilken kunskap hans medarbetare har förvärvat vid projektets
slut. Linjechefen kan balansera arbetsmängden för de personer denna ansvarar för
och omfördela resurser mellan projekten. Linjechefens ansvar blir att leverera
resultat från utfört arbete. Projektledaren kan ägna sig åt kundens önskemål och
omsätta dessa till projektmål som skall uppfyllas, bryta ner dessa till
arbetsuppgifter och köpa dessa från linjen. Projektledaren kan förvalta projektets
vision.
Det sistnämnda arbetssättet har testats av företag som arbetar enligt principerna
för lean och visat sig vara framgångsrikt.
2.2
Visuell planering
Visuell planering är något som påbjuds i de principer som kännetecknar lean
produktutveckling (Morgan & Liker 2006). Ofta sker projektplanering
traditionellt så att arbetsuppgifter sätts upp i en kolumn till vänster på ett ark eller
planeringstavla. Arbetsuppgifterna finns längs den vertikala axeln och tiden längs
den horisontella axeln.
Figur 1. Exempel på traditionell layout för projektplanering
Horisontella streck dras sedan åt höger för att markera när i tiden arbetsuppgiften
ska göras. Ett schematiskt exempel visas i Figur 1.
9
Slutrapport
Figur 2. Visuell planering på gruppnivå
Denna typ av planering är förvisso visuell på så vis att den kan hängas upp och ses
av de som passerar förbi. Visuell planering i lean världen är dock något annat. De
typer av visuell planering som är vanligast i lean världen och som varit
framgångsrika använder sig av planeringstavlor där resurserna är längs den
vertikala axeln i en kolumn längst till vänster och tiden längs den horisontella
axeln. I korsningen mellan kolumner och rader så placerar man klisterlappar med
arbetsuppgifter för det tidsspann som en kolumn utgör. Denna planering erbjuder
en bättre balansering av arbetsuppgifter för den enskilde individen. En annan
variant av visuell planering är att ha projekt på den vertikala axeln och
avdelningar, gränssnitt och bedömningspunkter längs den horisontella axeln.
Exempel på dessa båda typer av tavlor visas i Figur 2 och Figur 3.
Figur 3. Visuell planering av flera projekt
Kolumnerna för gränssnitt representerar status för externa aktörer som tex.
Leverantörer eller avdelningar på annan ort som inte enkelt kan närvara vid möten
framför tavla. Det rum där man genomför planering på projektnivå brukar kallas
projektrum eller Obeyarum. Det rum där man har en tavla av den typ som visas i
Figur 3 brukar kallas pulsrum och tavlan brukar kallas pulstavla.Tavlorna kan
även placeras på någon annan plats där möten lätt kan hållas. Skärningspunkten
10
Slutrapport
(se Figur 3) mellan projekt (rad) och t.ex. avdelning eller gränssnitt (kolumn) är
en ruta där man sätter ner en färjad magnet eller klisterlapp. Färgerna brukar
representera läget för den avdelningen i projektet. Grönt är OK, Gult möjligt
problem och Rött är problem.
Vid tavlan för projektplanering träffas projektgruppen vanligtvis en eller två
gånger per vecka för att kommunicera läget i projektet. Ett möte tar ca 30 minuter
till en timme.
Vid pulstavlan träffas vanligtvis alla projektledare, alla linjechefer och
representanter för företagsledningen och genomför pulsmöten en eller två ggr per
vecka. Även dessa möten tar ca 30 minuter till en timme.
2.3
Strukturerad problemlösning
En del av det vi kallar ingenjörsarbete är att lösa problem. Inom ramen för lean
produktutveckling finns det strukturerade former för detta. Två typer av mallar
som ofta används är loopar av PDCA typ eller LAMDA typ. I fallet PDCA står
versalerna för:
P = Plan
D = Do
C = Check
A = Act
PDCA loopen kan tolkas olika beroende på hur den tillämpas. Betydelsen av
versalerna PDCA är alltid enligt listan ovan men tolkningen av vad som ska göras
varierar. Den variant som redovisas här är följande:
Steg i loopen
Plan
Do
Check
Act
Tolkning
Analysera problemet och planera för hur det ska lösas
Testa en tänkt lösning
Utvärdera resultatet
Om resultatet är bra agera utifrån det annars tillbaka till ”Plan”
I den andra loopen med versalerna LAMDA har dessa följande betydelse:
L = Look
A = Ask
M = Model
D = Discuss
A = Act
Denna loop innehåller fler steg och dessa är utformade för att på ett tydligare sätt
bidra till problemlösningen. Även här finns flera tolkningar av vad som ska göras
11
Slutrapport
i respektive steg. Nedan följer den tolkning som använts i detta arbeta och som
resultaten baseras på.
Steg i loopen
Look
Ask
Modell
Discuss
Act
Tolkning
Gå till platsen där problemet kan beskådas och se med egna
ögon.
Fråga andra om problemet. Samla fakta om problemet. Fråga 5
varför.
Gör en modell av problemet för att förstå det bättre. Modellen
kan vara enkel.
Diskutera problemet med andra. Använd modellen och den
insamlade informationen som stöd i diskussionen.
Bestäm vad som ska göras utifrån det som kommit fram.
Utvärdera resultatet genom att gå till Look
LAMDA loopen har flera tydliga steg av analys och faktainsamling innan beslut
om åtgärd tas. Faktum är att ordet Decide (på engelska) inte ens tydligt
representeras av versalerna. I LAMDA loopen skjuter man beslutet framför sig
och analyserar, modellerar och diskuterar ingående innan man binder up sig vid
ett beslut. Detta är något som kännetecknar ”leantänkandet”. Att utforska noga
annan man fattar beslut och att fatta beslut baserat på kunskap och samsyn är
något som går igen i lean. I Figur 4 visas båda looparna.
Figur 4. Här visas LAMDA loopen och PDCA loopen
2.4 A3or
A3 rapporter (A3or) har fått sitt namn från standardstorleken (A3) på papperet de
är skrivna på. Detta format valdes eftersom det är, eller brukade vara den största
format på papper som skulle passa in i en fax. Det är dock inte formatet som är det
viktigaste när det gäller A3or utan formen för hur de används. A3or har utvecklats
till ett begrepp i sig som också innehåller problemlösning med PDCA eller
12
Slutrapport
LAMDA loopar, kommunikation och coachning - både vertikalt och horisontellt i
organisationen [Sobek 2008]. A3or kan användas för att dokumentera
problemlösning, förslag, statusrapporter och många andra typer av information
som kan dra nytta av ett kompakt format. När det används för problemlösning, är
ett sätt att strukturera A3an att anpassa dess sektioner för stegen i PDCA loopen
eller LAMDA loopen (se Figur 5). Resultatet av ett problemlösande loop är
kunskap om problemet och dess lösning. Detta kan lätt kommuniceras om A3an
ges en pedagogisk utformning. Bilder är vanliga för att ge ett visuellt budskap.
Deras kompakta format bidrar till att göra dem viktiga byggstenar i den
kontinuerliga förbättringen och lärande processen i ett företag. De är därför ofta
uppsatta på väggarna i designkontor för att bidra till visualisering av arbetet och
därmed öka lärandet och informationsöverföring.
Figur 5. exempel på layout på A3 för PDCA och LAMDA.
En A3a behöver inte återspegla lösningen av ett problem utan kan vara en mängd
samlad information av något slag. Ett exempel är att det väsentliga budskapet i en
bok kan sammanfattas på en A3, observationer från ett studiebesök eller annan
information som man vill bevara och kommunicera till andra.
Som nämndes ovan är det inte formatet på A3a (A3 format) som är det viktiga
med dokumentet. Ett förfaringssätt som ofta nämns är att den som gör A3an
diskuterar framtagandet med en mentor och på så vis får coachning med antagen
förbättrad kvalité på arbetet. När A3an är klar så undervisar den som gjort
dokumentet sina kollegor i innehållet. Dessa ställer frågor och innehållet
diskuteras. På detta sätt tvingas den som gjort A3an att verbalisera innehållet och
svara på frågor om det. Denna process antas ge en ökad insikt om A3an innehåll
13
Slutrapport
och även att innehåller i A3an och den extra insikten blir spridd i företaget vilket
antas stärka hela organisationen.
2.5 Kundönskemål, kunskapsgap och konstruktörsarbete
När nya produkter ska utvecklas eller varianter på dessa så är det mycket vanligt
att det behövs ny kunskap för att välja utförande på produkten och för att säkert
veta att detta utförande ger produkten avsedd prestanda. De avsedda prestanda
man väljer att ge produkten ska vanligtvis motsvara kundens önskemål om hur
produkten ska vara i något avseende. Det finns med andra ord ett samband mellan
kundens önskemål på produktens utformning och den kunskap som behövs för att
skapa produkten. Ofta har man inte denna kunskap utan den måste förvärvas på
något sätt. Vanligtvis bygger man tidiga prototyper och testriggar för att testa
olika lösningar och lära sig om dem. Man kan testa för att se vad som fungerar
och nöja sig med det eller så kan man testa för att lära sig var gränserna för en viss
teknisk lösning går. När går produkten sönder eller var går gränsen för felfunktion
under en t.ex. en viss belastning? Det senare förfarandet ger mer kunskap om
produkten än att bara förvissa sig om att en viss lösning fungerar under ett
användarfall. Ju mer kunskap man har om olika lösningar desto mer kan man
variera utförandet på produkten och ändå veta att den kommer att fungera.
Lärandet under produktutveckling och bevarandet av erhållen kunskap är ett
konkurrensmedel för många företag och en av hörnstenarna i lean
produktutveckling. Kunskapen kan med fördel dokumenteras på A3.
2.6
Integration Event
Integration Event (IE) kan översättas till integrationstillfälle. Detta är ett begrepp
som tillkommit i de beskrivningar som finns om lean produktutveckling. Det finns
två snarliknande händelser som kan förväxlas med IE dessa är tvärfunktionella
konstruktionsgenomgångar och grindmöten. Det bör betonas att det inte är samma
sak och vi ska här försöka förklara skillnaden. Ett grindmöte är vanligtvis ett möte
då representanter för projektet träffar styrgruppen för företagets projekt. Mötet
sker ofta på en plats som är skilt från projektets dagliga verksamhet. De dokument
man har vid mötet är oftast någon typ av checklista som är ett aggregat av
dokumentationen och situationen i projektet. Resultatet av ett grindmöte blir att
styrgruppen bestämmer om projektet får fortsätta in i nästa fas och under vilka
förutsättningar. Vid en konstruktionsgenomgång går man igenom underlag som
beskriver konstruktionen och försöker förvissa sig om konstruktionsunderlagen
beskriver en produkt som kommer att uppfylla kraven på produkten. Resultatet
blir oftast att man måste göra ett omtag eller att underlagen är korrekta.
Vid ett IE samlas man hos projektet. Det kan vara i ett projektrum (Obeya i lean
terminologi) eller på en plats på företaget där projektet genomförs. Man tittar på
originaldokument, modeller, prototyper, saker som representerar kunden eller
användaren av produkten. Tanken är att utreda om man har kunskap för att
14
Slutrapport
bestämma att man har minst en pålitlig lösning till produktens olika delsystem och
att dessa passar till varandra. Resultatet av denna process blir en konvergerande
utvecklingsprocess. IE genomförs nästa uteslutande när man arbetar med
multilösningsteknik (Set-Based Design) vilket beskrivs i kapitel 2.7.
Man kan betrakta dessa tre typer av möten som ett sätt att värdera tillståndet i
projektet direkt eller indirekt.
2.7
Multilösningsteknik svenska för Set-Based Design
Den engelska termen Set-Based Design har använts i litteraturen som beskriver
området lean produktutveckling.
2.7.1
Bakgrund
Majoriteten av de problem som elever i grundskola och gymnasium samt
högskolestudenter övar på i matematik och teknikämnen är vad som kallas slutna.
Ett sådant problem är väldefinierat, idealiserat och innehåller precis den
information som behövs för att lösa det – och absolut ingenting därutöver. Det har
ofta också bara en korrekt lösning.
Verkliga problem, inte minst industriella produktutvecklingsproblem, är nästan
alltid öppna, dvs. beskaffade på precis motsatt sätt. De är alltså problem ut
verkliga livet, som nästan alltid är bristfälligt definierade i något avseende, och
man känner kanske inte till alla krav och önskemål som olika intressenter kan ha,
om man ens vet vilka alla de är. Det är heller inte säkert att de själva är helt klara
över vad de kräver av produkten i olika avseenden. Krav och önskemål från olika
intressenter - och i värsta fall från en och samma - kan dessutom strida mot
varandra på komplexa sätt, och i extremfall stå i direkt motsatsställning till
varandra. Det kan vidare förekomma irrelevant information samt ny, och oprövad
teknik, och antalet möjliga lösningar till problemet kan vara mycket stort eller
t.o.m. oändligt.
Det vanliga sättet att hantera alla de här oklarheterna och osäkerheterna är att
relativt snabbt bestämma sig för hur lösningen i princip ska se ut och vilken teknik
som ska användas, och sedan utveckla det valda konceptet. Man bygger alltså en
prototyp och testar den för att undersöka om konstruktionen uppfyller de krav och
önskemål som finns. Gör den inte det så konstruerar man om, ändrar och testar
igen.
15
Slutrapport
Figur 6. Traditionell, iterativ produktutvecklingsprocess
Förloppet är alltså iterativt, se Figur 6, och konvergerar i bästa fall mot en lösning
som uppfyller kravspecifikationen. Det finns dock ingen garanti för att processen
alls ska konvergera, så har man råkat välja ett koncept som så småningom visar
sig inte ha förutsättningar för att kunna uppfylla kravspecifikationen så får man
backa tillbaka och börja om igen, med den försening och de konsekvenser som det
medför.
Det här arbetssättet är mycket vanligt, men det är inte särskilt effektivt. Man kan
givetvis råka ha tur så att den lösning som man tidigt väljer att satsa sina
ansträngningar på också visar sig fungera, men det kan kräva många iterationer –
och alltså mycket arbete – att komma dit. Eftersom man har undersökt få eller i
värsta fall inga alternativ alls så är det inte alls osannolikt att det existerar bättre
lösningar, som man kanske hade kunnat hitta om man hade lagt tid på att söka
efter den/dem. En annan typ av problem som inte är ovanligt med den här
metodiken är att man under processen upptäcker att den teknik som man har tänkt
använda inte fungerar i den aktuella tillämpningen, eller att man saknar tillräcklig
kunskap för att kunna använda den.
2.7.2 Alternativ metodik
Det finns alltså anledning att studera bättre sätt att utveckla produkter, och det här
kapitlet kommer att presentera huvuddelarna i ett sådant, som schematiskt ser ut
som i figur 2. Det är alltså ett mer linjärt arbetssätt, där lineariteten syftar på att
man startar med inte ett eller få olika lösningsalternativ, utan med många, som
successivt reduceras till ett enda.
16
Slutrapport
Figur 7. Modern, linjär produktutvecklingsprocess med multilösningsteknik
Problemdefinition
Vilket problem är det som ska lösas? Vad är grundorsaken till det?
Det här är ofta långt ifrån självklart, och man måste därför ägna tid åt att försöka
förstå problemet så att man kan formulera det korrekt och arbeta med rätt saker.
Att verkligen förstå problemet är A och O. Att man t.ex. ser dåligt om det börjar
regna när man kör bil betyder kanske inte nödvändigtvis att man måste få bort
vattnet från vindrutan. Uttrycker man sig så att det är förekomsten av vatten på
rutan som är problemet så kommer produktutvecklingsarbetet självklart att handla
om att hitta lösningar i form av vindrutetorkare. Men vatten är bevisligen
genomskinligt, så det är ju knappast vätskan i sig som stör sikten. Om man
funderar så inser man att orsaken till att man ser dåligt är att det uppkommer
brytningsfel i den ojämna filmen på rutan. Om man inser att det är grundorsaken
till siktproblemet och istället uttrycker det lösningsoberoende som att ”sök en
lösning som säkerställer god sikt vid körning i regnväder” så säger man inget alls
om hur lösningen ska fungera, utan bara vad den ska åstadkomma.
Det inbjuder till att tänka i nya banor och inte bara på vindrutetorkare.
Kravspecificering
Kravspecificering är det övergripande namnet på processen att sammanställa och
konkretisera alla intressenters krav, önskningar om och förväntningar på en
produkt. De delas in i krav och önskemål, där de förra är sådana kriterier som
produkten ovillkorligen måste uppfylla medan de senare är sådant som det är till
dess fördel om den uppfyller. Önskemålen rangordnas på en lämplig skala, ofta 15, där stigande värde betyder ökande viktighet. Att man har de här värdena klara
för sig är nödvändigt när man senare i produktutvecklingsprocessen kommer till
lägen när man inte kan optimera flera egenskaper hos produkten utan behöver
göra avvägningar mellan dem. Det är ju då önskvärt att man så långt möjligt kan
tillgodose de viktiga önskemålen. Man behöver också specificera hur varje
kriterium ska verifieras – för att veta hur man ska kunna konstatera om det är
uppfyllt eller inte – och vem som står bakom det, dvs. en referens, se Figur 8. Det
är alltså viktigt att
17
Slutrapport
alla kriterier är spårbara, så att man vet vem man ska kommunicera med om något
behöver förtydligas eller diskuteras.
Figur 8. Modell för kravdokumentation
Hellre än att ange krav och önskemål som tekniska specifikationer, dvs. gränser
och absoluta värden för komponenter/system i produkten, så bör man uttrycka
dem som mål och intervall vad avser produktens funktion(er). Man kan tänka sig
den totala kravbilden med avseende på funktioner som ett område i ett
mångdimensionellt rum som till en början är mycket stort men som snävas in
efterhand i och som en del i utvecklingsprocessen, och som till sist krymper ihop
till en punkt, se Figur 9, som motsvarar den lösning som man kommer fram till.
Det här är det slags beskrivning och modell av lösningsrummet och –processen
som metoden multilösningsteknik (eng. Set-Based Concurrent Engineering,
SBCE) omfattar.
Figur 9. Kravbild i mångdimensionellt rum som successivt snävas in.
Kravspecifikationen är ett levande dokument, som succesivt specificeras
allteftersom man lär sig mer om vad olika lösningskoncept kan prestera. Den
exakta kravspecifikationen är inte klar från början i utvecklingsprocessen, utan
den växer fram i takt med utvecklingen av produkten och blir klar samtidigt med
den.
När man skriver kravspecifikationen bör man inte använda termerna ska(ll)-krav
och bör-krav för att beteckna krav respektive önskemål! Den förra av dem är ett
slags tautologi och den senare är en självmotsägelse, vilket är fullgoda skäl för att
inte bruka dem. Men utöver det så är deras uppenbara engelska översättningar
18
Slutrapport
shall respektive should svåra att skilja på för många som inte har engelska som
modersmål, så missförstånd kan alltså lätt uppstå även på ett annat språk än
svenska. Requirements respektive wishes är mycket bättre.
Konceptgenerering
Multilösningsteknik innebär alltså att man undersöker många olika alternativa
lösningar i den rymd som spänns upp av kravspecifikationen, dvs. en tänkt
utsträckning av de olika kraven och önskemålen bortom de gränser för olika
variabler som kommer att bli slutgiltiga konstruktionsdata. Enklare uttryckt så
söker man först förutsättningslöst efter tänkbara lösningar utan att titta på om de
ligger inom kravspecifikationens gränser eller inte.
Processen är något olika om problemet gäller omkonstruktion eller
vidareutveckling av en existerande produkt, eller om det handlar om nyutveckling
av en produkt från grunden. I det förra fallet blir det huvudsakligen fråga om att
skapa varianter av den existerande produkten, som eventuellt innehåller nya
funktioner och/eller ny teknik. Ramarna är alltså på ett sätt ganska snäva, och
utrymmet för nytänkande är därför relativt begränsat. I en förutsättningslös
utvecklingsprocess finns det däremot i utgångsläget inga begränsningar alls för
vilka tekniker som kan bli aktuella och för lösningens olika egenskaper utöver vad
som anges i kravspecifikationen.
I båda fallen är det bra att försöka generera så många olika lösningsalternativ som
möjligt. Det finns kreativa respektive systematiska metoder för att göra det. Den
enklaste kreativa metoden är brainstorming, som inte kommer att diskuteras
vidare här. En systematisk metod är att tillämpa funktionsanalys i kombination
med en morfologisk matris. I funktionsanalysen bryter man ner lösningens
totalfunktion i delar. Om man kan identifiera en kronologisk ordning för hur
delfunktionerna utförs, så är den s.k. flödesmodellen lämplig. Annars, och i vilket
fall, kan man använda sig av ett funktionsträd, där totalfunktionen delas upp i
delfunktioner som förgrenar sig på lämpligt många nivåer. I båda fallen söker man
sedan lösningar till delfunktionerna, och utnyttjar en morfologisk matris för att
kombinera dem till en totallösning på så många olika sätt som möjligt, se Figur
10. Varje (möjlig) väg genom matrisen, t.ex. kombinationen a1-b2-c1-d3
representerar alltså ett lösningskoncept. Det kan finnas övergångar mellan
delfunktioner som inte är praktiskt (eller ens teoretiskt) möjliga att realisera
eftersom de respektive dellösningarna inte kan samarbeta med varandra, men
matrisen ger ändå upphov till förbluffande många olika lösningar. Som exempel
ger ju en matris med, som här, tre delfunktioner och tre dellösningar till varje
delfunktion 33 = 27 olika lösningar. Med fler identifierade delfunktioner och
genererade dellösningar så stiger antalet totallösningar mycket snabbt.
19
Slutrapport
Figur 10. Morfologisk matris med delfunktioner, dellösningar och exempel på en
totallösning.
Efter idégenereringen har man alltså (förhoppningsvis) ett stort antal
lösningsförslag, eller koncept. Om problemet ifråga gäller omkonstruktion eller
utveckling av en existerande produkt så är de antagligen få, och gäller det
nyutveckling av en produkt från grunden så är de fler.
Beslutsmetoder
Det är nu frestande att bland alla idéer försöka välja ut den bästa lösningen, men
gör man det så hamnar man i den iterativa standardmodellen som visas i Figur 6,
och som alltså inte rekommenderas. Mycket bättre är att istället undersöka
potentialen hos varje alternativ, och att tillämpa olika tekniker för att successivt
eliminera hela grupper eller ett och ett av dem tills ett enda återstår, vilket då är
det bästa.
Istället för att välja ut det bästa alternativet så gör man alltså precis tvärtom: man
väljer i en kontinuerlig process bort de sämsta. Fördelen med den här metodiken
är att förutom att man lär sig mycket så kommer man att ha undersökt de olika
alternativen bättre, och sannolikheten för att man hittar det bästa alternativet ökar.
Man börjar med att kontrollera om det finns lösningar som inte klarar alla krav
som ställs. Alternativ som ligger utanför konstruktionsrymden kan direkt
elimineras. Samma gäller för alternativ som man på goda grunder bedömer inte
kommer att kunna klara kraven ens efter mer utvecklingsarbete, endera inte alls
eller inte i praktiken p.g.a. att de innehåller okänd teknik eller olämpliga material
eller att man inte har tillräckligt med tid och resurser för det arbete som skulle
krävas för att få dem funktionsdugliga etc. Målet är att eliminera så många
koncept som möjligt och så snart som möjligt, men det måste göras på sakliga
grunder, och man ska noga dokumentera vad man har lärt sig av det som man nu,
åtminstone för tillfället, slutar att studera. De kunskaperna, som man för övrigt
ska systematisera och försöka generalisera så långt det är möjligt, kan komma till
nytta i både det pågående och andra projekt. Det kan mycket väl vara så att ett
koncept som idag inte går att realisera därför att det t.ex. kräver ny och ännu
outvecklad teknik, visar sig vara synnerligen konkurrenskraftigt och aktuellt vid
nästa uppdatering av produkten, och har man då inte dokumenterat det man redan
vet om konceptet så innebär det slöseri att behöva göra om arbetet igen.
20
Slutrapport
Figur 11. Kravbild för ett problem och visuella dokument associerade med olika
lösningskoncept.
Den här processen eliminerar alla mer eller mindre omöjliga alternativ, och kvar
har man sedan mer realistiska alternativ som man nu behöver studera närmare för
att kunna skilja åt. Det gör man genom att experimentera och göra andra slags, i
sammanhanget billiga, försök, t.ex. simuleringar, för att bilda sig en uppfattning
om hur bra de olika alternativen är i förhållande till varandra och i förhållande till
kravbilden i Figur 9. Målen med arbetet är både att lära sig mer om vart och ett av
dem och att kunna eliminera fler koncept. Ju färre man har kvar, desto mer arbete
krävs det för att kunna skilja dem åt. Så småningom har man eliminerat alla
alternativ utom ett. Samtidigt sjunker kravbilden i Figur 9 ihop och blir till sist en
punkt, som definierar den lösning som väljs.
Under urvalsprocessen utnyttjar man visuella metoder för att illustrera vilka
möjligheter som olika alternativ erbjuder. Förutom kravbilden i Figur 9 så ritar
man olika diagram och grafer som visar hur de storheter som förekommer i
konceptet är relaterade till varandra, och de är också verktyg i själva arbetet. Det
handlar både om att illustrera vilka kombinationer av värden på storheterna som är
möjliga, och kurvor som visar hur olika variabler beror av varandra. De här
dokumenten görs upp på basis av såväl teoretiska som empiriska data för varje
koncept. Eftersom det kan vara fråga om helt olika typer av konstruktioner i varje
koncept så kan kurvorna ha mycket olika utseende mellan koncepten, och de
behöver inte ens vara lika många. Dokumenten för varje koncept är dock
kopplade till lösningsrymden/kravbilden, se Figur 11, och påverkar den. Den
senare förändras i takt med att dokumenten ändras som en följd av att man
studerar och utvecklar de olika alternativen, och den uttrycker vid varje tidpunkt
den ”minsta gemensamma nämnaren” för de olika koncepten, alltså vad de alla
bedöms kunna prestera.
21
Slutrapport
2.8
Avvägningskurvor och begränsningskurvor
Exempel
Betrakta följande problem, som visar en möjlig lösningsgång:
Figur 12. Tank med två symmetriplan.
Vi vill konstruera en tank som ska innehålla gas, se Figur 12. Det är alltså
övertryck i tanken (relativt atmosfären), som i teorin kan ha oändligt många olika
utseenden. Bland ett antal olika varianter som vi kom fram till via idégenerering
så har vi med hjälp av eliminering underifrån kommit fram till att vi ska välja en
avlång, cylindrisk tank med kupade gavlar. Figur 13 visar en järnvägsvagn som
har en sådan tank. Den avrundning av gavlarna och övergången mellan dem och
mantelytan som tydligt framgår av bilden är gynnsam för hållfastheten eftersom
den gör att man får lägre spänningar i materialet i övergången mellan gavlarna
och tankens mantelyta. Man kan i och med det också använda en förenklad teori
för att beräkna spänningarna i tanken.
22
Slutrapport
Figur 13. Amerikansk tankvagn med kupade gavlar. Foto: Sean Lamb, 2005.
Symmetrin hos tanken gör att huvudspänningarna i materialet ligger i de två
vinkelräta planen I och II, se Figur 12. Vi lägger därför ett snitt i vart och ett av
dem, frilägger och sätter ut de verkande krafterna. Tyngdkrafterna är små i
sammanhanget och försummas därför.
Figur 14. Vänster gavel frilagd, med verkande krafter utsatta och förutsatt att
t<<D.
Om man antar att t<<D, dvs. tunnväggig konstruktion, vilket uppfylls med god
marginal för alla kommersiella tankar, så kan man räkna med konstant spänning
över tvärsnittet. Jämvikt för gaveln ger då
σL·2π·(D/2)·t - p·π·D2/4 = 0
σL = [D/(4t)]·p
På motsvarande sätt kan man studera jämvikten för den övre halvan av tanken,
som visas frilagd i Figur 15.
23
Slutrapport
Figur 15. Tankens övre halva frilagd, med verkande krafter utsatta.
Jämvikt ger
σφ·(2Lt + πDt) - p·[LD + (π/4) ·D2] = 0
σφ·Lt·(2 + πD/L) - p·LD·[1 + (π/4) ·(D/L)] = 0
Om nu också D<<L, vilket är hyggligt uppfyllt för en tank med slank geometri
som i Figur 12, så är
σφ = p·LD/(2Lt)
σφ = [D/(2t)]·p
vilket alltså är dubbelt så hög spänning som i snitt I.
Materialet reagerar på effektivspänningen, som enligt von Mises kan skrivas som
σe = (σL2 + σφ2 - σLσφ)½
Vi får alltså
σe = [σL2 + (2σL)2 - 2σL2]½ = (σL2 + 4σL2 -2σL2)½ = √3·σL = √3·[D/(4t)]·p
σe = (√3/4)·(D/t) ·p
Detta är ett uttryck som kan användas för att studera lämpliga tankdimensioner
och -tryck. Figur 11 visar hur två tankar med olika förhållanden mellan diameter
och godstjocklek har olika grafer.
24
Slutrapport
Figur 16. Effektivspänningen som funktion av trycket för olika tankar.
Man kan uttrycka vilken som helst av p, σe, t och D som funktion av de tre
övriga, så man får då en skara räta linjer som symboliserar olika tankar. Med
många olika tankar i samma diagram blir det dock trångt i figuren, och ett
alternativt sätt att visualisera samma samband är då att sätta effektivspänningen
lika med brottspänningen, dvs.
σe = σB
och att skriva om uttrycket som
t/D= (√3/4)·p/σB
Detta samband sammanfattar vad som gäller för alla tankar av den aktuella typen,
dvs. cylindriska, slanka och tunnväggiga som alltså uppfyller villkoren t << D <<
L. De kan då illustreras med en enda graf, se Figur 17. Man kan notera att
variablerna i det diagrammet är dimensionslösa, vilket är ett sätt att uttrycka
information på som har många fördelar.
Figur 17. Grafen visar sambandet mellan relativa väggtjockleken och relativa
trycket i en tank vid gränsen för haveri.
Punkter på linjen utgör kombinationer av p, σe, t och D för tankar som ligger
precis på gränsen till haveri. Grafen utgör då skiljelinjen mellan möjliga och
omöjliga lösningar/tillstånd, varav de förra ligger i området ovanför, se Figur 18.
25
Slutrapport
Figur 18. Områden med möjliga och omöjliga lösningar.
Man kan nu använda diagrammet som ett konstruktionshjälpmedel för att finna
lämpliga lösningar. För att få säkerhet mot haveri är det lämpligt att introducera
en säkerhetsfaktor S > 1 som gör att sambandet övergår i
t/D= (√3/4)·S·p/σB
och diagrammet blir som i Figur 19.
Figur 19. Säkert område m.h.a. säkerhetsfaktor.
26
Slutrapport
Figur 20. Kausalitetsanalys.
En analys av kausaliteten i problemet, Figur 20, visar hur olika variabler relateras
till och påverkas av eller påverkar varandra. Trycket i tanken och tankens
geometri bestämmer spänningsfältet, som i sin tur ger effektivspänningen.
Eftersom problemet är statiskt bestämt så beror den senare inte av några
materialegenskaper. Hur effektivspänningen förhåller sig till brottspänningen
avgör slutligen om man har en fungerande lösning eller inte, och om man vill så
kan man även se säkerhetsfaktorn som en komponent i sammanhanget.
Diagrammet i Figur 19 kan också användas som grund för att illustrera
användning av tanken, med fyllning respektive tömning. Säkerhetsmarginalen kan
förutom med säkerhetsfaktorn även påverkas genom olika ändringar av tanken,
vilket då syns tydligt i figurerna. Figur 21 visar hur säkerhetsmarginalen ökar när
man med oförändrad geometri och samma tryck ökar brottspänningen, dvs. byter
till ett mer hållfast material i tanken.
Figur 21. Höjning av säkerhetsmarginalen (i höger diagram) p.g.a. ökad
brottspänning, σB.
I Figur 22 ser man hur säkerhetsmarginalen ökar p.g.a. att man istället ökar
tankens tjocklek eller minskar diametern.
27
Slutrapport
Figur 22. Höjning av säkerhetsmarginalen (i höger diagram) p.g.a. tjockare
material i tanken eller mindre diameter.
De olika figurer som har presenterats utgör tillsammans det underlag för
konceptet cylindrisk tank som skulle förekomma som ett av flera alternativ i en
sammanställning av konstruktionsprocessen i Figur 11. I multilösningsteknik
arbetar man alltså inte bara med olika alternativa lösningar/koncept, utan med
(oändligt) många varianter av varje, och man växlar mellan att studera kravbilden
och de olika diagram som sammanfattar olika lösningsegenskaper och hur
storheter förhåller sig till varandra. I fallet med den cylindriska tanken handlar det
om kontinuerliga funktioner för variablerna, och arbetet utmynnar i att man
slutligen väljer en punkt som representerar lösningen.
Som påpekats förut är variablerna på axlarna i dimensionslösa fr.o.m. Figur 17.
Det är viktigt att inse att ett sådant diagram är extremt informationstätt. En punkt i
diagrammet i det säkra området motsvarar t.ex. två olika kontinuerliga funktioner
som kan uttryckas som räta linjer i diagram, ett diagram som relaterar
väggtjockleken till diametern och ett annat diagram som uttrycker förhållandet
mellan trycket i tanken och brottspänningen i dess material, se Figur 23.
Värdena på tjockleken och diametern kan varieras proportionellt mot varandra,
och samma gäller för trycket och brottspänningen. För en viss tank har man
givetvis ett fixt värde på vardera t, D och σB, medan trycket varierar beroende på
tankens fyllnadsgrad. Tankens representeras då av en punkt på den räta linjen i tD-diagrammet, och av en lodrät linje mellan abskissan och den räta linjen i p-σBdiagrammet. Var man befinner sig på den lodräta linjen beror på fyllnadsgraden;
med ökande fyllning och därmed ökat tryck i tanken så rör man sig uppåt på
linjen.
En horisontell linje i det dimensionslösa diagrammet relateras på motsvarande sätt
till en rät linje i t-D-diagrammet och till ett område i p-σB-diagrammet.
Multilösningsteknik, med dess naturliga inslag av dimensionslösa variabler och
diagram, är ett effektivt hjälpmedel i produktutvecklingsarbetet och representerar
en arbetsmetodik som på flera
28
Slutrapport
Figur 23. En punkt i det dimensionslösa diagrammet motsvarar två linjära
funktioner.
sätt är bättre är den traditionella iterationstekniken med konstruera-bygg-testa. Det
krävs dock träning för att lära sig att arbeta med dimensionslösa variabler och
med diagram, vare sig de senare är dimensionslösa eller inte. Det gör att
multilösningstekniken sannolikt inte är lika lätt att ta till sig som
iterationstekniken är, vilket kanske är åtminstone en delförklaring till den senares
dominans inom industrin. Multilösningstekniken har dock många fördelar över
iterationstekniken när man har lärt sig den, varav ett exempel är att den underlättar
och stimulerar återanvändning och generalisering av information och kunskap.
Det behövs dock mer forskning för att (vidare)utveckla metodik och verktyg för
multilösningsteknik som kan användas av produktutvecklare och konstruktörer.
3 Affärsmodeller
När produkter ska säljas eller de effekter som kunden är i behov av så kan det
göras på en rad olika sätt. Ibland säljs produkten i form av en hårdvara och ett
stycke materia byter ägare. I andra fall så säljs en tjänst som ger samma effekt
som produkten. Om produkten är en damsugare så kan man även ge kunden
samma effekt genom att sälja städtjänster. När komponenter ska säljas som inte är
konstruerade och tillverkade så kan affären se olika ut jämfört med tillverkade
29
Slutrapport
produkter. Traditionellt i fordonsindustrin så har utveckling och leverans gjorts
upp i en affär med tidssatt leverans. Detta är typiskt för fordonsindustrin. All
utveckling har då sålts till fast pris med fast leveransdag för produkten.
Leverantören har fått förutsättningarna av OEM företaget och startat utvecklingen
utifrån dem. Ett sätt att göra detta annorlunda vore att på egen hand utreda vad
slutkunden d.v.s. användaren av ett fordon önskar sig i form av egenskaper på
produkten. Utifrån denna kunskap så utvecklar leverantören en egen lösning och
erbjuder OEM företaget denna lösning och kan på detta sätt addera värde till
produkten på ett proaktivt sätt. Leverantören kommer på detta sätt att besitta mer
kunskap om lösningen och på så vis svara upp i dialogen med OEM företaget och
med större kraft påverka OEM företagets sätt att få kundens önskan om effekt
realiserad. Detta innebär en något annorlunda affärsmodell som är mer proaktiv
jämfört med den som är vanligast och som är mer reaktiv. Vid starten av
rubricerat projekt och i samband med ansökan om projektanslag redovisades ett
förslag på affärsmodell. Denna visas i Figur 24.
Figur 24. En proaktiv affärsmodell för fordonsindustrins underleverantörer
I affärsmodellen i Figur 24 visas hur underleverantören har egna aktiviteter för att
förstå slutanvändarens situation och krav på produkten. Denna bild var en av
målbilderna för rubricerat projekt.
30
Slutrapport
3.1
Mätning av projektuppfyllelse under produktutveckling
Att mäta produktutveckling ur någon aspekt är något som flera försökt. Det man
velat mäta är effektiviteten på produktutvecklingen. Hur mycket produkt man får
fram per nedlagt konstruktörstimma eller något liknade. Man vill ibland mäta
tiden för att upptäcka förseningar. Man vill ibland mäta kravuppfyllelsen i
konstruktionsarbetet. Hur många krav är uppfyllda vid ett vist läge i tiden eller vid
en viss nivå av återstående utvecklingsbudget. Dessa mätningar görs ofta genom
att samla in kvantitativa data. Data från olika håll kan kombineras för att genom
enkla beräkningar bilda aggregerade värden. Ett exempel kan vara att dela antalet
kvarvarande krav med återstående tid i ett utvecklingsprojekt. Detta värde
kommer att öka om inte kraven uppfylls i takt med att projektet fortlöper. Om
löptiden är 10 månader och vi har 50 krav så kommer kvoten att vara 5 vid
projektets start. Om hälften av kraven är uppfyllda när det återstår 1 månad av
projektet kommer kvoten att vara 25. Denna siffra blir då en indikator på att
projektet eventuellt inte kommer att uppfylla sitt mål under given tid. Denna typ
av kvantitativa mätetal är relativt enkla att ta fram och mäta. En nackdel är att
man inte vet så mycket om de bakomvarande orsakerna. Kanske är de 25
kvarvarande kraven enkla att uppfylla och kanske är de 25 redan uppfyllda kraven
näst intill omöjliga att uppfylla. Om ett av de uppfyllda kraven är att omvandla
koldioxid till fast kol och syre snabbt och billigt så är det en sensation. Det är ofta
lätt att manipulera denna typ av mätningar. Om ett krav på en produkt är att
omvandla koldioxid till fast kol och syre snabbt och billigt samt att man har nio
andra krav på text säkerhet, transporterbarhet på utrustningen mm. Om man då
uppfyller alla krav utom det som gäller koldioxid så kan man vid en tidpunkt i
projektet meddela att man uppfyllt nio krav av tio och dessutom tidigt i projektet.
Denna bild ger då ingen riktig bild av det verkliga värdet. Ofta är denna typ av
indikatorer av släpande typ dvs det visar ett läge som just har varit. Det är mer
intressant att använda ledande indikatorer som i förväg kan visa att man att man är
på väg åt fel håll. En sådan ledande indikator när det gäller kravuppfyllnad kan
vara att några av företagets viktigaste konstruktörer gått över till en konkurrent.
Det kommer att bli svårt att bli svårt att uppfylla kraven på den nya produkten
utan dessa. Övergången till konkurrenten kan dock vara en släpande indikator vad
gäller stämningen eller kanske löneläget på företaget vilket kan vara ett skäl att
personal lämnar.
I rubricerat projekt ska en ansats till ”lean” mätning av produktutvecklingsprojekt
tas fram.
4 Metoder som använts under arbetet
I rubricerat forskningsprojekt har en rad olika metoder använts. Data har samlats
in från huvudföretagen. Insamlade data har redovisats i projektgruppen där även
forskningsutförarna och referensföretagen deltagit. De metoder som använts för
datainsamling är semistrukturerade intervjuer och en typ av enkät som besvaras
och bearbetas i form av en workshop. Datainsamlingen har varvats med coachning
31
Slutrapport
av ett av huvudföretagen. Regelbundna coachningsmöten har hållits där företagets
arbete följts upp och nya utmaningar formats. Nedan följer närmare beskrivningar
av enkäten som vi kallar Ståupp-enkät och coachningsmodellen som använts. För
att jämföra resultat mellan huvudföretagen har fallstudiemetodiken enligt (Yin
2009) använts.
4.1 Stå-upp enkät
För att fånga upp de punkter som är viktiga för företaget att förändra och
samtidigt engagera personalen i detta så använde vi en form av enkät som är
mycket visuell. Enkäten består av ett antal frågor inom sex stycken områden.
Frågorna besvaras genom att välja mellan fem olika svarsalternativ som motsvarar
det tillstånd som gäller för respektive fråga. Ett huvudområde är t.ex.
projektgenomförandeprocessen. Detta område delas upp i delområden som är:
ständiga förbättringar, standardiserat arbetssätt, normalläge, värdeskapande arbete
och visualisering. Varje delområde beskrivs med sämsta tillstånd respektive ett
idealtillstånd. Respondenten får välja, genom att interpolera mellan sämsta
tillståndet och idealtillståndet, hur nuläget är och vad önskat läge är för respektive
underområde (se Figur 25). Svaren summeras per huvudområde och en graf för
nuläge och önskat läge ritas (se Figur 25). Både svarandet, summerandet (se Figur
26) och ritandet av grafen görs av respondenterna. Resultatet blir tydligt och
självupplevt vilket antas ökar respondenternas insikt och samsyn om deras
situation. När graferna är uppritade får respondenterna studera resultatet och
indelade i små grupper föreslå och diskutera åtgärder för att gå från nuläget till
önskat läge (se Figur 27). Förslagen sätts upp som gula klisterlappar på enkäten
(se Figur 28). Förslagen prioriteras sedan för införande inom sex månader, ett år
och två års sikt.
32
Slutrapport
Figur 25. Sammanräkning av svar i Stå-upp enkäten.Nuläge är det röda
stapeldiagrammet och önskat läge är det blå diagrammet.
33
Slutrapport
Figur 26. Här visas ett exempel på summering av nuläget.
34
Slutrapport
Figur 27. Här samlas en lite grupp respondenter för att diskutera fram förslag på
förbättringar.
35
Slutrapport
Figur 28. Här visas en fråga med svar som summerats och med utritad graf. Gula
lappar finns uppsatta med förslag på förbättringar
4.2 Coachning och utbildning
För att få en bra kontakt med företagen (i detta fall ett av huvudföretagen) så
genomfördes en serie coachningsmöten. Mötena innebar att en lista av
förbättringar som tagits fram genom stå-upp enkäten gicks igenom. Utmaningarna
i listan varvades med korta utbildningsinsatser för att stärka företaget i olika
metoder. Det kunde vara typiska metoder från lean produktutveckling som t.ex.
användningen av A3or och LAMDA loopar eller användningen av andra
ingenjörsmetoder som kan hjälpa företaget att nå sina mål. Under mötet delades
uppgifter ut till deltagarna från företaget för att slutföras till nästa möte. På
kommande möte följdes uppgifterna upp och coachningsaktiviteterna upprepades.
Arbetssättet visade sig vara mycket lämpligt för denna typ av förbättringsarbete i
kombination med datainsamling för forskning. Metoden har likheter med Design
Research Metod (Blessing 2009) och interaktiv forskning.
36
Slutrapport
4.3 Kontinuerlig uppföljning
En annan metod för datainsamling som prövades var att följa upp införandet av
lean produktutveckling på ett antal parametrar i ett antal skarpa
produktutvecklingsprojekt. Parametrarna var i detta fall antalet definierade
kundönskemål, antal kunskapsgap i början av ett projekt, antal A3or med
strukturerad problemlösning för att lösa problem kopplade till kunskapsgap, antal
integrationsmöten samt ett antal andra parametrar. Total följdes cirka 20 olika
parametrar upp. Uppföljningsmötena gjordes ungefär en gång per månad. Denna
metod visade tydlig hur långt införandet genomförts och även hur väl de uppföljda
projekten förlöpte. Metoder var dock påfrestande för de som blev uppföljda.
5 Resultat
I detta kapitel redovisas resultaten av de utförda aktiviteterna ute på
huvudföretagen.
5.1
Affärs- och produktframtagningsmodeller
En klar ambition i rubricerat projekt var att finna nya former för underleverantörer
och OEM företag att mötas för att addera mer värde till OEM företagets
slutleverans samt att skapa förutsättningar för mer förutsägbara utfall i
underleverantörens orderbundna produktutveckling. Ett av huvudföretagen var
synnerligen målmedvetna i sin strävan att införa en ny kombinerad affärs och
produktutvecklingsmodell. Resultatet visa grafiskt i Figur 29. Modellen innehåller
processer för:
-
Att följa OEM företagens strategier
-
Att syssla med egen innovation
-
Att göra värdebaserad försäljning
-
Att dela upp kundprojekt i kunskapsuppbyggnad och projektexekvering
-
Strategisk affärsutveckling
-
Exekvering av projekt
-
Kunskapsuppbyggnad
Ut ur modellen kommer en tydlig formell kunskapsvärdeström och en formell
produktvärdeström. Traditionella processer har endast en formell
produktvärdeström. Nedan följer kortfattat förklaringar för respektive avsnitt.
5.1.1
Att följa OEM företagens strategier
En ambition är att vara delaktiga i OEM företagens strategier när det gäller nya
produkter och tekniker. Företaget vill komma in tidigare och på så vis bygga egen
kunskap för att var bättre rustade att möta framtida förfrågningar på skarpa
utvecklings och leveransprojekt.
37
Slutrapport
5.1.2
Att syssla med egen innovation
Företaget vill skapa nya erbjudanden baserade på egna insikter om
slutanvändarens situation och önskningar
5.1.3
Att göra värdebaserad försäljning
De egna kunskapen ska stärkas genom formella processer för
kunskapsuppbyggnad. Företaget vill på så vis bidra med ett större värde i
leveransen till OEM företaget. Detta värde kan vara kunskap som kan leda till
förändringar i OEM företagets produkter. Underleverantören kan ta betalt för
detta värde.
5.1.4
Utvecklingsprojekt som kunskapsuppbyggnad och exekvering
För att slippa brist på kunskap i produktutvecklingsprojekten dels dessa in i en
kunskapsuppbyggande del och en del för ren projektexekvering. Den första delen
är till för att fylla kunskapsluckor ofta direkt kopplade till kundkrav. En andra
delen är en tidsplanerad del som genomförs då kunskapsluckorna är fyllda.
5.1.5 Strategisk affärsutveckling
Underleverantören kan ha en egen affärsstrategisk process för att utveckla egna
strategier och val att utveckla egna produkter.
Figur 29. Ny kombinerad affärs och produktutvecklingsmodell
En betydligt enklare variant på konceptet i Figur 29 är att föra loggbok på
kundkontakter och notera vad man lärt sig under kundkontakten. Detta är något
som testats av ett av huvudföretagen i projektet (inte det som införde modellen i
38
Slutrapport
Figur 29). Detta visade sig i all sin enkelhet vara ett sätt att förbättra kontakten
med kunderna och att sprida information som framkommit vid kundkontakten.
5.1.6
Kundönskemål och kunskapsluckor
Sättet att i sin projektmodell betrakta kundens önskemål i förhållande till den
kunskap och de lösningar man har att uppfylla dem är av stor betydelse. Om man
chansar och acceptera en kundorder till fast pris och fixt leveransdatum men med
outredda tekniska lösningar så kan man få stora problem att uppfylla sin leverans
till kunden. Hur noga man än planerar sitt utvecklingsprojekt så går det inte att
kompensera kunskapsbrist med bra planering. Ett sätt att ta sig an en situation som
den beskriven ovan är att vara medveten om kundens prioriterade behov och
utreda vilka av dessa vi kan möta med den kunskap och de lösningar vi har och
vilken kunskap vi saknar. Att ha denna bild klar för sig samt flödet från
kundönskemål via kunskap i en projektmodell är av stor vikt. Ett av
huvudföretagen har satsat på just en sådan modell i sitt projektgenomförande.
Prioriterade kundönskemål dokumenteras på A3or (CIx-A3) (se Figur 30).
Kopplade kunskapsluckor dokumenteras även de på A3or (p-A3). Varje sådan
A3a går in i en loop av strukturerad problemlösning som kan innebära testning
och konstruktion av testriggar mm. Projektmodellen innehåller sedan periodvisa
genomgångar (KR, se Figur 30) av erhållen och saknad kunskap. När produkten
börjar ta form integreras dess olika delar på integrationsmöten (IE, se Figur 30).
När man under ett integrationsmöte kan se att det finns kunskap att bygga alla
delsystem övergår man till en tidsplanerad projektmodell.
39
Slutrapport
Figur 30. Kopplingen mellan prioriterade kundönskemål och kunskapsluckor.
Det kan fortfarande vara problem att hinna med att utreda all brister på kunskap
innan man måste gå in i en tidplanerad utvecklingsmodell. Det kan dock med
goda skäl antas att det är bättre att ha utgått från ovan beskrivna modell (se Figur
30) eftersom man åtminstone har kartlagt vad man inte kan och är mer medveten
om det. Okunskap kan ha många former och man brukar tala om två typer:
1
Kunskap man vet att man saknar
2
Kunskap man inte vet att man saknar
Den sistnämnda kategorin är bedraglig eftersom den kan ge obehagliga
överraskningar. Genom att arbeta efter en modell i Figur 30. Så kan man
gissningsvis föra över en del från typ två (se ovan) till typ ett.
5.2
Visuell planering
Visuell planering används flitigt på ett av huvudföretagen. Veckovis genomför
man en planering i företagets pulsrum. Denna planering berör såväl kundprojekt
som interna projekt. För några av företagets projekt har man vikbara tavlor som
man tillverkat själva av enkla skivor och gångjärn. Dessa tavlor som är mobila
används för projektplanering. Projektledarna kan ta med sig tavlorna när de rör sig
inom företaget vilket ger stor flexibilitet och en möjlighet för projektledaren att
kommunicera med visuella hjälpmedel på stående fot var som helst på företaget.
40
Slutrapport
Figur 31. Multiprojektplanering i ett sk pulsrum. En vänstra tavla är för
kundprojekt och den högra för interna projekt.I bildens nedre del
strax framför de väggfasta tavlorna ses en vikbar mobil
planeringstavla för ett enskilt projekt.
Efter mötet i pulsrummet går delar av personalen som arbetar med
konstruktionsarbete och genomför en lokal puls för konstruktionsgruppen.
Figur 32. En mobil och fällbra planeringstavla för kundprojekt
Den mobila fällbara projekttavlan är en lösning som skapats i rubricerat projekt
och kan betraktas som en ”ny” lösning som kommit fram för denna tillämpning.
Tavlan bedöms särskilt lämpad för företag som inte har fria lokalytor för att
inrätta fasta projektrum.
41
Slutrapport
Figur 33. Visuell planering för utvecklingsarbete i en projektgrupp
Ett annat exempel på visuell planering är att utgå från väl definierade problem.
Genom att identifiera kundönskemål och koppla dessa mot befintlig eller saknad
kunskap så kan man identifiera vilka problem som måste lösas. Genom att noga
bryta ner dessa till arbetsuppgifter kan man placera dessa i en inkommande kö på
tavlan (vänster i Figur 33). Dessa prioriteras sedan i tre nivåer. Varje utvecklare
har två ärenden som placeras i en loop för strukturerad problemlösning. Genom
denna systematik ”äter sig” utvecklarna genom högen av problem. När ett
problem är löst placerad det i utkorgen (Out på tavla i Figur 33). Nyckeln till att
det fungerar är att definiera problemen noga. Gruppen som arbetar med denna
tavla hade korta möten på ca 10 minuter varje morgon för att fördela
arbetsuppgifter och kommunicera eventuella problem.
5.3 Strukturerad problemlösning
Att lösa problem är något som kan göras på en rad olika sätt. Ett problem kan vara
av olika natur. Här menas i första hand tekniska problem i produkten eller i
produktionsapparaten. Det problem som metoden ”Strukturerad problemlösning”
har testats på här är ett problem som fanns i en produktionsutrustning. Problemet
var följande:
-
Kvalitetsutfallet på en stukad rörände var ojämnt.
För att lösa problemet tillämpades strukturerad problemlösning med LAMDA
metoden. Lösningsgången kan följas i Figur 34.
42
Slutrapport
Figur 34. Här visas en A3a som dokumentation av problem löst med strukturerad
problemlösning med LAMDA loopen
Det man fann var att det verktyg som användes inte var härdat som det skulle
vara. Detta upptäcktes genom att använda 5 varför metoden. Denna kan ses i
vänstra nedre hörnet på A3an i Figur 34. När man kommit på denna orsak till
problemet ville man även lösa problemet att stuka rörändar av aluminium. Detta
löstes även det. Hela lösningsförfarandet dokumenterades på en A3a. Resultatet
av tillämpningen av LAMDA loopen var intressant eftersom man inte hittat ett
relativt enkla felet tidigare. Genom att bryta ner problem systematiskt och samla
information systematiskt kan man komma längre jämfört med en ostrukturerad
ansats.
5.4
A3or
Som nämnts tidigare så är sk A3or en bra form för att dokumentera kunskap (för
rätt betraktare) på ett kompakt format. A3orkan användas för att dokumentera
resultatet av en strukturerad problemlösning, essensen av en bok man läst,
avvägningskurvor (på eng. trade-off curves) eller begränsningskurvor (på eng.
limit curves). Figur 35 – nedan visas en begränsningskurva för läckage i en
rörkoppling. Skaparen av A3an har genomfört ett flerfaktorförsök enligt en
testplan och mätt läckaget med heliumläcksökning. I diagrammet i mitten är
accepterad nivå på läckage markerat med ett tjockt rött streck. På den vertikala
43
Slutrapport
axeln i diagrammet är läckaget i heliumläcksökningen och på den horisontella
axeln är åtdragningsmomentet. De olika kurvorna representerar olika varianter på
kopplingen.
Figur 35. En A3a som dokumenterar kunskap om accepterat läckage i en
rörkoppling
Detta röda streck kan representera en begränsning av konstruktionsrymden likt de
streck som avgränsar denna rymd i Figur 9. I A3an i Figur 34 kan det ses i
figurens nedre högra hörn att man valt att lägga dokumenthuvudet här. Det passar
bra med tanke på hur dokumenthuvudet är placerade i ritningsblanketter. Detta
underlättar när man ska sätta in A3orna i pärmar. Om A3a viks enligt sättet att
vika ritningar så kan man fortfarande bläddra relativt snabbt bland bladen.
Huvudet hamnar på samma ställe som större ritningar (A2, A1) om de viks enligt
metoden att vika ritningar.
5.5
Avvägningskurvor och begränsningskurvor
Avvägningskurvor eller trade-off curves som det heter på engelska är ett
relationssamband mellan två eller flera konstruktionsparametrar. I Figur 36 visas
en avvägningskurva mellan vikten och volymen för några olika utföranden på en
låda som innehåller en elektrisk drivlinekomponent. Lådan kan göras i aluminium,
plast eller en hybridvariant vilket ger olika förhållande mellan vikt och volym.
Kurvan kommer från en kunskap-A3a som ett av huvudföretagen tagit fram i ett
utvecklingsprojektet. Kurvan kan jämföras med kurvorna i kapitel 2.8 som visas i
Figur 18 och i Figur 19. I kapitel 2.8 kan man dimensionera en tank med kurvorna
här kan man välja material till en elektroniklåda. Kurvorna är värdefull hjälp till
44
Slutrapport
produktutvecklare som snabbt kan få kunskap om ett förhållande som påverkar ett
konstruktionsbeslut. Även kurvan i Figur 35 är ett exempel på visuell kunskap.
Denna typ av kurva brukar kallas begränsningskurva. Konstruktionsbeslutet kan
ingå i en offert eller vara ett beslut som man måste ta snabbt p.g.a. ändringar i
kundkraven. Kurvan är då en värdefull källa på kunskap som sparar tid och
resurser. Denna typ av kurvor är också möjliggörare i den typ av affärsmodell
föreslagits i rubricerat projekt.
Figur 36. Här visas en avvägningskurva mellan vikt och volym för en komponent
till en elektrisk drivlina
5.6
Set-Based Design - Multilösningsteknik
Ett försök att tillämpa Set-Based design har gjorts i projektet. Försöket
genomfördes som en workshop där flera av företagen i projektet deltog.
Funktionen som skulle realiseras var att kunna stiga upp på ramen av en
trailerdragande lastbil (se Figur 37). Detta görs idag genom att fästa ett fotsteg på
sidan av fordonet. En bild på ett fotsteg kan ses i Figur 38. Materialet i fotsteget är
stål. Fotsteget består av två rördelar som bildar gavlar och två fyrkantrör som
bildar stegpinnar. Fotsteget svetsas samman med fyra svetsfogar och lackas sedan
som korrosionsskydd.
45
Slutrapport
Figur 37. Trailerdragare
Följande egenskaper bedömdes som viktiga om en ny variant på produkten ska tas
fram:
-
Lägre vikt än nuvarande
-
Lågt pris än nuvarande (kundönskemål)
-
Snygg
-
Kan man slippa fotsteget helt genom fotsteg i batterilådan
-
Lägre kostnad (leverantörsönskemål)
-
Klättra upp och ner utan att halka
-
Livslängd och bra infästning
-
Bra lösning för halkskyddet
Figur 38. Fotsteg som fäste på batterilådan på fordonet
För att generera ett antal lösningsalternativ genomfördes en brain storming
övning. Från denna kom ett antal nya lösningar fram som sattes upp i en matris
med de nya lösningarna på den vertikala axeln och önskvärda egenskaper på den
horisontella axeln. I korningen mellan rader och kolumner i matrisen skrevs en
bedömning om kravuppfyllanad in (se Figur 39).
46
Slutrapport
Figur 39. Här visas upplägget för Set-Based design av ett fotsteg
De lösningar som kom fram var:
-
Fotsteg i batterilådan. Dvs. att ändra på höljet till denna och forma ett
fotsteg i den
-
Samma som idag fast i aluminium
-
I aluminium och svetsarna ska ersättas med nitar
-
Olika varianter av ändrat utförande så att man bara behöver två svetsar
istället för fyra som det är idag. Material stål
-
Två varianter på utförande som endast kräver en svets
-
En variant av tvåsvetsvarianten fast i aluminium
Efter att bedömningen av förslagen var klar kunde tre förslag omedelbart sorteras
bort. Dessa är markerade med kryss på matrisens högra sida se Figur 39. Övriga
förslag är värda att gå vidare med. De kunskapsluckor som identifierades och där
kunskap måste sökas är:
-
Hållfastheten om fotsteget görs i aluminium
-
Hur göra halkskydd i runda rör
-
Prisskillnaden mellan lösning i aluminium och lösning i stål
47
Slutrapport
-
Blir det galvanisk korrosion med aluminium
-
Hur korrosionsskydda en lösning i aluminium
Den beskrivan övningen la grunden för en fortsatt process i Set-Based design för
att ta fram ett vinnande lösningsalternativ. Övningen tog ca två timmar att
genomföra. En kritik som ofta riktas mot metoden Set-Based Design är att den är
resurskrävande. Mot bakgrund av denna kritik så gick den ovan beskrivan
övningen förvånansvärt snabbt och återstående arbete bedöms vara överkomligt ur
resurssynpunkt.
5.7
Integration event (IE)
Trots at man inte bedriver produktutveckling enligt principerna för
multilösningsteknik så testade ett av huvudföretagen att genomföra ett IE.
Skillnaden mot en vanlig konstruktionsgenomgång var främst att man blandade in
fler personer från företagets olika avdelningar. Resultatet blev att man hittade fler
saker som behövde åtgärdas jämfört med en konstruktionsgenomgång.
5.8 Mätning av produktutveckling
I rubricerat projekt har vi försökt att hitta sätt att sätt att visa på hur läget är i ett
utvecklingsprojekt. I detta kapitel redovisas några ansatser på hur mätning kan
göras. I ett fall har ansatsen införts på ett av huvudföretagen. Ett vanligt sätt är att
visualisera situationen i ett eller flera projekt genom visuell planering. I Figur 40
visas en tavla, i figurens övre vänstra hörn, för planering i multiprojektmiljö.
Tavlan visar läget i projektet och om någon vill ha denna bild förmedlad till sig
kan man delta på något av de pulsmöten som regelbundet hålls. Vill man förmedla
bilden till någon som inte kan närvara så kan man fotografera tavla med
digitalkamera och mejla bilden eller anslå den på ett intranät. En pulstavla
innehåller dock oftast bara ögonblicksbilder av läger. Ofta ser man att företag
kompletterar dessa tavlor med traditionella kvantitativa indikatorer. Vill man så
kan man dock skapa visuella ”minnen” av läget och på så vis se utvecklingen över
tiden. I Figur 40 ser vi två sådana exempel. I den övre vänstra tavlan ser man läget
för projektet vid senaste pulsmötet. Vi ser antalet röda magneter som visade
problemen just vid detta tillfälle. I den övre vänstra tavlan ser vi antalet röda
magneter (problem) vid olika pulsmöten över tiden. En kolumn motsvarar ett
pulsmöte. Ju fler problem ju högre stapel. På detta sätt kan man se om problemen
ökar eller minskar per projekt eller flera projekt beroende på hur man väljer att
utforma tavlan.
48
Slutrapport
Figur 40. Exempel på visuella indikatorer för mätning i utvecklingsprojekt.
I bildens nedre del (se Figur 40) visas ett annat exempel på visuell uppföljning
över tiden. I detta exempel sätts en röd klisterlapp upp för att ange att det finns ett
problem på en avdelning i exempelvis ett projekt. När problemet är löst sätts en
gul lapp upp till höger om den röda för att ange hur problemet löstes. Om tavlan
gäller för ett projekt kommer det att bildas serier av problem och lösningar på
raderna för avdelningar och gränssnitt. Ju fler problem ju längre rad av lappar. En
sådan serie ger information om antalet problem och hur de löstes. Stapeln kommer
att ge en återkoppling till andra och innehåller viss kunskap. På så vis får man en
indikator med en återkoppling och möjlighet till lärande.
49
Slutrapport
Figur 41. Exempel på visuella indikatorer för projektuppföljning
En annan ansats är de som visas i Figur 41. Här följs ett projekt upp genom att
följa upp om man använt de medel som finns anvisade. I tabellen nedan finns
förklaringar till samtliga förkortningar i figuren.
Förkortning
Betydelse
Ung. översättning till svenska
BE
Business Event
Affärstillfälle
D&Q
Design & Quote
Konstruera och offerera
E
Engineering
Ingenjörsarbete
S
Supplier involvement
Involvering av leverantörer
PP
Production Preparation
Produktionsförberedelser
SOP
Start of Production
Start av produktionen
CI
Customer Interest
Prioriterade kundönskemål
Gap-PKB
Gap Problem Knowledge
Brief
A3a som beskriver en
kunskapslucka
KB
Knowledge Brief
A3a som beskriver kunskap
50
Slutrapport
CS
Check Sheet
Checklista för producerbarhet
BR
Business review
Genomgång av affärsmöjlighet
KR
Knowledge Review
Genomgång av kunskapsläget
IE
Integration Event
Integrationstillfälle
STC
Steering Committee
Styrkommitté
I figurens (se Figur 41) visas en pil som representerar processflödet. Bokstäverna
(BE, D&Q, E, S, PP och SOP) representerar faser eller hållpunkter under
projektet. Den gröna och den röda kvadraten representerar klisterlappar. En gröna
visar var i processflödet den del av projektet som kommit minst framåt är. Den
röda klisterlappen visar hur långt de delar i projektet kommit som kommit längst i
processflödet. I en vänstra nedre delen i Figur 41 visas staplar. Staplarna visar
antalet identifierade och prioriterade kundönskemål (CI). En gröna delen av
stapeln visar de CI som kan uppfyllas med befintlig kunskap och en röda är de där
kunskap saknas. Kunskapsgapen är illustrerade med stapeln Gap-PKB. Den gröna
delen av stapeln är de kunskapsluckor som identifierats och beskrivits hittills i
projektet och den röda delen är de som är identifierade men inte beskrivna som
A3a. Stapeln märkt KB är representerar antalet KB som tagits fram och som
beskriver kunskap som tagits fram för att fylla identifierade kunskapsluckor. CS
är antalet checklistor som använts för att stämma av producerbarheten av
produkten. Med denna uppföljning kan man visa hur väl kundens prioriterade
önskemål är beskrivna och kan uppfyllas samt vilka kunskapsluckor som återstår
att fylla. Röda staplar betyder varning och gröna att projektet löper väl
(förhoppningsvis). I den högra nedre bilden visas vilka möten som hållits i
projektet. Om inga eller få möten hållits så kan man misstänka att det inte står rätt
till. Har extremt många möten hållits så är även det ett tecken på att något är fel.
Har flera STC hållits men inga IE kan man misstänka att det finns problem som
kräver styrgruppens inblandning och att kunskapen i projektet inte stämts av
mellan delsystemen. Det som visats ovan i Figur 40 och Figur 41 är en ansats som
formats i projektet. Delvis har antalet IE börjat följas upp hos ett av
huvudföretagen.
5.8.1
Uppföljning av kunskapsluckorna
Ett sätt att mäta ett utvecklingsprojekt på och som förmodligen ger en mycket bra
bild av hur bra projektet fortlöper är att mäta antalet identifierade kunskapsluckor.
Det vill säga den brist på kunskap som finns för att realisera en produkt som
uppfyller kundens önskemål. Utvecklas denna tanke fullt ut så kan man mäta
antalet identifierade och prioriterade kundönskemål, antalet kunskapsluckor och
51
Slutrapport
antalet kunskaps-A3or som tagits fram för att fylla kunskapsluckorna. Troligt är
då att antalet kundönskemål ökar när man lär känna dennes önskningar. Kurvan
bör plana ut efter en tid (se Figur 42).
Figur 42. Antagen utvecklingen av prioriterade kundönskemål, kunskapsluckor
och kunskaps-A3or under löptiden av ett projekt.
När kundens önskemål jämförs med befintliga lösningar kommer ett antal
kunskapsluckor att framträda. Genom testning och lärande kan dessa fyllas med
kunskap och antalet luckor minskar och idealt går de mot noll. I samma takt
kommer antalet kunskap-A3or att öka när ny kunskap kommer fram. I Figur 42
visas denna utveckling i ett läge då samtliga kunskapsluckor är fyllda och när det
inte uppkommer fler prioriterade krav från kunden. Hur denna utveckling ser ut i
olika typer av projekt vet vi inte säkert idag. Här behövs mer forskning för att
utreda hur väl dessa indikatorer fyller sitt syfte.
52
Slutrapport
5.9 Införande av lean produktutveckling
Införande av lean produktutveckling kan göras på en rad olika sätt. I detta projekt
så fann vi två angreppssätt som var olika. Det ena var att utgå från lägsta nivån på
företaget och identifiera behoven där. Detta gjordes med den typ av stå-up enkät
som beskrivs i kapitel 4.1. Forskargruppen genomförde sedan periodiska
coachningsmöten för att stötta införandet. Detta resulterade i en rad införda
förbättringar. I det andra huvudföretaget började man från toppen och införde
nedåt via en central funktion för processutveckling. Det man hade ambition att
införa var ett heltäckande koncept innehållande en utvecklings och affärsprocess
med tillhörande organisatoriska förändringar. I det senare fallet tog det längre tid
att enas om utformningen av konceptet och i ett kort perspektiv var det förra
angreppssättet mer effektivt.
6 Diskussion
Framkomna resultat har god trovärdighet som vi bedömer det. För att stämma av
resultaten med andra bedömare har referensföretagen utnyttjats som referens.
Vidare har litteratur studerats för att hitta liknade tillämpningar och
problembilder. Dessa jämförelser pekar på att resultaten är trovärdiga och
generaliserbara. De metoder som använts för analys och datainsamling är väl
beprövade och vi fick stor acceptans från huvudföretagen när vi använde dessa
metoder. Dock ska sägas att vi stötte på visst motstånd för att göra kontinuerliga
uppföljningar på läget i pågående utvecklingsprojekt.
7 Slutsatser
Vi drar följande slutsatser från genomfört projekt:
-
Strukturerad problemlösning med PDCA eller LAMDA är kraftfulla
metoder för problemlösning
Visuell planering av olika slag är kraftfulla metoder för att planera och
samordna projekt
Det är en fördel att ha en god bild av kundens prioriterade önskningar och
jämföra denna med befintliga lösningar och befintlig kunskap för att
identifiera kunskapsluckor.
Det finns ansatser till att mäta läget i ett produktutvecklingsprojekt med
återkopplat lärande. Här behövs dock mer forskning.
Den typ av stå-upp enkät som använts i projektet gav en bra start till ett
förändringsarbete.
Coachning med varvad uppföljning, målformulering och undervisning var
ett bra sätt att driva på utvecklingen i kombination med datainsamling.
53
Slutrapport
8 Referenser
Blessing L., Chakrabarti A., (2009), “DRM, a Design Research Methodology”, Springer,
London, London.
Fritzell, I. and Göransson, G., (2012), Value stream mapping in product development –
Adapting value stream mapping at Ascom Wireless Solutions, Master´s thesis,
Chalmers University of Technology.
Modig N., Åhlström P., (2012), Detta är LEAN, ISBN 978-91-86797-07-2, Stockholm
School of Economics Institutes for Research, Stockholm, Sweden
Morgan J. M., Liker J. K., The Toyota product development system, Productivity Press,
NY, NY, USA, 2006.
Raudberget D., (2012), Industrial Experience of Set-Based Concurrent Engineering –
Effects, results and applications, Chalmers University of Technology, Gothenburg,
Sweden
Sobek D. K., Ward A., Liker J., (1999), Toyota’s Principles of Set-Based Concurrent
Engineering, Sloan Management Review, 1999. 36:p. 67-83
Sobek II D. K., Smalley A., Understanding A3 Thinking: A Critical Component of
Toyota’s PDCA Management System, Productivity Press, Boca Raton, FL, USA,
2008.
Söderberg B., (2012), On the Use of Visual Planning in Teams, Chalmers University of
Technology, Gothenburg, Sweden
Ström M., (2013), Improving engineering change processes by using lean principles,
Licentiate thesis, Chalmers University of Technology, Gothenburg, Sweden
Ström, M., et.al, (2013), A method to understand and improve your engineering processes
using Value Stream Mapping. In Proceedings of ICoRD´13, IIT, Madras, Chennai,
India, 7-9 January 2013.
Ström, M., et.al., (2012), Transformation to Lead Product Development – Approaches at
Two Automotive Suppliers. In Proceedings of Design 2012, Dubrovnik, Croatia, 2124 May, 2012.
Ulrich K. T., Eppinger S. D., (2012), Product Design and Development, McGraw Hill
Companies Inc, NY, NY, USA
Ward A. C., Lean Product and Process Development, (2009), The Lean Enterprise
Institute, Cambridge, MA, USA.
Williamson K., (2002), Learning to see, ISBN 1 876938 42 0, Center for Information
Studes, Wagga Wagga, NSW Australia.
Yin R. K., (2009), Case Study Research - Design and Methods, SAGE Publ. Inc.,
Thousand Oaks, CA, USA.
54