Akademin för Innovation, Design och Teknik

Symptombaserad felsökning

av tunga fordon En systematisk metod för att sammankoppla kundsymptom

med systemreaktioner

Examensarbete

Avancerad nivå, 30 hp

Produkt- och processutveckling

Alexander Törnqvist & Jesper Jansson

Rapport nr:

Handledare, företag: Nedim Zaimovic

Handledare, Mälardalens högskola: Jennie Åkesson

Examinator: Sten Grahn

Abstract This thesis is about symptom-based troubleshooting of heavy vehicles. The existing

troubleshooting system at Scania is adapted to handle errors based on electronic fault codes.

This means that some faults, such as mechanical faults when sensors are missing, are difficult

to troubleshoot. In the thesis, a method is developed that will be a part of a symptom-based

troubleshooting system which can handle all types of errors. The main objectives of the thesis

are both to develop a method that can link customer symptoms with system reactions and also

to develop formats for both customer symptoms and FMEA for the developed method.

In the thesis, a literature study was first conducted in which troubleshooting methods and

principles for the formalization of customer data were identified. The identified troubleshooting

methods were Bayesian Network, Case-Based-Reasoning and Fault tree analysis. A case study

was then conducted which was based on several documents for troubleshooting in gas engines

and gas tanks. In the case study, data from the literature study and the empirically collected data

were used to develop the final concept of the method. The case study included, among other

things, semi-structured interviews to map out the existing troubleshooting process, and a

workshop to choose the final concept.

In order to meet the objectives of the thesis two research questions and one question linked to

the case study were formulated:

Research Questions:

• RQ1: How is the troubleshooting process affected by the methods that can be used to

link customer symptoms with system reactions in heavy vehicles?

• RQ2: How can customer data and FMEA be formalized in order to be useful in the

troubleshooting process of heavy vehicles?

Case Study:

• What kind of data is missing from Scania’s existing documentation to link customer

symptoms with system reactions?

The thesis resulted in a method based on two troubleshooting methods Bayesian network and

Case-Based-Reasoning. The method links customer symptoms with system reactions by

excluding human considerations and instead relying on previously documented cases and

probabilities. A requirement for using this method is a cooperation between customer support,

mechanics and development engineers. The formalization of customer symptoms in the

developed method is based on what good data is for mechanics in troubleshooting contexts and

what customers are capable of communicating; deviation – the customer’s description of the

vehicle’s unexpected condition, position – where the customer considers the deviation to be

present, context – what happened before, during and after the deviation was discovered.

The conclusions that can be drawn is that it is not necessary to link customer symptoms with

system reactions since the developed method allows the customer symptoms to be linked

directly to the corrective actions needed. In addition, it was noted that the existing

documentation at Scania on customer symptoms and system reactions is insufficient. However,

this is not problematic as it was shown that FMEA is redundant for the method developed. In

order for customer data to be useful, the formalization should include deviation, position and

context. Further conclusions are that the role of the customer support becomes less critical when

data driven troubleshooting methods are used, and that the accuracy of the developed method

will improve over time as more data will be collected.

Sammanfattning Detta arbete behandlar symptombaserad felsökning av tunga fordon. Scanias befintliga

felsökningssystem är anpassat för att hantera fel som grundas i elektroniska felkoder. Detta

innebär att vissa typer av fel, såsom mekaniska fel när sensorer saknas, är svåra att felsöka. I

detta arbete utvecklas en metod som ska ingå i ett symptombaserat felsökningssystem eftersom

ett sådant system kan hantera alla typer av fel. Målen med arbetet är att utveckla en metod som

kan sammankoppla kundsymptom med systemreaktioner, och utveckla format för

kundsymptom och FMEA för den framtagna metoden.

I arbetet utfördes först en litteraturstudie där felsökningsmetoder och principer för

formaliseringen av kunddata identifierades. Felsökningsmetoderna som identifierades var

Bayesiska nätvkerk, Case-Based-Reasoning och Felträdsanalys. Därefter utfördes en fallstudie

som grundades på underlag om felsökning inom gasmotorer och gastankar. I fallstudien

användes data från litteraturstudien och den empiriskt insamlade data för att utveckla det

slutgiltiga konceptet. I fallstudien utfördes bland annat semistrukturerade intervjuer för att

kartlägga den befintliga felsökningsprocessen, och en workshop för att kunna välja det

slutgiltiga konceptet.

För att kunna uppfylla arbetets mål formulerades två forskningsfrågor och en frågeställning

kopplad till fallstudien:

Forskningsfrågor:

• F1: Hur påverkas felsökningsprocessen utifrån de metoder som kan användas för att

sammankoppla kundsymptom med systemreaktioner inom tunga fordon?

• F2: Hur kan kunddata och FMEA formaliseras för att vara användbara inom

felsökningsprocessen av tunga fordon?

Fallstudie:

• Vilken data saknas i Scanias befintliga dokumentation för att kunna sammankoppla

kundsymptom med systemreaktioner?

Arbetet resulterade i en metod som baseras på de två felsökningsmetoderna Bayesiska nätverk

och Case-Based-Reasoning. Metoden sammankopplar kundsymptom med systemreaktioner

genom att exkludera mänskligt avvägande och istället förlita sig på tidigare dokumenterade fall

och sannolikhet. En förutsättning för att metoden ska kunna användas är ett samarbete mellan

kundmottagare, mekaniker och utvecklingsingenjörer. Formaliseringen av kundsymptom i den

framtagna metoden bygger på vad bra data är för mekaniker i felsökningssammanhang och vad

kunderna är kapabla att förmedla; avvikelse – kundens beskrivning av fordonets oväntade

tillstånd, position – var anser kunden att avvikelsen förekommer, kontext – vad hände innan,

under och efter att avvikelsen upptäcktes.

Slutsatserna som kan dras utifrån arbetet är att det inte är nödvändigt att sammankoppla

kundsymptom med systemreaktioner, utan kundsymptom kan sammankopplas direkt med

åtgärder med den framtagna metoden. Dessutom noterades det att den befintliga

dokumentationen hos Scania angående kundsymptom och systemreaktioner är bristfällig. Detta

är inte problematiskt då det påvisades att FMEA inte är nödvändig för att metoden ska fungera.

För att kunddata ska vara användbart bör formaliseringen ske med avvikelse, position och

kontext. Ytterligare slutsatser är att kundmottagarrollen blir mindre kritisk när datadrivna

felsökningsmetoder används, och att den framtagna metodens träffsäkerhet kommer att

förbättras över tid allt eftersom mer data har samlats in.

Förord Arbetet har varit lärorikt och intresseväckande, men samtidigt väldigt utmanande då det har

behandlat ett område som ingen av oss har haft kontakt med tidigare under vår utbildning.

Dessutom var det utmanande på grund av de rådande omständigheterna i världen med covid-19

pandemin. Vi vill därför tacka Jennie Åkesson, vår handledare från Mälardalens Högskola, som

har stöttat oss under arbetes gång. Dina insiktsfulla råd har varit ovärderliga och en stor

bidragande faktor till att arbetet har kunnat genomföras. Följaktligen vill vi tacka Nedim

Zaimovic, vår handledare på Scania AB, som har avsatt sin tid trots begränsade resurser på

grund av permittering. Slutligen vill vi tacka de mekaniker och kundmottagare på Scania R&D

som har gjort det här arbetet möjligt genom att ställa upp på intervjuer.

Eskilstuna, Juni 2020.

Alexander Törnqvist & Jesper Jansson

Innehållsförteckning 1 Inledning ............................................................................................................................. 1

1.1 Bakgrund ..................................................................................................................... 1

1.2 Problemformulering ..................................................................................................... 2

1.3 Syfte och mål ............................................................................................................... 3

1.4 Frågeställningar ........................................................................................................... 4

1.5 Projektdirektiv ............................................................................................................. 4

1.6 Avgränsningar ............................................................................................................. 4

2 Teoretisk referensram ......................................................................................................... 5

2.1 Felsökning ................................................................................................................... 5

2.2 Symptom ...................................................................................................................... 5

2.3 Felsökningsmetoder ..................................................................................................... 6

Bayesiska nätverk ................................................................................................... 6

Case-Based Reasoning ........................................................................................... 7

Felträdsanalys ......................................................................................................... 8

2.4 Formalisering av kundsymptom .................................................................................. 9

Jämförelse mellan erfaren och oerfaren felsökare .................................................. 9

Kund och kundmottagare ..................................................................................... 11

2.5 Failure Mode and Effect Analysis (FMEA) .............................................................. 12

FMEA - I felsökningssammanhang ...................................................................... 13

3 Metod ............................................................................................................................... 15

3.1 Produktutvecklingsprocessen .................................................................................... 15

3.2 Litteraturstudie ........................................................................................................... 15

3.3 Fallstudie ................................................................................................................... 16

Avgränsningar för fallstudien ............................................................................... 18

Produktutvecklingsverktyg ................................................................................... 18

Datainsamlingstekniker ........................................................................................ 20

3.4 Kvalitativ analys ........................................................................................................ 23

3.5 Validitet och reliabilitet ............................................................................................. 24

3.6 Etik och moral ........................................................................................................... 25

4 Fallstudie .......................................................................................................................... 27

4.1 QFD ........................................................................................................................... 27

4.2 Analys av felsökningssystem identifierade i litteratur .............................................. 27

4.3 Scanias befintliga felsökningsprogram – SDP3 ........................................................ 29

4.4 Kartläggning av den befintliga initiala felsökningsprocessen ................................... 30

4.5 Dataanalys av dokument från Scania ......................................................................... 34

Analys av underlaget inom gasmotorer och gastankar ......................................... 34

Konkurrensanalys - Volvo Cars VIDA ................................................................ 37

4.6 Konceptutveckling ..................................................................................................... 38

Konceptgenerering ............................................................................................... 38

Konceptval ........................................................................................................... 41

5 Resultat ............................................................................................................................. 43

5.1 Presentation av valt slutgiltigt koncept ...................................................................... 43

Den inledande fasen ............................................................................................. 43

Den faktiska fasen ................................................................................................ 44

5.2 Uppfyllelse av mål ..................................................................................................... 46

6 Analys ............................................................................................................................... 49

6.1 Analys av det slutgiltiga konceptet ............................................................................ 49

6.2 Besvarande av fallstudiens frågeställning ................................................................. 51

6.3 Besvarande av forskningsfrågorna ............................................................................ 52

7 Diskussion ........................................................................................................................ 57

Litteraturförteckning ................................................................................................................ 65

Bilagor ...................................................................................................................................... 68

Figurförteckning Figur 1. Visar hur ett Bayesiskt nätverk kan presenteras grafiskt med noder och relationer.

Figuren är baserad på en figur framtagen av Huang et al. (2008). ............................................. 6 Figur 2. Visar produktutvecklingsprocessen som har tillämpats under arbetet. ...................... 15 Figur 3. Visar den initiala och faktiska felsökningsprocessen som utförs på Scania. .............. 17 Figur 4. Visar flödet för den inledande fasen. .......................................................................... 43 Figur 5. Visar den grafiska modellen för det Bayesiska nätverket för exemplet ovan. ........... 45

Figur 6. Visar flödet för den faktiska fasen. ............................................................................. 46

Tabellförteckning Tabell 1. Visar teman som användes till respektive analys. ..................................................... 24

Tabell 2. Visar en sammanfattning av några potentiella lösningar och rekommendationer på

hur ett felsökningssystems formalisering kan vara uppbyggt. ................................................. 28 Tabell 3. Visar bakgrundsinformation om respondenterna: kön, ålder, År av erfarenhet,

befattning, samt i vilket perspektiv hen intervjuats. ................................................................. 30 Tabell 4. Visar beskrivningar av respektive steg i den initiala felsökningsprocessen. ............ 31 Tabell 5. Visar data som kunden kan förmedla till kundmottagaren. ...................................... 32 Tabell 6. Visar tidsåtgången för respektive moment i den initiala felsökningsprocessen. ...... 32

Tabell 7. Visar rubrikerna som fanns i FMEA:n och en beskrivning av respektive rubrik. .... 35 Tabell 8. Visar datakvaliteten för respektive rubrik i FMEA:n. .............................................. 36 Tabell 9. Visar uppfyllnad av de kritiska kraven samt vilket huvudmål de påverkar. ............. 47

Tabell 10. Visar uppfyllnad av de önskade kraven samt vilket huvudmål det påverkar. ......... 47 Tabell 11. Visar uppfyllnad av huvudmål och delmål samt motivering till samtliga del och

huvudmål. ................................................................................................................................. 48

Förkortningar

CBR Case-Based-Reasoning

ECU Electronic Control Unit

FMEA Failure Mode and Effect Analysis

OBD On-Board-Diagnostics

QFD Quality-Function-Deployment

RPN Risk priority number

SDP3 Scania Diagnos & Programmer 3

1 (68)

1 Inledning I följande kapitel presenteras bland annat det som låg till grund för arbetet och vilka målen för

arbetet är. Utöver det presenteras även de formulerade forskningsfrågorna och

frågeställningen för fallstudien.

1.1 Bakgrund Inom fordonsindustrin kan ingen tillverkare utesluta att det inte finns fel på ett fordon trots

intensivt kvalitetsarbete och diagnostisering av fordonet då vissa fel bara kan uppenbaras efter

att fordonet tillhandahållits av kunden och varit under drift (Wedeniwski, 2015). En anledning

till varför fel inträffar trots noggranna åtgärder i produktutvecklingsfasen av fordon, är att under

de senaste åren har funktionaliteten och komplexiteten av fordonen ökat. Den ökade

komplexiteten av tekniska fordon bidrar till mer komplexa symptom när fel uppkommer under

användningsfasen hos fordonen (Bracke & Haller, 2012). Detta gör även att

felsökningssystemen blir viktigare för fordonens säkerhet och tillförlitlighet samtidigt som det

blir mer komplext att felsöka fordon (Huang, et al., 2008).

Scania CV AB är ett tillverkande företag av produkter för transportlösningar, så som lastbilar

och bussar. Samtidigt erbjuder Scania ett flertal tjänster kopplade till deras produkter gällande

reparationer och underhåll (Scania CV AB, 2018). Kristensson et al. (2014) påpekar att en

värdeskapande process kan skapas i kombination av tjänst och fysisk produkt för kunden. Det

innebär att det inte är själva lastbilen eller bussen som efterfrågas av kunden, utan istället

förmågan att kunna frakta gods mellan olika platser. Därför är det tillgängligheten av

transportlösningen som skapar värde för kunden. Detta innebär att tyngden ligger i vad

produkten gör och inte vad den är (Kristensson, et al., 2014). Genom att effektivt upprätthålla

Scanias produkters funktionalitet med välutvecklade felsökningssystem kan företaget skapa

konkurrenskraftiga värdeerbjudanden.

Inom Scania R&D arbetar YS-avdelningen med eftermarknad där utveckling av verktyg

kopplade till diagnosticering sker. YSNE-gruppen, som tillhör YS-avdelningen, ansvarar för

diagnosticeringen av styrenheter, Electronic Control Unit (ECU), kopplade till hytt och chassi.

YSNE arbetar huvudsakligen med utveckling av verktyget Scania Diagnos & Programmer 3

(SDP3), som framförallt används av mekaniker på Scanias verkstäder. SDP3 bygger på felkoder

som identifieras av styrenheterna i Scanias produkter. Om felkoder är aktiva kan SDP3

användas av mekanikerna för att åtgärda felet (Scania CV AB, 2017). Arbetet med SDP3

innebär bland annat att utveckla lösningar inom verktyget som både förbättrar tillgängligheten

för kundernas fordon och reducerar servicekostnader. Underhåll är en nödvändig aktivitet inom

de flesta mekaniska och dynamiska system vilket är både tidskrävande och kostsamt. För

fordonsindustrin är detta inte ett undantag. Inom underhåll är feldiagnos en kritisk aktivitet och

om det utförs effektivt och produktivt kan det spara tid, pengar och därmed öka tillgängligheten

för fordonsägare, då tillgängligheten ofta är deras källa för inkomst. Diagnostisering ses som

upptäckten av fel, isolering av fel och åtgärd (James, et al., 2018).

Verktyg, såsom SDP3, kan också betraktas som en produkt. Verktygen används i sin tur för att

tillhandahålla tjänster till Scanias huvudprodukter, det vill säga lastbilar och bussar. Ur ett

produktutvecklingsperspektiv kan diagnosticeringen ses som en kritisk del eftersom om

information kring produktens hälsa inte kan erhållas, kan inte lämpliga åtgärder utföras.

Lämpliga åtgärder kan exempelvis vara reparation eller vidare diagnosticering av fordonet.

2 (68)

Scania undersöker ständigt hur deras felsökningsprocesser kan förbättras. Ett sätt att förbättra

felsökningsprocessen är att ta fram ett verktyg som inkorporerar kundsymptom i

felsökningsprocessen. I ett initiativ från Scania har därför ett förslag lagts fram att undersöka

möjligheten att utveckla ett verktyg inom symptombaserad felsökning som kompletterar det

befintliga felkodsbaserade felsökningssystemet. Detta för att kunna hantera alla typer av fel,

vilket omfattar elektroniska, hydrauliska och mekaniska fel. Dessutom görs detta också för att

Scania eftersträvar att majoriteten av lastbilarna ska vara färdigdiagnosticerade innan de

kommer in till verkstäderna.

Verktygets princip bygger på att sammankoppla kundsymptom med systemreaktioner, och

sedan systemreaktioner med lämpliga åtgärder. I praktiken innebär detta att de angivna

kundsymptomen leder till lämplig åtgärd. I studien kommer kundsymptom betraktas som

kundens sätt att beskriva avvikelser hos ett system utan teknisk kompetens. I detta fall en

beskrivning av fordonets oväntade tillstånd. Exempelvis vibrationer, ljud, lukt och synliga

tecken så som rök och varningslampor. Systemreaktioner betraktas som de designade effekterna

felet har på ett systemet. Exempelvis om en ventil sitter fast så produceras en felkod och en gul

lampa börjar lysa på informationsklustret i fordonet. I detta fall är systemreaktionen både

felkoden som aktiveras samt att den gula lampan börjar lysa. Felet är att ventilen sitter fast, och

effekten av det blir systemreaktionerna.

I samband med att nya komponenter utvecklas till lastbilarna eller bussarna av Scania utförs en

så kallad Service Failure Mode and Effect Analysis (SFMEA). Detta för att bland annat

identifiera fel, så kallade felmoder, för olika komponenter och konsekvenserna som blir om

felmoderna uppstår (Scania AB, 2014). Scanias SFMEA är en variant av den traditionella

Failure Mode and Effect Analysis (FMEA). I studien kommer enbart termen FMEA att

användas för att erhålla en generaliserbarhet genom arbetet. Scania anser att denna datakälla,

FMEA, kan vara en relevant utgångspunkt för studien i och med att den innehåller information

kring systemreaktioner. Dessutom anser YS-avdelningen på Scania att detta är deras mest

pålitliga data inom området.

1.2 Problemformulering Problematiken med att endast använda sig av felkoder är att felkoder endast kan detektera några

av alla potentiella grundorsaker till ett problem. Detta gör att felkoder endast kan ge visst stöd

för diagnostisering och endast peka ut vissa felaktiga komponenter i systemet, beroende på

felkodens precision (James, et al., 2018). Scanias befintliga felsökningsprogram SDP3 är

anpassad för att hantera felkoder för diagnostisering av fordonen idag. Vissa system i fordonen

har i viss utsträckning ofta sensorer som i sin tur kan fungera som underlag för felkodsbildning.

Dock är det praktiskt och ekonomiskt omöjligt att förse alla fordonets delar med sensorer, vilket

innebär att det alltid kommer att finnas mekaniska fel vars uppkomst inte kan upptäckas och

identifieras med felkoder. I sådana fall kan inte mekanikerna instrueras av SDP3 för vilka

lämpliga åtgärder som måste utföras för ett observerat fel, och det blir då även svårt att kunna

upprätthålla den tänkta funktionaliteten hos produkten.

För att kunna hantera alla typer av fel har, som tidigare nämnts, ett förslag lagts fram att utveckla

ett verktyg inom symptombaserad felsökning. Problemet i dagsläget är dock att ingen

omfattande utredning har gjorts för att klargöra hur verktyget för symptombaserad felsökning

ska fungera. Dessutom finns problematiken att Scanias verkstäder runt om i världen inte är

konsekventa med hur insamlingen av kundsymptom utförs. Därför påverkas kvaliteten och

formen på den data som samlas in av hur verkstadspersonal väljer att dokumentera den. För att

systematisera sammankopplingen mellan kundsymptom och systemreaktioner måste därför

3 (68)

formaliseringen av kundsymptom först överses. Dessutom kommer även formaliseringen av

FMEA att utredas i och med att sammankopplingen anses grundas i FMEA. Därefter måste en

metod för sammankopplingen mellan kundsymptom och systemreaktioner identifieras för att

kunna erhålla en tillräckligt god träffsäkerhet mellan kundsymptom och åtgärd. God kvalitet på

metoden för sammankopplingen leder till en god kvalitet på felsökningen av Scanias

huvudprodukter, lastbilar och bussar, vilket i sin tur leder till att Scania kan säkra sitt

värdeerbjudande.

1.3 Syfte och mål Syfte: Syftet med studien är att få en matchning mellan kundsymptom och systemreaktioner

inom felsökning av tunga fordon. Dessutom ska studien utreda hur formaliseringen av

kundsymptom och verktyget Failure Mode and Effects Analysis (FMEA) bör se ut för att

möjliggöra denna sammankoppling.

Mål: Arbetet har två mål. Det ena är att utveckla en metod för att tydligt sammankoppla

kundsymptom med systemreaktioner inom tunga fordon (1). Metoden kommer att vara en

dellösning som ingår i det verktyg för symptombaserad felsökning. Det andra är att utveckla ett

format för kundsymptom och FMEA som kan tillämpas i den framtagna metoden för

sammankopplingen mellan kundsymptom och systemreaktioner (2).

För att uppnå målen definieras ett delmål med tillhörande kravlista. Varje krav i listan är kopplat

till minst ett huvudmål. Det finns både kritiska krav och önskade krav, för motivering av de

kritiska kraven, se Bilaga A – Motivering av kritiska krav.

Delmål: Uppfylla 10/10 av kraven, det acceptabla målvärdet är att uppfylla alla kritiska krav

5/5.

Kravlista:

Kritiska krav:

• Identifiera kategorier av data som är nödvändiga för att formalisera kundsymptom och

som möjliggör att en sammankoppling mellan kundsymptom och systemreaktioner kan

uppnås. Påverkar mål: (1), (2).

• Identifiera kategorier av data som är nödvändiga för att formalisera FMEA och som

möjliggör att en sammankoppling mellan kundsymptom och systemreaktioner kan

uppnås. Påverkar mål: (2).

• Identifiera vetenskapligt grundade felsökningsmetoder som kan tillämpas för att

sammankoppla kundsymptom med systemreaktioner. Påverkar mål: (1).

• Metoden skall kunna hantera kundsymptom som både grundas i elektroniska fel och

mekaniska fel. Påverkar mål: (1).

• Metoden skall ta hänsyn till den detaljrikedom av information som en kund är kapabel

till att ge kundmottagaren med sin tekniska kompetens. Påverkar mål: (1), (2).

Önskade krav:

• Metoden skall vara applicerbar inom samtliga system, som exempelvis broms- och

motorsystemet, i ett tungt fordon. Påverkar mål: (1).

• Metoden skall förebygga brister som existerar i den nuvarande initiala

felsökningsprocessen. Påverkar mål: (1).

• Metoden skall ta hänsyn till vad ”bra” data är för en felsökare. Påverkar mål: (1), (2).

4 (68)

• Metoden skall tillhandahålla möjlighet till förslag på åtgärd i framtida symptombaserat

felsökningsverktyg. Påverkar mål: (1), (2).

• Metoden skall vara tillämpbar till samtliga generationer av Scanias fordon. Påverkar

mål: (1).

1.4 Frågeställningar Forskningsfrågor:

• F1: Hur påverkas felsökningsprocessen utifrån de metoder som kan användas för att

sammankoppla kundsymptom med systemreaktioner inom tunga fordon?

• F2: Hur kan kunddata och FMEA formaliseras för att vara användbara inom

felsökningsprocessen av tunga fordon?

Fallstudie:

• Vilken data saknas i Scanias befintliga dokumentation för att kunna sammankoppla

kundsymptom med systemreaktioner?

1.5 Projektdirektiv Examensarbetet på 30 högskolepoäng utförs mot Scania AB under vårterminen 2020.

Tidsramen för arbetet är 20 veckor. Arbetet dokumenteras i en rapport som ska hålla en hög

teknisk nivå, och ska presenteras i arbetets slutskede. För att uppnå Mälardalen Högskolas

lärandemål ska även en opponering genomföras.

1.6 Avgränsningar

• Arbetet avser inte att behandla kopplingen mellan kundsymptom och lämpliga åtgärder

i ett symptombaserat felsökningssystem. Istället avser arbetet att behandla den initiala

kopplingen mellan kundsymptom och systemreaktioner.

• Arbetet avser att utveckla koncept, för att sammankoppla kundsymptom med

systemreaktioner, som använder befintliga felsökningsmetoder. Arbetet avser inte att gå

djupgående inom dessa felsökningsmetoder.

• Arbetet avser inte att praktiskt validera det slutgiltiga konceptet, istället utförs en

workshop i samband med konceptsållningen för att ta hänsyn till Scanias preferenser

och kunskaper. Samtidigt görs detta för att stödja att en god vetenskaplig nivå kan

erhållas i arbetet.

• Arbetet avser inte att behandla ekonomiska faktorer såsom kostnaden av att realisera

den framtagna metoden och/eller den eventuella kostnadsbesparingen för att nyttja

metoden i verksamheten.

5 (68)

2 Teoretisk referensram I följande kapitel kommer begreppet felsökning och symptom redogöras, samt kommer metoder

lämpade att använda vid felsökningsapplikationer att presenteras. Utöver detta presenteras

även principer för att formalisera kunddata.

2.1 Felsökning Felsökning kan betraktas som en problemlösningsform. En felsökning kan utföras inom flera

olika tillämpningsområden, exempelvis inom mekaniska och elektroniska system. Strategin för

att felsöka komponenter är att först identifiera komponenten som har ett avvikande beteende,

och vad som orsakar att komponenten inte kan utföra den önskvärda funktionen. Förutom

felidentifikationen, även kallad feldiagnos, omfattar felsökning även handlingar för att åtgärda

felen. En åtgärd kan vara reparation av komponenten, men när detta inte är möjligt så kan en

ersättning istället vara nödvändig. Dock menar H. Jonassen & Hung (2006) att den största

vikten inom felsökning ligger på den initiala felidentifikationen. Det huvudsakliga syftet med

felsökning är att komponenter ska återfå ett normalt beteende. Därför använder

felsökningsarbetare den insamlade feldiagnosdata för att kunna utföra relevanta åtgärder som

eliminerar felet (Hung & Jonassen, 2006).

Inom felsökning förekommer det flera utmaningar, och en del grundas i att problembilden för

ett fel kan vara väldigt stort. Det innebär att det kan finnas många potentiella orsaker till att ett

specifikt fel uppstår. Dessutom grundas alla fel inte alltid av en enda orsak, utan flera orsaker

kan tillsammans ha inverkan på att fel uppstår. Det ökar komplexiteten i att kunna minimera

felets problembild. En annan utmaning grundas i att en förutsättning för att kunna utföra

feldiagnoser oftast är att mekanikern besitter tidigare erfarenheter kring systemet och

komponenterna i fråga. Därför kan det vara komplext för oerfarna mekaniker att utbildas inom

felsökningsområdet (Hung & Jonassen, 2006).

Cegarra & Hoc (2006) beskriver feldiagnos som processen av att jämföra symptom med

syndrom, med syndrom menas då en bestämd kombination avvikelser medan symptomen är de

enskilda avvikelserna. Men det förekommer flera definitioner av feldiagnos-strategier. Det

påpekas att det finns två sätt att se diagnostik på. Den ena är strategier som utgår från det

nominella beteendet av en enhet och baseras på den fysiska strukturen, för att kunna genomföra

en positionsbaserad sökning eller en funktionell sökning. Den andra är strategier vilka vägleds

av det icke nominella beteendet. Exempelvis genom sökning av hypoteser som vägleds av

relationen mellan symptom och syndrom. I samband av de två uppdelningarna beskrivs ett

tredje sätt som negligerar en uppdelning. Den tredje beskrivningen grundar sig i att en

uppdelning av positionsbaserad och funktionell sökning inte är nödvändig för den

symptombaserade sökningen, detta då symptomen kan anpassas efter både funktionella och

positionsbaserade termer (Cegarra & Hoc, 2006).

2.2 Symptom Enligt Nationalencyklopedin (2020) kan symptom även skrivas som ”symtom”. Där beskrivs

även att symptom ofta används inom medicinsk terminologi som beskrivning av tecken på en

viss sjukdom (Nationalencyklopedin, 2020) (Cegarra & Hoc, 2006). Exempelvis som en

sjukdomsyttring som uppfattas av den sjuka personen och yttrar sig genom obehag eller lidande

som följd av en sjukdom (Nationalencyklopedin, 2020). Cegarra & Hoc (2006) nämner att

symptom är en del av diagnostiken vilket omfamnar områden utöver medicin så som process

kontroll och felsökning. Ord som ”symtombild” och ”symtomfri” benämns även i sammanhang

med symptom (Nationalencyklopedin, 2020). Bergmann et al. (2003) beskriver i samband med

felsökningsmetoder att symptom används vid diagnostik av fordon. Beskrivning av ett fall inom

6 (68)

en felsökningsmetod kan göras genom de observerade symptomen hos fordonet. Symptomen

kan exempelvis vara en problembeskrivning (exempelvis, motorn startar inte),

kontextparametrar (exempelvis, tändningsnyckeln är vriden) eller mätparametrar (exempelvis

värden för hur en elektronisk enheten mår genom mätningar med testverktyg) (Bergmann, et

al., 2003).

2.3 Felsökningsmetoder I följande kapitel presenteras metoder som kan användas i felsökningssammanhang.

Bayesiska nätverk

Inom diagnos kan probabilistiska metoder som grundas i sannolikhetslära tillämpas. En metod

som används frekvent vid diagnosapplikationer är Bayesiska nätverk. Metoden kan användas

för att beräkna sannolikheten att ett specifikt fel hos ett system eller en komponent förekommer.

En förutsättning för att kunna utföra sannolikhetsberäkningen är att en grafisk modell först tas

fram. I denna modell redogörs relationer och beroenden mellan fel som kan förekomma och

observationer som kan göras när felen uppstår (Warnquist, 2015), se Figur 1. I Bayesiska

nätverk betraktas felen och observationerna som noder. Förutom fel och observationer kan även

symptom användas som noder (Huang, et al., 2008). Noder som påverkar andra noder i den

grafiska modellen kan betraktas som ”parent nodes”. Noder som är direkt beroende av andra

”parent nodes” betraktas istället som ”child nodes” (Kurz, et al., 2011). I Bayesiska nätverk är

det viktigt att beroendena mellan noderna inte är cykliska. Därför kan ett Bayesiskt nätverk

betraktas som ett så kallat ”riktat acykliskt diagram” (Huang, et al., 2008).

Figur 1. Visar hur ett Bayesiskt nätverk kan presenteras grafiskt med noder och relationer. Figuren är baserad på en figur

framtagen av Huang et al. (2008).

I utförandet av ett Bayesiskt nätverk bestäms respektive nods sannolikhetsdistribution, i en

tabell, efter att beroendena i den grafiska modellen har definierats. Hur nodernas sannolikhet

bestäms beror på typen av nod. Till ”parent nodes” som inte är beroende av några andra noder

kan sannolikheten bestämmas genom att studera statistiska data, eller så kan den erhållas genom

tidigare erfarenheter. Sannolikheten till ”child nodes” bestäms istället av ”parent nodes”, vilket

innebär att sannolikheten blir i detta fall villkorlig. En ”child nodes” sannolikhet grundas alltså

i andra påverkande sammankopplade noders status (Huang, et al., 2008).

Bayesiska nätverk kan tillämpas till system som är väldigt komplexa i sin natur, exempelvis

fordon med ett stort antal ingående system och komponenter. Dessutom förutsätter inte metoden

att samtliga data, till exempel data gällande observationer, har identifierats, utan metoden kan

7 (68)

tillämpas ändå (Kurz, et al., 2011). Dessutom kan Bayesiska nätverk bli smartare då ny data

tillförs (Warnquist, 2015).

Case-Based Reasoning

Case-Based-Reasoning (CBR) är en metod som kan tillämpas vid komplexa

felsökningsapplikationer. Metoden har sitt ursprung från maskininlärningsområdet, ”machine

learning”. Principen för metoden är att identifiera lösningar till nya problem genom att

sammankoppla tidigare fall av lösta problem. Detta kan liknas med människans naturliga

tillvägagångsätt för att lösa problem (Yu, et al., 2015). Fallen av lösta problem beskrivs i så

kallade ”cases”, och dokumenteras efter att felsökningsprocessen är avklarad och validerad

(Warnquist, 2015). Formaliseringen på fallen är i största grad standardiserad. Varje fall

innehåller huvudsakligen två typer av information som tidigare nämnts; problem och lösning.

Problembeskrivningen utgörs främst av observationer som användaren kan göra när ett fel har

uppstått. Lösningen innehåller istället information kring vilka aktiva åtgärder, i detta fall

reparationer, som gjordes för att eliminera felet som orsakade problemet (Yu, et al., 2015).

Dokumentation av fallen sker i ett bibliotek, i en så kallad ”case library”. Biblioteket används

sedan som underlag när nya problem hos system ska diagnosticeras. Informationen i fallen

jämförs med tidigare dokumenterade fall i biblioteket, och uppstår det en matchning

rekommenderas lösningen från det tidigare fallet. Dock om det inte sker någon matchning kan

istället användaren instrueras att utföra vissa relevanta observationer. Genom att tillföra

kompletterande information kan en matchning eventuellt ske. En förutsättning för att kunna

utföra felsökningar när nya problem uppstår är att det finns tidigare fall i biblioteket. Därför

utförs oftast initialt manuella felsökningsprocesser för att tillföra fall i biblioteket som

möjliggör att matchningar mellan nya och tidigare fall kan göras. En nackdel med CBR är att

felsökningskvaliteten är direkt beroende av tid, och därför är inte alltid metoden tillförlitlig till

en början (Warnquist, 2015).

Matchningen av ett liknande fall görs genom en så kallad ”retrieval” (hämtning). Det finns flera

sätt att utföra en hämtning på vilket ofta påverkas av fallets representation i ”case library”.

Exempelvis om det använts ett textbaserat CBR-system för dokumentationen används en

nyckelordsdriven metod för att hämta fallet. Däremot om CBR-systemet har använts med ett så

kallat ”konversions-CBR-system” har systemet en mer djupare och mer avancerad kodning

bakom sig för att kunna möjliggöra en hämtning av fallet (Bergmann, et al., 2003).

”Konversations-CBR-system” är CBR-system som framkallar en fråga för att beskriva ett

problem, ofta i användning för att minimera problembilden och komma fram till en lösning

(Aha, et al., 2006). Det nämns även att CBR-system som följer ett strukturerat tillvägagångsätt

ofta går att skräddarsy utefter hur matchningen mellan fallen sker och då hämtningen av fallet

sker. Tekniken som används för detta kallas ”nearest neighbour” och utgår från att den globala

likheten mellan fall kan matchas. I tekniken kan funktioner eller andra värden som nummer och

symboler användas för att göra en matchning mellan fallen. I samband med textbaserade CBR-

system nämner Bergmann et al. (2003) att det är orealistiskt att ens en tränad kundmottagare

skall kunna alla nyckelord vid sökning efter fall i ett ”case library”. Inte heller kan då förvänts

att en kund kan alla nyckelord (Bergmann, et al., 2003).

CBR kan betraktas som en metod som relativt enkelt kan identifiera lösningar på problem. Detta

grundas i att nya fall jämförs med tidigare fall för att identifiera lämpliga lösningar. Vilket

innebär att den bakomliggande logiken för sammankopplingen mellan fel och lösning inte

behöver utredas. Dock kan avsaknaden av logik medföra att träffsäkerheten mellan fel och

8 (68)

korrekt lösning kan försämras. Dessutom kan det vara svårt att erhålla en god feldiagnos när

symptom inte bara grundas i ett enda fall (Yu, et al., 2015).

Felträdsanalys

Felträdsanalys (FTA) är en ofta förekommande metod som används inom spridda branscher.

En FTA:s huvuduppgift är ofta att bidra med pålitlighet och utvärdering av säkerhet i stora

komplexa och säkerhetskritiska system (Bobbio, et al., 2001). FTA har även föreslagits av

forskare som metod för att hitta potentiella fordonsfel, genom att systematiskt analysera

fordonets system, delsystems och komponenters grundorsaker till fel. Under senare år har FTA

exempelvis används för att diagnostisera fel inom fordonsindustrin (James, et al., 2018). Det

finns flera typer av felträdsanalyser varav en är standarfelträd (SFT). Ett SFT passar till statiska

system medan det finns felträd som är skräddarsydda för dynamiska system, så kallade

Dynamiska Felträd (DFT). Dynamiska felträd är utvecklingar av standarfelträd (Kabir, 2017).

Standardfelträd – SFT

Uppbyggnaden av SFT bygger på att ansvarig för uppbyggnad av trädet har förståelse av

systemets struktur samt principer inom systemet (Yu, et al., 2015). Metodens struktur baseras

på att oönskade händelser och felsymptom analyseras, det kan exempelvis vara ett systemfel i

ett fordon. Det oönskade felsymptomet sätts som Topp-händelse (TH) i strukturen av trädet.

Strukturen bygger sedan på att en bakvänd metod där utgångspunkten är TH och jobbar mot att

hitta grundorsaken till problemet genom att gå mot trädets grenar och löv. Detta betyder att

strukturen av ett SFT följer en ”top-down” approach (Bobbio, et al., 2001). Ett SFT erbjuder

även en grafisk presentation av hur felsymptom och kombinationer av felhändelser leder till det

innan nämnda grundorsaken till problemet. Det som ofta presenteras grafiskt som det logiska

trädet är en översättning av det fysiska systemets logiska struktur till ett logiskt diagram i form

av ett SFT (James, et al., 2018). Den visuella presentationen hjälper användare att utföra

felsökning på ett lämpligt sätt (Yu, et al., 2015). Förutom den visuella fördelen med ett SFT, är

att resultatet visar hur olika komponenters felsymptom eller miljörelaterade förhållanden

tillsammans skapar systemets fel (Kabir, 2017). Vid analys av ett färdig konstruerat SFT utförs

analysen ofta genom två nivåer, så kallade kvantitativ och kvalitativ analys. En kvalitativ analys

används oftast för att reducera antalet grundhändelser till det minsta antalet nödvändiga, för att

hitta orsaken till topp-händelsen (TH). Detta görs ofta genom att beräkna sannolikheten av

underliggande noders gemensamma sannolikhet, (förhållandet mellan dessa sannolikheter beror

på händelsernas relation med varandra) för att sedan jämföras mellan grenarna i trädet.

Kvantitativanalys av ett SFT innebär oftast att sannolikheten och/eller någon annan typ av

mätbardata, används för att räkna ut vilken individuell komponent av systemet som med största

sannolikhet innehar det grundläggande felet (Kabir, 2017) (Ruijters & Stoelinga, 2015). För

mer information om grindar och symboler som kan används i ett SFT, se Bilaga B –

Symbolbeskrivning av felträdsanalys.

Dynamiskt felträd – DFT

Standardfelträd är endast kapabla till att utvärdera statiska system. Ett statiskt system är ett

system som endast har ett typ av läge under drift, vilket gör att påfrestningen av system är

konstant och förändras inte beroende på systemets driftläge. Stora komplexa system så som

moderna tunga fordon, har däremot flera driftlägen vilket gör att ett SFT inte är tillräckligt för

att bevaka pålitligheten. En skillnad mellan driftlägen kan till exempel vara hur ett fordon

opererar i ett stillastående läge och hur det opererar i ett drivande driftläge. En konsekvens av

dynamiska system blir att fel uppstår som är karakteristiskt-urskiljbara i relation till

funktionsrelaterade händelser för olika driftlägen av de dynamiska systemet. Dynamiska

pålitlighetsbedömningar har många fördelar över statiska pålitlighetsbedömningar, genom

9 (68)

möjlighet till analys av dynamiska system kan det dynamiska angreppssättet inhämta

information från flera typer av stadier i ett system. Det kan även modellera flera senarior av

interaktion mellan olika komponenter och variabler. Ett dynamiskt system har även möjlighet

till att fånga tid- och sekvensberoende beteenden i komplexa system (Kabir, 2017). Det finns

flera typer av dynamiska pålitlighetsbedömningar varav den vanligast använda är DFT, vilket

också är en typ av utveckling av ett SFT (Ruijters & Stoelinga, 2015). Ett dynamiskt felträd står

ut från mängden på grund av förmågan att kunna behandla sekventiella beteenden av system

(Kabir, 2017). För att det sekventiella beteendet skall kunna analyseras används vanligtvis två

till typer av grindar i ett DFT, Funktionellt Beroende (FB) grindar och RESERV grindar. Med

sekventiellt beteende menas ett beteende vilket återkommer i en sekvens (Ruijters & Stoelinga,

2015).

Automatiskt genererarbara felträd

FTA: er utförs oftast manuellt, men med växande komplexitet av system finns ett behov av att

simplifiera FTA:er. Under senare år har därför forskare utforskat möjligheten till att

åstadkomma pålitlighetsinformation från systemmodeller automatisk och semiautomatisk.

Enligt Kabir (2017) har det lett till utveckling inom området ”Modellbasserad

Pålitlighetsanalys” eller på engelska ”Model-based Dependability Analysis” (MBDA). Flera

MBDA tekniker baseras på felträd som grunden för teknikens pålitlighetsanalys. Det finns flera

tekniker för MBDA några av dem är ”Failure Propogation and Transformation Notation”

(FPTN), ”Hierrarchically Performed Hazard Orgin & Propogation Studies” (HiP-HOPS) och

”AltaRica” (Kabir, 2017).

2.4 Formalisering av kundsymptom Här presenteras i flera delar den identifierade litteraturen gällande formalisering av

kundsymptom. Delarna presenterar bland annat hur en oerfaren felsökare ställer sig mot en

erfaren felsökare och vilka kunskapsområden felsökare använder vid felsökning.

Jämförelse mellan erfaren och oerfaren felsökare

Enligt Hung & Jonassen (2006) finns det flera skillnader mellan erfarna och oerfarna felsökare.

Lärande oerfarna felsökare bygger ofta upp kunskapsrika mentala konceptuella modeller av alla

olika ingåendesystem som exempelvis ingår i ett fordon, en erfaren felsökare däremot litar mer

på mentala händelsescheman som byggs upp utefter erfarenhet. Oberoende av vilket område

felsökning utförs inom exempelvis medicin eller fordon, visar forskning på att en frekvent

exponering av så kallade ”sjukdomsbeskrivningar” giver felsökaren kunskap av

symptommönster och ett mentalt händelseschema kan byggas upp. Symptommönster kan

användas som kunskap och är tendenser av att specifika delar går sönder i specifika

fordonsmodeller och feltillstånd. Vad som gör informationen användbar hos en erfaren

felsökare jämfört med en oerfaren, är att en erfaren felsökare har en större mängd relaterbara

händelser med sin erfarenhet att relatera till. Hung & Jonassen (2006) beskriver några punkter

för vilka nivåer av kunskap olika erfarenhetsnivåer av felsökare kan besitta:

• Förståelse för systemens olika syften och mål.

• Förståelse för övergriplig struktur och funktion.

• Generaliserad förståelse för standardfunktioner och processer för systemet.

• Förståelse för fysisk struktur och funktioner av systemet, exempelvis mekaniska och

elektrisk komponenter vad dem gör och deras betydelse.

• Förståelse för systemets struktur, funktioner, ”informationstopologi” (koppling emellan

del-system och hur dem samarbetar) och materialkunskaper.

10 (68)

I högsta grad kan en oerfaren felsökare ha en övergripande förståelse för struktur och funktion

medans en erfaren felsökare förstår systemets struktur fullt ut, vart del-system sitter, hur varje

del har sin funktion och hur flödet av funktioner och information i systemet hör ihop (Hung &

Jonassen, 2006).

Hung & Jonassen (2006) presenterar flera kunskapsområden inom vilka erfarna och oerfarna

felsökare utnyttjar olika information.

(1) Domänkunskap är generellkunskap om teorier och principer som rör system och del-

systems, exempelvis specifika materialkunskaper så som korrosionsbeständighet eller principer

som Ohm`s lag. Domänkunskap är inte en viktig del för att bli en erfaren felsökare, däremot är

det viktigare i den meningen att få djupare kunskap och förstå grunder till felorsaker (Hung &

Jonassen, 2006). Erfarna felsökare har ofta en djupare förståelse och kunskap av

domänkunskaper än oerfarna felsökare (Cegarra & Hoc, 2006).

(2) Systemkunskap ses som kunskap av strukturen i systemet, funktionerna av komponenterna

i systemet och beteendet av komponenterna och beteendet i samspelet med andra komponenter.

Den största skillnaden mellan erfarna och oerfarna felsökare ses som kunskapen av systemet

(Hung & Jonassen, 2006). Forskare har kommit fram till att erfarna felsökare använder

topografiskkunskap för att bestämma felorsak av fordon på ett systematisk sätt (Hung &

Jonassen, 2006) (Cegarra & Hoc, 2006). En topografisk modell av ett system är en rumslig

presentation av systemet. I fordonsindustrin innebär topografisk kunskap positionen av

systemets alla ingående komponenter, till exempel positionen av komponenterna i en motor

eller bromssystem. Topografiskkunskap har visat sig effektivt för att bryta ner problembilden.

Jämfört med oerfarna felsökare som inte har sådan kunskap skapar teorier av felorsaken

slumpmässigt, vilket inte är lika effektivt för att hitta felorsaken till problemet. Lika väl som

topografiskkunskap är funktionellkunskap viktigt för felsökare. Funktionellkunskap är

förståelse för varje individuell komponents funktion och relation till andra komponenter.

Funktionellkunskap kan exempelvis vara hur gnist och valv synkroniseringen påverkar

kompressionen i en motor. Många erfarna felsökare organiserar ofta sin mentala topografiska

karta utefter funktioner i förstahand. Oerfarna felsökare har en tendens till att skapa

lösningsteorier till felorsaker mer på den topografiska kunskapen, som nämnt innan är oftast

även kunskapen begränsad inom detta område. Även fast att både topografiskkunskap och

funktionskunskap båda är två bra källor att basera en hypotetisklösning på, använder oftast

erfarna felsökare den funktionella kunskapen i första hand som en metod för att skapa en mental

visuell problembild. Felsökning baserad på funktionellkunskap leder oftast felsökaren till

felorsak effektivare (Hung & Jonassen, 2006). Cegarra & Hoc (2006) förklarar även att ett

topografiorienterat tillvägagångsätt har två variabler att ta hänsyn till, vilka är bedömningen av

symptomets relevans och hur vidare positionen är korrekt.

(3) Prestanda- och procedurkunskap handlar om kunskap relaterad till mätningar och

utförande av tester. Sådan kunskap sker till stor del automatiskt genom sensorer i modernare

fordon. Även är utförande av rutinarbete så som service och underhåll kopplad till prestanda-

och procedurkunskap. Utförandet av kunskapen är oftast begränsad till just det specifikt lärda

systemet eller del-systemet. I dagens läge finns det ofta felsökningssystem som assisterar

felsökaren med prestanda- och procedurspecifik kunskap för varje individuell fordons modell.

Genom att kunskapen är så pass automatiserad är det oftast ingen större skillnad på erfarna och

oerfarna felsökare inom kunskapsområdet prestanda- och procedurkunskap (Hung & Jonassen,

2006).

11 (68)

(4) Strategiskkunskap är kunskap relaterad till vetskap av vad som skall felsökas i första eller

nästa steg om felorsak inte kan urskiljas samt att bekräfta hypoteser för felorsaken. Författarna

beskriver att strategiskkunskap är en väsentlig del i att isolera potentiella fel. En klassificering

kan göras gällande strategiskkunskap. Strategiskkunskap kan delas upp i lokal- och global-

strategi. Globalstrategi är strategikunskap oberoende av systemet och området. Det betyder att

kunskap som är globalt strategisk kan användas för flera system och del-system inom olika

områden, så som mekaniska eller elektroniska. Lokalstrategikunskap klassificeras som kunskap

som endast kan användas inom ett specifikt system, komponent eller område, så som

instrumentbräda, varvmätare och elektronik. Hung & Jonassen (2006) nämner att

globalstrategikunskap hjälper felsökare att minimera problembilden medans

lokalstrategikunskap assisteras felsökaren i att utföra en reduceringsprocess. Inom strategisk

kunskap finns det ett antal kända strategier för att systematiskt genomföra felsökning, dem

specifika strategierna är oftast mer användbara för oerfarna felsökare än för erfarna felsökare.

Erfarna felsökare använder sig mer av erfarenhet än specifika felsökningsstrategier. Vid

felsökning av mycket komplexa system kan det vara fördelaktigt för en erfaren felsökare att

också använda en specifik felsökningsstrategi (Hung & Jonassen, 2006).

(5) Erfarenhetskunskap har bevisats i flera studier vara den mest användbara typen av kunskap.

Vid diagnostisering har erfarenhetskunskap visats vara det vanligaste sättet för att strategiskt

gå fram i ett felsökningsperspektiv. Enligt Hung & Jonassen (2006) har även forskare kunnat

konstatera att felsökare grundar hypoteser om felorsak då där finns ett avvikande symptom som

kan ge felsökaren insikt i orsaken. Vidare har där även bevistats att erfarna felsökares vanligaste

handling mot att lösa ett problem, är att undersöka det vanligaste felet utefter erfarenhet.

Erfarenhetskunskap visar sig vara den mest användbara kunskapen för felsökare, vilket också

är den största skillnaden mellan en erfaren och en oerfaren felsökare (Hung & Jonassen, 2006).

En skillnad mellan erfarna och oerfarna felsökare är att erfarna felsökare är bättre på att bedöma

ifall ett symptom är korrekt eller inte. Samtidigt är en erfaren felsökare även bättre på att

identifiera potentiella symptom (Cegarra & Hoc, 2006).

Kund och kundmottagare

När en kund beskriver ett symptom beskriver kunden ofta felet utefter vad kunden observerar.

Kunden besitter i generell mening ingen teknisk kunskap om fordonet vilket gör att

observationerna som görs av kund vid observerade avvikelser från det nominella beteendet ofta

inte är av analyserad karaktär. Med analyserad karaktär menas att kunden inte drar några

slutsatser kring det observerade symptomet. Faktumet att kunden inte drar slutsatser från det

observerade symptomet visar på att teknisk kunskap saknas om fordonet. Om samma symptom

observeras av en erfaren kundmottagare beskriver oftast kundmottagaren symptomet som en

direkt felorsak. Exempel på ett sådant scenario skulle kunna vara om kunden observerar att

fordonet inte har någon tändning vid uppstart av fordonet, symptomet skulle kunna beskrivas

som ”inget vrid i motor, när nyckel vrids om”. Kundmottagaren given samma observation

beskriver symptomet istället som ”urladdat batteri”. Faktumet att kundmottagaren beskriver

symptomet som felorsak indikerar då på ett tekniskt kunnande om fordonet (O`Neill, et al.,

2005).

Kundmottagare har i många fall en roll som översättare mot kunden. Kundmottagare översätter

ofta det mer vardagliga språket som kunden beskriver symptomen i till mer tekniska termer.

Konversationen mellan kund och kundmottagare sker ofta i mer vardagligt språk.

Översättningen kundmottagaren gör utförs ofta av två anledningar. För det första för att

symptom eller felorsakbeskrivningar i de felsökningsprogram som kundmottagaren jobbar mot

ofta använder mer tekniskt korrekta termer vilka är okända för kunden. För det andra på grund

12 (68)

av att kunden saknar tekniskt kunnande kan inte kunden medla i tekniska termer eller förstå den

tekniska informationen kundmottagaren har tillhandahållet. Det är tydligt att kundmottagaren

har en viktig roll i förädlandet och tolkningen av vad kunden observerar, för att kunna förmedla

vidare information i felsökningsprocessen (O`Neill, et al., 2005). Forskare menar på att kunden

inte skall behöva ha ett tekniskt kunnande för att kunna beskriva sina felsymptom på ett sätt

som är värdefullt för kundmottagaren. I situation där kunden skall beskriva symptom utan

assistans av kundmottagare som översättare av kundens symptom, är det också viktigt att

beskrivningen kan ges på ett sätt som kunden är kapabel till att utföra. Eventuellt genom ett mer

vardagligt språk i form av symptom istället för i form av felorsaker och lösningar (O`Neill, et

al., 2005) (Bergmann, et al., 2003).

Kundmottagaren har även en viktig roll att, med hjälp av kunden medla för att komma fram till

felorsaker. På grund av kundens lägre grad av tekniskt kunnande kan observerbara symptom

ibland vara svåra att observera. På grund av det är kundmottagaren också ett form av bollplank

mot kunden för att tillsammans komma fram till fler symptom som annars kunden inte hade

observerat utan kundmottagarens hjälp. Kunden kan även göra egna bedömningar av vikten av

ett symptom. Exempelvis kan kunden anse att symptomet inte har någon informationsmässig

tyngd för att resultera i en felorsak. Det kan leda till att kundmottagaren inte får all den

tillgängliga informationen som behövs för att göra en korrekt diagnostisering direkt.

Kundmottagaren kan då behöva ställa följdfrågor för att vara säker på att all relevant

information samlats in (O`Neill, et al., 2005).

För att symptom skall vara aktuella understryker O`Neill et al. (2005) att där bör finnas ett sätt

att uppdatera eller tillföra symptom i felsökningssystemet. När kundmottagare inte är

närvarande är det även relevant att ge kunden information om vilka steg som måste genomföras

för att kontrollera symptomens relevans. Det ska då ge kunden möjlighet att själv kunna

minimera problembilden. När kundmottagare inte är tillgänglig är det även viktigt att ge kunden

möjlighet till att kunna söka både på tekniska termer och vardagliga språktermer. På så sätt kan

kunden utnyttja den tekniska kunskapen kunden besitter, samtidigt som kunden kan utnyttja

vardagliga termer där kunden inte besitter teknisk kompetens (O`Neill, et al., 2005).

2.5 Failure Mode and Effect Analysis (FMEA) Failure Modes and Effects Analysis (FMEA) är en metod för att identifiera fel som kan uppstå

hos en produkt (Ullman, 2010). Khan et al. (2014) beskriver att FMEA är en väl använd metod

för att identifiera och eliminera kritiska fel som påverkar pålitligheten i ett system. Ofta används

metoden för att förbättra pålitligheten hos ett system innan dess systemet lanseras på

marknaden, då designförändringar fortfarande är möjliga inom en rimlig kostnad (Khan, et al.,

2014). Inom fordonsindustrin är det vanligt att använda sig av FMEA för att utvärdera

pålitligheten och potentiella fel både i design- och funktionselementen av ett system. Att

kombinera en FMEA-analys med en design för en komponent är ett vanligt utförande i

fordonsindustrin (Teng & Ho, 1996). FMEA kan även användas vid felsökning av produkter då

fel och åtgärder har kartlagts. I detta fall omfattar definitionen av fel både orsaken till att felet

uppstod, och vilken funktion hos produkten som felet påverkar. Utförandet av en FMEA

grundas i fem steg; ”Identify the Function Affected”, ”Identify Failure Modes”, ”Identify the

Effect of Failure”, “Identify the Failure Causes or Errors”, och “Identify the Corrective

Action” (Ullman, 2010).

Det första steget handlar om att avgöra vilken funktion hos produkten som felet påverkar. Det

andra steget handlar istället om hur felet artar sig, och hur det synliggörs. I det tredje steget

undersöks andra funktioner än den som är direkt påverkad av felet. Detta beror på att ett fel kan

13 (68)

innebära att andra fel också uppstår. Därför undersöks och beskrivs övriga potentiella effekter

av felet. Efter detta arbete startar det fjärde steget som handlar om att identifiera det

bakomliggande felet. Ullman (2010) menar att felen kan kategoriseras enligt följande; designfel

(D), tillverkningsfel (M) och operationella fel (O). Det slutgiltiga steget handlar om att utreda

och dokumentera vilka handlingar som åtgärdar respektive fel. I det här steget listas handlingar

som rekommenderas att utföras, och vilken medarbetare inom organisationen som ska utföra

handlingen. Ibland kan det vara en annan åtgärd än den rekommenderade som löste felet. Därför

är det viktigt att dokumentera den åtgärd som verkligen fungerade. Om ett fel är ett design-

eller tillverkningsfel är åtgärden för att minimera risken att felet uppstår oftast att göra vissa

förändringar i produktens design. Därför dokumenteras dessa förslagna designändringar.

Däremot om felet är operationellt, så kan det vara mer relevant att utveckla en rutin för att

enklare upptäcka felet. Dock så kan designändringar även underlätta vid operationella fel för

att felets inverkan på funktionen inte ska bli lika stort (Ullman, 2010). Riskprioritetsnummer -

”Risk priority number” (RPN) kan ansättas för felmoder i en FMEA. Värdet för RPN består

ofta av tre faktorer, upptäckbarhet - ”detectability”, förekomst - ”occurrence” och

allvarlighetsgrad - ”severity” (Khan, et al., 2014). Värdena för varje faktor utgår oftast från en

10 gradig skala, där ett lågt nummer eftersträvas. RPN-värdets faktorer kan även bedömas

individuellt. Exempelvis om en felmod har en hög faktor för allvarlighetsgraden kommer den

anses som en kritisk felmod, däremot kan en kritisk felmod fortfarande ha ett relativt lågt RPN-

värde om den har en låg faktor för förekomst (Teng & Ho, 1996).

FMEA - I felsökningssammanhang

FMEA är ett typiskt sätt att förutse potentiella fel av ett system. Med informationen från

metoden kan ingenjörer avgöra hur ”On-Board-Diagnostics” (OBD) teknik kan upptäcka

potentiella fel. OBD är en dataenhet vilket övervakar och producerar felkoder i en lastbil. Med

informationen från FMEA kan även felsökningsaktiviteter förberedas, aktiviteterna gör det

sedan möjligt att hitta felets grundorsak från alla möjliga potentiella orsaker. Khan et al. (2014)

menar på att aktiviteter för felsökning samlas i felsökningsmanualer. Manualerna används

sedan manuellt av kompetent personal för att avgöra grundorsaken till ett potentiellt fel.

Manualerna är inte felfria, vilket betyder att manualerna inte är helt korrekta eller kan ge stöd

för alla potentiella fel, men det förespråkas heller inte att manualerna är det. Samtidigt uppdagas

ändå att det är viktigt att uppdatera materialet för FMEA som om det vore ett dynamiskt

dokument med ny information och kunskap gällande potentiella felorsaker. Där påpekas även

att FMEA-analyser användas för att bidra till utvecklingen av effektiva underhålls-,

felsöknings- och reparationsaktiviteter samt underlag till underhållsmanualer och OBD-system

i flera branscher. Det är ingenjörer som förutser de potentiella felen i en FMEA, men på grund

av den mänskliga faktorn kan ingenjörerna inte förutse alla fel. Om ett fel uppstår som står

utanför de identifierade potentiella felen, löses problemet ofta av kunskap på verkstäder

(fältkunskap). Lärdomar som görs från felen som inte har förutspåtts av ingenjörerna genom

FMEA lämnas ofta odokumenterade, även fast där finns viktiga lärdomar att göras från dessa

lösta fall (Khan, et al., 2014).

Det har uppdagats att det gynnar arbetsflödet för felsökningen med fälterfarenhet. I samband

med fälterfarenhet av underhåll och reparationer är det positivt med delandet av erfarenhet

mellan parter. Vidare spridning av nya erfarenheter kring ett system kan leda till att andra parter

inom ett företag exempelvis, avdelning för reparation och underhåll kan lösa problem snabbare.

Att spara ned fälterfarenhet inom underhåll och reparationer kan även över tid hjälpa den

utvecklande sidan i ett företag att förbättra pålitligheten av system och komponenter. Khan et

al. (2014) menar med detta att fälterfarenhet hade gynnat utvecklingen av arbetsflödet för

felsökning om informationen förmedlas tillbaka till ingenjörerna som utför FMEA (Khan, et

al., 2014).

14 (68)

Med FTA är det möjligt att räkna ut pålitligheten av att system. Däremot är det nödvändigt att

identifiera de potentiella felen innan en FTA utförs. En FMEA kan användas för att ge en FTA

information angående de potentiella felen i ett system. Detta görs möjligt genom att översätta

data i en FMEA till matematiska modeller. Modellerna används sedan för att implementera i en

FTA. En FTA möjliggör sedan att det går att peka ut enskilda potentiella fel i komplexa system.

Det föreslås att standardiserade kontroller bör göras så att fälterfarenhet och numerisk data kan

samlas in på ett standardiserat sätt. Ren numerisk data från fälterfarenhet kan konverteras till

sannolikhetsdata. Att återkoppla data från fält gällande sannolikhet för exempelvis

komponenter, hade varit fördelaktigt för RPN-värdet i en FMEA. RPN-värdet i FMEA kan

stödja sannolikheten för olik komponenters sannolikhet för potentiella fel, vilket vidare kan

användas i en FTA. Fördelaktigheten med att basera RPN-värdet på fältdata är att talet blir

trovärdigt, och om detta görs kontinuerligt kan det även vara en bevakning över komponenter

och olika designval för komponenter, hur dem presterar och mår ute på fält (Teng & Ho, 1996).

15 (68)

3 Metod I följande kapitel presenteras metoden som har tillämpats genom hela arbetet.

3.1 Produktutvecklingsprocessen

Arbetet innehåller både en litteraturstudie och en fallstudie, där litteraturstudien kan ses som ett

förarbete till fallstudien. Tillvägagångsättet som har följts under arbetet baseras på

produktutvecklingsprocessen beskriven av Ulrich & Eppinger (2012). Denna

produktutvecklingsprocess innehåller sex olika faser; ”Fas 0: Planering, Fas 1:

Konceptutveckling, Fas 2: Utveckling på systemnivå, Fas 3: Detaljutveckling, Fas 4: Testning

och vidareutveckling samt Fas 5: Produktionsupptakt (Ulrich & Eppinger, 2012). Eftersom

arbetet inte avser att resultera i en färdig produkt, utan endast i ett metodförslag, måste vissa

faser exkluderas eller anpassas. För att vara lämpad för arbetets ändamål utformades därför en

egen produktutvecklingsprocess med bas i den tidigare nämnda processen, se Figur 2. Fas 0

omfattar bland annat litteraturstudien, medan Fas 1 och 2 omfattar fallstudien.

Figur 2. Visar produktutvecklingsprocessen som har tillämpats under arbetet.

3.2 Litteraturstudie Litteraturstudien utfördes inom områdena kunddata, FMEA och felsökningsmetoder för att

skapa en bas till den kommande fallstudien. Det fanns två mål med att utföra litteraturstudien.

Det första målet var att samla in data angående tidigare forskning inom respektive område.

Detta gjordes för att kunna identifiera vilka metoder och principer som senare skulle kunna

tillämpas vid konceptgenereringen i fallstudien. Det andra målet var att kunna stödja

fallstudiens slutsatser med vetenskapliga artiklar vilket anses öka arbetets generaliserbarhet.

Utöver de ovan nämnda områdena studerades även begreppen felsökning och symptom för att

kunna erhålla relevanta ämneskunskaper. Då arbetet grundades i felsökning och symptom

ansågs det fördelaktigt att erhålla en allmän förståelse kring dessa begrepp i samband med att

arbetet uppstartades.

Innan insamlingen av litteratur påbörjades bestämdes ett flertal begränsningsfaktorer för att

erhålla en högre relevans på litteraturen (Bell, 2006). Begränsningsfaktorerna som bestämdes

var bland annat; tidsintervall 2005-2020, litteratur som är expertgranskad och att antalet resultat

vid sökning inte får överskrida 100 stycken. Årtalsbegräsningen valdes för att det ansågs som

ett rimligt span för att avgränsa för relevant litteratur och antalet resultat sattes som

begränsningsfaktor för att visa på att kombinationen av nyckelord var tillräckligt specifik. De

satta begränsningsfaktorerna följdes så gott det kunde, i ytterst få fall där relevant litteratur inte

kunde hittas släpptes tyglarna för vissa begränsningsfaktorer, såsom tidsintervall och antal

resultat. För fullständig information kring begränsningsfaktorerna, se Bilaga C – Information

om litteraturstudie. Eftersom den insamlade litteraturen initialt var avsedd för andra studier så

16 (68)

är data i litteraturstudien sekundär. Detta skiljer sig från primära data, som är data som exklusivt

samlats in till en studie (Saunders, et al., 2009).

I början av litteraturstudien studerades först Scanias rekommenderade litteratur inom

felsökning, vilket var doktorsavhandlingen Troubleshooting Trucks – Automated Planning and

Diagnosis av Warnquist (2015). Utifrån avhandlingen skrevs korta minnesanteckningar och

använda nyckelord dokumenterades. Relevant litteratur som refererades undersöktes även för

att erhålla ytterligare ämneskunskap och förståelse kring frekvent använda nyckelord. Vid

dokumentationen av denna litteratur noterades även dess relevans med kategorierna; starkt

relevant, tveksamt relevant och inte relevant. Detta för att kunna undersöka litteraturen på ett

strukturerat sätt. Utifrån den identifierade litteraturen och arbetets forskningsfrågor kunde egna

nyckelord formuleras. En del nyckelord var direkt tagna från dokumentation kring frekvent

använda nyckelord, medan andra egenformulerades. Ett exempel på ett egenformulerat

nyckelord var Customer symptom, där ordet Customer lades till för att göra nyckelordet mer

specifikt mot arbetet än vad enbart ordet symptom hade varit. Exempel på nyckelord som

användes vid litteratursökningen var; Automotive industry, Fault diagnosis, Symptom och

Troubleshooting. Sökningen av litteratur utfördes i bland annat följande databaser; IEEE

Xplore, ScienceDirect, Google Scholar, SpringerLink och Emeraldinsight. För att avgöra den

identifierade litteraturens relevans utvärderas litteraturens titel först. Därefter utvärderades även

sammanfattningen. Vid osäkerhet lästes även litteraturens inledning och slutsats. Därefter

dokumenterades samtlig relevant litteratur (Bryman, 2016).

Det ovannämnda tillvägagångsättet för att söka efter litteratur följer metoden för

litteratursökning beskriven av Bryman (2016). Metoden användes utav två anledningar. Den

första anledningen var att metoden ansågs ge en tydlig struktur till litteratursökningen, vilket

ökar arbetets reliabilitet. Den andra anledningen var att metoden utgår ifrån specifik litteratur,

i detta fall den tidigare nämnda doktorsavhandlingen, vilket gjorde det möjligt att använda

litteratur med anknytning till både Scania och forskningsfrågorna. Detta ansågs underlätta

litteratursökningsprocessen då relevant data kunde samlas under kortare tid.

3.3 Fallstudie En fallstudie utfördes för att kunna utveckla format för kundsymptom och FMEA. Dessutom

för att kunna utveckla en metod, där respektive format integreras, för att sammankoppla

kundsymptom med systemreaktioner i tunga fordon. En fallstudie innebär att utföra en studie

vilket involverar empiriska utföranden i en verklig kontext som stödjs av flera källor (Saunders,

et al., 2009). Inom studien har förövrigt flera kvalitativa datainsamlingstekniker använts inom

fallstudien. Av alla tillgängliga kvalitativa insamlingstekniker för fallstudie, användes

semistrukturerad intervju, workshop och litteraturstudie. Flera datainsamlingstekniker valdes

att användas för att försäkra att data berättar det som är antaget, enligt triangulering (Saunders,

et al., 2009). Fallstudien har anpassats för att kunna besvara de frågeställningar som formulerats

i arbetets uppstartningsfas. Frågeställningarna formaliserades utöver arbetets syfte och mål,

utefter arbetets valda approach, ändamål och forskningsprocess. I arbetet valdes induktiv som

approach, då tillvägagångssättet linjerade med syftet och målet med arbetet. En induktiv

approach innebär bland annat; att teori följer empiriska data, att där kan finnas flera alternativa

lösningar till samma problem och inom en induktiv approach framställs kvalitativa data som

den primära datatypen (Saunders, et al., 2009). Arbetet har skett i ett utforskande

tillvägagångssätt. Det har inneburit att arbetet har inriktats mot att utforska bland annat mönster

och besvara frågeställningar istället för att grunda arbetet på att bevisa en hypotes (Sage

Publications, 2020). Arbetet har vidare skett enligt en anpassad produktutvecklingsprocess, se

3.1 Produktutvecklingsprocessen, som forskningsprocess för arbetet.

17 (68)

Underlaget för fallstudien bestod av dokumentation inom felsökning av gasmotorer och

gastankar framtaget av Scania. Orsaken till att detta underlaget valdes var för att Scania redan

hade påbörjat ett arbete med att använda symptom med syftet att kunna felsöka dessa

komponenter. Dessutom, för att fallet behandlade komponenter där mekaniska fel kunde

uppstå. Saunders et al. (2009) påpekar att just ett fall ofta används i situationer där fallet

representerar ett unikt eller extremfall, samt att det ger en unik möjlighet till att undersöka något

som få har övervägt innan. Underlaget som tagits fram inom detta fall var en FMEA och ett

felsökningsschema som baserades på FMEA:n. I felsökningsschemat presenterades bland annat

en rad kontroller som måste utföras för diverse problem kopplade till gastankar och gasmototer.

I början av fallstudien utfördes en QFD, en analys av litteratur samt undersöktes Scanias

befintliga felsökningsprogram SDP3. Därefter kartlagdes den befintliga initiala

felsökningsprocessen där fokuset var på; process, dataflöden, tidsåtgång och brister och

förbättringsmöjligheter. De två teman process och dataflöden valdes för att få en förståelse

kring den initiala felsökningsprocessens samtliga steg och för att undersöka vilka data som

fanns tillgänglig på Scania, kopplad till felsökning och symptom, och hur denna data överförs

mellan processens olika parter. De två teman tidsåtgång och brister och

förbättringsmöjligheter valdes för att identifiera utvecklingsmöjligheter med den befintliga

initiala felsökningsprocessen och för att möjliggöra en redogörelse kring hur bra det slutgiltiga

konceptet blev. I fallstudien betraktas den initiala felsökningsprocessen som samtliga moment,

utanför verkstaden, innan mekanikern utför ett servicearbete på ett fordon. Den faktiska

felsökningsprocessen betraktas istället som det mekanikern utför under ett servicearbete på ett

fordon, se Figur 3. Under fallstudien utfördes även en analys av dokumentationen inom

felsökning av gasmotorer och gastankar samt en konkurrensanalys. Syftet med de tidigare

nämnda momenten i fallstudien var att skapa ett underlag till konceptutvecklingsprocessen som

utfördes i ett senare stadie i fallstudien.

Figur 3. Visar den initiala och faktiska felsökningsprocessen som utförs på Scania.

Under konceptutvecklingsprocessen tillämpades metoder och principer som erhölls från

litteraturstudien. Felsökningsmetoderna Bayesiska nätverk, CBR och Felträdsanalys valdes av

flera anledningar. För det första behandlas samtliga metoder i diverse vetenskaplig litteratur.

De två metoderna Bayesiska nätverk och CBR behandlades även i doktorsavhandlingen

Troubleshooting Trucks – Automated Planning and Diagnosis av Warnquist (2015) som erhölls

från Scania. Detta påvisar att samtliga metoder är vetenskapligt grundade. Dessutom valdes

18 (68)

metoderna för att de ansågs kunna användas till arbetes ändamål och initialt även kunna utnyttja

data från FMEA. Slutligen valdes enbart tre metoder på grund av arbetets begränsade tidsram.

Det ansågs inte möjligt att studera och generera koncept med fler än dessa metoder. I slutet av

fallstudien utfördes en konceptsållning och ett slutgiltigt konceptval gjordes med hjälp av en

workshop.

Avgränsningar för fallstudien

I fallstudien särskiljs befintliga data inom Scania som kunddata och expertdata. Kunddata

betraktas som den data som kundmottagaren erhåller från kunden vid bokningar av

servicearbeten. Expertdata betraktas istället som den tekniska data kring fordonens

komponenter som framställs utav Scania. På grund av studiens begränsande tidsram avser

fallstudien inte att kartlägga samtliga datatyper relaterad till felsökning och symptom. Därför

kommer enbart kunddata att kartläggas, och expertdata kommer istället bestå utav FMEA.

Orsaken till att FMEA valdes var för att Scania anser att det var den mest tillförlitliga formen

av expertdata som används idag.

I den erhållna FMEA:n från Scania inom felsökning av gasmotorer och gastankar fanns det

flera olika symptom som utvecklingsingenjörer på Scania har identifierat. I fallstudien valdes

det enbart att analysera komponenter och fel som är kopplade till symptomet Högt tryck.

Orsaken till detta var att det fanns mest data inom detta symptom och för att det inte var möjligt

att analysera hela FMEA:n på grund av arbetets begränsade tidsram.

Fallstudien avgränsas även geografiskt. Primärdata från fallstudien kommer att erhållas från

semistrukturerade intervjuer inom Scania R&D i Södertälje, Sverige. Vid val av det slutgiltiga

konceptet kommer även en workshop att utföras. Primärdata från workshopen kommer enbart

att erhållas från relevanta medarbetare från Scania R&D i Södertälje, Sverige. Fallstudien

avgränsas ytterligare genom att enbart samla in data från relevanta medarbetare inom Scania.

Kunder av Scanias produkter kommer därför inte att involveras.

Fallstudien avgränsas även till den initiala felsökningsprocessen, och exkluderar därmed den

faktiska felsökningsprocessen, se Figur 3. Orsaken till detta är för att arbetet inte avser att

sammankoppla kundsymptom med lämpliga åtgärder som utförs av mekanikern. Istället avser

arbetet att sammankoppla kundsymptom med systemreaktioner. Trots att den faktiska

felsökningsprocessen exkluderas kan arbetet inom studien fortfarande betraktas som

produktutveckling. Detta beror på att sammankopplingen mellan kundsymptom och

systemreaktioner i den initiala felsökningsprocessen är en förutsättning för att kunna utföra

symptombaserade felsökningar av Scanias huvudprodukter.

I fallstudien kommer inte egna tester att utföras för att erhålla statistik på tiden det tar att utföra

olika moment i den befintliga initiala felsökningsprocessen. Istället kommer primärdata

gällande tidsåtgången att erhållas vid semistrukturerade intervjuer.

Produktutvecklingsverktyg

I följande kapitel presenteras de produktutvecklingsverktyg som använts i

produktutvecklingsprocessen.

Quality Function Deployment – QFD

Quality Function Deployment (QFD) är en metod som används för att säkerställa att kundernas

behov tas hänsyn till under utvecklandet av nya produkter (Ullman, 2010). I arbetet har delar

av en QFD tillämpats för att kunna översätta kundens behov till urvalskriterier som tillämpades

19 (68)

i fallstudiens konceptsållning och val. Stegen från en traditionell QFD som har tillämpats var

identifiering av kundbehov och egenskaper. I en QFD identifieras behov från kund i samarbete

med kund för att förstå vad kunden vill ha. I samband med detta översätts behoven till

egenskaper för att förstå hur behoven ska uppnås. Ett steg som vanligtvis görs i en QFD är att

ta fram tekniska specifikationer (Ullman, 2010). I arbetet har detta steg ändrats till att istället ta

fram urvalskriterier för att passa arbetets ändamål.

Översättningen till urvalskriterier gjordes på grund av två anledningar. Den första anledningen

är att Scanias behov var omfattande för hela projektet för symptombaserad felsökning. För att

göra behoven mer relevanta för detta arbete omformulerades behoven till urvalskriterier med

hjälp av de identifierade egenskaperna i QFD:n. Exempelvis översattes behovet ”Metoden skall

möjliggöra en högre träffsäkerhet mellan fel och korrekt åtgärd än idag” till urvalskriteriet

”Metoden skall möjliggöra en matchning mellan kundsymptom och systemreaktioner” då det

kriteriet bidrar till att behovet ska kunna tillgodoses. Den andra anledningen var för att många

egenskapers enheter som identifierades var antingen subjektiva [subj] eller [ja/nej]. Exempel

på sådana typer av egenskaper; Standardiserad [ja/nej] och Arbetsbelastning [subj]. Detta

ansågs göra det svårt att ta fram tekniska specifikationer.

Konkurrensanalys

Innan påbörjandet av konceptgenereringen i fallstudien utfördes en konkurrensanalys av

liknande produkter, i detta fall felsökningsprocesser, hos andra företag. Ulrich & Eppinger

(2012) menar att en konkurrensanalys skapar goda förutsättningar för att en nyutvecklad

produkt blir framgångsrik. Dessutom kan konceptgenereringsprocessen underlättas om

utvecklare har utvärderat liknande produkters design innan (Ulrich & Eppinger, 2012). I

fallstudien utvärderades felsökningsprogrammet VIDA, Volvo Car Corporation’s workshop

system, som används av Volvo Cars för att bland annat felsöka Volvos bilar. Orsaken till att

VIDA undersöktes var för att det programmet använder symptom vid felsökningsprocessen.

Dessutom för att stödja en generaliserbarhet då studiens slutprodukt ska kunna tillämpas av

samtliga företag som arbetar med tunga fordon.

Brainstorming

I konceptgenereringsprocessen som utfördes i fallstudien tillämpades först

produktutvecklingsmetoden brainstorming. Vid tillämpningen av metoden följdes riktlinjer

som Ulrich & Eppinger (2012) beskriver. Den första riktlinjen betonar vikten av att avsätta tid

för konceptgenereringen och inte kritisera andras idéer. Den andra och tredje riktlinjen handlar

istället om att många koncept ska utvecklas och att det inte ska finnas restriktioner kring

koncepten. Ulrich & Eppinger (2012) menar att idéer som kan betraktas som omöjliga, kan

förbättra gruppens kreativitet. Den sista riktlinjen handlar om att visuella medel kan underlätta

processen att presentera sina idéer för resterande medlemmar i gruppen (Ulrich & Eppinger,

2012).

I detta arbete utfördes brainstormingen genom att först generera koncept enskilt utan kontakt

mellan de två gruppmedlemmarna med målet att generera så många olika koncept som möjligt.

Detta för att inte influera varandras tankar och idéer. Efter att koncept generats på skilda håll

presenterades och diskuterades koncepten för varandra. I detta stadie kritiserades inte koncepten

utan gruppmedlemmarna var öppna för varandras tankar och idéer. I vissa fall kunde enkla

skisser göras för att tydliggöra vissa delar av koncepten. Efter detta stadie vidareutvecklades

koncepten återigen enskilt med den andra medlemmens åsikter och koncept i åtanke. Processen

med att generera koncept enskilt och i grupp gjordes upprepande gånger tills koncepten var

20 (68)

färdigutvecklade vilket medför att brainstormingen i detta fall kan betraktas som en iterativ

process.

Pughs matris

I fallstudien användes en konceptvalsmatris som till största del grundades på Pughs

konceptvalsmatris, vilket är en metod för att kunna sålla koncept som tagits fram under

konceptgenereringsfasen (Ulrich & Eppinger, 2012). I fallstudien har den även använts för att

kunna göra ett slutgiltigt konceptval. Metoden bygger på att utvärdera konceptens uppfyllelse

av ett antal urvalskriterier. I matrisens översta rad placeras koncepten, och i den vänstra

kolumnen sätts kriterierna in. Matrisens urvalskriterier kommer normalt från kundbehoven som

har identifierats i ett tidigare stadie i produktutvecklingsprocessen (Ulrich & Eppinger, 2012).

I fallstudien har behoven som identifierades i QFD:n översatts till urvalskriterier. Detta för att

säkerställa att det slutgiltiga konceptet kunde tillgodose Scanias behov. För att kunna avgöra

vilket koncept som är den mest lovande används ett referenskoncept i en traditionell Pughs

konceptvalsmatris. Detta koncept kan exempelvis vara en produkt som redan finns ute på

marknaden (Ulrich & Eppinger, 2012). I fallstudiens konceptvalsmatris exkluderades principen

att använda ett referenskoncept i och med att kritisk data saknades kring ett befintligt

symptombaserat felsökningssystem.

I en traditionell Pughs konceptvalsmatris utförs en egen utvärdering av koncepten som

framtagits (Ulrich & Eppinger, 2012). I fallstudien utvärderades respektive koncept istället av

deltagare i en workshop. Deltagarna var medarbetare inom Scania som besatt relevant

kompentens inom områdena diagnos/felsökning samt detta arbetes medlemmar. Detta för att

både kunna utvärdera koncepten objektivt, men också för att det ansågs fördelaktigt att få

koncepten expertgranskade.

Enligt Ulrich & Eppinger (2012) är det möjligt att vikta urvalskriterierna i matriser som används

för att poängsätta koncept. Detta gjordes i konceptvalsmatrisen genom att fördela 100% över

respektive urvalskriterium. Orsaken till att viktningen utfördes var för att säkerställa att det

koncept som valdes som det slutgiltiga konceptet verkligen var det mest lovande konceptet. Om

viktning hade exkluderades så hade det varit möjligt att ett koncept med högst betyg valts men

som eventuellt inte hade uppfyllt de mer kritiska urvalskriterierna såsom ”Metoden skall

möjliggöra en matchning mellan kundsymptom och systemreaktioner”.

Vid poängsättningen av respektive urvalskriterium ansattes betyget 1 om deltagarna i

workshopen ansåg att ett koncept inte alls uppfyllde ett urvalskriterium, 2 om deltagarna ansåg

att ett koncept inte uppfyllde ett urvalskriterium tillräckligt bra, 3 om deltagarna ansåg att ett

koncept uppfyllde ett urvalskriterium på en acceptabel nivå och 4 om deltagarna ansåg att ett

koncept uppfyllde ett urvalskriterium väldigt bra. Orsaken till att poängsättningen 1-4 användes

var för att möjliggöra en nyanserad poängsättning vilket underlättar att identifiera likheter och

skillnader mellan koncepten. Betyget ”N/A” ansattes om deltagarna ansåg att det inte var

möjligt att utvärdera ett koncepts uppfyllelse av ett urvalskriterium. Efter poängsättningen

beräknades respektive koncepts poäng genom att addera antalet ”+” med antalet ”-”.

Datainsamlingstekniker

I följande kapitel presenteras teknikerna som använts i arbetet för att samla in data.

Dokument

I arbetets uppstartsfas erhölls dokumentation från Scania relaterat till arbetets område vilket i

detta fall var felsökning. Dokumentationen bestod av en FMEA, i form av ett excel-dokument,

21 (68)

inom gasmotorer och gastankar, samt ett felsökningsschema som baserades på FMEA:n. Utöver

detta erhölls även doktorsavhandlingen Troubleshooting Trucks – Automated Planning and

Diagnosis av Warnquist (2015), en manual för Scanias felsökningsprogram SDP3 (Scania CV

AB, 2017), en manual för Volvo Cars VIDA (Volvo Cars, 2015) samt ett dokument som

behandlar FMEA:or från Scania (Scania AB, 2014). Samtlig dokumentation från Scania är

kvalitativ och sekundär. Skillnaden mellan kvalitativa och kvantitativa data är att kvalitativa

data utgörs av ord, medan kvantitativa data utgörs av siffror (Saunders, et al., 2009).

Semistrukturerade intervjuer

Semistrukturerade intervjuer användes som teknik för att samla in kvalitativ primärdata under

fallstudien (Saunders, et al., 2009). En fördel med att använda intervju som teknik för insamling

av data är att intervjuer kan vara flexibla och anpassas efter respondentens svar. I en intervju

kan även viktig data som tonfall och pauser noteras, vilket skapar kontext och gör att

underliggande information kan identifieras i analysen. En intervju är en bra teknik för att samla

in rikt material med fördjupad information (Bell, 2006).

I studien formulerades teman utefter vilken typ av information som skulle resulteras från

intervjuerna i en så kallad intervjuguide. Intervjuguider presenteras i Bilaga D – Intervjuguide.

Teman och frågorna för varje tema formulerades på så sätt att forskningsfrågorna skulle kunna

besvaras och att studiens mål skulle kunna uppnås. Intervjuguider konstruerades specifikt för

den befattning respondenten hade. Under en semistrukturerad intervju är det tillåtet att ändra

frågeföljden och även lägga till odokumenterade följdfrågor (Bryman, 2016). Detta gjordes för

att både anpassa frågorna efter respondentens svar men även för att vara säker på att en

fördjupad bild av den information som respondenten besitter samlas in (Bell, 2006).

Intervjuerna utfördes så ofta som möjligt på plats där respondentens befattning ägde rum och

intervjuerna utfördes då fysiskt. När distans emellan parter var för lång utfördes istället digitala

intervjuer. Intervjuerna spelades in när respondenterna godkände det. Enligt Bryman (2016)

finns det fler anledningar till varför intervjuer bör spelas in och några av dem är:

• Det hjälper personen som håller i intervjun att få en återblick i detaljer, då det är svårt

att komma ihåg och skriva ned allt som sades under intervjun.

• Det möjliggör en mer genomarbetad och detaljrik sammanfattning av det som sades.

• Det möjliggör en repetition av det som sades.

• Det möjliggör att andra forskare kan gå igenom materialet om ett återskapande vill

genomföras av arbetet eller data vill analyseras på egen hand.

Semistrukturerad intervju valdes som teknik då Saunders et al. (2009) påpekar att

semistrukturerade intervjuer kan underlätta att förstå vad som händer i en utforskande studie.

Intervjuerna varade 25 till 60 minuter beroende på bland annat respondentens personlighet,

erfarenhet, befattning och syfte med intervjun. En annan orsak till att semistrukturerade

intervjuer valdes för att samla in data var på grund av möjligheten till att samla in kvalitativa

data genom tekniken. Den kvalitativa data typen samspelar även med det induktiva

tillvägagångssättet med studien vilket stödjs av Saunders et al. (2009).

Målgrupper till semistrukturerade intervjuer

Fallstudiens fokus är på den initiala felsökningsprocessen, och den involverar huvudsakligen

två parter, kunden och kundmottagaren. Eftersom kundmottagaren även har en direkt kontakt

med kunderna anses denna grupp vara intressant att intervjua. I den initiala

felsökningsprocessen är inte mekanikern involverad. Dock är data som mekanikern

tillhandahåller från kundmottagaren en del av den initiala felsökningsprocessen. Därför var

22 (68)

även denna grupp intressant att intervjua. Genom data från mekanikerna är det möjligt att

validera huruvida den initiala felsökningsprocessens utdata är tillräcklig och korrekt utifrån

mekanikerns perspektiv. Mekanikerns indata kan alltså användas för att få en förståelse hur

bland annat kundmottagarens indata och symptombeskrivningen bör vara formaliserad.

Det finns kundmottagare och mekaniker inom både vanliga verkstäder och R&D-verkstäder.

Till intervjuerna ansågs medarbetarna med anknytning till R&D som mest relevanta. Eftersom

dessa dagligen arbetar med utveckling ansågs de vara mer benägna än medarbetare inom

vanliga verkstäder att identifiera förbättringsmöjligheter. Målgrupperna som valdes till

intervjuerna var kundmottagare inom R&D och mekaniker inom R&D. Utöver kundmottagarna

och mekanikerna ansågs även medarbetare inom Scania som besatt goda kunskapar om

kundmottagarrollen eller mekanikerrollen ingå i de ovannämnda målgrupperna. Detta för att

dessa ansågs kunna generera kompletterande värdefull information kring kundmottagar- och

mekanikerrollen utifrån andra perspektiv.

I arbetet är ett av delmålen att se över formaliseringen av kundsymptom. I detta avseende kan

det anses vara relevant att en målgrupp för intervjuerna skulle vara kunderna. Dock för att kunna

erhålla pålitliga och generaliserbara data från kunden hade ett stort antal intervjuer varit

nödvändiga att utföras. Målgruppen kundmottagare inom R&D anses dock kunna presentera en

helhetsbild av kundernas respons.

Urval till semistrukturerade intervjuer

Urvalet av målgrupperna valdes att inte vara hela populationen, vilket hade inneburit alla

mekaniker och kundmottagare för tunga fordon i hela Sverige. Det hade tagit för lång tid, kostat

för mycket och varit opraktiskt att utföra. Saunders et al. (2009) menar att 12 stycken intervjuer

är tillräckligt, när urvalsgruppen är relativt homogen. Med homogen menas att urvalsguppens

deltagare inte skiljer sig åt i för stor utsträckning, utan det förväntas att få liknande svar/resultat

från samtliga deltagare i urvalsgrupperna. Bedömningen gjordes att urvalsgrupperna var

tillräckligt homogena, samt gjordes bedömningen att det låg stor vikt i att ta fram kvalitativt

material med en djup insikt och väl genomförd analys av den insamlade data. 12 intervjuer

sattes som mål för antalet intervjuer inom varje målgrupp enligt Saunders et al. (2009)

rekommendationer. Urvalsgrupperna valdes enligt teknikerna målmedvetet stickprov och

Snowbolling (Saunders, et al., 2009). Ett medvetet val gjordes för urvalsgrupper där det ansågs

vara störst chans att få in en hög grad användbar information. Samtidigt fick personerna på plats

rekommendera vilka andra personer på plats som skulle delta på intervjuerna, där av tekniken

Snowbolling. Det ska påpekas att samtidigt som 12 intervjuer är en rekommendation menar

dock Saunders et al. (2009) att antalet intervjuer vilket anses godtyckligt varierar kraftigt mellan

forskare.

Workshop

Fokuset inom workshopen var att använda workshop som stöd för att sålla koncept. Deltagaren

i workshopen som var en medarbetare på Scania ansågs kunna bidra i konceptsållningsfasen

med expertiskunskap och råd, för vad som ansågs funkar och inte funkar av de presenterade

koncepten. Medarbetaren med spetskompetens ansågs även kunna bidra med mindre

designändringar av koncepten för mindre detaljer. Det som även var en stark faktor till att

genomföra en workshop i sållningsstadiet, var att tillräcklig information om en referensprodukt

för en vanlig Pughs matris inte kunde identifieras. Ulrich & Eppinger (2012) nämner att det är

viktigt vid användning av workshop i ett sållningssammanhang att koncepten presenteras

likgiltigt mot varandra, detta för att inte något av koncepten ska bli bias. Inför workshopen

23 (68)

strävades därför efter att presentera koncepten likvärdigt för att inte påverka deltagarens val

och bedömning och då resultatet av sållningen.

Deltagare av en workshop av denna typ väljs ofta för att de har en specifik kompetens, vilket

också gör att urvalet inte sker slumpmässigt. Det är även så att kompetensen deltagarna besitter

förväntas bidra med kunskap till det mål som ska uppnås med workshopen. Det nämns att en

helhetsbedömning av en grupp är ett mycket effektivt sållningskriterium för koncept (Ulrich &

Eppinger, 2012). Gruppen i detta anseende bestod av forskarna själva och en medarbetare från

Scania med spetskompetens inom felsökning. Workshop benämns även som en ofta använd

metod för att sålla koncept (Ulrich & Eppinger, 2012). Workshopens resulterande data är primär

och kvalitativ (Saunders, et al., 2009). Workshop som medel inom studier används ofta för att

komma fram till ett mål (Orngreen & Levinsen, 2017). De övergripande målen med

workshopen i studien var. (1) För sållningen att resultera i en slutlig design för ett koncept, (2)

Att deltagaren kunde bidra med expertis runt koncepten för att genomföra eventuella mindre

detaljändringar av koncepten.

3.4 Kvalitativ analys I fallstudien samlades både primära och sekundära kvalitativa data in, vilket analyserades med

hjälp av en kvalitativ analysmetod beskriven av Williamson & Bow (2002). En kvalitativ analys

kan betraktas som ett hjälpmedel för att kunna skapa en förståelse kring en mängd data som

insamlats. Analysen har inte en förbestämd struktur, utan det är upp till forskaren att bestämma

hur analysen ska gå tillväga. Dock presenterar Williamson & Bow (2002) ett flertal steg som

kan användas i analysen.

I fallstudien har huvudsakligen två steg tillämpats; kategorisera data och skriva

minnesanteckningar, så kallade ”Memos” (Williamson & Bow, 2002). Williamson & Bow

(2002) menar att det kan vara fördelaktigt att kategorisera den insamlade data. Detta beror på

att det kan både möjliggöra att en mer grundlig analys kan göras, och att forskaren kan få insikt

i hur kategorierna relateras till varandra. Slutligen handlar minnesanteckningar om att forskaren

gör korta noteringar, exempelvis kring idéer och tankar, i samband med att analysen utförs

(Williamson & Bow, 2002). Williamson & Bow (2002) menar även att ett annat steg,

transkribering av intervjuer är bra att utföra inom kvalitativa analyser då det kan underlätta

analysprocessen. Dock på grund av arbetets begränsade tidsram exkluderades detta steg och

ingen transkribering gjordes. Istället spelades samtliga intervjuer in, och egna noteringar

gjordes i samband med intervjuerna. Inspelningar av intervjuerna gjordes för att kunna

presentera data om den efterfrågas efter att arbetet har publicerats. Detta för att kunna påvisa

att ingen partiskhet har påverkat analysen av data. Det fanns två orsaker till att stegen

kategorisera data och skriva minnesanteckningar valdes att tillämpas och inte resterande steg

som Williamson & Bow (2002) beskriver. Den första orsaken var arbetets begränsade tidsram.

Det ansågs inte möjligt att genomföra grundliga analyser av all insamlad data i och med att flera

analyser utfördes i fallstudien. Den andra orsaken var för att dessa steg ansågs vara mest

lämpade för fallstudiens upplägg och syfte.

Minnesanteckningarna och kategoriseringen av data utfördes på liknande sätt inom samtliga

analyser. I analyserna av data från de semistrukturerade intervjuerna skedde dock

kategoriseringen både med hjälp av teman och färgkodning. Orsaken till att färgkodning

användes var för att lättare kunna urskilja likheter och skillnader mellan respondenternas svar

kopplade till respektive tema. I analysen av underlaget inom felsökning av gasmotorer och

gastankar, konkurrensanalysen samt analysen av litteraturen så kategoriserades data istället

enbart med hjälp av teman. Följande teman användes till respektive analys, se Tabell 1.

24 (68)

Tabell 1. Visar teman som användes till respektive analys.

Analys Tema

Felsökningssystem

identifierade i litteratur

Kategorisering med underkategorier: Systemuppdelning och

Funktioner, Inmatning med underkategorier: Fritext,

Nyckelordssökning och Dropdown-meny och Språk med

underkategorier: Vardagligt språk och Tekniskt språk.

Semistrukturerade

intervjuer

Process, dataflöden, tidsåtgång samt brister och

förbättringsmöjligheter.

FMEA Innehåll i FMEA, kundsymptom, systemreaktioner,

datakvalitet, RPN-värde, förhållanden mellan symptom,

komponent och felmod.

Felsökningsschema Symptom och felsökning.

Konkurrensanalys Kundsymptomkoder (CSC), tekniska journaler och felsökning.

3.5 Validitet och reliabilitet Validitet innebär om det som mäts, analyserats och samlats in faktiskt är det som var tanken att

samlas in, med andra ord går det att lita på den resulterande informationen. Reliabilitet refererar

till rekonstruktionen av det som utförts, med andra ord går arbetet att göra om och resultera i

samma resultat. Reliabilitet innebär även till hur använda insamlings eller analystekniker i en

studie kan leverera konsekventa resultat (Saunders, et al., 2009).

För att säkerställa att en god validitet under studien har främst vetenskapliga artiklar använts.

Artiklarna har identifierats med hjälp av en sökstrategi utvecklad av Bryman (2016). Detta för

att säkerställa artiklarnas relevans och vetenskaplighet. Samtidigt har en tydlig arbetsprocess

använts genom hela studien för att även kunna säkerställa en god reliabilitet. Det omfattar

dokumentationen kring sökstrategin för litteraturstudien och samtliga aktiviteter inom den

valda produktutvecklingsprocessen, se 3.1 Produktutvecklingsprocessen.

I fallstudien tillämpades semistrukturerade intervjuer för att tillhandahålla primär data. Detta

har en negativ inverkan på studiens datakvalitet, och därmed på studiens validitet och

generaliserbarhet. Detta beror på att resultatet från intervjuerna med respektive målgrupp inom

Scania, exempelvis mekaniker och kundmottagare inom R&D, inte representerar hela

målgrupperna. Saunders et al (2009) beskriver att detta problem kan åtgärdas genom att

kombinera resultatet med befintlig forskning. För att kunna erhålla en acceptabel nivå av

validitet och generaliserbarhet i studien har därför vetenskaplig litteratur inom området använts.

På så sätt har forskningsfrågorna kunnat besvaras genom fallstudien med vetenskapliga

grunder. Förutom validiteten påverkas även reliabiliteten av att semistrukturerade intervjuer

används. Detta beror på att det är svårt att erhålla samma resultat vid ett senare skede då

upplägget på intervjuerna kan variera (Saunders, et al., 2009). För att motverka detta har hela

intervjuprocessen dokumenterats för att möjliggöra vidare analyser av resultatet (Saunders, et

al., 2009). För att ytterligare öka reliabiliteten spelades intervjuerna in och anteckningar togs

även under intervjuerna av den intervjuaren som inte ställde frågorna. Ghauri & Gronhaug

(2005) menar att både spela in och notera det respondenten säger motverkar negligering av

reliabiliteten, då meningen och kontexten av det respondenten säger under intervjun kan

glömmas bort eller av andra anledningar inte kan användas.

Forskare argumenterar för att det anses vara en svag generaliserbarhet i kvalitativa studier som

involverar för få fall i fallstudien och som inte är representativa för det generella

etablissemanget eller området (Saunders, et al., 2009). Däremot menar en annan del av

25 (68)

forskningen att en fallstudie i många andra meningar kan visa sig starkare än andra kvantitativt

baserade forskningsstudier. Det kan exempelvis göras genom att stödja fallstudiens resultat med

mer generaliserbar litteratur (Marschall & Rossman, 1999). Detta har tillämpats i studien för att

kunna uppnå en generaliserbarhet i studien.

För att öka validiteten i arbetet användes triangulering. Triangulering är användning av flera

typer av insamlingstekniker i ett och samma arbete. Trianguleringen används för att försäkra

att insamlad data faktiskt innebär det som i första anblick är tron att den betyder (Bell, 2006).

Genom att stärka ett antagande med information från flera olika källor och insamlingstekniker

har triangulering använts och en starkare validitet har uppnåtts (Saunders, et al., 2009). I fallet

för denna studie har semistrukturerade intervjuer, litteraturstudie och workshop använts för att

stödja antaganden med triangulering. Bias eller skevhet är något som kan uppstå under studier

antingen medvetet eller omedvetet. Att använda sig av triangulering för att inte omedvetet begå

bias är en metod som använts i arbetet och som Bell (2006) förespråkar.

I intervjuerna förekom riktade frågor även om detta försökte undvikas med att ställa öppna

frågor. Genom att ställa öppna frågor kan man undvika bias, och genom att ha öppna frågor i

en intervju kan även väl formulerade följdfrågor tillåtas att ställas för att samla in djupare

information om studiens ämne (Easterby- Smith, et al., 2008). Vissa intervjufrågor var svåra att

formulera så att frågorna skulle bli tydliga för respondenten och i vissa fall vid dessa

förekomster kan riktade frågor ha ställts i intervjuerna. Följdfrågor ställdes även efter situation

i intervjuerna vilka också kan haft en risk att bli riktade. Att ha riktade frågor är något som kan

skapa bias i studien (Saunders, et al., 2009). Dock beskriver Bell (2006) att även om

formulering av frågor är viktigt i semistrukturerade intervjuer så är det inte lika viktigt som i

exempelvis en enkät, det viktigaste är att frågorna blir tydliga så att respondenten lätt kan förstå

frågorna. För att kompensera för vissa riktade frågor, lades stor vikt på att fråga respondenterna

aktivt under intervjun om dem kom på något annat som skulle kunna vara av intresse inom

ämnesområdena i intervjun.

3.6 Etik och moral Med etik menas lämpligheten av forskarens beteende mot deltagarna eller dem påverkade av

studien. Etik relaterar även till hur forskningsfrågorna formuleras likt så väl som vilket ämne

som väljs att utforska. Lika väl ryms hur studien designas, tillgång till material, hur data samlas

in och analyseras så att fynden från studien dokumenteras på ett ansvarsfullt och moraliskt

försvarbart sätt (Saunders, et al., 2009). I studien var de känsligaste delarna inom etik och moral

intervjuerna och workshopen. Intervjuerna och workshopen ansågs som mest kritiska inom

studien, för att deltagarna av intervjun (respondenterna) och ”experten” i workshopen kan

tyckas ha en liten makt över vad som i slutändan resulterar i studiens rapport. Det ansågs därför

viktigt att vara transparenta mot respondenterna och experterna om innehållet, syftet,

deltagarnas rättigheter och målet med studien samt varför intervjuerna genomfördes med

deltagarna.

Bell (2006) menar, för att respondenten ska känna sig trygg vid en intervju bör där finnas ett

form av kontrakt eller skriftlig beskrivning av respondentens rättigheter och en beskrivning av

syftet med studien. I en beskrivning kan där klargöras att respondenten har rätt att avsluta

intervjun när den vill och avstå från att besvara en fråga när som helst. Bell (2006) beskriver

även att där ofta ingår någon typ av utlovande gällande anonymitet, men att det är av yttersta

vikt att förklara vad som menas med överenskommelsen gällande anonymitet. Inför

intervjuernas genomförande konstruerades ett informations- och samtyckesavtal mot

respondenterna. Informations- och samtyckesavtalet konstruerades för att klargöra studiens

26 (68)

syfte samtidigt som respondenternas rättigheter presenterades. Avtalet skickades i förväg till

alla deltagare så att det kunde läsas igenom i en icke stressad situation innan eventens start, för

att deltagarna skulle känna sig trygga inför intervjuerna. Avtalet kan ses i Bilaga E -

Informationsblad och samtycke.

27 (68)

4 Fallstudie I följande kapitel presenteras tillvägagångsättet för att kunna utveckla en metod för att

sammankoppla kundsymptom med systemreaktioner som baseras på resultatet från

litteraturstudien, intervjuerna, dokument och workshopen. Formaliseringen av kundsymptom

och FMEA kommer även att behandlas.

4.1 QFD I början av fallstudien utfördes delar av en QFD beskriven av Ullman (2010) för att kunna ta

hänsyn till Scanias behov vid den kommande konceptgenereringen. I en traditionell QFD tas

tekniska specifikationer fram med hjälp av QFD:n, men i detta arbete användes den istället för

att ta fram urvalskriterier till en konceptsållningsmatris. Detta för att kunna sålla koncept och

göra ett slutgiltigt konceptval i det avslutande skedet för fallstudien.

Under arbetets uppstartsfas erhölls kundbehoven från kunden, vilket i detta fall var Scania. Efter

att kundbehoven hade identifierats kunde tillhörande egenskaper bestämmas. I denna process

eftersträvades det att ta fram egenskaper med fysikaliska enheter för att egenskaperna skulle

vara kvantifierbara. I fallen när detta inte gick blev egenskapernas enheter istället [ja/nej] eller

subjektiva [subj].

Efter att behoven och egenskaperna hade identifierats, undersöktes korrelationen mellan

behoven och egenskaperna. Detta för att säkerställa att alla behov hade tillhörande egenskaper.

Därefter översattes behoven till urvalskriterier. I vissa fall kunde egenskaperna användas för att

formulera ett urvalskriterium. Exempelvis översattes behovet Metoden skall inte förlänga

felanalysen för utvecklingsingenjörer av befintliga eller nya komponenter och system (FMEA)

med hjälp av egenskapen arbetsbelastning [subj] bland annat till urvalskriteriet Metoden skall

inte innebära en större arbetsbelastning, i form av tidsåtgång, för utvecklingsingenjörerna vid

framtagning av FMEA. För fullständig information kring QFD:n och urvalskriterierna, se

Bilaga F – QFD.

4.2 Analys av felsökningssystem identifierade i litteratur Under insamlingen av litteratur i litteraturstudien identifierades ett antal felsökningssystem

vilket forskare förklarade sina studier runt om. En analys av dessa felsökningssystem ansågs

kunna ge en god inblick i hur forskarna tagit hänsyn till olika aspekter av formulering i

felsökningssystemen. Analysens resultat användes sedan som stöd för den kommande

konceptgenereringen i arbetet, tillsammans med den redan insamlade litteraturen av

formalisering, se 2.4 Formalisering av kundsymptom.

Samtliga undersökta källor i Tabell 2 hänvisar till färdiga koncept av felsökningssystem eller

färdiga felsökningssystem, vilket medför att beskrivningar av systemen ofta syftar till hur

uppbyggnaden av systemens användargränssnitt skall se ut. Slutsatsen drogs dock vid analysen

av felsökningssystemen att data som berör vissa formaliseringsregler måste finnas med i den

ursprungliga datakällan. Med den ursprungliga datakällan menas den källa där data sparas ned

som sedan används vid presentation eller val i ett användargränssnitt. Slutsatsen drogs för att

kunna ta hänsyn till formaliseringsregler gällande Språk och Kategorisering enligt Tabell 2, bör

informationen linjera från datakällan till användargränssnittet, vilket gör att en undersökning är

relevant. Delen för Inmatning i tabellen berör dock inte den ursprungliga källan för

formaliseringen av kundsymptom på samma sätt som Språk och Kategorisering görs.

Inmatningen berörs inte exempelvis på grund av att, en fritext i datakällan kan fortfarande

presenteras som en ”dropdown-meny” för kundmottagaren. Däremot ansågs Inmatning

relevant då den visar hur användarna förhåller sig till data, och då i vilket format som data kan

28 (68)

förväntas sparas ned från användare i ett symptombaserat felsökningssystem. Från litteraturen

noterades relevant information som berörde formalisering av kundsymptom i samband med

felsökningssystemen. Därefter kunde kategorier utläsas från den noterade informationen:

Kategorisering - Systemuppdelning och Funktioner, Inmatning - Fritext, Nyckelordssökning

och Dropdown meny samt Språk - Vardagligt språk och Tekniskt språk. Efter att kategorierna

skapats kunde egna tankar noteras kring de formaliserade kategorierna. Den utförda analysen

utgår från Williamson & Bow (2002) kvalitativa metod för att analysera.

I Tabell 2, visar några potentiella lösningar på vilka källor har byggt upp eller rekommenderar

hur formalisering av kundsymptom kan se ut i ett felsökningssystem. Källornas olika approach

för diverse delar av formaliseringen av kundsymptom listas för att få en överblick över hur

formaliseringen av kundsymptom kan lösas. Kolumnen ”Kategorisering” av kundsymptom

visar i huvudsak vilken typ av kategorisering som har använts för att orientera och minimera

problembilden med hjälp av kundsymptom. Exempelvis använder Bandini et al. (2008) en

initial kategorisering av HLC (High Level Components) i en trädmeny, vilket bestämmer vilket

huvud-system som besitter grundorsaken till problemet. För att sedan minimera antalet

potentiella grundorsaker ännu mer finns underkategorier vilket består av mer

funktionsorienterade symptom kopplade till del-system av huvudsystemet. Kolumnen

”Inmatning” visar vilka alternativ för inmatning av symptom som existerar eller

rekommenderas i felsökningssystemet. Inmatningen påverkar vilka vidare steg som måste göras

för att komma närmare grundorsaken i felsökningsprocessen. Kolumnen för ”Språk” visar

bland annat ifall felsökningssystemet tar aktiv hänsyn till en användares nivå av teknisk

kunskap.

Tabell 2. Visar en sammanfattning av några potentiella lösningar och rekommendationer på hur ett felsökningssystems

formalisering kan vara uppbyggt.

Källa

Kategorisering Inmatning Språk

System

uppdelning

(huvud-

system, del-

system,

komponent)

Funktioner Fritext Nyckelords-

sökning

”Dropdown

meny”-

Trädmeny

(Förbestämda

val)

Vardagligt

språk

Tekniskt

språk

(Bergman

n, et al.,

2003) X X X X X

(O`Neill,

et al.,

2005)

X X X X

(Bandini,

et al.,

2008)

X X X

(Southey,

et al.,

2014)

X X X X X X

(Davis &

Erway,

2015)

X X X X X X X

29 (68)

Kategorisering

I tabellen kan ses att funktioner är den typ av kategorisering som används mest i de presenterade

felsökningssystemen. Det kan dock tydligt utläsas att båda sätten att kategorisera,

systemuppdelning och funktioner har använts tillsammans i majoriteten av

felsökningssystemen. Vilket kan indikera på att kategorisera efter både funktion och

systemuppdelning kan vara fördelaktigt.

Inmatning

I tabellen kan det utläsas att ”dropdown-meny” är det vanligaste sättet att föra in data i

felsökningssystemet. Där kan även utläsas att kombinationer av inmatning kan ske, antingen

som ett alternativ från det ena eller för inmatningen av olika data som kräver olika

förutsättningar. Att ”dropdown-meny” är det mest använda sättet för inmatning kan bero på att

mindre tolkningar behöver göras från kundmottagaren vid inmatning än vid exempelvis fritext.

Att ha en ”dropdown-meny” ger även kundmottagaren alternativ på vad kundsymptomet kan

vara, vilket skapar en möjlighet att utgå från uteslutningsmetoden eller att succesivt fråga sig

fram från alternativen som finns mot kunden.

Språk

I tabellen kan ses att vardagligt språk används oftast av alternativen i felsökningssystemen. Där

kan även ses att tekniskt språk används aldrig uteslutande utan det används alltid vardagligt

språk också. Detta kan bero på det som både Bergmann et al. (2003) och O`Niell et al. (2005)

menar, att kunden inte skall behöva ha ett tekniskt kunnande för att kunna ge kundmottagaren

användbar information. Och det görs ofta genom användning av ett mer vardagligt språk i

felsökningssystemet. En annan fördel med att använda ett mer vardagligt språk i ett

felsökningssystem är att det blir enklare för mer oerfarna felsökare/oerfarna kundmottagare att

förstå och använda systemet. Samtidigt blir det även enklare att ta in information från kunden

om informationen som kundmottagaren får in från kunden linjerar mer med det språk som

används i felsökningssystemet. Om informationen i systemet linjerar med det kunden säger

behöver eventuellt inte kundmottagaren göra lika mycket tolkningar av kundens observerade

symptom.

4.3 Scanias befintliga felsökningsprogram – SDP3 Efter analysen av felsökningssystem identifierade i litteratur, se 4.2 Analys av

felsökningssystem identifierade i litteratur, så undersöktes Scanias befintliga

felsökningsprogram, SDP3. Detta gjordes för att få en bättre förståelse över hur Scania felsöker

sina produkter i dagsläget och för att eventuellt kunna dra nytta av detta vid den kommande

konceptgenereringen. SDP3 kan tillämpas till både Scanias lastbilar och bussar, samt till

industri- och marinmotorerna som Scania utvecklar. Programmet är kompatibelt med

elsystemen som Scanias produkter är uppbyggda av. I samtliga produkter finns det flera

styrenheter, exempelvis motor- och bromsstyrenheten, som ansvarar för produktens olika

funktioner. Enheterna kommunicerar sinsemellan med hjälp av en så kallad CAN-

kommunikation (Scania CV AB, 2017).

Förutom felsökning har SDP3 ett flertal andra tillämpningsområden, så som kalibrering och

uppdatering av komponenter. Vid uppstart av programmet får användaren möjligheten att välja

mellan flera olika typer av arbeten beroende på ändamålet. Inom typen Kontroll och justering

utförs felsökningsprocessen. Vid felsökning förutsätter SDP3 att en dator först kopplas in till

produkten som ska felsökas. Kopplingen mellan datorn och produkten sker via en så kallad

VCI. Dessutom krävs en USB-nyckel för få behörighet till programmet (Scania CV AB, 2017).

30 (68)

Felsökningsprocessen sker normalt enligt följande:

1. Kommunicera med kunden för att identifiera problemet med produkten.

2. Starta felsökningen genom att gå in på Kontroll och justering i SDP3.

3. Kontrollera vilka felkoder inom elsystemet som är aktiva.

4. Undersök vilka komponenter som felkoderna påverkar.

5. Utför relevanta åtgärder (Scania CV AB, 2017).

4.4 Kartläggning av den befintliga initiala felsökningsprocessen Semistrukturerade intervjuer utfördes för att kartlägga det aktuella läget för Scania, det vill säga

hur den initiala felsökningsprocessen ser ut i dagsläget. Intervjufrågorna baserades på fyra

teman som togs fram utifrån studiens mål och frågeställningar, se Bilaga D – Intervjuguide.

Följande teman användes; process, dataflöden, tidsåtgång samt brister och

förbättringsmöjligheter. I de semistrukturerade intervjuerna så intervjuades tre respondenter

inom målgruppen kundmottagare inom R&D och tre respondenter inom målgruppen mekaniker

inom R&D, se Tabell 3. Respondenternas svar på varje fråga dokumenterades, se Bilaga G –

Färgkodade anteckningar av respondenternas svar.

Tabell 3. Visar bakgrundsinformation om respondenterna: kön, ålder, år av erfarenhet, befattning, samt i vilket perspektiv

hen intervjuats.

Bakgrunds-

information

Respondenter

Kön Ålder År av erfarenhet Nuvarande

befattning

Intervju i

perspektiv av

Respondent 1 Man 42 9 år inom Scania UX/service

designer Kundmottagare

Respondent 2 Man 26

7 år som mekaniker

var av 2år hos

Scania

Mekaniker Mekaniker

Respondent 3 Kvinna 26 8 år Koordinator Kundmottagare

Respondent 4 Man 35 10 år Mekaniker

inriktad EL Mekaniker

Respondent 5 Man 37 13 år

Innan

inköpare

verkstad- Nu

Metodingenjör

Kundmottagare

Respondent 6 Man 51

Inom bransch 25 år,

på Scania 33 år

(produktionen

innan), verkmästare

8 år.

Innan

verkmästare-

Nu gruppchef

Mekaniker

Dataanalys av insamlad data från intervjuerna

Vid analysen av intervjudata utfördes en variant av kvalitativ analys enligt Williamson & Bow

(2002). Analysen påbörjades genom att först studera noteringarna som hade gjorts i samband

med intervjuerna. I vissa fall kunde även inspelningarna från intervjuerna lyssnas på för att

31 (68)

säkerställa att korrekt information hade noterats. I samband med att noteringarna undersöktes

så gjordes egna minnesanteckningar där respondenternas svar ansågs vara relevanta för arbetet.

Dessutom kategoriserades data genom färgkodning baserad på intervjuteman. Data färgades

enligt följande; process – grönt, dataflöden – blått, tidsåtgång – gult och brister och

förbättringsmöjligheter – rött. Detta för att identifiera likheter och skillnader mellan

respondenternas svar kring respektive tema, och utifrån det kunna dra egna slutsatser. Nedan

presenteras den mest relevanta data som erhölls inom respektive tema. För fullständiga data

kring intervjuerna, se Bilaga G – Färgkodade anteckningar av respondenternas svar. Analysen

från intervjuerna användes både vid konceptutvecklingsprocessen, och vid analysen samt

diskussion av det slutgiltiga konceptet.

Process

Utifrån analysen av intervjuerna kunde den initiala felsökningsprocessen kartläggas, se Tabell

4. Tabell 4. Visar beskrivningar av respektive steg i den initiala felsökningsprocessen.

Steg i den initiala

felsökningsprocessen

Beskrivning

Kontakt med kunden Sker vanligast över telefon eller disk, men det kan även ske via sms

och mejl. Kundmottagaren försöker få in kunder till verkstaden för

till exempel underhåll, men de hanterar även kundens klagomål

eller generella behov. Det finns inget standardiserat sätt hur

kundmottagaren ska gå tillväga vid insamling av information från

kunden, utan de går istället på erfarenhet och ställer motfrågor.

Kundmottagarens syfte är att samla in så mycket information till

mekanikern som möjligt. Vid kommunikation med kund kan det

handla om tre alternativ; Vill kunden komma in? Ska

Assistanskåren komma ut? Eller ska kundens fordon bärgas?

Den initiala felsökningen kan både resultera i att ett fel detekteras

(enkelt fel), men också i att det kommer att krävas vidare felsökning

av mekanikern för detektera felet (svårt fel).

Kundens förmåga att beskriva felet de upplever (teknisk kunnighet

och kommunikationsförmåga) påverkar kundmottagarens förmåga

att avgöra tiden och kostanden för arbetet.

Dokumentera

kunddata

Data från kunden dokumenteras i en arbetsorder, både i

pappersform och i datasystem.

Bearbeta kunddata Det finns ingen uttalad metod för detta utan det är upp till var och

en. Handlar mycket om erfarenhet och den mänskliga faktorn.

Kundmottagaren kan fråga mekaniker eller kollegor, samt använda

vissa datasystem. I vissa fall skriver kundmottagaren i princip exakt

ned i arbetsordern vad kunden berättade.

Administration Tidsbokning och tidsplanering över verkstaden. Här spelar

erfarenhet och rutin roll. Kundmottagaren försöker passa in

verkstadens schema med kundens schema. Vid oförutsägbara

händelser kan kundmottagaren behöva planera om uppdrag.

Beställa artiklar I vissa fall har kundmottagaren som uppgift att beställa in artiklar

för servicearbetena.

32 (68)

Återkoppling Återkoppling kan ske muntligt med mekaniker, verkmästare,

platschef eller reservdelsman. Sker dock ingen organiserad

återkoppling.

Problemhantering Om det uppstår problem med kundmottagarens arbete kan

kundmottagaren ta kontakt med andra, till exempel; verkmästare,

helpdesk, mekaniker eller andra verkstäder. Vid problem att

detektera kundens fel kan kundmottagaren be kunden att komma in

till verkstaden så att fordonet bland annat kan provköras. Om

kunden behöver akut hjälp kan kundmottagaren skicka ut

Scaniaassistans för att lösa problemet.

Dataflöden

I den initiala felsökningsprocessen sker det ett dataflöde mellan kunden, kundmottagaren och

mekanikern. Det kunden kan förmedla till kundmottagaren kan vara det som presenteras i

Tabell 5. Kunddata kan både förmedlas i muntligt format eller i fritext. Insamling av kunddata

görs till mesta dels vid reparationsuppdrag och akuta uppdrag. Vid underhållsuppdrag hämtas

istället tillsynspunkter från datasystem.

Dataöverföringen från kundmottagaren till mekanikern sker antingen muntligt eller skriftligt i

arbetsordern. Det är dock även möjligt att ta del av arbetsordern digitalt. I arbetsordern står det

bland annat vad mekanikern ska göra under servicearbetet. Kundmottagaren skickar även viss

data vidare till olika datasystem inom företaget. I vissa enstaka fall kan mekanikern även erhålla

data kring uppdraget från verkstadschefen eller kunden direkt.

Tabell 5. Visar data som kunden kan förmedla till kundmottagaren.

Kunddata

Symptom – vad kunden upplever för fel.

Chassinummer och registreringsnummer – med denna data kan kundmottagaren se vilka

komponenter/system fordonet har.

Kör-situationer, underlag, utetemperatur och mätarställning.

I vissa fall kan kunden läsa upp felkoder för kundmottagaren genom fordonets interna

system. Det finns även fjärrutläsning av felkoder, då kan kundmottagaren läsa av fordonets

felkoder på distans.

Tidsåtgång

Baserat på analysen av intervjuerna kunde tidsåtgången till en del moment i den initiala

felsökningsprocessen bestämmas, se Tabell 6.

Tabell 6. Visar tidsåtgången för respektive moment i den initiala felsökningsprocessen.

Moment Tidsåtgång

Samtal och bokning med kunden 5-10 minuter men kan även ta längre tid – ju

bättre kunden kan fordonet desto snabbare

går samtalet. Samtal kan ta längre tid vid till

exempel fakturafrågor. Kundmottagaren

avsätter så mycket tid det behövs för kunden.

Skriva ner data i arbetsordern Ospecificerad tidsåtgång - tar inte så lång tid.

Förberedelse av data Direkt eller upp till någon timme beroende på

om kundmottagaren behöver hjälp.

33 (68)

Materialbeställning Om material måste beställas till ett uppdrag

kan det ta ungefär 4 dagar att få hem

materialet. Om materialet redan finns på plats

tar det 1-2 timmar från det att mekanikern

påbörjar uppdraget.

Brister och förbättringsmöjligheter

Utifrån analysen av intervjuerna kunde både brister och förbättringsmöjligheter identifieras.

Vid misskommunikation med kunden eller om kunden inte är tekniskt kunnig kan

kundmottagaren råka beställa fel komponenter, planera tiden fel och det blir även svårare att

förmedla jobbet vidare till mekanikern. Om inte tillräcklig information kan fås av kunden

brukar den enda lösningen vara att kunden får komma in till verkstaden. Oftast kan

kundmottagaren inte ställa en exakt diagnos över telefonen. I dagsläget har förarna generellt

sämre förståelse kring fordonen på grund av fordonets komplexitet. För att förstå kundens

problem bättre och för att kunna göra en bättre tidsplanering av arbetet ansågs det fördelaktigt

att involvera mekanikern vid kontakten med kund.

Det hade varit fördelaktigt med ett hjälpmedel som kan användas vid insamling av data från

kunden som är mindre beroende av kundmottagarens erfarenhet. Alltså ett underlag med

stående punkter där det står vilka frågor som ska ställas till kunden. Det ansågs även fördelaktigt

att utbilda kundmottagare att ställa rätt frågor.

Ibland kan kundsymptom stjälpa mer än vad de hjälper då kunder tror att de upplever fel fast

fordonet fungerar felfritt. Samtidigt kan det vara tvärtom, att felkoder är missvisande och då

skulle det vara möjligt att använda kundsymptom. Respondent 1 menade att det inte fanns

någon mening med att spara ner symptom då, så fort fordonet kommer in till verkstaden och

mekanikern börjar arbeta med den så är symptomen ointressanta och efteråt med. Respondent

1 menade att det handlar mer om att föra vidare informationen till mekanikern så att de kan

förbereda arbetet, och det ansågs lättast göra muntligt.

Ett symptombaserat felsökningssystem bör vara simpelt. Det går inte att förvänta sig att

chauffören har samma tekniska kompetens som mekanikern. Det hade varit fördelaktigt att ha

ett system med en vettig filtreringsnivå och sökbarhet för att kunna söka på symptom kopplade

till fel på fordonen. I detta fall hade det varit bra att använda Scaniaspecifika komponentkoder

för att göra det lättare för användarna. Det hade inneburit en kombination av symptom och

komponenter (komponentkoder). Vid lösning av nya problem hade det varit fördelaktigt att få

fram liknande fall där åtgärder som tidigare utförts finns med. Dessutom hade det varit

hjälpsamt att få fram information kring varför specifika problem inträffar på fordon.

Vid felsökning är bra data för mekanikerna bland annat information om vad som gjorts med

fordonet precis när felet upptäcktes, till exempel låg kunden på motorvägen? Eller höll kunden

på att backa? Det vill säga en förenklad situationsbeskrivning. Det ansågs även vara

fördelaktigt att veta ett kort händelseförlopp, exempelvis om det vibrerade 10 minuter innan

det small. Händelseförlopp betraktas i detta fall beskriva ett sammanhang för avvikelsen och

anses därför ingå i kontext. Andra bra beskrivningar av fel från kund innehåller position. Ett

exempel på bra data från kunden är: ”ett vinande ljud från vänster bakhjul vid inbromsning”. I

detta exempel kan från vänster betraktas som position och vid inbromsning som kontext. I detta

fall anses ett vinande ljud vara själva avvikelsen hos fordonet, och betraktas därför ingå i vad

bra data är för mekanikerna.

34 (68)

Vid bearbetningen av den insamlade data av kundmottagaren kan det bli missbedömningar på

grund av bristfällig kunskap eller erfarenhet från kundmottagarens sida. Detta leder till

konsekvenserna som till exempel att det tar längre tid, andra kunder kan bli påverkade då

kundmottagaren måste planera om uppdrag. Vid bristfällig information från kundmottagaren

till mekanikern kan mekanikern behöva be kundmottagaren att ringa upp kunden igen – onödigt

moment och tid.

4.5 Dataanalys av dokument från Scania I detta avsnitt presenteras analyserna som gjordes på de följande erhållna dokumenten från

Scania; dokumentationen inom gasmotorer och gastankar samt manualen för Volvo Cars

VIDA.

Analys av underlaget inom gasmotorer och gastankar

I underlaget behandlas felsökning av gasmotorer och gastankar, och grundas i data framtaget

av Scania. Bakgrunden för fallet var att det kan uppstå flera mekaniska fel i gasmotorerna och

gastankarna. Scanias befintliga felsökningsprogram, SDP3, kan i dagsläget inte identifiera alla

dessa fel. Därför utfördes en utredning för att avgöra huruvida symptom kan användas inom

felsökning. Resultatet av utredningen var ett underlag där ett felsökningsschema för

gasmotorerna och gastankarna presenteras. Felsökningsschemat baseras på data från FMEA

som tidigare tagits fram. I schemat presenteras både problem, symptom, kontroller och åtgärder,

samt korrelationen mellan dem.

Analysen av underlaget inom gasmotorer och gastankar, vilket var en FMEA och ett

felsökningsschema baserat på FMEA:n, utfördes i form av en kvalitativ analys, som beskrivs

av Williamson & Bow (2002). Nedan presenteras de två analyserna och hur den kvalitativa

analysens gick tillväga.

Analys av FMEA

I analysen av FMEA:n noterades det att det fanns flera olika symptom som

utvecklingsingenjörer på Scania har identifierat. Exempel på symptom var; Högt tryck, Lågt

tryck och Gasläckage. Dessa bör dock inte förväxlas med kundsymptom, som är de symptom

som studien avser att undersöka. På grund av studiens begränsade tidsram avgränsades analysen

att enbart analysera felen som var kopplade till symptomet Högt tryck. Orsaken till detta val var

för det fanns mest data inom detta symptom.

I samband med studerandet av FMEA:n gjordes egna minnesanteckningar där både

observationer och egna tankar kopplade till underlaget noterades. Därefter kategoriserades

informationen från minnesanteckningar med hjälp av teman som noterats. Följande teman

identifierades; Innehåll i FMEA, Kundsymptom, Systemreaktioner, Datakvalitet, RPN-värde

och Förhållanden mellan symptom, komponenter och felmod. Under följande rubriker

presenteras analysen av FMEA. För fullständig information kring analysen, se Bilaga H –

Analys av FMEA.

Innehåll i FMEA

Följande rubriker fanns i FMEA, se Tabell 7. För fullständig beskrivning av innehållet i FMEA,

se Bilaga H – Analys av FMEA.

35 (68)

Tabell 7. Visar rubrikerna som fanns i FMEA:n och en beskrivning av respektive rubrik.

Rubriker Beskrivning

Systemdel Produkten som analyseras.

Component Komponenter i produkten.

Functions, Purpose Komponenternas syfte.

Failure mode Fel, så kallad felmod, som kan uppstå hos

komponenterna.

Symptom Detta är sättet felet urartar sig på utifrån

mekanikerns perspektiv.

Failure effects Felens effekt.

Failure handling by system Systemreaktioner.

Failure detection Hur felen upptäcks.

Failure isolation Åtgärder för att minimera problembilden

ytterligare.

Remedy action Avhjälpande åtgärder av mekanikern.

RPN Risk-prioritetsvärdet.

Corrective actions/ Responsible/ Comments Långsiktiga lösningar.

Notes Anteckningar.

Kundsymptom

I FMEA:n fanns rubriken Symptom. Dock stämmer inte definitionen av symptom i FMEA:n

överens med studiens definition. I studien betraktas kundsymptom som kundens sätt att

beskriva avvikelser hos fordonet utan teknisk terminologi. I FMEA:n beskrivs istället symptom

med teknisk kompetens av utvecklingsingenjörer. I övrigt så finns ingen rubrik som enbart

beskriver kundsymptomen i FMEA:n.

En del data som finns under rubrikerna Failure mode, Failure effects, Failure handling by

system och Failure Detection skulle kunna betraktas som kundsymptom, exempelvis ”kalla

fläckar på tank”. Det hade varit fördelaktigt att ha en separat kolumn med rubriken Customer

symptom, där både data från befintliga kolumner, samt nya kundsymptom skulle kunna

dokumenteras.

Systemreaktioner

Rubriken Failure handling by system betraktas som systemreaktionerna. Som det kan utläsas

ovan så kan dock data från denna rubrik även betraktas som kundsymptom. Detta kan göra

kopplingen mellan kundsymptom och systemreaktioner komplicerad. För att undvika att

begreppen förväxlas så bör strukturen och innehållet i Failure handling by system formuleras

på ett annorlunda sätt. Dessutom anses systemreaktionerna sakna relevant information, som

exempelvis vilket system som systemreaktionen är kopplad till.

Datakvalitet

Datakvaliteten för respektive rubrik i FMEA bedömdes enligt följande, se Tabell 8. Rubrikerna

med hög kvalitet anses innehålla den data som i högsta grad kan vara användbar vid en

konceptgenerering. Rubriken Failure handling by system, som syftar till systemreaktionerna,

skulle behöva användas, men eftersom kvaliteten i dagsläget bedöms som medel skulle den

behöva förbättras. Övriga rubriker med kvaliteten medel eller låg innehåller antingen irrelevant

eller bristfällig data för studien.

36 (68)

Tabell 8. Visar datakvaliteten för respektive rubrik i FMEA:n.

Rubrik Datakvalitet

Systemdel Hög

Component Hög

Functions, Purpose Medel

Failure mode Hög

Symptom Låg

Failure effects Hög

Failure handling by system Medel

Failure detection Hög

Failure isolation Låg

Remedy action Låg

RPN Hög

Corrective actions/ Responsible/ Comments Låg

Notes Låg

RPN-värde

Delar av RPN-värdet, främst Occurence (frekvens) skulle kunna ses som ett tal på hur troligt

det är att ett specifikt fel har uppstått. Detta skulle kunna användas i felsökningsprocessen på

så sätt att kundmottagare och mekaniker oftare får förslag på fel med hög frekvens. Exempelvis

om två olika fel anses vara lika troliga, så kan det vanligaste felet (felet med högst frekvens)

presenteras.

Förhållanden mellan symptom, komponent och felmod

Enligt Scanias definition är en komponent och dess tillhörande felmod tillsammans en så kallad

komponent-felmod (Scania AB, 2014). Dessa kan ses som par, men är inte alltid exklusiva till

varandra. En komponent kan ha flera olika felmoder och felmoderna kan vara kopplade till flera

olika komponenter. Det finns dock även felmoder som enbart är kopplade till en komponent,

och vice versa.

Ett symptom, enligt FMEA:ns definition, kan vara kopplad till flera olika par av komponent-

felmoder, men en komponent-felmod kan endast ha ett symptom. Detta kan dock troligtvis inte

generaliseras för kundsymptomen eftersom en komponent-felmod troligtvis kommer ha många

olika kundsymptom i verkligheten. Analys av felsökningsschema

I analysen av felsökningsschemat var det svårt att avgöra till vilken grad felsökningsschemat

grundades på FMEA:n, då utvecklandet av felsökningsscheman inte är en formell metod som

används av Scania. Likt analysen av FMEA:n gjordes egna anteckningar i samband med att

underlaget studerandes. Innehållet i anteckningarna kategoriserades därefter enligt följande;

Symptom och Felsökning. Under följande rubriker presenteras analysen av felsökningsschemat.

Symptom

I felsökningsschemat betraktas symptomen från FMEA:n som problem. Det skulle kunna

indikera att innehållet i FMEA:n inte alltid är inskrivet i rätt kolumn, eller att

felsökningsschemat även grundas på annan data. Det noteras även utifrån felsökningsschemat

att symptomen ibland beskriver situationerna då ett problem upptäcks. Exempel på detta är

”Bränsletryck tank: Ökar snabbare än förväntat vid stillastående”. I det här fallet är

37 (68)

symptomen något som mekanikern kan observera, och inte kunden. Dock skulle liknande

principer, med att beskriva situationer, kunna anses vara ett alternativ för hur ett kundsymptom

skulle kunna formaliseras även i FMEA:n. Exempelvis ”Fordonet vibrerar när jag…”.

Felsökning

Felsökningen i felsökningsschemat går ut på följande sätt; problem – symptom – kontroller –

åtgärd. Det noteras att det finns flera symptom till ett problem. På grund av detta anses

komplexiteten i felsökningen att öka. Detta eftersom det först krävs att mekanikern identifierar

vilket symptom som är aktuellt. Vid problemet Högt tryck kan det vara nödvändigt att

undersöka exempelvis hur högt trycket är, samt i vilka situationer som trycket är högt. Denna

studie kommer dock att utgå ifrån kundsymptom och inte problem.

I nästa steg så leder de flesta symptom till en kontroll, men i vissa fall leder flera olika symptom

till samma kontroll. Detta anses underlätta felsökningen eftersom även om mekanikern

identifierat fel symptom så kan ändå åtgärden bli korrekt.

Felsökningsprocessen involverar både kontroller i Scanias befintliga felsökningssystem SDP3,

samt i MULTI. Programmet MULTI innehåller bland annat instruktioner för att installera

diverse komponenter i Scanias fordon. En slutsats som kan dras utifrån innehållet är att det

krävs många kontroller för att åtgärda ett problem. Detta anses vara både tidskrävande och

komplext för mekanikern.

Konkurrensanalys - Volvo Cars VIDA

Efter analysen av dokumentationen inom felsökning av gasmotorer och gastankar, se 4.5.1

Analys av underlaget inom gasmotorer och gastankar, utfördes en konkurrensanalys av Volvo

Cars VIDA som är ett program som bland annat kan användas vid felsökning av Volvos bilar

(Volvo Cars, 2015). Orsaken till att VIDA valdes att analyseras i konkurrensanalysen var för

att detta program använder kundsymptom inom felsökningsprocessen, vilket arbetet också

eftersträvar att göra. Data från konkurrensanalysen användes som inspiration vid

konceptgenereringen och var på så sätt ett stöd för att sammanställa den tidigare insamlade

empiriska data till konkreta koncept för att sammankoppla kundsymptom med

systemreaktioner.

Konkurrensanalysen utfördes i form av en kvalitativ analys, som beskrivs av Williamson &

Bow (2002), på en användarmanual för VIDA (Volvo Cars, 2015). Först noterades relevant

information från manualen kopplade till felsökning och kundsymptom. Dessutom

dokumenterades även egna tankar kring informationen. Därefter kategoriserades data efter

följande teman; Kundsymptomkoder (CSC), Tekniska journaler och Felsökning. I detta fall

ansågs det lämpligt att ansätta rubrikerna från manualen som teman. Nedan presenteras en

sammanfattning kring respektive tema.

Kundsymptomkoder (CSC)

I Volvo Cars VIDA används kundsymptom i felsökningsprocessen för att kunna minimera

problembilden och därmed identifiera felaktiga komponenter i fordonet. I detta fall benämns

kundsymptomen som kundsymptomkoder (CSC). I VIDA kan kundsymptomkoderna

grupperas i två olika kategorier. Den ena kategorin är komponent/funktion och den andra är

funktionsgrupp. Det kan noteras att flera kundsymptomkoder, i detta fall 6 stycken, är kopplade

till funktionen Audio annat (Volvo Cars, 2015). En slutsats som kan dras utifrån denna

observation är att Scanias symptombaserade felsökningssystem kommer kräva att ett stort antal

38 (68)

kundsymptom måste kartläggas för att kunna sammankoppla kundsymptom med

systemreaktioner inom samtliga system i ett fordon.

Exempel på kundsymptom under funktionen Audio annat är; ”Knappsats på mittkonsol

fungerar inte”, ”Volymen förändras plötsligt” och ”Display på audio-enhet fungerar inte”.

Till respektive kundsymptomkod går det även att utläsa vilka åtgärder, vilket benämns

operationer, som behöver utföras för att lösa ett specifikt problem. Det är möjligt för

användaren av VIDA att söka efter specifika kundsymptomkoder. Detta kan göras på två sätt.

Antingen genom att använda en tvåsiffrig kod som varje kundsymptomkod har, eller genom att

använda nyckelord (Volvo Cars, 2015).

Tekniska journaler

Det är möjligt att läsa så kallade tekniska journaler när ett verkstadsbesök planeras i VIDA.

Journalerna innehåller flera olika typer av information, men informationen som är mest

relaterad till studien är; ”tips vid felsökning”, ”tillfälliga lösningar”, ”den faktiska lösningen

för ett visst problem” och ”meddelanden om löpande ändringar som du kan behöva känna till”.

Vilka journaler som syns för användaren beror bland annat på vilka kundsymptom som tidigare

valts till fordonet som ska felsökas, samt vilka felkoder som är aktiva i fordonet (Volvo Cars,

2015). Det hade troligtvis varit fördelaktigt att tillämpa motsvarande tekniska journaler i

Scanias initiala felsökningsprocess. Kundmottagaren skulle möjligtvis då kunna dra egna

slutsatser och därmed minska problembilden om relaterad information till vad kunden

inrapporterade presenteras. Detta skulle då underlätta kundmottagarens arbete med att planera

lämpliga servicearbeten.

Felsökning

Inom felsökning kommer enbart information som kan användas till Scanias initiala

felsökningsprocess att dokumenteras. Ett sätt att felsöka Volvos fordon i VIDA är att först

dokumentera klagomålen från förarna, och sedan översätta dessa till kundsymptomkoder.

Därefter utläses bland annat fordonets felkoder när fordonet undersöks av mekanikern med

hjälp av VIDA på Volvos verkstäder. Detta för att sedan undersöka om kundsymptomkoderna

och felkoderna tyder på att samma problem har framkallat de båda. Efter detta presenteras

potentiella åtgärder för att lösa problemen i fordonet i så kallade rankade listor. För varje åtgärd

presenteras även en tillhörande komponent. Högst upp i listan står den åtgärd som anses

troligast att lösa problemet. Sedan fortsätter listan med den näst troligaste åtgärden och så

vidare. Efter att den föreslagna åtgärden har utförts kan användaren ranka åtgärden. Rankningen

har tre alternativ åtgärden löste, löste inte eller vet ej. Rankningen fungerar även som en

rullande kvalitetssäkring av kundsymptomens koppling till åtgärden (Volvo Cars, 2015).

4.6 Konceptutveckling I följande kapitel kommer konceptutvecklingsprocessen att presenteras, samt vilka metoder som

tillämpades för att generera koncept och slutligen välja koncept.

Konceptgenerering

Konceptgenereringen baseras på analysen av underlaget inom felsökning av gasmotorer och

gastankar, semistrukturerade intervjuer, konkurrensanalysen, analysen av felsökningssystem

identifierade i litteratur samt resultatet från litteraturstudien. Resultatet från litteraturstudien är

både felsökningsmetoder samt principer för att formalisera kundsymptom.

I konceptgenereringsfasen tillämpades produktutvecklingsmetoden Brainstorming för att

generera koncept (Ulrich & Eppinger, 2012). I detta fall handlar det både om att generera

39 (68)

koncept gällande formalisering av kundsymptom och FMEA, samt koncept gällande

sammankopplingen av kundsymptom med systemreaktioner. Brainstormingen utfördes både

enskilt och i grupp. Först genererades koncept enskilt och därefter presenterades och

diskuterades koncepteten i grupp. Denna process upprepades ett flertal gånger tills koncepten

var färdigutvecklade. Nedan presenteras kortfattat samtliga koncept som har genererats. I varje

koncept presenteras formatet på FMEA och där kommer enbart ändringar från den FMEA:n

som erhölls från Scania att presenteras. Om inget nämns innehåller FMEA:n rubrikerna;

Systemdel, Component, Functions, Purpose, Failure mode, Symptom, Failure effects, Failure

handling by system, Failure detection, Failure isolation, Remedy action, Corrective actions/

Responsible/ Comments och Notes.

De flesta koncepten har formalisering av kundsymptom enligt följande; Avvikelse: är kundens

beskrivning av fordonets oväntade tillstånd vilket gör att kunden är i behov av felsökning. Detta

kan ofta beskrivas genom sinnen, exempelvis att kunden ser att det ryker eller känner att det

vibrerar, Position: är området på fordonet där kunden anser att avvikelsen förekommer. Ta reda

på om till exempel avvikelsen sker i fordonets främre eller bakre del och Kontext: innefattar

allt som sker i samband med att avvikelsen uppkommer. Här kan ett händelseförlopp vara

fördelaktigt där det beskrivs vad som hände före, under och efter att avvikelsen uppkom.

Exempelvis att en kund först kör på en motorväg men vid inbromsning på grund av köbildning

så uppkom avvikelsen. Kunden ställde då fordonet vid vägrenen och ringde efter hjälp. Till

koncepten där inte kundsymptom nämns används ovanstående formalisering. För fullständig

beskrivning av respektive koncept, se Bilaga I – Koncept.

Koncept 1

Felsökningsmetod

CBR för att sammankoppla kundsymptom med systemreaktioner.

FMEA

I detta koncept tillämpas inte FMEA.

Koncept 2

Felsökningsmetod

Bayesiska nätverk för att sammankoppla kundsymptom med systemreaktioner.

FMEA

Lägg till rubriken Customer Symptom till FMEA:n som kan innehålla en/flera kundsymptom

för varje komponent-felmod. Varje kundsymptom tilldelas en unik kundsymptomkod för att

möjliggöra sökbarhet i ett senare stadie om konceptet realiseras. Ändra den befintliga rubriken

Symptom till Problem.

Koncept 3

Felsökningsmetod

I detta koncept tillämpas inga felsökningsmetoder.

Kundsymptom

I detta koncept tillämpas inget strikt format för kundsymptomen utan kundmottagaren samlar

in kunddata på samma sätt som idag, alltså genom erfarenhet. Dock skapas ett underlag där

kundmottagaren får tips på vilken information som är bra för mekanikerna vid

felsökningssammanhang.

40 (68)

FMEA

Lägg till rubriken Customer Symptom där data kring kundsymptom läggs in. Ta in data som kan

betraktas som kundsymptom från rubrikerna Failure mode, Failure effects, Failure handling

by system och Failure Detection. Alternativt även lägga in kompletterande data kring

kundsymptom allteftersom när nya lärdomar och kopplingar mellan kundsymptom och

komponenter (så att kundmottagaren kan koppla till systemreaktioner) har gjorts. Språket på

kundsymptomen ska vara vardaglig (inte tekniskt). Lägg till rubriken Main group där

komponent-felmodernas main group läggs in för att kunna sortera FMEA:orna som presenteras

för kundmottagaren. Ändra rubriken Symptom till Problem.

Koncept 4-A

Felsökningsmetod

CBR för att sammankoppla kundsymptom med Main group.

FMEA

Lägg till rubriken Customer Symptom där data kring kundsymptom läggs in. Ta in data som kan

betraktas som kundsymptom från rubrikerna Failure mode, Failure effects, Failure handling

by system och Failure Detection. Alternativt även lägga in kompletterande data kring

kundsymptom allteftersom när nya lärdomar och kopplingar mellan kundsymptom och

komponenter (så att kundmottagaren kan koppla till systemreaktioner) har gjorts. Språket på

kundsymptomen ska vara vardaglig (inte tekniskt). Lägg till rubriken Main group och Sub

System där det läggs in vilken huvudgrupp och sub system som respektive komponent-felmod

ingår. Ändra den befintliga rubriken Symptom till Problem.

Koncept 4-B

Felsökningsmetod

CBR används för att sammankoppla kundsymptom med main group och Bayesiska nätverk

används för att sammankoppla main group med systemreaktioner.

FMEA

Lägg till rubriken Main group där respektive komponent-felmods huvudgrupp läggs in. Ändra

den befintliga rubriken Symptom till Problem.

Koncept 5

Felsökningsmetod

Felträdsanalys (FTA) används för att hitta rätt sammankoppling mellan kundsymptom och

systemreaktion.

Kundsymptom

Position: Denna delen av kundsymptomet visar på vart kundsymptomet lokaliseras av kund på

fordonet. Formaliseringen grundar sig i Systemkunskap och kommer från hur erfarna felsökare

använder sig av Topografi för att hitta orsaken till fel. Funktion: Denna delen av

kundsymptomet indikerar på vilken funktion i fordonet som den observerade avvikelsen

grundar sig i. Formaliseringen grundar sig i systemkunskap och relaterar till hur erfarna

felsökare använder sig av funktioner för att minimera problembilden vid felsökning. Övrigt:

Denna delen av kundsymptomet är mer flexibel och har funktionen att täcka upp för den delen

av kundsymptomet när en specifik funktion inte kan pekas ut. Övrigt delen av kundsymptomet

kan användas för att göra helheten av kundsymptomet mer specifikt. Kundsymptomen har

”Kundsymptomkoder”. Kundsymptomen i FMEA har sannolikhetsvärden kopplade till sig

41 (68)

baserat på sin förekomst vid specifik felmod. Sannolikhets värdena sparas förslagsvis genom

kundsymptomkoden i annan databas.

FMEA

FMEA används för att dokumentera kopplingen mellan felmod och kundsymptom. FMEA

används även för att utläsa vilken systemreaktion som är kopplad till felmoden efter att rätt

felmod har hittats i FTA. FMEA används för att koppla felmod till komponent. FMEA är

sorterad enligt BTI-systemet hos det berörda företaget, vilket innebär Main-group (system-del),

Sub-group (del-system) och Component (komponent). I FMEA ny kolumn för system-del och

del-system samt symptom kolumn har byts ut till kundsymptom. FMEA fylls i genom den

uppstartande fasen där kopplingarna sparas. En rullande återkoppling finns även för att

uppdatera FMEA. Komponenterna i FMEA har sannolikhetsvärden kopplade till sig relaterade

till ”Hur ofta komponenten går sönder”. Denna data sparas förslagsvis genom BTI koderna i

annan databas.

Koncept 6

Felsökningsmetod

CBR används för att sammankoppla kundsymptom med systemreaktioner, men om

träffsäkerheten är för låg används även Bayesiska nätverk.

FMEA

I detta koncept tillämpas inte FMEA.

Konceptval

I följande kapitel presenteras metoden för att välja det slutgiltiga konceptet.

Pughs matris

För att kunna sålla bort koncept som genererats med hjälp av produktutvecklingsverktyget

Brainstorming, och göra ett slutgiltigt konceptval användes en konceptvalsmatris som till

största del grundades på Pughs konceptvalsmatris. Utvärderingen av konceptens uppfyllelse av

urvalskriterierna gjordes genom en workshop där en medarbetare från Scania som besatt

spetskompetens inom området felsökning involverades. Urvalskriterierna bestämdes, som

tidigare nämnts, med hjälp av den tidigare framtagna QFD:n, se Bilaga F – QFD.Under

workshopen presenterades samtliga koncept och frågor besvarades angående specifika delar av

koncepten. Därefter poängsattes respektive koncept tillsammans med medarbetaren.

Poängsättningen som användes i konceptsållningsmatrisen var; ”1” – konceptet uppfyller inte

urvalskriteriet alls, ”2” – konceptet uppfyller inte urvalskriteriet tillräckligt bra, ”3” – konceptet

uppfyller urvalskriteriet på en acceptabel nivå, ”4” – konceptet uppfyller urvalskriteriet väldigt

bra, och ”N/A” – i fallen där deltagarna i workshopen inte kan utvärdera ett koncepts uppfyllelse

av ett urvalskriterium.

I konceptsållningsmatrisen viktades respektive urvalskriterium tillsammans med medarbetaren

från Scania för att säkerställa att det koncept som tillslut valdes verkligen var det mest lovande

konceptet. Vid viktningen fördelades 100% över samtliga urvalskriterier. Urvalskriterierna som

viktades högst var; Metoden skall möjliggöra en matchning mellan kundsymptom och

systemreaktioner (35%), Metoden skall kunna hantera alla typer av fel, så som mekaniska och

elektroniska (15%), Metoden skall vara standardiserad (10%), Metoden skall vara billig att

realisera (10%) och Metoden skall grundas i utvecklingsingenjörernas befintliga arbetsprocess

(5%). Resterande urvalskriterier med viktning < 5% är fortfarande viktiga för koncepten men i

förhållande till de andra kriterierna så är de mindre viktiga. Om viktningen hade exkluderats så

42 (68)

hade konsekvensen kunnat bli att det slutgiltiga konceptet hade kunnat bli ett koncept med en

hög summa fast som inte uppfyller de kritiska urvalskriterierna som exempelvis Metoden skall

möjliggöra en matchning mellan kundsymptom och systemreaktioner.

Orsaken till att Metoden skall möjliggöra en matchning mellan kundsymptom och

systemreaktioner viktades högst var för att hela arbetet grundas i detta. Orsaken till att Metoden

skall kunna hantera alla typer av fel, så som mekaniska och elektroniska viktades högt var för

att metoden ska kunna vara bättre än Scanias befintliga felsökningssystem SDP3 som enbart

kan felsöka med elektroniska felkoder. Orsaken till att Metoden skall vara standardiserad

viktades högt var för ju mer standardiserad metoden är desto lättare är det att göra dataanalyser

för att kunna koppla ihop data med åtgärder i ett senare stadie. Metoden kommer att hantera en

stor mängd data vilket gör det viktigt att denna data är strukturerad. Orsaken till att Metoden

skall vara billig att realisera viktades högt var för att koncepten skulle bli mer realistiska ur ett

ekonomiskt perspektiv. Orsaken till att Metoden skall grundas i utvecklingsingenjörernas

befintliga arbetsprocess viktades högt var för att kunna eftersträva att metoden inte skulle

innebära radikala förändringar för utvecklingsingenjörerna.

Efter viktningen multiplicerades varje urvalskriteriums procentandel med poängen koncepten

hade tilldelats för just det urvalskriteriet för att bestämma den viktade poängen. Därefter

summerades samtliga viktade poäng för respektive koncept. Det koncept med högst summa

valdes därefter till det slutgiltiga konceptet vilket var Koncept 6 med summan 3,54. Koncept 4-

B fick näst högst summa på 3,31. Orsaken till att Koncept 6 valdes var för att det konceptet fick

högst summa och för att detta koncept erhöll höga poäng på samtliga kritiska urvalskriterier.

För fullständig information om konceptsållningsmatrisen se Bilaga J – Pughs matris.

43 (68)

5 Resultat I följande kapitel kommer resultat från fallstudien att presenteras och arbetets uppfyllelse av

målen.

5.1 Presentation av valt slutgiltigt koncept

Koncept 6 innehåller två faser; den inledande fasen och den faktiska fasen. Detta koncept skulle

kunna betraktas som en datadriven metod. Metoden bygger främst på CBR men för att kunna

erhålla en hög träffsäkerhet mellan kundsymptom och systemreaktioner så används även

Bayesiska nätverk om ett kundsymptom är kopplat till fler än en systemreaktion.

Den inledande fasen

Den inledande fasen handlar om att dokumentera kundsymptom och systemreaktioner samtidigt

som Scanias befintliga felsökningsprocess utförs. I denna fas frågar kundmottagarna kunderna

efter avvikelse, position och kontext vid kontakt med kunder och dokumenterar svaren i fritext.

Denna data skickas sedan både till mekanikern i arbetsordern som grund för det kommande

servicearbetet, men också till utvecklingsingenjörerna på Scania R&D. Efter att mekanikerna

har utfört servicearbetet så återkopplar de vilken systemreaktion som var aktiv i fordonet till

utvecklingsingenjörerna.

Utvecklingsingenjörerna utreder kundmottagarens data där de formaliserar kundsymptomen

enligt formatet avvikelse, position och kontext. Utvecklingsingenjörerna bestämmer alltså

baserat på kundmottagarens data vad som ska stå under respektive kategori. När

kundsymptomen (input) har formaliserats och tillhörande systemreaktion (output) har

identifierats så dokumenteras denna data i ”cases” enligt felsökningsmetoden CBR vilket sedan

överförs till ett ”case-library” (Warnquist, 2015). I figuren nedan presenteras ett flödesschema

för den inledande fasen, se Figur 4.

Figur 4. Visar flödet för den inledande fasen.

Format för kundsymptom

Avvikelse:

• Avvikelsen är kundens beskrivning av fordonets oväntade tillstånd vilket gör att kunden

är i behov av felsökning. Detta kan ofta beskrivas genom sinnen, exempelvis att kunden

ser att det ryker eller känner att det vibrerar.

Position:

• Position är området på fordonet där kunden anser att avvikelsen förekommer. Ta reda

på om till exempel avvikelsen sker i fordonets främre eller bakre del.

44 (68)

Kontext:

• Kontext innefattar allt som sker i samband med att avvikelsen uppkommer. Här kan ett

händelseförlopp vara fördelaktigt där det beskrivs vad som hände före, under och efter

att avvikelsen uppkom. Exempelvis att en kund först kör på en motorväg men vid

inbromsning på grund av köbildning så uppkom avvikelsen. Kunden ställde då fordonet

vid vägrenen och ringde efter hjälp.

Den faktiska fasen

I den faktiska fasen byts Scanias befintliga felsökningsprocess ut till denna metod.

Felsökningsmetoden CBR används för att matcha nya kundsymptom med tidigare fall som finns

dokumenterat i ”case library”. I denna fas frågar kundmottagarna återigen efter avvikelse,

position och kontext vid kontakt med kunden. Men istället för att kundmottagaren dokumenterar

svaren i fritext får kundmottagaren välja i en dropdown-meny under respektive kategori vad

som passar kundens beskrivning bäst. Om exempelvis kunden beskriver en avvikelse hos

fordonet som ”det ryker i fordonets främre del” så kan kundmottagaren välja fram under

kategorin position. Valalternativen som presenteras för kundmottagarna i dropdown-menyn

baseras på det förarbete utvecklingsingenjörerna utförde i den inledande fasen.

Baserat på vad kundmottagaren väljer under respektive kategori sker det en ”retrieval”

(nyckelordsdriven) enligt CBR för att matcha detta kundsymptom med tidigare fall i ”case-

library” och på sätt koppla ihop kundsymptomet med dess tillhörande systemreaktion

(Bergmann, et al., 2003). Om ett kundsymptom tidigare har kopplats till mer än en

systemreaktion så matchas i detta koncept kundsymptomet med systemreaktionen som har

uppkommit flest gånger. Det är upp till Scania att avgöra vad en acceptabel nivå av träffsäkerhet

är, men principen för detta koncept är att om matchningen är över den acceptabla nivån så förs

systemreaktionen vidare direkt till mekanikern. Däremot om matchningen blir lägre en den

acceptabla nivån så anses vidare felsökning vara nödvändigt för att erhålla en bättre

träffsäkerhet.

Den vidare felsökningen sker med hjälp av Bayesiska nätverk där data hämtas från ”case

library”. I den grafiska modellen av det Bayesiska nätverket så ansätts det inmatade

kundsymptomet som ”child node” och den matchade systemreaktionen som ”parent node”.

Beroendet i den grafiska modellen blir att systemreaktionerna leder till kundsymptomen.

Sannolikhetsdistributionen för ”parent nodes” baserar på antalet gånger kundsymptomet

kopplat till systemreaktionen har dokumenteras i ”case library”. Utöver den matchade

systemreaktionen så ansätts även de andra systemreaktionerna som tidigare kopplats med det

aktuella kundsymptomet i ”case library” som ”parent nodes”. I ”case library” identifieras

sedan andra kundsymptom som eventuellt är kopplade till de aktuella systemreaktionerna.

Dessa blir också ”child nodes” i den grafiska modellen. Anledningen till att andra

kundsymptom som kopplats till de aktuella systemreaktionerna identifieras är att

kundmottagaren med hjälp av dessa kan ställa följdfrågor. Dessa följdfrågor är om kunden

upplever de andra kundsymptomen också. Med hjälp av denna kompletterande information kan

det Bayesiska nätverket avgöra vilken systemreaktion som är den mest sannolika.

Det ovanstående kan exemplifieras genom följande situation. Kundmottagaren väljer baserat

på vad kunden förmedlar olika valalternativ i dropdown-menyn som blir kundsymptom 1.

Genom CBR matchas detta kundsymptom med 70% till systemreaktion A och 30% till

systemreaktion B baserat på antalet gånger respektive case har dokumenterats i ”case library”.

I exemplet ansätts den acceptabla nivån av träffsäkerhet till 75%. Eftersom ingen av

systemreaktionerna överstiger 75% så anses vidare felsökning behöva göras. Detta görs med

45 (68)

det Bayesiska nätverket. För att kunna konstruera det Bayesiska nätverket så identifieras sedan

de andra kundsymptomen som eventuellt är kopplade till systemreaktion A och B. I detta

exempel är systemreaktion B även kopplad till kundsymptom 2 och 3. Därefter konstrueras det

Bayesiska nätverket enligt följande för att avgöra vilken systemreaktion som verkligen orsakar

kundsymptom 1, se Figur 5.

Figur 5. Visar den grafiska modellen för det Bayesiska nätverket för exemplet ovan.

Kundmottagaren får i ett grafiskt användargränssnitt efter inmatningen i dropdown-menyn reda

på att kundsymptom 2 och 3 är kopplade till det som initialt matades in och ställer baserat på

det följdfrågor till kunden. Beroende på vad kunden svarar påverkar det sannolikheten för de

olika systemreaktionerna. Om kunden skulle svara att även kundsymptom 2 och kundsymptom

3 har noterats kan det innebära att det är systemreaktion B som är den korrekta systemreaktionen

till det initialt inmatade kundsymptomet. Principen för detta är alltså att ju fler frågor

kundmottagaren ställer till kunden desto högre träffsäkerhet mellan kundsymptom och

systemreaktion kan erhållas.

Efter varje matchning, och avklarat servicearbete, så återkopplar mekanikern om den

rekommenderade systemreaktion verkligen var rätt. Om den rekommenderade

systemreaktionen var korrekt så skapas ett nytt ”case” med kundsymptomet och den

rekommenderade systemreaktion. Detta kommer för framtida fall påverka

sannolikhetsdistributionen. Om den rekommenderade systemreaktionen inte stämde så är det

viktigt att den korrekta systemreaktionen identifieras för att öka träffsäkerheten för framtida

matchningar. I detta fall presenteras de andra systemreaktionerna som tidigare kopplats till det

inmatade kundsymptomet. När mekanikern har valt vilken systemreaktion som var korrekt från

listan så skapas ett nytt ”case” med kundsymptomet och denna systemreaktion. Detta kommer

för framtida fall påverka sannolikhetsdistributionen. Om den rekommenderade

systemreaktionen inte stämde och de andra systemreaktionerna inte heller är korrekta så

återkopplas istället den verkliga systemreaktionen till utvecklingsingenjörerna på R&D. De

skapar sedan ett nytt ”case” och lägger in i det i ”case library”. Även detta påverkar

sannolikhetsdistributionen för framtida fall. Metodens träffsäkerhet ökar med antalet fall som

dokumenteras i ”case library”.

Det finns två fall när den faktiska fasen inte fungerar. Den första är när kundmottagaren kan

beskriva kundsymptomet med den data som finns i dropdown-menyn, men detta kundsymptom

inte kan matchas med några tidigare fall i ”case library”. Då utförs felsökningsprocessen likt

den befintliga idag frånsett att mekanikern efter utfört servicearbete återkopplar till

utvecklingsingenjörerna på R&D vilken systemreaktion som var kopplad till kundsymptomet.

Utvecklingsingenjörerna skapar då ett nytt ”case” och dokumenterar i ”case library”. Den

andra är när kundmottagaren inte kan beskriva kundsymptomet fullständigt med den data som

finns i dropdown-menyn. Då sker felsökningen som i den inledande fasen. I figuren nedan

presenteras ett flödesschema för den faktiska fasen, se Figur 6.

46 (68)

Figur 6. Visar flödet för den faktiska fasen.

5.2 Uppfyllelse av mål I följande kapitel presenteras uppfyllelsen av del- och huvudmålen som definierades i samband

med studiens start. Delmålet som skapades i studiens start baseras på en kravlista bestående

av 10 krav, genom att uppfylla kraven skapas förutsättningen för att uppfylla delmålet och

vidare huvudmålen.

Delmålet är att uppfylla 10/10 krav från kravlistan. Det acceptabla målvärdet är att uppfylla

alla kritiska krav, vilket gör att en uppfyllnad av 50% av kraven är den minsta acceptabla

uppfyllanden om och endast om alla av kraven är kritiska krav. Acceptabel uppfyllelse av

huvudmålen anses vara för huvudmål (1) 44% då det berörs av totalt 9 krav varav 4 är kritiska

och huvudmål (2) 60% då det berörs av totalt 5 krav varav 3 är kritiska. I Tabell 9 nedan kan

de kritiska kraven med tillhörande uppfyllelse utläsas och i Tabell 10 kan de önskade kraven

med tillhörande uppfyllelse utläsas. För motivering till de ”kritiska kraven”, se Bilaga A –

Motivering av kritiska krav. För motivering av uppfyllnad för de kritiska och önskade kraven,

se Bilaga K – Motivering till uppfyllnad av kritiska och önskade krav. I Tabell 11 kan

motivering till uppfyllelse samt uppfyllelsen av delmål och huvudmål utläsas. Det visade sig

att ett av kraven inte hade någon relevans för den framtagna metoden och bedömdes därför att

negligeras, detta var kravet ”Identifiera kategorier av data som är nödvändiga för att

formalisera FMEA som möjliggör att en sammankoppling mellan kundsymptom och

systemreaktioner kan uppnås”. Negligeringen påverkar det totala antalet krav samt hur många

krav huvudmål (2) har kopplat till sig och dess acceptabla uppfyllelse, se motivering i

motivering uppfyllelse till delmål i Tabell 11.

47 (68)

Tabell 9. Visar uppfyllnad av de kritiska kraven samt vilket huvudmål de påverkar.

Kritiska krav Uppfyllelse

[JA/NEJ]

Identifiera kategorier av data som är nödvändiga för att formalisera

kundsymptom och som möjliggör att en sammankoppling mellan

kundsymptom och systemreaktioner kan uppnås.

Påverkar mål: (1), (2)

JA

Identifiera kategorier av data som är nödvändiga för att formalisera

FMEA som möjliggör att en sammankoppling mellan kundsymptom och

systemreaktioner kan uppnås.

Påverkar mål: (2)

N/A

Identifiera vetenskapligt grundade felsökningsmetoder som kan

tillämpas för att sammankoppla kundsymptom med systemreaktioner.

Påverkar mål: (1) JA

Metoden skall kunna hantera kundsymptom som både grundas i

elektroniska fel och mekaniska fel.

Påverkar mål: (1) JA

Metoden skall ta hänsyn till den detaljrikedom av information som en

kund är kapabel till att ge kundmottagaren med sin tekniska kompetens.

Påverkar mål: (1), (2) JA

Tabell 10. Visar uppfyllnad av de önskade kraven samt vilket huvudmål det påverkar.

Önskade krav Uppfyllelse

[JA/NEJ] Metoden skall vara applicerbar inom samtliga system, som exempelvis

broms- och motorsystemet, i ett tungt fordon.

Påverkar mål: (1) JA

Metoden skall förebygga brister som existerar i den nuvarande initiala

felsökningsprocessen.

Påverkar mål: (1) JA

Metoden skall ta hänsyn till vad ”bra” data är för en felsökare.

Påverkar mål: (1), (2) JA

Metoden skall tillhandahålla möjlighet till förslag på åtgärd i framtida

symptombaserat felsökningsverktyg.

Påverkar mål: (1), (2) JA

Metoden skall vara tillämpar till samtliga generationer av Scanias

fordon.

Påverkar mål: (1) JA

48 (68)

Tabell 11. Visar uppfyllnad av huvudmål och delmål samt motivering till samtliga del och huvudmål.

Delmål Uppfyllelse

[ja/nej] Motivering uppfyllelse

Uppfylla 10/10 av kraven, det

acceptabla målvärdet är att

uppfylla alla kritiska krav.

JA

Det visade sig för det kritiska kravet: ”

Identifiera kategorier av data som är

nödvändiga för att formalisera FMEA

som möjliggör att en sammankoppling

mellan kundsymptom och

systemreaktioner kan uppnås.” var

överflödigt i samband med användning

av CBR. Detta gjorde att kravet inte

hade någon relevans för metoden och

bedömdes därför att negligeras. Det gör

att kravlistan består av 9 aktuella krav.

Eftersom metoden uppfyller alla andra

krav kan därför delmålet anses vara

uppfyllt.

Grad av uppfyllelse av delmål

[%]

Kritiska krav: 4/4 uppfyllda = 100%

Önskade krav: 5/5 uppfyllda = 100%

Total uppfyllelse krav: 9/9 uppfyllda = 100%

Delmål: 1/1 uppfyllda = 100%

Huvudmål Uppfyllelse

[ja/nej] Motivering uppfyllelse

(1) Det ena är att utveckla en

metod för att tydligt

sammankoppla kundsymptom

med systemreaktioner inom

tunga fordon. Metoden kommer

att vara en dellösning som ingår

i det verktyg för

symptombaserad felsökning.

JA

Målet har 9 krav vilket det påverkas av.

9/9 av kraven är uppfyllda. Delmålet

anses även uppfyllt vilket även stödjer

huvudmålets uppfyllnad. Eftersom att

alla krav och delmål påverkande

huvudmål (1) är uppfyllda anses även

huvudmålet uppfyllt.

(2) Det andra är att utveckla ett

format för kundsymptom och

FMEA som kan tillämpas i den

framtagna metoden för

sammankopplingen mellan

kundsymptom och

systemreaktioner.

JA

Målet hade 5 krav vilket det påverkas

av. Ett av kraven negligerades då det

inte hade någon relevans för den

framtagna metoden, vilket gör att mål

(2) har 4 aktuella krav kopplade till sig.

Den acceptabla nivån av uppfyllelse är

då istället 50% då den har totalt 4 krav

varav 2 är kritiska. 4/4 av kraven är

uppfyllda vilket ger en uppfyllnad på

100%. Med detta anses målet uppfyllt.

Grad av uppfyllelse av

huvudmålen [%]

Mål (1): 9/9 krav uppfyllda som påverkar målet = 100%

Mål (2): 4/4 krav uppfyllda som påverkar målet = 100%

49 (68)

6 Analys I följande kapitel kommer arbetet att analyseras.

6.1 Analys av det slutgiltiga konceptet Konceptets formalisering av kundsymptom grundades på svaren från de semistrukturerade

intervjuerna som utfördes bland annat med R&D-mekaniker. Där noterades det att ”bra” data

för mekaniker vid felsökningssammanhang är avvikelse, position och kontext, se avsnitt 4.4

rubrik Brister och förbättringsmöjligheter. Hung & Jonassen (2006) och Cegarra & Hoc (2006)

menar även att topografiska kunskaper, alltså kunskapen om vart ingående komponenter i en

produkt är placerade, är fördelaktiga att besitta vid felsökning av produkter. I detta fall anses

litteraturen stärka arbetets val av format för kundsymptom då topografi anses kunna jämföras

med position. Under intervjuerna noterades även att ett generellt problem idag är att fordonens

ökande komplexitet medför att förare har svårare att förstå vad som sker i fordonet, se avsnitt

4.4 rubrik Brister och förbättringsmöjligheter. Det anses därför fördelaktigt att formalisera

kundsymptomen efter avvikelse, position och kontext för det är information som en kund anses

kunna förmedla utan att ha förståelse av enskilda komponenter i fordonet. Metodens

formalisering av kundsymptom kräver alltså ingen teknisk kompetens utifrån kundens

perspektiv. Denna strategi att inte kräva att kunden ska vara tekniskt kunnig för att kunna

beskriva symptomen stärks även utav O`Neill, et al. (2005) och Bergmann, et al. (2003).

I detta koncept exkluderades användandet av FMEA:or. Utifrån analysen av FMEA, se avsnitt

4.5.1 rubrik Analys av FMEA, noterades det att data kring systemreaktioner under rubriken

Failure handling by system var bristfällig och datakvaliteten bedömdes därför till ”Medel”.

Dessutom var det den kolumn som saknade mest data i FMEA:n. Det ansågs därför fördelaktigt

att exkludera FMEA:orna i konceptet och istället dokumentera data för att sammankoppla

kundsymptom med systemreaktioner i ett ”case library” enligt CBR.

Detta koncept förlitar sig mindre på mänskliga felsökare och istället mer på datordrivna metoder

som CBR och Bayesiska nätverk. Detta då kundmottagarna enbart väljer förbestämda val

baserat på kundens data i en dropdown-meny och ställer följdfrågor som metoderna presenterar

under den faktiska fasen. Det har påvisats att erfarenhetskunskap är den form av kunskap som

är mest användbar för felsökare vid felsökning av produkter (Hung & Jonassen, 2006). Dock i

detta koncept exkluderas den mänskliga erfarenheten i kundmottagarrollen. I dagsläget är det

svårt att avgöra vad detta har för exakt innebörd för träffsäkerheten mellan kundsymptom och

systemreaktion. En fördel däremot med att ha förbestämda val i dropdown-meny är att det anses

kunna minimera risken att kundmottagarna gör felaktiga analyser av kundens data. Från de

semistrukturerade intervjuerna noterades det att det kunde bli missbedömningar från

kundmottagarens sida i steget Bearbeta kunddata, se avsnitt 4.4 rubrik Brister och

förbättringsmöjligheter. Denna metod kräver inte lika mycket bearbetning av kunddata från

kundmottagarens sida i den faktiska fasen som i den befintliga initiala felsökningsprocessen.

Enligt O`Neill, et al. (2005) ska kundmottagaren instruera kunden att förmedla information som

är värdefull ur ett felsökningsperspektiv eftersom det kan vara svårt för kunden att veta vad som

bör berättas för kundmottagaren. Med hjälp av kategorierna avvikelse, position och kontext blir

det både enklare för kundmottagarna att veta vilka frågor som de bör ställa till kunden och

samtidigt enklare för kunden att veta vilken typ av information som betraktas som värdefull.

Från de semistrukturerade intervjuerna noterades det att kundmottagarna ansåg det fördelaktigt

att ha ett hjälpmedel som möjliggör ett mindre beroende av kundmottagarens egna erfarenheter,

se avsnitt 4.4 rubrik Brister och förbättringsmöjligheter. Med hjälp av det Bayesiska nätverket

presenteras kundsymptom som kundmottagaren kan fråga kunden efter för att erhålla en högre

50 (68)

träffsäkerhet mellan kundsymptom och systemreaktion. På så sätt förlitar sig metoden inte

längre på kundmottagarnas erfarenhet, utan erfarenheten samlas in i metoden istället.

Detta konceptet tillämpar felsökningsmetoden CBR för att göra en sammankoppling mellan

kundsymptom och dess tillhörande systemreaktion. Enligt Warnquist (2015) kräver denna

metod att ”cases” dokumenteras i ett ”case library” under en längre tid för att metoden ska

vara tillförlitlig, alltså att det ska kunna ske matchningar när nya fall introduceras. Detta innebär

att det kan ta tid innan det är möjligt för Scania att övergå från den inledande fasen till den

faktiska fasen. En fördel med felsökningsmetoden är dock enligt Yu, et al. (2015) att det är

relativt enkelt att matcha ihop lösningar till problem med denna metod. I detta fall matchas som

tidigare nämnts kundsymptom och systemreaktion vilket anses vara samma sak som att matcha

ihop lösningar och problem. Även om felsökningsmetoden kan betraktas som enkel har denna

enkelhet konsekvensen att metodens träffsäkerhet kan påverkas negativt (Yu, et al., 2015).

Detta koncept anses kunna hantera detta genom att även tillämpa Bayesiska nätverk när

träffsäkerheten för CBR är för låg enligt Scania. Enligt Kurz, et al. (2011) är fördelarna med

Bayesiska nätverk bland annat att den kan tillämpas till komplexa produkter vilket tunga fordon

kan betraktas vara. Detta påvisar att denna felsökningsmetod kan tillämpas till detta ändamål.

En annan fördel enligt Kurz, et al. (2011) är att metoden kan tillämpas även om data saknas.

Detta anses fördelaktigt i fallen när en kund inte kan exempelvis besvara följdfrågorna som

kundmottagaren ställer.

I det Bayesiska nätverket kommer systemreaktionerna i detta koncept vara ”parent nodes”.

Enligt Huang et al. (2008) kan tillhörande sannolikhetsdistributioner till dessa noder bestämmas

med bland annat erfarenhet. I konceptet baseras värdena i sannolikhetsdistributionen på antalet

gånger ett kundsymptom och dess tillhörande systemreaktion, alltså ett ”case”, dokumenterats

i ”case library”. Detta anses vara lättare än om omfattande tester på Scanias produkter skulle

genomföras för att erhålla statistik till sannolikhetsdistributionerna.

Enligt O`Neill et al. (2005) är det kritiskt för ett felsökningssystem att symptom kan uppdateras,

men även att nya symptom kan tillkomma i systemet. Detta koncept bygger på denna princip

genom att i den inledande fasen dokumentera kundsymptom och systemreaktioner

kontinuerligt, och i den faktiska fasen tillföra metoden med nya kundsymptom och

systemreaktioner vid behov. Här har mekanikern en kritisk roll eftersom det är mekanikern som

i konceptet verifierar att metodens rekommendationer stämmer med vad som faktiskt skedde

med fordonet.

I konceptet bestämdes inte den acceptabla nivån av träffsäkerhet som avgör om det Bayesiska

nätverket ska användas för att erhålla en bättre träffsäkerhet mellan ett kundsymptom och

systemreaktion (”case”). Det anses vara upp till Scania att bestämma denna gräns. För att

undvika att flera systemreaktioner kan få lika stor matchning i CBR föreslås i alla fall att gränsen

är mer än 50%. Detta beror på att om det blir två matchningar så blir träffsäkerheten som högst

50% för respektive case förutsatt att dessa två ”cases” har dokumenterats lika många gånger i

”case library”. Om gränsen är då över 50% kommer det Bayesiska nätverket alltid att användas

om det finns två matchningar med samma träffsäkerhet.

Från de semistrukturerade intervjuerna noterades det att felkoder kan ingå i dataflödet mellan

kund och kundmottagare, se avsnitt 4.4 rubrik Dataflöden. I och med att det slutgiltiga resultatet

använder felsökningsmetoden CBR, där data dokumenteras i ”cases” (Warnquist, 2015), anses

det vara möjligt att även dokumentera felkoder utöver kundsymptom och systemreaktioner.

Från intervjuerna noterades att kundsymptom ibland kan stjälpa felsökningsprocessen om

51 (68)

kunderna tros uppleva en avvikelse från fordonet, se avsnitt 4.4 rubrik Brister och

förbättringsmöjligheter. I dessa fall hade insamlandet av felkoder kunnat hantera sådana

missuppfattningar om den framtagna metoden jämförde kundsymptomen och felkoderna likt

Volvo Cars VIDA, se 4.5.2 Konkurrensanalys - Volvo Cars VIDA. Alltså att undersöka om

kundsymptomen och felkoderna tyder på samma problem hos fordonet eller om de är

motsägande.

6.2 Besvarande av fallstudiens frågeställning I följande kapitel kommer fallstudiens frågeställning att besvaras vilket ligger till grund för

besvarandet av forskningsfrågorna.

Vilken data saknas i Scanias befintliga dokumentation för att kunna sammankoppla

kundsymptom med systemreaktioner?

För att kunna besvara denna frågeställning kopplad till fallstudien har Scanias befintliga initiala

felsökningsprocessen kartlagts och expertdata, i form av FMEA, från Scania har även

analyserats. En sammankoppling mellan kundsymptom och systemreaktioner anses förutsätta

att de både dataformerna finns tillgängliga och strukturerade i Scanias befintliga

dokumentation.

Det noterades under arbetets gång att kundsymptom inte dokumenteras av Scania på ett

strukturerat sätt. I FMEA:n som ingick i underlaget inom gasmotorer och gastankar fanns

rubriken Symptom men denna data var mer teknisk, som exempelvis ”Högt tryck”, se avsnitt

4.5.1 rubrik Analys av FMEA. Detta ansågs inte vara data som kunden kan förmedla och

därmed konstaterades det att symptom-begreppet i FMEA:n inte var densamma som begreppet

kundsymptom. Vid analysen av felsökningsschemat som grundades på den erhållna FMEA:n

nämndes även begreppet symptom, se avsnitt 4.5.1 rubrik Analys av felsökningsschema. Likt i

FMEA:n så var begreppet symptom även här mer teknisk, exempelvis ”Bränsletryck tank: Ökar

snabbare än förväntat vid stillastående”. I och med att konstruera felsökningsscheman inte är

ett standardiserat arbetssätt för Scania kan data i schemat varken betraktas vara tillgänglig eller

strukturerad. Detta då inga andra felsökningsscheman har utvecklats för andra komponenter i

Scanias produkter än inom gasmotorer och gastankar.

I den befintliga initiala felsökningsprocessen noterades det att dataflödet mellan kund och

kundmottagare innehåller symptom som kan betraktas som kundens beskrivning av felet

kunden upplever, se avsnitt 4.4 rubrik Dataflöden. Detta innebär att kundmottagarna i den

initiala felsökningsprocessen erhåller bland annat kundsymptom som därefter dokumenteras i

arbetsordern. Dock använder kundmottagarna ingen standardiserad metod vid insamlandet av

data från kunden, se avsnitt 4.4 rubrik Process. Alltså anses denna data vara ostrukturerad.

Enligt intervjuerna noterades det även att kundmottagarna arbetar mycket på erfarenhet, se

avsnitt 4.4 rubrik Process. Detta anses kunna medföra att kvaliteten hos denna data kring

kundsymptomen även kan variera. Överföringen av kunddata sker från kundmottagaren till

mekanikern antingen muntligt eller skriftligt i arbetsordern, se avsnitt 4.4 rubrik Dataflöden.

Detta anses också påvisa att den data som överförs är ostrukturerad då överföringen inte sker

på ett konsekvent sätt. Problemet i dagsläget kring kundsymptom är att kundsymptom inte

dokumenteras av utvecklingsingenjörerna i FMEA:orna och om den dokumenteras i

arbetsordern av kundmottagaren är denna data inte strukturerad. För att data kring

kundsymptomen ska kunna användas för att kunna sammankopplas till systemreaktioner måste

utvecklingsingenjörerna involveras för att säkerställa att dokumentationen sker på ett

strukturerat sätt. Dessutom måste kundmottagarna ha ett standardiserat tillvägagångsätt,

förutom i arbetsordern, för att skapa struktur och öka kvaliteten i de insamlade kundsymptomen.

52 (68)

I den erhållna FMEA:n inom gastmotor och gastankar fanns rubriken Failure handling by

system vilket är systemreaktioner till respektive komponents felmod i FMEA:n (Scania AB,

2014). I analysen av FMEA:n noterades det att denna kolumn för systemreaktionerna var en av

de kolumner i FMEA:n som innehöll minst antal ifyllda celler, se avsnitt 4.5.1 rubrik Analys

av FMEA. Detta indikerar att FMEA:n antingen var bristfällig eller att varje komponent-felmod

inte har en tillhörande systemreaktion. Dessutom bedömdes datakvaliteten på de

systemreaktioner som fanns dokumenterade som ”Medel”, se avsnitt 4.5.1 rubrik Analys av

FMEA. Detta berodde delvis på att vissa systemreaktioner även kunde betraktas som

kundsymptom vilket anses kunna skapa förvirring för utvecklingsingenjörerna. Dessutom för

att det ansågs att kritiskt information saknades i systemreaktionen såsom vilket system som

reaktionen var kopplad till. Detta är dock inget problem om FMEA:orna studeras eftersom det

är då möjligt att se vilken komponent-felmod som en systemreaktion tillhör, men om

systemreaktionerna används, utan FMEA, i felsökningsmetoderna anses det kunna bli

problematiskt.

Problemet i dagsläget kring systemreaktionerna är alltså att data saknas och är av bristfällig

kvalitet i den befintliga dokumentationen. För att kunna sammankoppla till kundsymptom

måste därför alla systemreaktioner till respektive komponent-felmod i FMEA:orna identifieras

och innehållet under rubriken Failure handling by system måste differentieras så att det endast

finns data kring systemreaktioner där samt måste innehållet under rubriken överses för att öka

datakvaliteten. Dock i och med att det slutgiltiga konceptet inte använder befintlig

dokumentation för att sammankoppla kundsymptom med systemreaktioner så kan det

konstateras att det inte har någon betydelse om den befintliga dokumentationen kring

kundsymptom och/eller systemreaktioner är tillräcklig eller bristfällig.

6.3 Besvarande av forskningsfrågorna I följande kapitel besvaras forskningsfrågorna.

F1: Hur påverkas felsökningsprocessen utifrån de metoder som kan användas för att

sammankoppla kundsymptom med systemreaktioner inom tunga fordon?

Om datadrivna metoder används, så som CBR, Bayesiska nätverk och Felträdsanalys, för att

sammankoppla kundsymptom med systemreaktioner så blir kundmottagarrollen mindre kritisk

i felsökningsprocessen än vad den är idag. Utifrån de semistrukturerade intervjuerna noterades

det att kundmottagarnas arbete till största del grundas på erfarenhet, se avsnitt 4.4 rubrik

Process, men med användandet av metoderna kommer kundmottagarna inte längre att behöva

förlita sig på dessa tidigare erfarenheter. Istället kommer de att kunna använda sig av data

erhållen från metoderna. Detta innebär även att avvägandet av vad som är relevant data eller

inte från kunden övergår från mänsklig till datadriven. Dock motstrider detta med O`Neill, et

al. (2005) som anser att kundmottagarens roll är viktig för att få ut rätt data från kunden.

En fördel med att kundmottagarrollen blir mindre kritisk är att risken för att kundmottagarna

gör felaktiga missbedömningar under felsökningsprocessen kan minska. Detta problem

identifierades från de semistrukturerade intervjuerna, se avsnitt 4.4 rubrik Brister och

förbättringsmöjligheter, där konsekvenserna av missbedömningar noterades kunna vara att

servicearbeten tog längre tid att utföra. Däremot är en nackdel med detta att kundmottagarnas

erfarenhetskunskaper kan gå förlorade, eftersom metoderna inte alltid lämnar utrymme för egna

tankar och idéer. Dock säger även detta emot Hung & Jonassen (2006) som menar att

erfarenhetskunskaper är en kritisk form av kunskap vid felsökningssammanhang.

53 (68)

Om datadrivna metoder exkluderas och sammankopplingen mellan kundsymptom och

systemreaktioner istället görs med hjälp av kundmottagarna där FMEA:orna används som stöd

anses kundmottagarrollen i felsökningsprocessen bli lika kritisk som den är idag. Detta är, som

tidigare nämnts, eftersom felsökningsprocessen då kommer att grundas på kundmottagarnas

erfarenhet. Det finns dock vissa problem med att enbart grunda felsökningen på FMEA:or.

Exempelvis så baseras ofta FMEA:or på ingenjörers antaganden av vilka fel som kommer att

uppstå, och inte på faktiska fall (Khan, et al., 2014). Dessutom, enligt Khan, et al. (2014) så

dokumenteras oftast inte nya fel som identifierats på verkstäder i redan befintliga FMEA:or.

Detta innebär att exkluderande av datadrivna metoder kommer kräva att

utvecklingsingenjörerna gör ett mer omfattande arbete med att framta och underhålla

FMEA:orna. Uppdaterade och korrekta FMEA:or anses vara en förutsättning för att

kundmottagarna ska kunna sammankoppla kundsymptom med systemreaktioner utan

datadrivna metoder.

Eftersom den befintliga dokumentationen som skulle kunna användas till att sammankoppla

kundsymptom med systemreaktioner ansågs vara bristfällig, se 6.2 Besvarande av fallstudiens

frågeställning, så kommer det krävas ett förarbete som kommer att ligga som grund till de olika

felsökningsmetoderna. Felsökningsprocessen blir därför direkt beroende på hur väl förarbetet

till respektive metod utförs. Dock så kräver de olika metoderna varierande tidsåtgång och

arbetsbelastning för att kunna erhålla en tillräckligt hög träffsäkerhet. Exempelvis så anses de

metoder med logiska sammankopplingar, så som Bayesiska nätverk och Felträdsanalys, att

kräva mer tid och arbete än CBR som enbart består av indata och utdata (Yu, et al., 2015). Dessa

två metoder anses inkludera logik då sannolikhet används samt relationer och beroenden mellan

metodernas ingående komponenter utreds. Varför förarbetet för exempelvis Felträdsanalys

anses bli mer krävande är för att metoden kräver en djup förståelse för systemet i fråga (Yu, et

al., 2015). Detta anses även stämma för Bayesiska nätverk eftersom att noder och beroenden

måste utredas (Warnquist, 2015). Förarbetet för CBR, där ”cases” sparas ner till ett ”case

library”, görs vanligtvis genom att utföra manuella felsökningar (Warnquist, 2015), men

eftersom att Scania redan har en väletablerad felsökningsprocess så bör detta utnyttjas. Därmed

anses förarbetet till CBR att kunna utföras i samband med den befintliga felsökningsprocessen

vilket gör att den extra tidsåtgången och arbetsbelastningen blir minimal.

Felsökningsprocessen påverkas också av metodernas varierande träffsäkerhet eftersom metoder

med högre träffsäkerhet oftare anses hitta rätt systemreaktion. Enligt Yu, et al. (2015) medför

avsaknad av logik mellan problem och lösning att träffsäkerheten blir lägre, vilket är fallet för

metoden CBR. I detta arbete anses problem och lösning kunna liknas med kundsymptom och

systemreaktioner, även om systemreaktionerna egentligen är en dellösning och den faktiska

lösningen snarare är åtgärden till problemet. Kundsymptomen anses passa som problem

eftersom Yu, et al. (2015) menar att problemet oftast består av kundens observationer vilket

kundsymptomen också gör. Till skillnad från CBR så anses felsökningsmetoder med logik så

som Bayesiska nätverk och Felträdsanalys ha en högre träffsäkerhet. Något som alla tre

metoder har gemensamt är att deras träffsäkerhet anses öka med tiden. Detta är tydligast i CBR

där alla nya fall sparas ner och därmed görs ”case library” mer omfattande vilket i sin tur ökar

träffsäkerheten för framtida matchningar (Warnquist, 2015). För Bayesiska nätverk och

Felträdsanalys anses det krävas mer aktiva handlingar för att öka metodernas träffsäkerhet.

Exempelvis så menar Warnquist (2015) att Bayesiska nätverk kan använda ny data för att bli

smartare och därmed få en högre träffsäkerhet, men denna nya data kommer då behöva tillföras

till metoden manuellt.

54 (68)

Alla tre metoder har både för- och nackdelar. För att uppnå en hög träffsäkerhet och samtidigt

ett icke omfattande förarbete så anses en kombination av metoderna att vara optimal. I resultatet

av detta arbete används en sådan kombination där CBR kombineras med Bayesiska nätverk.

Här anses den låga träffsäkerheten för CBR att kompletteras med den höga träffsäkerheten för

Bayesiska nätverk eftersom valet av systemreaktion inte bara grundar sig i tidigare fall utan

även med hjälp av logiska samband. Bayesiska nätverk anses, som tidigare nämnt, att kräva ett

tids- och arbetskrävande förarbete, men i detta fall så används data från ”case library” vilket

gör att inget förarbetet krävs för Bayesiska nätverk. Dock så krävs ett förarbete för att skapa ett

”case library”, men som tidigare nämnt så är detta mindre tids- och arbetskrävande eftersom

det kan göras i samband med Scanias befintliga felsökningsprocess.

F2: Hur kan kunddata och FMEA formaliseras för att vara användbara inom

felsökningsprocessen av tunga fordon?

I arbetet har utgångspunkten för att kunna avgöra om kunddata är användbart eller inte i

felsökningsprocessen inom tunga fordon varit erfarna felsökare, i detta fall mekanikerna. Från

de semistrukturerade intervjuerna noterades det att ”bra” data för mekanikerna innehåller

information om avvikelse, position och kontext, se avsnitt 4.4 rubrik Brister och

förbättringsmöjligheter. Från litteraturstudien noterades det istället att kunskaper inom följande

områden är bra vid felsökningssammanhang; Domänkunskap, Systemkunskap (topografi- och

funktionskunskap), Prestanda- och Procedurkunskap, Strategikunskap och Erfarenhetskunskap

(Hung & Jonassen, 2006). För mer information om respektive område, se 2.4.1 Jämförelse

mellan erfaren och oerfaren felsökare. Samtliga områden, både från intervjuerna och från

litteraturen, anses kunna ge insikter i hur kunddata ska formaliseras. Exempelvis skulle

Strategikunskap, som handlar om att veta vad som bör felsökas först (Hung & Jonassen, 2006),

kunna innebära att kunddata skulle formaliseras på så sätt att kunden kan beskriva själv vad

som bör felsökas först i deras fordon. Från analysen av litteraturen noterades det även att

funktioner ingår i befintliga felsökningssystems formalisering av kundsymptom, se 4.2 Analys

av felsökningssystem identifierade i litteratur. Detta påvisar ytterligare att Systemkunskap, där

funktioner ingår, borde ingå i formaliseringen av kunddata.

Det anses finnas både likheter och skillnader mellan data från intervjuerna och litteraturen

gällande formaliseringen av kunddata. Exempelvis anses topografikunskap, som tidigare

nämnts i 6.1 Analys av det slutgiltiga konceptet, kunna liknas med position. En av skillnaderna

är exempelvis att det krävs en hög teknisk kompetens av kunden för att kunna förmedla data

enligt områdena som beskrivs av Hung & Jonassen (2006), exempelvis Domänkunskap och

Strategikunskap, till skillnad från avvikelse, position och kontext. Även om en viss typ av data

är bra i felsökningssammanhang så måste kunderna kunna förmedla den. Detta innebär att

formaliseringen av kunddata inte bara är beroende på mekanikerna, utan också på kunderna.

Från de semistrukturerade intervjuerna noterades det att kunderna oftast inte besitter så goda

kunskaper om deras fordon. Dessutom noterades det att det inte går att förvänta sig att kunderna

besitter samma expertis som mekanikerna, se avsnitt 4.4 rubrik Brister och

förbättringsmöjligheter. Detta påvisas även av O`Neill, et al. (2005) och Bergmann, et al.

(2003). På grund av detta anses det inte vara lämpligt att formalisera kunddata med områdena

beskrivna av Hung & Jonassen (2006). Det slutgiltiga konceptet exkluderar därför dessa

områden och formaliseras istället genom avvikelse, position och kontext.

I arbetet var utgångspunkten för att avgöra vilket format på FMEA som är användbart inom

felsökning av tunga fordon till en början hur kundmottagarna ville ha den. Dock, från de

semistrukturerade intervjuerna, noterades det att kundmottagarna inte arbetade med FMEA:or

55 (68)

i den befintliga initiala felsökningsprocessen, se avsnitt 4.4 rubrik Process. Samtidigt noterades

det under konceptsållningen att koncept som grundades i att kundmottagarna manuellt skulle

studera FMEA:or ansågs vara svårare att förstå och använda än om felsökningsmetoder hade

involverats, se Bilaga J – Pughs matris. Detta påvisar att FMEA:or inte bör användas manuellt

av kundmottagarna. Istället bör utgångspunkten för formaliseringen av FMEA, för att vara

användbart inom felsökningsprocessen, vara på hur formaliseringen ska anpassas för att vara

användbar i felsökningsmetoderna.

De olika felsökningsmetoderna anses ställa olika krav på hur FMEA:n bör formaliseras. CBR,

som dokumenterar data i ett ”case library” (Warnquist, 2015), anses inte behöva FMEA:n alls

eftersom data istället bör hämtas från riktiga fall i den befintliga felsökningsprocessen.

Däremot, för metoderna Bayesiska nätverk och Felträdsanalys som både innehåller logiska

sammankopplingar och kräver, som tidigare nämnts, ett mer omfattande förarbete än CBR så

anses FMEA vara relevant. Exempelvis så anses FMEA kunna användas till Bayesiska nätverk

för att dokumentera noder och beroenden/relationer mellan dem vilket måste göras innan

metoden kan användas (Warnquist, 2015). Eftersom Bayesiska nätverk är uppbyggda av noder,

som i detta fall är kundsymptom och systemreaktioner, och kräver sannolikhetsdistributioner

enligt Huang et al. (2008) så anses följande data behöva finnas med vid formaliseringen av

FMEA:n; Customer Symptom som innehåller kundsymptom, Failure handling by system som

innehåller systemreaktioner, och RPN-värdet som kan användas som grund för respektive

sannolikhetsdistribution. I den FMEA som erhölls från Scania saknades en kolumn för

kundsymptom, se avsnitt 4.5.1 rubrik Analys av FMEA, och likaså för den teoretiska FMEA:n

som beskrivs av Ullman (2010). Däremot fanns rubrikerna Failure handling by system och RPN

i den erhållna FMEA:n, se Bilaga H – Analys av FMEA. RPN fanns även i den teoretiska

FMEA:n beskriven av Khan, et al. (2014) men inte Failure handling by system.

Felträdsanalys kräver istället följande formalisering av data för att fungera, vilket ställer krav

på formaliseringen av FMEA; System-del vilket presenterar det överliggande systemet i FTA:n

och är kopplad till ett eller fler Del-system, Del-system vilket presenterar det system vilket

komponenten tillhör och är en del av system-delen i FTA:n, Komponent vilket presenterar den

komponent som är kopplad till ett eller fler felmoder samt tillhör en system-del och del-system

i FTA:n, Felmod vilket presenterar felet på komponenten och har tillhörande systemreaktioner

och kundsymptom kopplade till sig i FTA:n, Systemreaktioner vilket presenterar vad den eller

de aktiva reaktionerna av systemet är av en specifik felmod i FTA:n, Kundsymptom vilket

presenterar kundens observerade avvikelser hos systemet och kundsymptomet är kopplat till de

felmoder vilket det sker för, och RPN-värde vilket bland annat visar komponentens sannolikhet

att gå sönder som också används i FTA:n. FTA:n hjälper endast kundmottagaren att hitta rätt

felmod. För att sedan hitta rätt systemreaktion måste kundmottagaren titta i FMEA:n för att

utläsa den kopplade systemreaktionen till den identifierade felmoden. En FMEA används alltså

främst för att identifiera de potentiella felen för att sedan kunna bygga upp en FTA. Utöver att

FMEA:n används som stöd för uppbyggnaden av FTA används även FMEA för att samla in

aktuella RPN-värden till felträdets sannolikhet, helst ska då RPN-värdet vara baserat på fältdata

för att vara aktuell för FTA:n (Teng & Ho, 1996).

Eftersom dokumentationen gällande systemreaktioner i FMEA:n är bristfällig, som tidigare

nämnts, anses det inte bara räcka att kolumner läggs till i den befintliga FMEA:n, utan befintliga

kolumner måste även ses över. Exempelvis anses kolumnen Symptom behöva ändra namn till

förslagsvis Problem för att undvika förvirring hos utvecklingsingenjörerna då kolumnen

Customer Symptom har lagts till. Dessutom måste data under Failure handling by system

56 (68)

(systemreaktioner) överses eftersom det anses finnas data kring kundsymptom under denna

rubrik.

I det slutgiltiga konceptet exkluderas användandet av FMEA i och med att metoden CBR

används för att samla in data. Därmed finns egentligen inga specifika krav på formaliseringen

av FMEA för att kunna använda det slutgiltiga konceptet. Dock så anses data från ”case

library” att kunna föras in i FMEA:orna om behovet finns från utvecklingsingenjörerna. Då

föreslås ändå att en ny kolumn med namnet Customer Symptom läggs till i FMEA:orna.

57 (68)

7 Diskussion Arbetes två huvudmål var att utveckla en metod för att sammankoppla kundsymptom med

systemreaktioner inom tunga fordon, samt utveckla format för kundsymptom och FMEA som

skulle ingå i metoden. Alla mål med tillhörande krav kunde uppfyllas med den resulterande

metoden i arbetet. Detta med en uppfyllnad på 100% för både huvudmål (1) och (2).

Potentiella värdeerbjudanden

Följande avsnitt presenterar potentiella värdeerbjudanden som kan erbjudas genom det

resulterande konceptet, jämfört med hur situationen ser ut i dagsläget för den initiala

felsökningsprocessen.

Några av bristerna som identifierades under intervjuerna kan potentiellt undvikas genom det

resulterande konceptet av studien. Det gör att potentiella värdeerbjudanden finns som resultat

av konceptet för både företaget Scania, Scanias kunder (ägarna och/eller användarna av

fordonen), samt den generella marknaden. Många av de nedanstående argumenten bygger på

tre antaganden: (1) Att Scania som företag ofta går in och ersätter kunden för stillastående av

fordon/produkt, då ofta vid akuta stillestånd. (2) Att kundens främsta inkomstkälla är deras

fordon/produkter, vilket gör tillgängligheten av fordonen/produkterna direkt den främsta

påverkande faktorn för deras ekonomiska tillstånd. (3) Antagandet görs även att besvärande

situationer för kunden även påverkar företaget negativt, eventuellt genom dåligt rykte och tillit.

I intervjuerna uppdagades det att kundmottagare eller mekaniker med dagens

felsökningssystem, ibland får ringa tillbaka till kund. Detta på grund av att kundmottagaren

missat att samla in nödvändig information eller att kundmottagaren inte haft tillräckligt med

kunskap för att ställa rätt motfrågor till kunden. Genom att konceptet använder sig av en

standardiserad metod som tillhandahåller stöd för kundmottagaren vid frågor mot kund för att

samla in kundsymptom från kunden kan detta undvikas. Att ringa tillbaka till kunden är inte ett

värdeadderande moment för företaget då det skulle kunna undvikas. Genom att minimera risken

för att behöva ringa tillbaka till kunden undviks att värdefull tid läggs på ett onödigt moment.

Att värdefull tid kan läggas på andra värdeadderande moment inom den initiala

felsökningsprocessen och/eller den faktiska (eftersom mekanikern kan bli involverad) är både

värdeadderande för företaget samt kunden. Detta då företaget kan spara pengar beroende på det

serviceavtal som finns mellan företag och kund samt att tillgängligheten av fordonet kan ökas

vilket gynnar kundens finansiella tillstånd då det ofta är kundens huvudsakliga inkomstkälla.

Ett onödigt moment som att ringa tillbaka till kunden kan även ske för andra verkstäder med

likande initiala felsökningsprocesser där det inte finns någon standardiserad metod för att utföra

den initial felsökningen. Det gör att metoden även kan erbjuda värde för utomstående

Scaniaverksamheter, så som andra verkstäder och eventuellt andra konkurrenter till det aktuella

företaget.

Under intervjuerna nämndes att misskommunikation mellan kund och kundmottagare eller

kundmottagarens bristande kunskap om fordonen kan leda till att icke korrekta bedömningar

görs av felen på fordonet. Att göra missbedömningar av fel på fordonet kan ha flera

konsekvenser. Konsekvenserna kan bli att:

- Kundmottagaren beställer fel material, vilket leder till att oanvändbara likvider ligger i

lager och bara blir en kostnad för verkstaden och/eller företaget. Att beställa fel material

kan även leda till längre tid på verkstad för fordonet vilket leder till minskad

58 (68)

tillgänglighet av fordonet för kund, vilket kan få negativa konsekvenser ekonomiskt för

både företag och kund.

- Kundmottagare måste boka om planerat servicearbete för att den planerade tiden inte

räcker till för det faktiska felet, vilket gör att kundens tillgänglighet till fordonet minskar

och kan komma att påverka både företag och kund negativt ekonomiskt sätt. Att behöva

boka om tider på verkstad kan få vidare konsekvenser, exempelvis gynnar det inte ett

effektivt och produktivt serviceschema på verkstaden och kan få konsekvenserna att

värdefull tid inte kan läggas på värdeadderande moment som mekanikern utför på

fordonen. Detta för att förändring i schemat inte kan ta hänsyn till nästa prioriterade

servicearbete på ett effektivt sätt, och värdefull tid kan gå förlorad. En felbedömning av

fel kan även leda till att andra kunder blir påverkade då tider är uppbokade i onödan.

Resultatet blir ett oproduktivt arbetssätt och medför negativa ekonomiska konsekvenser

för både företag och kund samt försämrad tillit ifrån kund.

- Mekaniker utför onödiga servicearbeten och byter delar som inte hade behövt bytas.

Detta får konsekvenserna att kunden betalar för onödigt material, att kundens tillit till

företaget minskar och det kan leda till att företaget måste ersätta kunden för

stillaståendet som även tar längre tid vid onödigt utförda servicearbeten av fordonet.

Genom att metoden i det resulterande konceptet för studien är standardiserad, så är inte

misskommunikation mellan kund och kundmottagare eller kundmottagarens eventuellt

bristande kunskap om fordonet, en lika stor risk för missbedömning av fel längre. Detta grundar

sig i att metoden möjliggör att kunden inte behöver ha någon teknisk kompetens kring fordonet

då formatet för kundsymptomen inte kräver någon förkunskap om tekniska termer kring

fordonet. Genom att kundmottagaren endast behöver välja från de förbestämda alternativen i

en ”dropdown-meny”, undviks även större tolkningar från kundmottagaren. Kundmottagaren

behöver heller inte lägga alla eventuella kundsymptom på minnet vilket gör att kundmottagaren

inte behöver förlita sig lika mycket på erfarenhet som innan. Den identifierade bristen undviks

även om flera systemreaktioner matchas och hämtas från ”case library”. Detta genom att

sannolikhetsberäkningar utförs av Bayesiska nätverk i samband med att kundmottagaren ställer

motfrågor om kunden upplever andra kopplade kundsymptom. Beroende på vad kunden svarar

på de andra kundsymptomen (ja eller nej) ändras då sannolikheten med hjälp av det Bayesiska

nätverket, och metoden kan utesluta vilken som faktiskt är den aktiva systemreaktionen.

Sammanfattningsvis undviker både företaget och kund allvarliga konsekvenser genom metoden

vilket inger ett värde för både företag och kund. Dessa konsekvenser kan även appliceras på

branschen generellt för företag med liknande initiala felsökningsprocesser, vilket även ger

värde för andra företag att använda den resulterande metoden.

Metoden presenterar en dellösning för att komma fram till åtgärder för fel av tunga fordon. Det

gör att metoden är en kompletterande och integrerande lösning till det idag redan existerande

felsökningssystemet som utgår från felkoder. Metoden erbjuder ett sätt att både felsöka efter

mekaniskt grundande fel lika väl som elektroniskt upptäckbara fel, vilket gör att den både

utöver dagens felsökningssystem även stödjer det existerande. Detta då den erbjuder ett

komplement mot felsökning med felkoder (elektroniskt upptäckbara fel). Detta skapar flera

värden, att fler fordon kan lyckas felsökas innan de kommer in till verkstad vilket både sparar

tid och pengar för företaget samt ökar tillgänglighet för kund. Det stödjer även mer säkra och

grundade diagnoser samt att fler typer av eventuella fel kan identifieras på fordonen, vilket både

kan spara tid och pengar för företag samt ökar tillgängligheten för kund. Att använda felkoder

59 (68)

är en allmän metod inom fordonsindustrin för att felsöka fordon. Däremot erbjuder metoden ett

kompletterande sätt att felsöka, vilket lika väl kan appliceras hos andra verksamheter och

därmed erbjuder värde för utomstående Scania-verksamheter.

Resultatet för studien visar att FMEA i samband med CBR är överflödigt, vilket sker på grund

av att CBR-systemet kan ersätta FMEA. Det skall nämnas att FMEA fortfarande har många

positiva egenskaper när det kommer till kvalitetskontroll inom företag, men att FMEA anses

överflödig i syfte för den initiala felsökningen i samband med användning av CBR. I uppstarten

av studien ansågs FMEA vara den trovärdigaste och starkaste källan som utgångspunkt för

symptombaserad felsökning. Studien visade dock att så inte var situationen med det

tillhandahållna underlaget för fallstudien. Där fanns bristfällig data i FMEA:n. Här kan två olika

värden poängteras. Scania tillhandahåller en insikt genom studiens resultat att FMEA har brister

som bör undersökas vidare och denna insikt inger ett värde. Samtidigt giver studiens resultat en

insikt i att FMEA är överflödig då ett CBR-system används i ett symptombaserat

felsökningssystem, vilket både ger ett värde av insikt för den generella marknaden av diagnos

av tunga fordon och Scania.

I den befintliga felsökningsprocessen inom Scania används i dag flera program som möjliggör

en initial felsökningsprocess. Resultatet för studien erbjuder enbart en lösning för den initiala

felsökningsprocessen. Detta kan ge följden att det blir lättare för kundmottagaren att enbart

förhålla sig till ett tillvägagångssätt för den initiala felsökningen då flera program kan innebära

flera tillvägagångssätt vilket kan göra det rörigt och svårare för kundmottagaren att genomföra

en initial felsökning. Detta ger värdet för Scania att det blir lättare att träna upp nya

kundmottagare för den initiala felsökningsprocessen, samt kan det leda till att fler korrekta

bedömningar görs om en tydligare väg för hur en bedömning skall utföras finns. En annan faktor

som även bidrar till detta är att den resulterande metoden inte kräver några större förkunskaper

för att kunna användas, och mindre bedömningar baserat på erfarenhet behöver göras av

kundmottagaren.

Kvalitet på arbetet

I arbetet har resultatet inte validerats och därmed har inga mätbara värden kopplade till

resultatet kunnat identifieras. Exempel på sådana värden hade kunnat vara tiden för att utföra

metoden. Detta gör det svårt att bedöma hur bra resultatet blev. Dock så har resultatet tagit

hänsyn till både empirisk och litterärt insamlad data. Det som finns att grunda redogörelsen på

hur bra resultatet blev är istället på uppfyllelsen av målen och de identifierade värdena som kan

erbjudas genom metoden. I och med att 100% av målen uppfylldes och ett flertal brister kunde

undvikas med metoden, se avsnitt 7 rubrik Potentiella värdeerbjudanden, så är det i alla fall

möjligt att konstatera att den framtagna metoden är bättre än den befintliga initiala

felsökningsprocessen.

På grund av de rådande omständigheterna i världen med Covid-19 pandemin och Scanias

verksamhetsomställningar har det varit utmanande att utföra detta arbete. Det som främst har

påverkats är tidsplaneringen i Gantt-schemat som bestämdes i samband med arbetets uppstart.

Många moment i tidsplaneringen har varit tvungna att förskjutas framåt och kortats ner på grund

av exempelvis besöksförbud på verkstäder och permittering av personal. Konsekvensen av detta

är att kvaliteten hos vissa moment i arbetet har försämrats. Det kommer därför i detta avsnitt

bland annat presenteras moment som hade kunnat utföras annorlunda och på vilket sätt.

Dessutom kommer validitet och reliabilitet samt felkällor att diskuteras.

60 (68)

Felsökningsmetoder

I litteraturstudien identifierades felsökningsmetoderna Bayesiska nätverk¸ CBR och

Felträdsanalys. Dessa metoder valdes att användas till konceptgenereringen. Dock noterades

det under arbetets gång att det finns flera felsökningsmetoder som skulle kunna tillämpas till

detta arbetes ändamål. Scania bör därför ta hänsyn till denna vetskap vid vidareutvecklingen av

det symptombaserade felsökningssystemet.

FMEA

I arbetet gjordes en begränsning att enbart utgå från expertdataformen FMEA. Dock hade det

eventuellt varit bra att studera annan befintliga data på Scania. En initial utredning borde alltså

först ha utförts för att säkerställa att FMEA var den bästa möjliga utgångspunkten för att

identifiera en sammankoppling mellan kundsymptom och systemreaktioner. Detta genom att

identifiera olika typer av expertdata och ställa denna data mot varandra. Det hade även varit bra

då att involvera medarbetare från flera olika avdelningar på Scania för att validera denna data.

Innan starten av detta arbete hade det varit fördelaktigt att först kartlägga kundsymptomen till

respektive fel i FMEA:n som erhölls inom gasmotorer och gastankar för att lättare kunna utreda

sammankopplingen mellan kundsymptom och systemreaktioner i detta arbete. Eftersom alla

system i Scanias produkter inte fungerar och beter sig på samma sätt så borde även andra system

och tillhörande FMEA:s undersökts. Användandet av FMEA:s exkluderades i det slutgiltiga

konceptet på grund av bristfällig och avsaknad av data men om andra FMEA:s hade undersökts

så hade möjligtvis andra analyser och slutsatser dragits.

Om Scania vid skapandet av FMEA:n inom gasmotorer och gastankar inte varit konsekvent

med datahanteringen. Kan det därmed finns data under kolumner som inte bör vara där på grund

av den mänskliga faktorn. Detta skapar en potentiell felkälla att bedömningar har gjorts i

analysen av FMEA:n utifrån icke korrekt data. Detta påverkar validiteten då bedömningar har

gjorts utifrån felaktigt grundad data, vilket kan ha givit andra slutsatser av FMEA:n än om en

annan FMEA med korrekt ifylld data analyserats. Om andra slutsatser hade dragits i analysen

av FMEA:n, hade det även resulterat i ett annat resultat och slutsats.

I FMEA:n som analyserats i arbetets empiriska fas finns också en adderad kolumn ”symptom”

som inte benämns i Scanias egna manual för hur en FMEA skall utföras (Scania AB, 2014).

Detta kan peka på att den analyserade FMEA:n endast är en variant av flera, vilket kan tyda på

att FMEA:n inte är konsekvent och har utförts på ett annat sätt än andra FMEA:or inom Scania.

Det kan även visa på att den analyserade FMEA:n inte erhåller en acceptabel nivå av reliabilitet,

om den skiljer sig från den standardiserade metoden för hur en FMEA skall utföras inom Scania.

Om den analyserade FMEA:n skiljer sig från andra FMEA inom Scania kan andra slutsatser

dras för andra FMEA. Detta påverkar arbetets reliabilitet då det blir svårt att rekonstruera

arbetet om inte exakt den potentiellt felaktiga FMEA:n ges som grund för rekonstruktionen.

Semistrukturerade intervjuer

En aspekt som påverkar studiens resultat var att kunderna exkluderas vid de semistrukturerade

intervjuerna. Värdefull information har erhållits från kundmottagarna, men det hade varit bra

att även intervjua kunderna. På så sätt hade likheter och olikheter kunnat identifierats mellan

kundmottagarens beskrivelse av kunddata, och det kunden egentligen sade. Detta hade kunnat

påverka konceptgenereringen av koncept gällande formatet på kundsymptom. Dessutom, efter

att de semistrukturerade intervjuerna hade utförts konstaterades det att det mest ideala hade

varit att intervjua kundmottagare och mekaniker inom vanliga verkstäder och inte

kundmottagare och mekaniker inom R&D. Denna möjligheten fanns tyvärr inte i samband med

61 (68)

att intervjuerna skulle utföras på grund av besöksförbud. Orsaken till att vanliga mekaniker och

kundmottagare anses vara mer lämpade att intervjua, var för att dessa målgrupper arbetar

närmare mot Scanias kunder.

Endast tre intervjuer inom varje målgrupp utfördes vilket innebär att totalt 6 intervjuer utfördes

i arbetet. Detta är en stor skillnad från de 12 rekommenderade inom varje målgrupp enligt

Saunders et al. (2009). Det uppkom flera anledningar som gjorde det svårt att utföra det

rekommenderade antalet intervjuer. En av anledningarna var att tiden för arbetets ramar inte

räckte till för att utföra 12 intervjuer per målgrupp, då intervjuerna kom att bli långa, mellan

25-60 min och därmed tog lång tid att analysera. Att intervjuerna blev långa var dock ett aktivt

val, för att få in ”kvalitativt material med en djup insikt och väl genomförda analyser av det

insamlade materialet”, se avsnitt 3.3.3 rubrik Semistrukturerade intervjuer. Med stundande

omständigheter var det även svårt att få tag i frivilliga respondenter på grund av besöksförbud,

vilket försvårade möjligheten till att utföra 12 intervjuer. Om fler intervjuer hade kunnat utföras

hade resultatet eventuellt kunnat vara mer stöttande från de empiriska delarna av arbetet. Fler

intervjuer hade även kunnat resulterat i andra slutsatser och resultat som även kunde vart mer

grundande från flera respondenter.

Att endast tre respondenter intervjuades inom varje målgrupp gentemot det rekommenderade

antalet 12 av Saunders et al. (2009) kan även anses som en felkälla. Detta för att ett lågt antal

intervjuer kan komma att påverka både validiteten och reliabiliteten. Validiteten blir påverkad

av ett få antal intervjuer då ett få antal respondenter inte kan bedömas representera hela

målgruppen. Validitet påverkas även av det faktum, att om mer information från fler intervjuer

hade samlats in hade eventuellt andra slutsatser kunnat dras från det analyserade materialet.

Reliabiliteten blir påverkad negativt då det är svårt att reproducera arbetet om generella

antaganden gjorts utifrån en icke-representativ målgrupp. På grund av detta bör resultatet och

slutsatserna i arbetet beaktas med åtanke på reliabiliteten och validiteten. Samtidigt är det även

viktigt att poängtera att antalet intervjuer per målgrupp är något forskare har olika åsikter om,

då Saunders et al. (2009) menar att för få fall i fallstudien kan innebära en svag generaliserbarhet

i kvalitativa studier, medan Marschall & Rossman (1999) menar att en fallstudie kan visa sig

starkare än andra kvantitativa forskningsstudier.

Workshop

På grund av den rådande situationen var det enbart möjligt att en medarbetare från Scania kunde

delta i workshopen vid konceptsållningen. Detta påverkar resultatet då poängsättningen

respektive koncept fick hade kunnat bli annorlunda om andra medarbetare med spetskompetens

inom förslagsvis system/IT hade deltagit. Dessutom var det inte heller möjligt att validera

resultatet som erhölls i arbetet. Detta hade kunnat göras genom att inte bara använda

workshopen vid konceptsållningen utan även vid en validering. Detta hade kunna generera

insikter angående resultatets genomförbarhet samtidigt som det hade varit en chans för Scania

att påverka resultatet ytterligare. En förutsättning för workshopen hade varit att medarbetare

med flera olika typer av spetskompetenser inkluderats. Exempel på rekommenderade

spetskompetenser hade varit inom felsökning och system/IT. Förutom workshopen hade

resultatet även kunna valideras praktiskt genom att utveckla en POC, ”Proof of Concept”,

vilket kan betraktas som en funktionsprototyp och använda den på verkstäderna.

Inför konceptvalet skapades urvalskriterier. Urvalskriterierna översattes från de behov som togs

fram i samarbete med Scania. Översättningen av behoven till urvalskriterier gjordes genom en

subjektiv bedömning. Detta betyder att inga tekniska eller utanför gruppen, stöttande grunder

för varför urvalskriterierna blev vad dem blev användes eller fanns inte. Detta kan ha påverkat

62 (68)

studien negativt då felaktiga bedömningar kan ha gjorts som påverkar resultatets validitet. Att

göra subjektiva bedömningar påverkar även arbetets reliabilitet, då det kan vara svårt att göra

om arbetet vid ett senare stadie om icke metodbaserade val har gjorts.

I konceptvalet gjordes bedömningen av koncepten genom en workshop där en medarbetare från

Scania som besatt spetskompetens inom felsökning deltog. Detta gjorde att uppfyllelsen av

vissa krav, som även var samma som vissa av urvalskriterierna, redan innan bedömningen och

uppfyllnad av resultatet var bedömt genom spetskompetens tillhandahållen av Scania, vilket

anses öka trovärdigheten för resultatet.

Slutsatser

Utifrån det resultat som erhölls noterades det att sammankopplingen mellan kundsymptom och

systemreaktion egentligen är överflödig. Resultatet skulle lika gärna kunna anpassas för att

sammankoppla kundsymptom med åtgärder direkt för att tillgodose Scanias huvudsakliga mål

med symptombaserad felsökning. Detta är för att sammankopplingen enbart sker i ”cases”

enligt felsökningsmetoden CBR.

Nuvarande dokumentation angående kundsymptom och systemreaktioner är bristfällig. Med

resultatet så krävs dock ingen tidigare dokumentation så detta visades inte vara ett problem.

Detta för att insamlandet av data kring kundsymptom och systemreaktioner kommer att utföras

i samband med Scanias befintliga felsökning enligt felökningsmetoden CBR. Det som också

noterades utifrån resultatet var att FMEA:orna inte var kritiska för att sammankoppla

kundsymptom med systemreaktioner. Scania ansåg initialt att FMEA var den mest lämpade

formen av expertdata för detta ändamål men arbetet bevisade motsatsen. Detta beror på att

metoden helt och hållet baseras på data genererad av metoden och inte på expertdata som Scania

tidigare har genererat för andra ändamål. För att kunddata ska vara användbart inom

felsökningsprocessen bör den formaliseras efter; avvikelse, position och kontext.

Med datadrivna metoder så blir kundmottagarrollen mindre kritisk än vid en erfarenhetsbaserad

metod i felsökningsprocessen. Dock krävs ett relativt omfattande förarbete om datadrivna

metoder ska implementeras. Det slutgiltiga resultatet som främst baseras på CBR har dock minst

omfattande förarbete av de tre datadrivna metoderna undersökta i detta arbete.

Felsökningsprocessen påverkas även av den varierande träffsäkerheten mellan de olika

metoderna. Resultatets träffsäkerhet kommer att öka med tiden då mer och mer data

dokumenterats.

Framtida studier

I resultatet presenterades formatet på kundsymptom enligt avvikelse, position och kontext.

Dock presenterades inga instruktioner i hur utvecklingsingenjörerna på R&D ska formalisera

kundsymptomen under respektive kategori baserat på fritexten från kundmottagarna.

Exempelvis vad som ska stå under kategorin position om kundens beskrivning är ”Det ryker i

fordonets bakre del”. Ska denna information då formaliseras till ”bak”? Hur detaljrik behöver

formaliseringen vara för att kundmottagaren ska anse att det beskriver en kunds symptom

tillräckligt bra och därmed välja det i dropdown-menyn? Det behöver även utredas från Scanias

sida vilken formalisering som lämpar sig mest för felsökningsmetoderna CBR och Bayesiska

nätverk.

En annan frågeställning som uppstod i samband med konceptgenereringen var hur det

geografiska läget har för inverkan på den initiala felsökningsprocessen. Vissa kundsymptom är

möjligtvis beroende på driftförhållanden som exempelvis lufttemperatur, luftfuktighet,

63 (68)

lufttryck, samt väder- och vägförhållanden. Därför bör en internationell utredning göras för att

avgöra om arbetets resultat blir konsekvent eller inte beroende på det geografiska läget. Alltså

om exempelvis en kund i Sverige beskriver ett kundsymptom till en systemreaktion annorlunda

än en kund i Brasilien? Förutom att utreda detta bör det även utredas hur kundens varierande

sätt att beskriva symptom, oberoende av det geografiska läget, påverkar resultatet. Exempelvis

kan en kund beskriva ett symptom som ”det ryker” medans en annan kund med samma problem

med fordonet skulle beskriva symptomet ”det luktar rök”.

I framtiden bör även Scania utreda vad som händer om kunden förmedlar felaktig information

till kundmottagaren. Exempelvis om kunden förmedlar ”det låter konstigt i fordonets främre

del” men att det egentligen ”låter konstigt i fordonets bakre del”. Hur ska detta hanteras för att

undvika att denna felaktiga data dokumenteras i ett nytt ”case”?

I resultatet används bland annat felsökningsmetoden CBR vilket är en metod som blir bättre ju

längre den används (Warnquist, 2015). Det väcker frågan hur länge den inledande fasen måste

köras för att metoden ska vara tillräckligt tillförlitlig med att matcha kundsymptom med

systemreaktioner. En annan fråga som uppstod under arbetet var hur följdfrågorna som

kundmottagaren ska ställa till kunden, när en matchning mellan kundsymptom och

systemreaktioner är för låg, prioriteras och väljs. Är det möjligt att använda Bayesiska nätverket

för detta? En ytterligare frågeställning kopplat till detta är hur många frågor kunder är villiga

att besvara innan kunden blir besvärad. I den sistnämnda frågeställningen rekommenderas det

att kunderna involveras om resultatet ska realiseras av Scania.

I det Bayesiska nätverket ansågs beroendena mellan kundsymptomen och systemreaktionerna

vara att systemreaktionerna leder till kundsymptomen. Vad skulle det dock innebära för

metoden om vissa systemreaktioner även leder till andra systemreaktioner, och liknande för

kundsymptomen? Detta anses öka komplexiteten av den grafiska modellen, men den exakta

innebörden av detta bör utredas av Scania.

Arbetets avgränsning var bland annat att inte utreda djupgående hur felsökningsmetoderna

skulle användas i den framtagna metoden. På grund av detta uppstod frågeställningen hur

metodens olika funktionaliteter ska realiseras och vad dessa funktionaliteter ställer för krav på

ett system. Två exempel på detta är hur det ska fungera att hämta ut data från ”case library”

och identifiera hur många gånger vissa kopplingar mellan ett kundsymptom och systemreaktion

har gjorts. Kopplat till det sistnämnda uppstod även frågeställningen om

sannolikhetsdistributionen enbart kan baseras på antalet gånger ett ”case” har dokumenterats i

”case library” som det nu görs i den framtagna metoden. Scania bör i framtiden utreda om

denna statistik är tillräcklig och tillförlitlig för felsökningsmetoderna CBR och Bayesiska

nätverk.

Hur skulle resultatet påverkas om kunden rapporterar in mer än ett kundsymptom till

kundmottagaren? Skulle det exempelvis bli ett ”case” enligt följande; Kundsymptom A och B

– Systemreaktion 1? Vad har detta för konsekvens för utformandet av metoden med avseende

på felsökningsmetoderna CBR och Bayesiska nätverk? En ytterligare frågeställning som

uppstod i arbetet var vad effekten av att använda ett detaljrikt kundsymptom eller ett detaljfattigt

kundsymptom i de två olika felsökningsmetoderna. Blir det lättare att få matchningar om data

är detaljrikt, och i sådana fall hur påfrestande blir det för det symptombaserade

felsökningssystemet sedan när det realiseras?

64 (68)

I arbetet har det undersökts vad ”bra” data är för mekaniker vid felsökningssammanhang för att

få insikt i hur kundsymptomen bör formaliseras. Dock exkluderades mänskliga felsökare i

resultatet som istället förlitar sig på datordrivna metoder. På grund av detta uppstod

frågeställningen vad är bra data för de två felsökningsmetoderna som användes? Det kan ju vara

så att bra data för felsökare inte är bra data för datadrivna metoder. Därför bör formatet på

kundsymptomen överses av Scania. Oavsett om resultatets formalisering av kundsymptom är

bra för datadriva metoderna eller inte anses formatet som presenteras ändå kunna ge Scania

insikter. Insikten om att avvikelse, position och kontext är värdefull för mekanikerna skulle i

alla fall kunna användas som underlag för kundmottagarnas arbete även om den inte används i

de datordrivna metoderna. Det uppstår även en följande utmaning i fallet om inte bra data för

mekaniker kan linjera med bra data för datadrivna metoder. Utmaningen grundar sig i att data

som samlas in i det presenterade formatet utgår från där problemet detekteras alltså i verkstaden,

att komma fram till en annat format som inte utgår ifrån vart problemet detekteras kan då

försvåra insamlingen av data. Detta är även en fråga Scania bör se över vid bestämmelse av

formatet för kundsymptomen.

I analysen, se 6.2 Besvarande av fallstudiens frågeställning konstaterades att FMEA:an har

bristfällig information och/eller att det inte finns systemreaktioner för alla felmoder. Scania har

en tydligt dokumenterad beskrivning för hur en FMEA ska genomföras på ett korrekt sätt. Detta

betyder att om problemet ligger i att informationen i FMEA är bristfällig på grund av ett icke

noggrant genomförande av FMEA:n samt otydliga rubriker och innehåll, bör där involveras fler

led-kontroller för FMEA:n samt en översikt av rubrikernas innehåll och betydelse. Detta om

FMEA fortfarande skall användas och vara användbar för kvalitetsarbete inom Scania.

65 (68)

Litteraturförteckning Aha, D. W., McSherry, D. & Yang, Q., 2006. Advances in conversational case-based. The

Knowledge Engineering Review, 20(3), pp. 247-254.

Bandini, S. o.a., 2008. Case-Based Troubleshooting in the Automotive Context: The SMMART

Project. Trier, Tyskland, ECCBR: European Conference on Case-Based Reasoning.

Bell, J., 2006. Introduktion till forskningsmetodik. 4:e red. Lund: Studentlitteratur AB.

Bergmann, R. o.a., 2003. Developing Industrial Case-Based Reasoning Applications. volume

1612 red. Berlin: Springer, Berlin, Heidelberg.

Bobbio, A., Portinale, L., Minichino, M. & Ciancamerla, E., 2001. Improving the analysis of

dependable systems by mapping fault trees into Bayesian networks. Reliability Engineering

and System Safety, 71(3), pp. 249-260.

Bracke, S. & Haller, S., 2012. OMSP: Failure detection based on small field part and data

volumes. USA. Reno, IEEE Xplore.

Bryman, A., 2016. Social reserch methods. 5 red. United Kingdom, Oxford: Oxford

university press.

Cegarra, J. & Hoc, J.-m., 2006. Cognitive styles as an explanation of experts’ individual

differences: A case study in computer-assisted troubleshooting diagnosis. International

Journal of Human-Computer Studies, 64(2), pp. 123-136.

Davis, N. M. & Erway, E. J., 2015. Dynamic online presentation of solutions based on

customer symptoms. Round Rock, Texas, (US), Patentnr US 9,075,802 B2.

Easterby- Smith, M., Thorpe, R. & Jackson, P., 2008. Management Reasearch. 3:e red.

London: Sage.

Ghauri, P. & Gronhaug, K., 2005. Research Methods in Bussines Studies: A Practical Guide.

3:e red. Harlow: Financial times prentice hall.

Huang, Y., McMurran, R., Dhadyalla, G. & Jones, P. R., 2008. Probability based vehicle fault

diagnosis: Bayesian network method. Journal of Intelligent Manufacturing, 19(3), pp. 301-

311.

Hung, W. & Jonassen, D. H., 2006. Learning to Troubleshoot: A New Theory-Based Design

Architecture. Educational Psychology Review, 18(1), pp. 77-114.

James, T. A., Gandhi, P. O. & Deshmukh, G. S., 2018. Fault diagnosis of automobile systems

using fault tree based on digraph modeling. International Journal of System Assurance

Engineering and Management, 9(3), pp. 494-508.

Kabir, S., 2017. An overview of fault tree analysis and its application in model based

dependability analysis. Expert Systems with Applications, 77(1), pp. 114-135.

66 (68)

Khan, S., Phillips, P., Hockley, C. & Jennions, I., 2014. No Fault Found events in

maintenance engineering Part 2: Root causes, technical developments and future research.

Reliability Engineering & System Safety, 123(1), pp. 196-208.

Kristensson, P., Gustafsson, A. & Witell, L., 2014. Tjänsteinnovation. 3:e red. Lund:

Studentlitteratur AB.

Kurz, D., Kaspar, J. & Pilz, J., 2011. Dynamic Maintenance in semiconductor manufacturing

using Bayesian networks. Trieste, 2011 IEEE International Conference on Automation

Science and Engineering.

Marschall, C. & Rossman, G., 1999. Designing Qualitative Research. 3 red. Thousand Oaks:

CA: Sage.

Nationalencyklopedin, 2020. Nationalencyklopedin. [Online]

Available at: http://www.ne.se.ep.bib.mdh.se/uppslagsverk/ordbok/svensk/symtom

[Använd 01 05 2020].

O`Neill, J., Grasso, A., Castellani, S. & Tolmie, P., 2005. Using Real-Life Troubleshooting

Interactions to Inform Self-assistance Design. Springer, Berlin, Heidelberg, Human-Computer

Interaction - INTERACT 2005.

Orngreen, R. & Levinsen, K., 2017. Workshops as a Research Methodology. The Electronic

Journal of e-Learning, 15(1), pp. 70-81.

Ruijters, E. & Stoelinga, M., 2015. Fault tree analysis: A survey of the state-of-the-art in

modeling, analysis and tools. Computer Science Review, 15-16(1), pp. 29-62.

Sage Publications, 2020. Methods Map. [Online]

Available at: https://methods.sagepub.com/methods-map/research-methods

[Använd 12 03 2020].

Saunders, M., Lewis, P. & Thornhill, A., 2009. Research methods for business students. 5 red.

England, Essex, Harlrow: Pearson Education Limited.

Scania AB, 2014. Service-FMEA Underhållsanalys via FMEA, u.o.: u.n.

Scania CV AB, 2017. Scania Diagnos & Programmer 3: Användarinstruktioner, Södertälje:

Scania.

Scania CV AB, 2018. Scania. [Online]

Available at: https://www.scania.com/se/sv/home/products-and-services/repair-and-

maintenance.html

[Använd 7 Februari 2020].

Southey, E. C. o.a., 2014. MACHINE ASSISTED TROUBLESHOOTING. Dallas, TX (US) ,

Patentnr 0279718A1 .

67 (68)

Teng, G. S.-H. & Ho, M. S.-Y., 1996. Failure mode and effects analysis: An integrated

approach for product design and process control. International Journal of Quality &

Reliability Management, 13(5), pp. 8-26.

Ullman, D. G., 2010. The Mechanical Design Process. 4 red. New York: MC Graw Hill.

Ulrich, K. T. & Eppinger, S. D., 2012. Produktutveckling: Konstruktion och design. 5:e red.

Lund: Studentlitteratur AB.

Warnquist, H., 2015. Troubleshooting Trucks: Automated Planning and Diagnosis (PhD

dissertation), Linköping: Linköping University Electronic Press.

Wedeniwski, S., 2015. The Mobility Revolution in the Automotive Industry. 1:a red. Berlin

Heidelberg: Springer-Verlag .

Williamson, K. & Bow, A., 2002. Research methods for students, academics and

professionals : information management and systems. 2:a red. New South Wales: Wagga

Wagga, New South Wales: Centre for Information Studies.

Volvo Cars, 2015. VIDA KLASSRUMSUTBILDNING STUDENTHANDBOK, u.o.: u.n.

Yu, X.-p., BeiHang, L. Q. & Hu, X., 2015. Aircraft fault diagnosis system research based on

the combination of CBR and FTA. Beijing, 2015 First International Conference on Reliability

Systems Engineering (ICRSE).

68 (68)

Bilagor Bilaga A – Motivering av kritiska krav ....................................................................................... i

Bilaga B – Symbolbeskrivning av felträdsanalys ...................................................................... ii Bilaga C – Information om litteraturstudie ............................................................................... iii Bilaga D – Intervjuguide ........................................................................................................... iv Bilaga E - Informationsblad och samtycke ................................................................................ x Bilaga F – QFD ......................................................................................................................... xi

Bilaga G – Färgkodade anteckningar av respondenternas svar ................................................ xii Bilaga H – Analys av FMEA ................................................................................................. xlvi Bilaga I – Koncept ....................................................................................................................... l Bilaga J – Pughs matris ........................................................................................................... lxii Bilaga K – Motivering till uppfyllnad av kritiska och önskade krav ..................................... lxiii

i

Bilaga A – Motivering av kritiska krav

Kravlista Motivering till kritiskt krav

Kritiskt krav:

Identifiera kategorier av data som är

nödvändiga för att formalisera

kundsymptom och som möjliggör att en

sammankoppling mellan kundsymptom

och systemreaktioner kan uppnås.

Påverkar mål: (1), (2)

Motivering kritiskt krav:

Kravet anses vara kritiskt då en formalisering

av kundsymptom direkt påverkar och är en

förutsättning för att uppfylla mål (2).

Kritiskt krav:

Identifiera kategorier av data som är

nödvändiga för att formalisera FMEA

som möjliggör att en sammankoppling

mellan kundsymptom och

systemreaktioner kan uppnås.

Påverkar mål: (2)

Motivering kritiskt krav:

Kravet anses vara kritiskt då formalisering för

FMEA, direkt påverkar och är en förutsättning

för att uppfylla mål (2).

Kritiskt krav:

Identifiera vetenskapligt grundade

felsökningsmetoder som kan tillämpas

för att sammankoppla kundsymptom med

systemreaktioner.

Påverkar mål: (1)

Motivering kritiskt krav:

Kravet anses vara kritiskt då arbetet inte är

vetenskapligt grundat om inte dess ingående

delar, så som felsökningsmetoder inte är det.

Det är även kritiskt för att en felsökningsmetod

anses vara en förutsättning för mål (1).

Kritiskt krav:

Metoden skall kunna hantera

kundsymptom som både grundas i

elektroniska fel och mekaniska fel.

Påverkar mål: (1)

Motivering kritiskt krav:

Kravet anses vara kritiskt då motiveringen av

studien bygger på en problembild av att vissa

mekaniska fel i dagens läge inte är lika lätta att

hitta som DTC baserade elektroniska fel.

Kritiskt krav:

Metoden skall ta hänsyn till den

detaljrikedom av information som en

kund är kapabel till att ge

kundmottagaren med sin tekniska

kompetens.

Påverkar mål: (1), (2)

Motivering kritiskt krav:

Kravet anses vara kritiskt då det är en

förutsättning att veta vilken detaljrikedom

informationen från en kund kan förväntas vara

för att skapa ett linjerande format vilket kunden

kan bidra till. Det påverkar förutsättningen att

kunna besvara både mål (1) och (2).

ii

Bilaga B – Symbolbeskrivning av felträdsanalys Sohag Kabir (2017) beskriver mer ingående hur ett SFT är uppbyggt. Figuren presenterar

symbolerna som representerar händelser och grindar i ett SFT. Ett SFT byggs upp i regel med

tre olika noder, noderna består av händelser, grindar (OR, AND, XOR) och transportsymboler.

Grundläggandehändelser har formen av cirklar i trädet och har inga vidare möjliga

utvecklingar av sig själva. Grundläggande händelser är de yttersta noderna i ett SFT , flera

grundläggande händelser kombineras för att skapa så kalla mellanliggande händelser.

Grundläggandehändelser ges ofta mätbara data för att kunna utföra kvantitativa analyser.

Vidare är kombinationerna av grundläggandehändelser del-set för utförande av

kvalitativanalys.

Mellanliggandehändelser är fel som uppstår i kombinationen av andra

underliggandehändelser i felträdet. Mellanliggandehändelser är vanligtvis bildade från andra

händelser, på grund av detta fungerar dem ofta som logiska grindar. En mellanliggandehändelse

symboliserad genom en kvadrat.

Outvecklade händelser är händelser som inte bidrar till finnandet av grundorsaken.

Outvecklade händelser symboliseras vanligtvis som en diamantform i ett SFT.

Tillståndsbaseradehändelser är händelser som tillhandahåller speciella avgränsningar för

specifika grindar. Tillståndsbaseradehändelser symboliseras vanligtvis med elipser.

Normalhändelser representerar det nominella beteendet av systemet och är därför inte ett fel.

En normalhändelse symboliseras vanligtvis med symbolen av ett hus (Kabir, 2017).

OR Grind. En OR grind visar en output om någon av OR grindens inputhändelser infinner sig

(Ruijters & Stoelinga, 2015).

AND Grind. AND grindens output infinner sig om alla händelser för AND gatens input

infinner sig (Ruijters & Stoelinga, 2015).

XOR Grind. En XOR grind är sann om och endast om ett av inputen är sanna, gaten är ett

specialfall av OR gaten.

INHIBERANDE Grind. En INHIBERANDE (hindrande) grind är sann om och endast om

inputhändelsen är sann tillsammans med en tillståndsbaseradhändelse. En INHIBERANDE

grind anses vara ett specialfall av en AND grind (Kabir, 2017).

Transportnoder. Den sista typen av noder i ett SFT är transportnoder. Det finns två typer av

transportnoder den ena är ”transport in” och används då ett SFT inte får plats på ett dokument.

Transport in visar då att det finns en till sida där SFT fortsätter och på den motsvarande sidan

finns en ”transport ut” symbol som svarar mot transport in symbolen (Kabir, 2017).

Figuren presenterar de symboler som kan ingå i ett Standard felträd.

iii

Bilaga C – Information om litteraturstudie

Tabell (Begränsningsfaktorer, Nyckelord och Databaser) Tabell 12. Visar Begränsningsfaktorer för litteratur studie, Använda nyckelord och Primärt använda databaser

Begränsningsfaktorer

Tidsintervall Typ av artikel Språk Geografisk

restriktion

Antal resultat vid

sökning

2005-2020 Conference

artikel

Svenska Ingen <100

Artikel i journal Engelska

Bok

Exempel på använda nyckelord

Troubleshooting Felsökning Diagnosis Fault diagnosis

Symptom Customer

symptom

Customer

symptom codes

(CSC)

CSC Kundsymptom

Automotive Automobile Automotive

industry

Automobile

industri

Vehicle

Failure Modes and

Effects Analysis

(FMEA)

FMEA Risk priority

number

RPN

Bayesian network

(BN)

BN

Fault tree analasys

(FTA)

FTA Standard fault tree

(SFT)

SFT Felträd

Case based

reasoning (CBR)

CBR

Primärt använda databaser

Ieeexplore ScienceDirect Springerlink Google scholar Emerald insight

Exempel på genomförd litteraturdokumentation Tabell 13. Visar exempel på utdrag från det Excel-dokument vilket litteraturstudien genomfördes genom

Artikel namn Databas Använda nyckel

ord

Nyckelord artikel Antalr

esultat

Tidsinter

vall

Typ av källa Relevans

The diagnosis-resolution

structure in

troubleshooting procedures

Ieeexplore Symptom AND Troubleshooting

writing, documentation, procedures,

troubleshooting

10 2005-2020

Artikel Conference

Stark relevant

A domain-specific decision

support system

for knowledge discovery using

association and

text mining

SpringerLink Customer, AND symptom, AND

codes, AND

troubleshooting AND vehicle

AND automobile

Knowledge Base, Technical Knowledge,

Online User, Computer

Support, Cooperative Work, Office Equipment

13 2005-2020

Artikel i Journal

Tveksamt relevant

Case-Based

Troubleshooting

in the Automotive

Context: The

SMMART Project (s.613)

SpringerLink Symptom AND

Troubleshooting

AND Automotive AND Fault

diagnosis

Case–Based Reasoning,

Automotive

Troubleshooting, Industrial Application of

CBR.

44 2005-

2020

Artikel från

Conference

Starkt

relevant

iv

Bilaga D – Intervjuguide Intervjuteman: Process, Dataflöden, Tidsåtgång och Brister.

(Kursiv text är till för oss och kan vara kontraster, förklaringar till begrepp eller en beskrivning

på det vi vill få fram med dem specifika frågorna)

Målgrupp: Kundmottagare

Fråga 1:

- Vilken roll har kundmottagaren i den initiala felsökningsprocessen av tunga fordon?

•

Följdfrågor till Fråga 1:

- Vilka moment utförs av en kundmottagare?

•

- Vad är syftet med respektive moment?

•

- Hur lång tid tar respektive moment uppskattningsvis?

(Finns det data på det, vi kan ta del av?)

•

- Finns det några moment som skulle kunna undvikas, och i sådana fall vilka och

på vilket sätt?

•

- Hur lång tid brukar kontakten med kunden ta?

•

- Vad avsätter ni för tid för varje kund? (Så lång tid som behövs, 10 min, finns det ett

max, har ni en planering för det?)

•

- Hur hanterar ni oförutsägbara händelser? (t.ex. om problem skulle uppstå, måste ni

planera om eller har ni avsatt tid för sådana händelser?)

•

- Hur påverkas ditt arbete av kundens förmåga att berätta hens observationer av

problemet? (otillräcklig information, längre tid, vad blir konsekvenserna?)

•

- Hur ser kundens situation ut när ni får kontakt med hen? (Är kunden vid fordonet,

Stressad, blockerar vägen, uppgiven, omtumlad)

•

- När anses ett samtal med kund lyckat och när anses det mindre lyckat?

•

- Om du stöter på problem med att hjälpa en kund, kan du ge exempel på vad problemet

kan grunda sig i? och vad är dem vanligaste orsakerna?(Otillräcklig information,

okunskap från kund?)

•

- Om du stöter på problem med att hjälpa en kund, vilka åtgärder kan du då ta till?

(hjälp av kollega, hjälp från annan avdelning)

•

- Från vilka källor använder ni data i erat arbete (t.ex. DTCer, SOPS-fil), och hur

används dem? (Använder ni exempelvis DTCer från fordonets On Board System, för

att minimera problembilden)

•

- Vad är erat mål med kontakten med kunden i slutändan i ett felsökningsperspektiv?

(Är målet att få kunden till verkstad eller samla nödvändiginformation åt mekanikern)

v

•

Fråga 2:

- Vilken typ av data/information erhåller du från kunden?

•

Följdfrågor till Fråga 2:

- Vilket/vilka kommunikationsmedel används för att erhålla information/data från

kunden? (samtal, app, direktmeddelande, mail)

•

- I vilket format erhålls data/information från kunden (t.ex. muntligt, fritext,

förbestämda val)?

•

- På vilket/vilka sätt får ni kunden att dela med sig av relevant information?

(knep, ställer ni bara frågor eller förklarar du varför det kan vara just detta fel och

hur det uppstår, för att kunden skall kunna reflektera och komma med mer

information om problemet och eventuellt ge fler symptom om den förstår problemet

bättre)

•

- Hur skiljer sig kvalitén på informationen från kund, från fall till fall? (ser du skillnad

i samma typ av fall mellan olika kunder)

•

- Kan du peka på aspekter som gör att kvalitén varierar?

(kundens tekniska kunskap, kundens tydlighet i sin symptombeskrivning,

undersöker visa kunder problemet själva innan initial kontakt)

•

- Hur hanterar ni situationer när, informationen kunden ger är otillräcklig/ av sämre

karaktär?

•

- Om kundens information inte är tillräcklig, behöver ni då göra egna tolkningar för att

kunna planera servicearbetet? Vad har detta för påverkan på felsökningsprocessens

kvalité?

•

- Vilken typ av data från kunden hade kunnat förbättra ert arbete tror du?

•

- Vårt arbete handlar som sagt om symptombaserad felsökning, och därför undrar vi

hur arbetet ser ut kring dokumentation av kundsymptom i dagsläget?

(Kundsymptom är egentligen dem observationer kunden har gjort utav systemets

reaktioner på den okända grundorsaken till problemet. Kunden kan även berätta om

händelsen och andra kring liggande faktorer som kan påverka så som väder och vind,

men kundsymptom utmynnas ofta från kundens observation av ett problem och vad

som inte är det nominella beteendet)

•

- På vilket sätt tror du att dokumentation av kundsymptom skulle kunna integreras i er

befintliga arbetsprocess?

•

- Av den data som samlas in idag, hur sker analysen av datan?

(sparar du kunddata rakt av och skickar iväg eller skickar du iväg information som

har analyserats, bedömts och om formaliserats)

•

vi

- Hade du sätt ett värde i att spara kunddata rakt av, som sedan finns tillgängligt för

mekanikern? Varför, varför inte? (Alltså data som inte är bedömd, omformulerad och

analyserad. Även intressant vad du tror om tillgänglighet av både delarna,

analyserad och icke)

•

Fråga 3:

- Hur dokumenteras data från kunden?

•

Följdfrågor till Fråga 3:

- Kan du berätta lite mer om hur konversationen med kunden går till? (ställer du några

standard frågor, Måste du omformulera den information kunden ger dig)

•

- Vilket program/system använder ni för att dokumentera kunddata?

(Vad heter programmet, Hur fungerar det)

•

- Vilka verktyg använder ni som hjälp för att få in rätt kunddata?

(Använder ni frågeträd, Skriver ni in data i något program och får tillbaka respons i

form av fler frågor mot kund etc..)

•

- Hur utnyttjas data från kunden vid planering av andra servicearbeten?

•

- Vilken data anser du hade varit bra att kunna använda vid planering av andra

servicearbeten som inte används idag? (Vägförhållanden, mer information om

händelseförloppet vid observationen av problemet)

•

Fråga 4:

- Till vem och vart skickar ni den insamlade informationen? (när ert arbete är avklarat)

•

Följdfrågor till Fråga 4:

- På vilket sätt för ni vidare all data?

(Genom ett dokument, verbalkontakt)

•

- Hur förbereds data innan ni skickar den vidare?

(Skriver ni data i dokument som skickas till mottagare eller är det någon typ av online

baserat dokument som delas genom ett system)

•

- Om ni förbereder data, hur lång tid brukar det ta?

(kan det ske simultant i kontakt med kund, eller finslipar man data nått efter kontakt

med kund är avslutad)

•

- Vilken data skickar ni vidare?

(Menat av den data du samlar in, är det någon data du inte skickar vidare som du

samlar in och vad händer i så fall med denna data, sparas eller raderas den)

•

Fråga 5:

- Hur hanteras lärdomar/erfarenheter efter lyckat servicearbete?

•

Följdfrågor till Fråga 5:

vii

- Vilken typ av data gällande lärdomar/erfarenheter anser du hade varit fördelaktig att

spara för att underlätta ditt arbete och mekanikerns arbete?

•

- Om lärdomar/erfarenheter dokumenteras, hur används denna data i ditt arbete?

•

- Hur jobbar ni med återkoppling?

•

- Med vem återkopplar ni? (med mekaniker, kund)

•

- Vad kan det handla om?

•

- Vad är din uppfattning om mekanikerns nytta av informationen ni skickar? (Förstår

mekanikern informationen ni skickar fullt ut? Finns det förbättringsmöjligheter i

förtydligandet av informationen mot mekanikern?)

•

- Övrigt? Nått vi glömt? eller inte nämnt som du vill diskutera?

•

Målgrupp: Mekaniker

Fråga 1:

- Vad innebär mekanikerns roll i felsökningsprocessen?

•

Följdfrågor till Fråga 1:

- Vilka steg/processer utför en mekaniker innan dess hen börjar felsöka fordonet?

•

- Vart börjar din kontakt med service/reparationsuppdraget?

•

- Hur fungerar planering för reperationsuppdrag?

•

- Vem erhåller dig med informationen om uppdraget? (Du själv, kollega, en

kundmottagare på verkstad, kundmottagare utom verkstaden, chef)

•

- Vart kommer informationen ifrån? (Kund, kundmottagare)

•

- När får du information om uppdraget eller när finns den tillgänglig? (När

fordonet kommer till plats, innan dess fordonet kommer till plats)

•

- I vilka typ av uppdrag förekommer insamlad information om ett uppdrag som

har gått genom en kundmottagare? (serviceuppdrag, akut-reparationsuppdrag,

underhåll)

•

- Av 10 fall hur ofta förekommer information om uppdraget? Och i vilka typer av

uppdrag är det?

•

- Hur ofta av 10 fall kommer det in kunder till verkstad utan att ha gått igenom en

kundmottagare först?

•

- Hur fungerar planeringen och i de fallen? (Vem tar emot kund , samlar in

information, och planerar arbetet, utförs en initialfelsökning då?)t

viii

•

- När ett uppdrag är inplanerat, hur lång tid passerar innan ni utför

reparation/servicen?

•

- Finns det uppdrag som prioriteras? (akuta-uppdrag, alvarligare problem, när

fordonet inte kan brukas)

•

Fråga 2:

- Hur tar du del av information om uppdraget? (Genom ett speciellt program, mail)

•

Följdfrågor till fråga 2:

- Hur presenteras informationen för dig? (fritext, check-boxar)

•

- Vad är det för data? (Symptom, DTCer, beskrivning av händelseförloppet,

vägförhållanden)

•

- Varierar användbarheten och detaljrikedomen på de olika data inom uppdragen? På

vilket sätt? (Är det någon information som sticker ut i sin användbarhet, för att lösa

problemet, någon information du inte använder i ditt felsökande men som finns

med)

•

- Varierar användbarheten och detaljrikedomen på informationen från fall till fall? På

vilket sätt? Varför?

•

- Ser du några förbättringsmöjligheter med den information som idag finns

tillgänglig, i samband med ett uppdrag? (presentationen , data i säg otydlig, vilken?,

Återkoppling vid otydlig data, kan du ibland känna ”om jag viste detta hade jag

kunnat lösa problemet”)

•

- Vet du vad kundmottagaren som samlat in information om uppdraget, gjort med

informationen? (har den börjat en initialfelsökningsprocess så du iallafall vet att det

är nått i motorn eller med tändningen som är fel)

•

- Hur långt gången är felsökningsprocessen när du tillhandahåller uppdraget? (Vet du

vilket system problemet ligger i, eller vet exakt vilken del felet ligger i)

•

- Händer det att ni inte behöver felsöka fordonet?

•

- Ifall, hur ofta av 10 fall?

•

- Och varför? (För att ni vet av erfarenhet vad felet är? för att felet är så pass

specifikt, för att den initiala felsökningsprocessen redan är så långt gången)

•

Fråga 3:

- Hur arbetar ni med kundsymptom i dagsläget? (urskiljer kundsymptom av fel

beskrivning från kundmottagare, ringer upp kunden ibland och frågar lite, när kund

kommer förbi verkstad)

•

Följdfrågor till fråga 3:

ix

- Att integrera kundsymptom i eran felsökningsprocess och program på daglig basis,

hur tror du att det hade kunnat hjälpt din vardagliga verksamhet? (på ett mer

standardiserat sätt, den kunskapen ni har idag om kundsymptom finns även i

felsökningsprogrammen, ex statistisk data som ni annars bara tar förgivet ”denna

delen går ofta sönder så kollar den först”)

•

- Vad tror du är viktigt att ta i åtanke vid skapandet av ett sådant felsökningssystem?

(Nån tanke kring data, användningen, presentationen av data)

•

Fråga 4:

- Kan du gå igenom de olika processerna/momenten du genomför i ett uppdrag från

början till slut? (Det kan vara ett exempel på ett uppdrag, vilka process/moment är

generella som du alltid genomför)

•

- Kan du säga nått om tiden för varje moment?

•

- Ser du att något moment som utförs idag är onödigt eller utförs på fel sätt? Varför?

•

- Övrigt? Nått vi glömt? eller inte nämnt som du vill diskutera?

•

x

Bilaga E - Informationsblad och samtycke Nedan presenteras två delar, den ena förklarar kort bakgrunden till intervjun och studien och den andra förklarar

vad du som deltagare har för rättigheter samt information om ditt medgivande till intervjun.

Bakgrund till studien och intervjun Studien som utför av två studenter från Mälardalens Högskola är ett examensarbete i samarbete med Scania CV

AB. Studien undersöker möjligheten till ett kompletterande felsökningssystem baserat på symptombaserad

felsökning.

I dagensläge används till största del DTC: er (felkoder) för att avgöra vad som är felet på ett icke fungerande

fordon. Tanken bakom ett symptombaserat felsökningssystem är att kunna använda sig av kundens (förarens)

observationer för att minimera problembilden. Förarens observationer benämns även som kundsymptom. Ofta

använder kundmottagare och mekaniker kundsymptom för att avgöra vad som är grundorsaken till ett problem, då

ofta genom att dra egna slutsatser utifrån erfarenhet. Dock finns det inte i dagen läge ett standardiserat sätt för att

använda sig av kundsymptom digitalt i de tillgängliga felsökningsprogram och system Scania tillhandahåller. Detta

är därför ett initiativ från Scanias sida att undersöka möjligheten till att använda sig av symptom inom den digitala

felsökningen.

Intervjuerna har till fokus att dokumentera den befintliga felsökningsprocessen samt undersöka vad personal som

ingår i den arbetsmässiga vardagen av den befintliga felsökningsprocessen har för tankar kring

symptombasseradfelsökning. Frågorna som ställs grundar sig i fyra olika teman dataflöde mellan parter, processer

i arbetet, tidsåtgång och brister i den befintliga felsökningsprocessen. Intervjun kommer vara ca 40-60 min.

Intervjuerna kommer utföras genom ”face to face”, telefon eller Skype-samtal. Intervjuerna kommer endast

innebära samtal och inte video-samtal i de fall där Skype eller telefonsamtal utförs. Två intervjuare kommer vara

närvarande under intervjun. Intervjun kommer ljud-inspelas för att underlätta dokumentation.

Samtycke och rättigheter Du är inbjuden att delta i en intervju, för att hjälpa till att samla in information om den befintliga

felsökningsprocessen genom din kunskap i din arbetsroll.

Deltagarens samtycke:

• Jag förstår att deltagandet är frivilligt.

• Jag samtycker deltagandet i intervjun.

• Jag ger mitt samtycke till att ljud spelas in i och sparas syfte att underlätta dokumentationen.

• Jag ger mitt samtycke till att ljud-inspelningen används i syfte av denna studie (Examensarbete av

Jesper Jansson & Alexander Törnqvist).

• Jag förstår att informationen som samlas in under intervjun kommer bedömas objektivt i en analys.

Samtycke av ovanstående punkter görs antingen muntligt vid start av intervjun, med ett JA.

Eller genom att skriva under nedan:

Underskrift: ______________________________________________

Namnförtydligande:______________________________________________

Rättigheter som deltagare:

• Du får avbryta intervjun när du vill, oavsett anledning.

• Du som deltagare har rätt att ställa frågor när du vill under intervjun.

• Du har rätt att avvisa frågor du inte vill besvara, oavsett anledning.

• Du som deltagare kommer vara anonym* i studien.

*Endast närvarande på intervju kommer ta del av ditt namn och andra eventuella personuppgifter. De

personuppgifter som samlas in och dokumenteras i studien är: ålder, befattning, kön och år inom

yrkesrollen

xi

Bilaga F – QFD

xii

Bilaga G – Färgkodade anteckningar av respondenternas svar

Anteckningar för respondenternas individuella svar

Följande del presenterar anteckningarna av respondenternas individuella svar. Frågorna och

svaren är färgkodade enligt: Process, Dataflöden, Tidsåtgång och Brister och

förbättringsmöjligheter, respektive Process, Dataflöde, Tidsåtgång och Brister och

förbättringsmöjligheter.

Respondent 1:

Målgrupp: Kundmottagare

Fråga 1:

Vilken roll har kundmottagaren i den initiala felsökningsprocessen av tunga fordon?

Det beror på marknaden och kompetensen hos kundmottagaren – det varierar ganska

kraftigt. I vissa fall är kundmottagaren gamla mekaniker så då har de goda tekniska

kunskaper. Detta kan variera från verkstad till verkstad. Kundmottagaren är första filtret

mot kunden.

Följdfrågor till Fråga 1:

Vilka moment utförs av en kundmottagare?

I verkstadsprocessen, Dedicated Customer Service, beskrivs samtliga moment som

kundmottagaren ska utföra och i vilken ordning. I praktiken – se till att kunder kommer in

till verkstaden, kommunicera med kunden, administrera och se till att mekanikern kan göra

något. Alla roller i verkstaden förutom mekanikern är till för att stödja mekanikern. Det

Scania får betalt för i verkstäderna är när mekanikern gör något åt kunden eller när delar

säljs.

Vad är syftet med respektive moment?

Det kan man läsa om i verkstadsprocessen (rollbeskrivning och syfte) – Dedicated

Customer Service.

Hur lång tid tar respektive moment uppskattningsvis? (Finns det data på det, vi kan ta del

av?)

Det beror på jobbet – allting från att kunden dyker upp på verkstaden och säger ”Hej trasig

bil – fixa nu” till att man 2-3 veckor innan ringer upp kunden och säger att vi har planerat

ett underhåll.

För mekanikern tar själva genomförandet några timmar till någon dag. Detta beror också på

jobbet, ibland kan det ta flera dagar att få hem reservdelar. Det är likadant på vägen ut. När

processen avslutas med fakturering och uppföljning – i vissa fall går det snabbt men ibland

kan det ta någon dag. I extremfall kan fakturor ligga 2-3 månader, det varierar stort.

# Hur länge pratar man med kunden (felbeskrivning)?

Det beror på. Vissa kundmottagare småpratar först för att hålla en bra relation med kunden,

och därefter går igenom vad problemet är. Själva felsökningsbiten kan ta från 5 minuter till

längre beroende på hur komplext problemet är.

Finns det några moment som skulle kunna undvikas, och i sådana fall vilka och på vilket

sätt?

Det finns mycket administration, praktiskt manuellt jobb som man kan undvika. Det som

kan förbättras är på systemsidan, t.ex. har vi möjlighet till fjärrdiagnos idag men det är

bökigt och sker manuellt fortfarande.

xiii

Hur lång tid brukar kontakten med kunden ta?

-

Vad avsätter ni för tid för varje kund? (Så lång tid som behövs, 10 min, finns det ett max,

har ni en planering för det?)

Så lång tid det tar, inget standardmått, beror på kunden och fallet.

Hur hanterar ni oförutsägbara händelser? (t.ex. om problem skulle uppstå, måste ni planera

om eller har ni avsatt tid för sådana händelser?)

Det varierar från verkstad till verkstad – men man får göra omprioriteraringar.

Hur påverkas ditt arbete av kundens förmåga att berätta hens observationer av problemet?

(otillräcklig information, längre tid, vad blir konsekvenserna?)

Det blir svårare att utföra arbetet om inte kunden kan beskriva felet. Detta kan t.ex. ske om

ägaren ringer in istället för föraren. Att prata med kunden har man gjort länge och kan –

något att förbättra är att automatiskt få information från fordonet.

Hur ser kundens situation ut när ni får kontakt med hen? (Är kunden vid fordonet, Stressad,

blockerar vägen, uppgiven, omtumlad)

Beror helt på vad saken gäller. Finns ingen standardvariant – beror på vad kunden för

problem och hur allvarligt felet är.

När anses ett samtal med kund lyckat och när anses det mindre lyckat?

Kundmottagarens målsättning är att alltid lösa kundens problem - är kunden glad är

kundmottagaren glad. Om kunden har ett problem kan det anses vara lyckat när problemet

är löst och kunden kan använda sitt fordon igen.

Om du stöter på problem med att hjälpa en kund, kan du ge exempel på vad problemet kan

grunda sig i? och vad är dem vanligaste orsakerna?(Otillräcklig information, okunskap från

kund?)

Kundmottagarna är väldigt kreativa, försöker med alla varianter för att lösa kundens

problem. T.ex. om man inte har reservdelar hemma – undersöker om andra verkstäder i

närområdet har det så att man kan hämta dem därifrån.

Om du stöter på problem med att hjälpa en kund, vilka åtgärder kan du då ta till? (hjälp av

kollega, hjälp från annan avdelning)

-

Från vilka källor använder ni data i erat arbete (t.ex. DTCer, SOPS-fil), och hur används

dem? (Använder ni exempelvis DTCer från fordonets On Board System, för att minimera

problembilden)

Det är en djungel med en massa system, t.ex. DTCer, 15-20 system kan man rota i för att få

information om fordonet. All information är sorterad på informationstyp. Detta är bara

Scaniasystem, sedan kan det finnas egna system på verkstäder i olika länder.

Vad är erat mål med kontakten med kunden i slutändan i ett felsökningsperspektiv? (Är

målet att få kunden till verkstad eller samla nödvändiginformation åt mekanikern)

Det ena är att få in fler kunder till verkstäderna, proaktivt, ringa upp kunder – nu är det dags

för att göra underhåll. Det andra är att lösa kundens problem (så att kunden kan använda

sitt fordon igen) när kunden ringer upp och har ett problem.

xiv

Fråga 2:

Vilken typ av data/information erhåller du från kunden?

Det man frågar efter. De har några Appar som man testkör, kunden kommer in och pratar.

Det finns inget generellt inskick av information – beroende på kunden och vad det är för

business så får man lite olika saker.

Följdfrågor till Fråga 2:

Vilket/vilka kommunikationsmedel används för att erhålla information/data från kunden?

(samtal, app, direktmeddelande, mail)

Alla olika varianter, oftast det som passar bäst för kunden. Vissa mejlar, ringer, skickar

sms, eller vissa dyker upp i verkstaden själva. Det finns inget facit där utan det handlar om

det som råkar funka för den verkstaden och den kunden.

I vilket format erhålls data/information från kunden (t.ex. muntligt, fritext, förbestämda

val)?

Beror på.

På vilket/vilka sätt får ni kunden att dela med sig av relevant information?

(knep, ställer ni bara frågor eller förklarar du varför det kan vara just detta fel och hur det

uppstår, för att kunden skall kunna reflektera och komma med mer information om

problemet och eventuellt ge fler symptom om den förstår problemet bättre)

Det finns inget standardiserat Scaniaverktyg för kundmottagaren. Varje kundmottagare lär

sig vad man ska ställa för frågor. Ett problem är att det inte är så ofta man kan ge en exakt

diagnos över telefonen. Assistans hade ett A3-papper där det stod vilka frågor man skulle

ställa, men inte kundmottagaren.

Hur skiljer sig kvalitén på informationen från kund, från fall till fall? (ser du skillnad i

samma typ av fall mellan olika kunder)

Beror helt på kunden, kundmottagaren och situationen. Är det t.ex. en enbilsåkare som äger

bilen själv och är tekniskt kunnig – då kan han säga vissa saker. I vissa fall kan det vara en

inhyrd bemanningschaufför som bara kör bilen, och har ingen aning om hur den funkar.

Kan du peka på aspekter som gör att kvalitén varierar? (kundens tekniska kunskap, kundens

tydlighet i sin symptombeskrivning, undersöker visa kunder problemet själva innan

initial kontakt)

En teknisk kunnig kund kan i vissa fall komma närmare felet. Största skillnaden är när man

kan få faktisk data, som felkoder och driftdata på bilen man tittar på – då är det lättare att ge

en diagnos. Sedan beror det helt på felet – vissa fel är lätta att detektera genom att lyssna,

titta och känna medans andra är svåra.

Hur hanterar ni situationer när, informationen kunden ger är otillräcklig/ av sämre karaktär?

Det är få saker vi kan lösa på distans så oftast måste fordonet in till verkstaden för att lösa

problemet. Det brukar handla om 3 frågor; Vill du komma in? Ska Assistans komma ut?

eller ska vi bärga?

Om kundens information inte är tillräcklig, behöver ni då göra egna tolkningar för att kunna

planera servicearbetet? Vad har detta för påverkan på felsökningsprocessens kvalité?

Får vi inte tillräckligt mycket information från kunden – ta in bilen till verkstaden så får vi

titta på den. Det är svårt att boka/beställa delar utan att veta vad som är fel.

Vilken typ av data från kunden hade kunnat förbättra ert arbete tror du?

xv

Driftdata från fordonet, t.ex. felkoder och historik – då hade man kunnat få ett bättre hum

om problemet. Men på helheten kanske inte det påverkar resultatet så mycket.

Vårt arbete handlar som sagt om symptombaserad felsökning, och därför undrar vi hur

arbetet ser ut kring dokumentation av kundsymptom i dagsläget? (Kundsymptom är

egentligen dem observationer kunden har gjort utav systemets reaktioner på den okända

grundorsaken till problemet. Kunden kan även berätta om händelsen och andra kring

liggande faktorer som kan påverka så som väder och vind, men kundsymptom utmynnas

ofta från kundens observation av ett problem och vad som inte är det nominella beteendet)

Det som görs i viss mån är att man skriver ner symptomen och problemen på arbetsordern,

men oftast är det kundmottagaren som pratar med mekanikern direkt. Att spara symptomen

har egentligen ingen funktion – så fort bilen kommer in och man börjar arbeta med den så

är symptomen ointressanta och efteråt med. Det handlar mer om att föra vidare information

till mekanikern så att de kan förbereda - plocka fram delar.

På vilket sätt tror du att dokumentation av kundsymptom skulle kunna integreras i er

befintliga arbetsprocess?

Det finns nog inget behov av att dokumentera kundsymptom, mer än att föra över dem till

mekanikern – då är det lättare att prata direkt med mekanikern. För kundmottagarens del,

det som skulle vara mer effektivt är att kundmottagaren får stöd att ställa rätt frågor för att

kunna göra en initial diagnos.

Av den data som samlas in idag, hur sker analysen av datan? (sparar du kunddata rakt av

och skickar iväg eller skickar du iväg information som har analyserats, bedömts och om

formaliserats)

Det sker i huvudet på kundmottagaren, eller i vissa fall pratar dem med mekaniker eller

kollegor.

# Skickar man data direkt till mekanikern?

Man pratar med kunden, sedan skriver man antingen ner på arbetsordern vad kunden klagar

på, t.ex. vibrationer vänster bak – felsök, eller så pratar man med mekanikern och berättar

om kundens problem. I vissa marknader så pratar även mekanikern direkt med kunden, med

det är ungefär som kundmottagaren gör. Informationsöverföringen är antingen muntlig eller

skriftlig i arbetsordern.

Hade du sätt ett värde i att spara kunddata rakt av, som sedan finns tillgängligt för

mekanikern? Varför, varför inte? (Alltså data som inte är bedömd, omformulerad och

analyserad. Även intressant vad du tror om tillgänglighet av både delarna, analyserad och

icke)

Det beror på. Det hade varit fördelaktigt för mekanikerna att få en snapshot på driftdata när

ett fel inträffade.

Fråga 3:

Hur dokumenteras data från kunden?

-

Följdfrågor till Fråga 3:

Kan du berätta lite mer om hur konversationen med kunden går till? (ställer du några

standard frågor, Måste du omformulera den information kunden ger dig)

-

Vilket program/system använder ni för att dokumentera kunddata? (Vad heter programmet,

Hur fungerar det)

xvi

Det är olika. Det finns flera system, t.ex. i DMS ligger kunddata – vem kunden är och

kontaktuppgifter. Vissa har separata system.

Vilka verktyg använder ni som hjälp för att få in rätt kunddata? (Använder ni frågeträd,

Skriver ni in data i något program och får tillbaka respons i form av fler frågor mot kund

etc..)

-

Hur utnyttjas data från kunden vid planering av andra servicearbeten?

En del av verkstadsprocessen är att man ska göra en fjärrutläsningen innan man ringer upp

kunden och planerar in ett servicearbete. När man gör en fjärrutläsning kan man t.ex. se

felkoder och driftdata, och med hjälp av detta kan man fråga kunden om de vill att man

även ska titta på andra saker i samband med servicearbetet. Detta tar tid, så jag vet inte till

vilken grad detta tillämpas i praktiken.

Vilken data anser du hade varit bra att kunna använda vid planering av andra servicearbeten

som inte används idag? (Vägförhållanden, mer information om händelseförloppet vid

observationen av problemet)

Idag används vägförhållanden som underlag för intervaller av servicearbete. En

kundmottagare vet om vart hans kunder befinner sig ungefär (han vet vilka vägförhållanden

dem har). Man måst vara kunnig för att kunna utnyttja vägförhållande-data.

Fråga 4:

Till vem och vart skickar ni den insamlade informationen? (när ert arbete är avklarat)

Till mekanikern och en del system, t.ex. DMS.

Följdfrågor till Fråga 4:

På vilket sätt för ni vidare all data? (Genom ett dokument, verbalkontakt)

-

Hur förbereds data innan ni skickar den vidare? (Skriver ni data i dokument som skickas till

mottagare eller är det någon typ av online baserat dokument som delas genom ett system)

Kundmottagaren försöker förmedla vad de lärt sig från kunden till mekanikern, så att

mekanikern får ett försprång på felsökningen.

Om ni förbereder data, hur lång tid brukar det ta? (kan det ske simultant i kontakt med kund,

eller finslipar man data nått efter kontakt med kund är avslutad)

-

# Hur lång tid tar det att skriva ner i arbetsordern efter man har pratat med kunden?

Det tar inte så lång tid att skriva in i arbetsordern. Man kan förbereda arbetsordern men

man kan inte skapa den förens kunden kommer in.

Vilken data skickar ni vidare? (Menat av den data du samlar in, är det någon data du inte

skickar vidare som du samlar in och vad händer i så fall med denna data, sparas eller

raderas den)

-

Fråga 5:

Hur hanteras lärdomar/erfarenheter efter lyckat servicearbete?

Kundmottagare och mekaniker pratar med varandra i bästa fall.

Följdfrågor till Fråga 5:

xvii

Vilken typ av data gällande lärdomar/erfarenheter anser du hade varit fördelaktig att spara

för att underlätta ditt arbete och mekanikerns arbete?

Jag tror inte det är själva kommunikation i sig som är största vinsten, det handlar mer om

att kunna meddela kända problem och lösningar.

# Så mer statistiska data som kan vara bra i olika fall?

Nej det tror jag inte, allt är så beroende på problem och kund. Jag tror inte det finns

standardfrågor och standardsätt. Samma problem för olika kunder blir olika strategier.

Om lärdomar/erfarenheter dokumenteras, hur används denna data i ditt arbete?

-

Hur jobbar ni med återkoppling?

Jag har inte sett något officiellt verktyg. Enbart att de pratar med varandra, inget

organiserat.

# Kan det vara så att man kontaktar t.ex. produktägare om det uppstår ett ovanligt

problem?

Om det är ett skumt problem gör de en FRAS-anmälan, pratar med support och helpdesk,

tar hjälp uppåt – hela vägen till fabrik. Detta sker nästan alltid efter att bilen har dykt upp.

Hur och med vem återkopplar ni? (med mekaniker, kund)

-

Vad kan det handla om?

-

Vad är din uppfattning om mekanikerns nytta av informationen ni skickar? (Förstår

mekanikern informationen ni skickar fullt ut? Finns det förbättringsmöjligheter i

förtydligandet av informationen mot mekanikern?)

Försprång på att felsöka. I fall när det är latenta problem, d.v.s. problem som dyker upp

ibland (t.ex. vid en viss temperatur), måste mekanikern kunna återskapa problemen för att

lösa problemen. Då får mekanikern hjälp att återskapa problemet.

Är det något annat som du skulle vilja säga, övrigt?

Inte angående kundmottagaren direkt. Men att det är viktigt att kundmottagaren ställer rätt

frågor och att mekanikern får den information han behöver. En diagnosmotor som

behandlar reservdelar också så att man lätt ser om åtgärden är möjlig just nu eller om delar

behöver beställas. Även att diagnosmotorn i samma program kan behandla automatisk

diagnostisering samt manuell. Kunden är benägen att veta om den ska komma in till

verkstad, kommer assistans eller kan jag köra in?

Respondent 2:

Målgrupp: Mekaniker

Fråga 1:

Vad innebär mekanikerns roll i felsökningsprocessen?

En väldigt stor del, visuellt och praktiskt felsöka. På en vanlig verkstad har man en

kundmottagare som tar emot fordonet, beroende på kompetensen kan man få ett papper från

kundmottagaren där det t.ex. står ”bilen låter konstigt”. Då är man på ruta 1 och man får då

xviii

börja leta. Om man inte kan hitta felet själv får man fråga någon annan som kan provköra och

då åker man med och börjar leta. Om man har möjlighet – fråga den faktiska kunden hur dem

upplever felet. Mekaniker kan ringa upp kunden, men det funkar lite olika på olika verkstäder. Följdfrågor till Fråga 1:

Vilka steg/processer utför en mekaniker innan dess hen börjar felsöka fordonet?

Det har med erfarenhet och kunskap att göra – när kunden ibland kom in och berättade vad han

upplevde som fel kunde det ibland vara ett känt problem, då kunde man redan då börja beställa

reservdelar om man var säker. Vid en vanlig felsökning när man inte vet innan vad felet är, då

är första steget att avgöra om en provkörning behövs, annars börjar man leta.

Vart börjar din kontakt med service/reparationsuppdraget?

Antingen kom kunden in, eller ringde kunden in. Eller muntlig/arbetsordern från

kundmottagare.

Hur fungerar planering för reperationsuppdrag?

Lokalisera felet, bedöma vad som ska bytas, om något måste beställas – kontakta verkstadschef

eller kundmottagare, annars gå in och plocka från lagret om det fanns hemma, kontakta kunden

– om dem ville att man skulle utföra reparationen, ge kostnadsförslag.

Vem erhåller dig med informationen om uppdraget? (Du själv, kollega, en kundmottagare på

verkstad, kundmottagare utom verkstaden, chef)

Kundmottagare, verkstadschefen eller dig själv, eller kunden direkt.

Vart kommer informationen ifrån? (Kund, kundmottagare)

-

När får du information om uppdraget eller när finns den tillgänglig? (När fordonet kommer till

plats, innan dess fordonet kommer till plats)

Beror på, det kan vara ett planerat jobb, ett par dager till en vecka innan, annars akuta jobb –

agera direkt.

I vilka typ av uppdrag förekommer insamlad information om ett uppdrag som har gått

genom en kundmottagare? (serviceuppdrag, akut-reparationsuppdrag, underhåll)

När kunden kommer in, dialog om vad kunden upplever, vad problemet är. Inte så avancerat.

Av 10 fall hur ofta förekommer information om uppdraget? Och i vilka typer av uppdrag är

det?

10/10. Kundmottagaren kanske omformulerar kundens information innan mekanikern får den.

Hur ofta av 10 fall kommer det in kunder till verkstad utan att ha gått igenom en

kundmottagare först?

Det kan hända, fast det inte skulle hända. Ofta är det kunder som har lite egna erfarenheter,

som har ett hum om fordonet, som hellre pratar med mekanikern för att få den respons dem

vill. 3/10 eller 4/10.

Hur fungerar planeringen och i de fallen? (Vem tar emot kund , samlar in information, och

planerar arbetet, utförs en initialfelsökning då?)

Om man tar beslut med kunden att ett arbete ska utföras, då hänvisar man till kundmottagaren,

för mekanikern planerar inte sina dagar själv, det är inte deras sak att göra.

xix

När ett uppdrag är inplanerat, hur lång tid passerar innan ni utför reparation/servicen?

Vissa jobb kunde vara planerade jättelänge, t.ex. ett serviceavtal - teoretiskt sätt är det alltid

planerat, 12 månader tillbaka, ingår ingen felsökning i det.

# Om det är ett akutuppdrag, prioriteras det över serviceavtal?

Vid akuta fall är det upp till verkstäderna själva hur de prioriterar jobben. Det är lite

kundbaserat, ”är det värt att lägga den kunden åt sidan för att ge den här företräde?”. Om man

bortser från det, även om det är ett akutjobb så får man ställa sig i ledet.

Finns det uppdrag som prioriteras? (akuta-uppdrag, alvarligare problem, när fordonet inte kan

brukas)

Är man upplåst på ett stort åkeri som kund med t.ex. 50 bilar som man konstant underhåller

och reparerar hos en verkstad, jämfört med ett åkeri som har 1 bil, då kanske den med 1 bil blir

mindre prioriterad för att vara rädda om kunderna.

Fråga 2:

Hur tar du del av information om uppdraget? (Genom ett speciellt program, mail)

Arbetsorder i pappersformat, men man kunde även ta del av den digitalt. Men i huvudsak

pappersformat. I arbetsorderna var det ganska enkelt uppradat – t.ex. det här ska ni göra. När

man är klar med ett arbete textar man i arbetsordern vad som är gjort, som då sparas ner för

vårat ändamål, sen får kunden ut sitt slutgiltiga dokument där vissa saker mekanikern har skrivit

ned tas bort.

# Det kundmottagaren skriver i arbetsordern – görs det på data eller skriver hen för hand?

Det skriver dem digitalt som man sedan skriver ut.

Följdfrågor till fråga 2:

Hur presenteras informationen för dig? (fritext, check-boxar)

Beror på vad det är för jobb. En vanlig felsökning - där finns ingen check-box utan fritext, men

är det ett fast arbete som man ska göra – då kan man ha ett protokoll.

Vad är det för data? (Symptom, DTCer, beskrivning av händelseförloppet, vägförhållanden)

Vissa gånger kunde man få ” kunden tycker det låta illa i den främre delen av bilen”.

# Vad det till hjälp någon gång?

Ja, då slipper man leta bak. Vid såna fall hoppar man in i bilen, sen när man kör in den i

verkstaden då kan man redan stryka det som står, då har man redan listat ut att det är fram det

låter. Vid bättre beskrivningar, t.ex. ”ett vinande ljud från vänster bakhjul vid inbromsning” -

det eliminerar ganska många andra felsökningsstadier. Det underlättar att veta bland annat

kontext och position.

Varierar användbarheten och detaljrikedomen på de olika data inom uppdragen? På vilket

sätt? (Är det någon information som sticker ut i sin användbarhet, för att lösa problemet, någon

information du inte använder i ditt felsökande men som finns med)

-

Varierar användbarheten och detaljrikedomen på informationen vid liknande fall/problem? På

vilket sätt? Varför?

Man kan få varierande information om liknande fall. Och svårigheten med detta varierar från

mekaniker till mekaniker beroende på detta. Variationen beror främst på erfarenhet ” att man

kommer ihåg vad man har gjort innan”. Man börjar då ofta om man märker att det är samma

typ av fel att leta tillbaka i minnet och försöker komma ihåg vad man gjorde för att lösa det.

xx

#Har skillnaden på detaljrikedomen i dessa liknande fall gjort att felsökningsprocessen blivit

lidande?

Nej, det skulle jag inte säga. Absolut kan det vara skillnad från dag till dag. Men generellt så

är det nog ganska lika.

Ser du några förbättringsmöjligheter med den information som idag finns tillgänglig, i samband

med ett uppdrag? (presentationen , data i säg otydlig, vilken?, Återkoppling vid otydlig data,

kan du ibland känna ”om jag viste detta hade jag kunnat lösa problemet”)

Till verkstäderna - kundmottagaren skulle kunna sköta planeringen, men när det gäller

felsökningen så skulle jag gärna se att man hämtar mekanikern och låter mekaniker vara med

under i samtalet, det skulle nog kunna räta ut ganska många frågetecken, just vid tidsplanering.

Vet du vad kundmottagaren som samlat in information om uppdraget, gjort med

informationen? (har den börjat en initialfelsökningsprocess så du iallafall vet att det är nått i

motorn eller med tändningen som är fel)

Har inget jättebra svar, jag vet nu i efterhand att mycket av grejerna kan man använda sig av

ett program, Multi där man har lite kampanjer, lite tillvägagångsätt, lite felsökningshjälp. Sedan

om en kundmottagare använder det för att underlätta för mekanikern vet jag inte.

Hur långt gången är felsökningsprocessen när du tillhandahåller uppdraget? (Vet du vilket

system problemet ligger i, eller vet exakt vilken del felet ligger i)

Problemet är minimalt löst då, i alla fall ute på en vanlig verkstad. Det blir väldigt mycket

felsökning för mekanikerna.

Händer det att ni inte behöver felsöka fordonet?

Ja, det gör det. Men det har med erfarenhet att göra, beror på mekanikern. Kan ju vara ett fel

man gjort flera gånger tidigare eller att man vet om ett tekniskt fel på en artikel. T.ex. får ni

den här felkoden och bilen beter sig så här så är det garanterat den här som är trasig för det har

hänt 5000 bilar. Då tar man oftast in bilen och byter artikeln så kommer det fungera igen. Det

är enstaka fall.

# Det du går mycket på låter som symptom, statistik och erfarenhet, stämmer det?

Ja.

Ifall, hur ofta av 10 fall?

-

Och varför? (För att ni vet av erfarenhet vad felet är? för att felet är så pass specifikt, för att

den initiala felsökningsprocessen redan är så långt gången)

-

Fråga 3:

Hur arbetar ni med kundsymptom i dagsläget? (urskiljer kundsymptom av fel beskrivning från

kundmottagare, ringer upp kunden ibland och frågar lite, när kund kommer förbi verkstad)

Svårt att säga, skiljer sig mellan verkstad och verkstad. Dem verkstäderna som har en

mekaniker som är mer involverad från början – där funkar det nog mycket bättre.

# Är den informationen (kundsymptom) till hjälp?

Oftast, ibland kan det stjälpa mera. Finns ju gånger när det inte ens finns ett fel med bilen men

kunden upplever det ändå

xxi

# Varierar det beroende på chaufförens tekniska kompetens?

Ja, absolut.

Följdfrågor till fråga 3:

Att integrera kundsymptom i eran felsökningsprocess och program på daglig basis, hur tror du

att det hade kunnat hjälpt din vardagliga verksamhet? (på ett mer standardiserat sätt, den

kunskapen ni har idag om kundsymptom finns även i felsökningsprogrammen, ex statistisk data

som ni annars bara tar förgivet ”denna delen går ofta sönder så kollar den först”)

Ja, det har jag idag så jag vet att det hjälper. Vi har ett rapporteringsprogram, allt som händer

och inte händer med bilen, finns rapporterat. Jag jobbar mycket på annan ort, med inhyrda

förare, och dem har klockslag, när dem upplever en förändring med bilen, väderlek, väglag, allt

finns med (på en R&D-verkstad).

# Hur dokumenteras det?

I text.

# Är det kunden som skriver?

Ja.

Jag får uppdraget - vi har ett missljud på den här bilen, jag kollar i rapporten och ser exakt, det

kan vara från chaufför till chaufför, ibland kan de t.ex. berätta vilken växel dem hade i när det

felet uppstod. Det hjälper.

# Vet du om de har någon mall att utgå ifrån när de skriver?

Ja det har dem, vill jag minnas (inte vanlig verkstad).

Vad tror du är viktigt att ta i åtanke vid skapandet av ett sådant felsökningssystem? (Nån tanke

kring data, användningen, presentationen av data)

Det ska vara simpelt, man måste tänka på att det är vi som lagar, inte chauffören, man får inte

förvänta att dem har den kompetens som vi har. Därför kan man ju inte förvänta sig den

information som jag skulle kunna ge om jag körde fordonet. Ha det ganska basic, men ändå få

ut den information som mekanikern behöver ha.

# Vad skulle du kunna säga är bra data för mekaniker?

Vad man har gjort med fordonet precis där man upptäckte felet, låg du på motorvägen, eller

höll du på att backa? Alltså förenklad situation – vad som hände. Kort händelseförlopp, det

börjar skaka här, sen fortsatte jag köra, sen när jag stannade och började backa - då small det.

Den biten innan kanske glöms bort, oftast får man inte höra att t.ex. vibrerade 10 minuter innan

det small.

# Så mycket kontext är viktigt, inte bara specifika symptom?

Precis.

Fråga 4:

Kan du gå igenom de olika processerna/momenten du genomför i ett uppdrag från början till

slut? (Det kan vara ett exempel på ett uppdrag, vilka process/moment är generella som du alltid

genomför)

Jättesvårt. Man får uppdraget, granskar, börjar med att utgå från det som är nedskrivet om det

kan ge något. Beroende på vad det är för fel – visuell och fysisk felsökning fram tills man

upptäcker felet. Därefter meddelas kunden och man frågar om man ska göra jobbet. Beställning

av reservdelar - få hem dem så fort som möjligt. Sedan reparerar man och lämnar ut nyckeln

xxii

till kundmottagaren. Sedan berättar kundmottagaren det som är relevant från arbetsordern för

kunden. Vissa delar kring felsökningen som mekanikern skriver ner i arbetsordern är inte

relevant för kunden.

Kan du säga nått om tiden för varje moment?

Jättesvårt, felsökning kan ta allt mellan 10 minuter till 3 veckor.

# Dokumentationsprocessen, kan du säga någon tid på den?

Det ska inte ta lång tid. På en vanlig verkstad mellan 10-15 minuter. Då har man skrivit ganska

ordagrant vad man har gjort.

Ser du att något moment som utförs idag är onödigt? Varför?

Alla moment behövs egentligen. En del moment hade kunnat flyttas över till mekanikern – men

är det värt det? Att ta med mekanikern från första början underlättar, då tappar man steget från

kundmottagaren till papper, från papper till mekaniker. I vissa fall måste mekanikern kanske

tillbaka till kundmottagaren för att ställa frågor. Dock så gör mekanikern troligtvis ett annat

jobb samtidigt som kundmottagaren kommunicerar med kunden. Vinner man att plocka bort

mekanikern från det jobbet?

# T.ex. om man kan ge kundmottagaren något som egentligen kunde ersätta mekaniken på plats,

då skulle det vara mycket värt?

Ja, man skulle kunna göra ett underlag där man har lite stående punkter. Ställ de här frågorna,

skriv ner svaren. Det här kommer dock ta tid, då får man bolla fram och tillbaka – ska vi ställa

den här frågan? Ska vi lägga till en fråga? Det handlar om att undersöka vad som är värt att

veta.

Respondent 3:

Målgrupp: Kundmottagare

Fråga 1:

Vilken roll har kundmottagaren i den initiala felsökningsprocessen av tunga fordon?

Ta reda på vad som är fel, symptomen, få reda på körsituationer, underlag,

utetemperaturer, och en skillnad för deras ställe är att dem även går på generationer på

bilar. En vanlig kundmottagare kan kolla i multi efter generation etc. Det kan inte dem på

R&D för där kan det vara icke noterade/standardartiklar i bilarna.

Följdfrågor till Fråga 1:

Vilka moment utförs av en kundmottagare?

Hur situationen är för kund och vad kunden upplever tar dem reda på och ställer i

samband med detta kontrollerande frågor. Det är dock oftast erfarenhet som styr hur och

vad man frågar kunden, om vad som är felet.

# Det finns alltså ingen standard för hur man skall gå tillväga som kundmottagare?

Ibland finns standard. Ibland kan kunden beskriva ett ljud, och då kan det vara svårt att ta

över telefon, då kan mekanikern få åka med i fordonet. Mekanikern vill då ofta veta när

problemet utrycker sig, i uppförsbacke, nedförsbacke, vilken hastighet, kurvigt, vid

inbromsning, vid gaspådrag. Det kan vara bra för mekanikern att veta innan den ger sig

ut. Kontextdata. Efter att mekanikern kollat på fordonet kan det vara så att

xxiii

kundmottagaren beställer materialet som behövs för att lösa problemet, men det varierar

vilken roll som beställer material.

Vad är syftet med respektive moment?

Att ha så mycket information när fordonet kommer in, så att inte mekanikern måste

börja felsöka och ställa kontrollfrågorna, utan det finns i arbetsordern när dem börjar

jobba, så att det ska vara snabbt och smidigt och dem vet vad dem ska göra.

#Hur långt brukar man komma i den processen av felsökning, och hur mycket får

mekanikern göra?

Det beror på vad det är för typ av fel, när felen är av enklare typ så kan det vara så att

mekanikern vet direkt vad hen ska göra. Och ibland vid svårare fel kan det behövas

felsökning. Ibland kan det vara att det är mer steg som behöver genomföras, typ

tester, eller att man åtgärdar nått och sen får man börja byta om problemet återstår.

Hur lång tid tar respektive moment uppskattningsvis? (Finns det data på det, vi kan

ta del av?)

Det är minuter det handlar om, kan ta längre tid om material ska beställas.

#Kan man behöva ringa flera personer?

Ja precis. Är det standardartiklar är det ofta lättare, till standardfordon alltså. Men där

kan det ju också ta längre tid om artiklarna måste skickas.

Finns det några moment som skulle kunna undvikas, och i sådana fall vilka och på

vilket sätt? känner du att nått moment kan ta onädigt lång tid?

Nej, all information man kan få är det viktigaste egentligen.

Hur lång tid brukar kontakten med kunden ta?

Beror på, 5-10 minut om det är på telefon eller över disk.

#Frågar man kunden om den är stillastående att kontrollera saker?

Ja absolut, är dem stillaståendes då kan det ju va så att man kan be kunden åtgärda för att

komma till verkstad. Det kan exempelvis vara att återställa och ta bort lampor som tänts

temporärt, för att kund ska kunna komma till verkstad. Ex på åtgärd är detta, om det är ett

lättare fel.

Vad avsätter ni för tid för varje kund? (Så lång tid som behövs, 10 min, finns det ett max,

har ni en planering för det?)

Kan vara från några minuter till flera timmar.

#Men då får det vara så liksom (flera timmar)?

Ja absolut, hamnar man i ett sådant läge får man kanske prioritera eller delegera vidare

till en kollega om det behövs.

Hur hanterar ni oförutsägbara händelser? (t.ex. om problem skulle uppstå, måste ni

planera om eller har ni avsatt tid för sådana händelser?)

Ta kontakt med konstruktörer direkt, specialistmekaniker som är nischade till vissa

komponenter. Till viss del har Scania-verkstäder denna kontakt (Hovsjö eller Lindreten).

Dem andra ringer varandra – dem ringer alltså inte R&D då?

xxiv

#Finns det nått mer man kan göra?

Det finns alltid Scaniaassistansens kundcenter, dem kan säkert slussa vidare till annan

verkstad i Sverige. Eller om fordonet får problem utomlands kan dem hjälpa till att

komma tillverkstad i det landet kunden befinner sig. Men kunskapen kan fortfarande

finnas på fabriken i Södertälje. I dessa fall får verkstad utomlands och fabrik med

högkunskap hjälpa den verkstad kundens fordon är på.

Hur påverkas ditt arbete av kundens förmåga att berätta hens observationer av

problemet? (otillräcklig information, längre tid, vad blir konsekvenserna?)

Det påverkar väldigt mycket, ju mer information kundmottagaren har, ju lättare blir det

att förmedla vidare jobbet, eller kvaliteten på felsökningsjobbet. Vet inte kunden så

mycket av vad som hänt eller vad omständigheterna var när felet uppstod, blir det svårt

för kundmottagaren att göra en initial felsökning.

#Berättar man för kunden vad som är fel om man vet vad felet kan vara?

Ja vet man det så berättar man det. Det är ofta tryggande för kunden att få en

uppskattning av kostnaden och tiden, om man kan ge det.

Hur ser kundens situation ut när ni får kontakt med hen? (Är kunden vid fordonet ,Stressad, blockerar vägen, uppgiven, omtumlad)

Oftast här och nu, saker måste lösas nu. Blir bilen stående förlorar dem sin inkomst. Om

det är service kan man ju ta det längre fram, men annars har det gått sönder vill dem få

det fixat direkt.

#Tror du att kundens situation kan påverka den informationen ni får av kunden?

Absolut, står dem i en stressad situation eller på ett olämpligt ställe, där dem inte kan gå

ut och kontrollera situationen. Då får man gå på det som går att förklara vid tillfället. Sen

eller annars får man åka ut till kunden och ta med sig de delar man tror kan behövas bytas

ut. Och detta tar längre tid.

När anses ett samtal med kund lyckat och när anses det mindre lyckat?

Mindre lyckat när man inte kan hjälpa, eller inte kan ta in dem (ingen plats eller ledig tid

i verkstad), lyckat när man kan lösa problemet. Eller när man kan boka in o säga till

mekanikern vad som ska göras, snabbt och smidigt.

Om du stöter på problem med att hjälpa en kund, kan du ge exempel på vad

problematiken kan grunda sig i? och vad är dem vanligaste orsakerna?(Otillräcklig

information,okunskap från kund?)

Det stora är kunskapsnivå från kund eller kundmottagare, då får man ta hjälp av en

kollega med mer erfarenhet. Även kundens situation påverkar också.

Om du stöter på problem med att hjälpa en kund, vilka åtgärder kan du då ta till? (hjälp

av kollega, hjälp från annan avdelning)

Hoppade över

Från vilka källor använder ni data i erat arbete? (t.ex. DTCer, SOPS-fil), och hur används

dem? (Använder ni exempelvis DTCer från fordonets On Board System, för att minimera

problembilden)

xxv

SOPS-filer och felkods-utläsningar, Programmet Freud (fjärrutläsning), Sen finns även

Multi som ett program (artiklar, instruktioner på hur man byter eller ska gå tillväga)

#Hur länge har fjärrutläsning funnits?

Vet ej, men det börjar bli vanligare, ju nyare fordonsmodell desto större chans att det

finns.

Vad är erat mål med kontakten med kunden i slutändan i ett felsökningsperspektiv? (Är

målet att få kunden till verkstad eller samla nödvändiginformation åt mekanikern)

Självklart lösa problemet. Både två exemplen, d.v.s. kunden till verkstad och samla

nödvändig information. Det beror på situationen, om dem står vid sidan av vägen – kan

dem ta sig hem eller tillverkstad av egen maskin. Eller behövs en bärgare? Kan dem ta

sig till verkstad eller hem fine, efter det får man se om mekanikern kan ta sig dit eller om

man måste bärga. Så absolut båda, ja. Fråga 2:

Vilken typ av data/information erhåller du från kunden?

Oftast det kunden kan förmedla, chassinummer och mätarställning. Kunden kan läsa vad

felkoderna heter – ibland kan chauffören göra det själv eller så kan man vägleda dem. På

så sätt kan man få fram information på distans. Kunden beskriver även observationer dem

upplevt av problemet (Kontext).

Följdfrågor till Fråga 2:

Vilket/vilka kommunikationsmedel används för att erhålla information/data från

kunden? (samtal, app, direktmeddelande, mail)

Det vanligaste är telefon, mejl och FRAS – här. På vanlig verkstad är det telefon, mejl

eller över disk (muntligt) (Fleet management (APP) -FMP är under utveckling, mot

kund).

I vilket format erhålls data/information från kunden (t.ex. muntligt, fritext, förbestämda

val)?

Det är lite olika, fritext och muntlig är det vanligaste.

På vilket/vilka sätt får ni kunden att dela med sig av relevant information?

(knep, ställer ni bara frågor eller förklarar du varför det kan vara just detta fel och hur

det uppstår, för att kunden skall kunna reflektera och komma med mer information om

problemet och eventuellt ge fler symptom om den förstår problemet bättre)

Till viss del kan man hitta i Multi, annars erfarenhet främst. Finns ingen specifik

standardiserad metod för att samla in data från kund.

Hur skiljer sig kvalitén på informationen från kund vid samma typ av fel/fall? (ser du

skillnad i samma typ av fall mellan olika kunder)

Det varierar väldigt mycket, det beror på personligheten på kunden, vissa kan beskriva

problemen mer än andra. Antyder på relation till generation – lite yngre kanske tänker ett

steg längre (mer detaljerad beskrivning), men äldre nämner kort (mindre detaljerat)

Kan du peka på aspekter som gör att kvalitén varierar? (kundens tekniska

kunskap, kundens tydlighet i sin symptombeskrivning, undersöker vissa

kunder problemet själva innan initial kontakt)

Absolut, Kundens tekniska kunskap.

xxvi

Hur hanterar ni situationer när, informationen kunden ger är otillräcklig/ av sämre

karaktär?

Då är det kompletterande frågor. Behövs mer information kan kontakt med kunden

behövas tas igen. Då kan det ställas frågor om: Vart den kan läcka, är det X eller Y? Ge

kunden enklare tester att genomföra om det går. Kunden kan ta bilder ibland. Frågorna

baseras på erfarenhet, inget standardiserat sätt.

Om kundens information inte är tillräcklig, behöver ni då göra egna tolkningar för att

kunna planera servicearbetet? Vad har detta för påverkan på

felsökningsprocessenskvalité?

Absolut, då får man tänka i olika banor, är det X eller Y. Är det här det läcker eller här?

Kan leda till att man tar med fler artiklar om man skickar ut mekaniker till stillastående

kund, för att vara mer säker på rätt artikel som skall bytas är med. Man måste tänka till

när man köper in artiklarna – finns det på hyllan, är det standardartikel, om jag köper in

denna artikel kommer den användas om detta inte löser felet (likvider på hyllan annars).

#Svar på följd frågan kopplad:

Det tar ju längre tid om man får otillräcklig information, Kunden är väldigt beroende av

fordonet, ju längre tid kunden står stilla ju mer pengar förlorar kunden? Man vill bemöta

kundens förväntade tillgänglighet av fordonet.

Vilken typ av data från kunden hade kunnat förbättra erat arbete tror du?

Inte bara erfarenhetsmässigt, utan att ha ett hjälpmedel att använda vid insamling av data

från kunden också, som underlättar kundmottagarens tillit på erfarenhet (speciellt i de fall

där kundmottagaren inte har så mycket erfarenhet). Kundmottagaren är ju oftast bara en

förmedlare mellan kund och mekaniker. Tror att det kan ge träning för en oerfaren

kundmottagare att ha ett teoretiskt stöd.

Vårt arbete handlar som sagt om symptombaserad felsökning, och därför undrar vi hur

arbetet ser ut kring dokumentation av kundsymptom i dagsläget? (Kundsymptom är

egentligen dem observationer kunden har gjort utav systemets reaktioner

på den okända grundorsaken till problemet. Kunden kan även berätta om händelsen och

andra kring liggande faktorer som kan påverka så som väder och vind, men

kundsymptom utmynnas ofta från kundens observation av ett problem och vad som inte är

det nominella beteendet)

Dem jobbar i FRAS (inte vanlig verkstad), deras bas till information och deras sätt att

förmedla information till (mekaniker, fordonsägare, konstruktörer). Men detta finns inte

hos vanlig verkstad. Vet inte hur en vanlig verkstad jobbar. Antagligen någon journal,

genom regg-nummer.

På vilket sätt tror du att dokumentation av kundsymptom skulle kunna integreras i er

befintliga arbetsprocess?

Så att man får lite mer kött på benen, har ett verktyg att gå efter, istället för bara

erfarenhet även mer teoretiskt stöd.

Av den data som samlas in idag, hur sker analysen av data? (sparar du kunddata rakt

av och skickar iväg eller skickar du iväg information som har analyserats, bedömts

och om formaliserats)

Bara analys genom erfarenhet, ingen metod för det.

xxvii

Hade du sätt ett värde i att spara kunddata rakt av, som sedan finns tillgängligt för

mekanikern? Varför, varför inte? (Alltså data som inte är bedömd, omformulerad och

analyserad. Även intressant vad du tror om tillgänglighet av både delarna, analyserad

och icke)

Ja men absolut, speciellt om kunden är säker på sin sak, så kan det ge alternativa vägar att

gå för mekanikern att börja i, till exempel den dem tycker verkar mest rimlig av den

information som finns tillgänglig.

Fråga 3:

Hur dokumenteras data från kunden?

För R&Ds del FRAS (deras arbetsorder) eller mejl.

I vanliga kundmottagares fall i arbetsordern.

Följdfrågor till Fråga 3:

Kan du berätta lite mer om hur konversationen med kunden går till? (ställer du några

standard frågor, Måste du omformulera den information kunden ger dig)

Man frågor ju ofta efter symptom eller avvikelser, vad som har hänt? När uppstår felet?

När uppstod det? Är det något som kvarstår? Har du några varningar (varningslampor)?

Kan du ta dig till verkstad? läcker det mycket? Läcker det vid belastning, hela tiden eller

bara vid vissa varvtal eller hastigheter?

Om det är hårdvara är det ofta bärgning som gäller? Kan vara mer uppenbara fel som

innebär bärgning direkt och grundorsaken är känd från observation från kund direkt. Här

kan det handla om att delegera vart kunden vill, närmaste verkstad, om kunden inte ringer

direkt till den verkstad den vill till. Kan behöva beställa Scania assistans (mekaniker och

bärgare till plats) eller vanlig bärgare, beror på kontrakt med kund.

Vilket program/system använder ni för att dokumentera kunddata?

(Vad heter programmet, Hur fungerar det)

Arbetsorder.

Vilka verktyg använder ni som hjälp för att få in rätt kunddata?

(Använder ni frågeträd, Skriver ni in data i något program och får tillbaka respons i

form av fler frågor mot kund etc..)

Erfarenhet och MULTI.

Hur utnyttjas data från kunden vid planering av andra servicearbeten?

Alla fordon är individer, hon hoppas att dem flesta kundmottagaren gör egna

anteckningar kring dem enskilda fordonen, för att hjälpa kunden så gott dem kan

(historik om fordonet, vart går detta fordon, mätarställning, senast service, vad är bytt

inte bytt, etc.). Anteckningarna görs inte på ett standardiserat sätt förmodligen.

Vilken data anser du hade varit bra att kunna använda vid planering av andra

servicearbeten som inte används idag? (Vägförhållanden, mer information om

händelseförloppet vid observationen av problemet)

Inget svar, kommer inte på just nu.

#Vet du om man sparar vägförhållanden eller annan information från kund?

Vid felbeskrivning hoppas jag att det sparas på vanliga verkstäder. För det kan

hjälpa till att avgöra vad som är fel på fordonet.

Fråga 4:

Till vem och vart skickar ni den insamlade informationen? (när ert arbete är avklarat)

xxviii

Här berättar hon först om R&D. I vanliga fall mekaniker sen vid avklarat arbete till

kunden/företaget. Då är det den information kunden/föraren angav till kundmottagaren

och sedan skrevs ner på arbetsorder som företaget också får vid avslutat arbete.

Följdfrågor till Fråga 4:

På vilket sätt för ni vidare all data?

(Genom ett dokument, verbalkontakt)

Mejl och system, Fras i deras fall.

I vanliga fall arbetsorderssystem (XX) och muntligt.

Hur förbereds data innan ni skickar den vidare?

(Skriver ni data i dokument som skickas till mottagare eller är det någon typ av

online baserat dokument som delas genom ett system)

Man kan beställa delar, sen vid kompletterande info (ringa upp). Ibland blir det

tolkningen som man skickar vidare, ibland vet man även direkt veta vad det är för fel.

Kundmottagarens tolkning på felet man skickar till mekanikern.

Om ni förbereder data, hur lång tid brukar det ta?

(kan det ske simultant i kontakt med kund, eller finslipar man data nått efter kontakt

med kund är avslutad)

Direkt till någon timme om man behöver ta hjälp.

Vilken data skickar ni vidare?

(Menat av den data du samlar in, är det någon data du inte skickar vidare som du

samlar in och vad händer i så fall med denna data, sparas eller raderas den)

Det kunden har sagt.

Fråga 5:

Hur hanteras lärdomar/erfarenheter efter lyckat servicearbete?

Eventuellt egna anteckningar hos verkstad av kundernas specifika fordon, och datan är då

från kundmottagarens sida. Detta så att verkstad kan förmedla sin egna kunskap mot

kunden om fordonet.

Följdfrågor till Fråga 5:

Vilken typ av data gällande lärdomar/erfarenheter anser du hade varit fördelaktig att

spara för att underlätta ditt arbete och mekanikerns arbete?

Det är om man kan få fram liknande case, information om vad man har gjort för tidigare

åtgärder på fordonet. Det är ofta det en kundmottagare går på (erfarenhet! har jag stött på

detta innan?).

Om lärdomar/erfarenheter dokumenteras, hur används denna data i ditt arbete?

För att se trender på olika typer av fel, okej nu har vi bytt 10 st såna här! Har det då gjorts

på samma typ av fordon, har dem liknande specar (delar). Här kan det ju vara att man ser

en trend som kanske grundar sig i ett konstruktionsfel också. Med sådan information kan

man förebygga byten av artiklar . Det här är nog även observationer man gör

undermedvetet, man blir påmind hela tiden när man ser det. Det är nog inte säkert att man

gör en faktiskt dokumentering av sådan data utan den sker nog i huvudet som nämnt

innan.

Hur jobbar ni med återkoppling?

Något dem jobbar med varje dag, byta erfarenheter med varandra. Man återkopplar även

ganska grundligt till kundföretaget (Vi bytte detta etc.), sen berättar man även för

xxix

kunden/föraren vad som är bytt. Muntlig utbyte av erfarenheter i vanlig kundmottagare.

Hur och med vem återkopplar ni? (med mekaniker, kund)

Förare, kundföretag och kollegor. -Muntligt

Vad kan det handla om?

Erfarenheter och åtgärder som gjorts på fordonet, samt ifall man gjort övriga

noteringar under servicearbetet som mekaniker, ex denna kommer behöva bytas om

ett tag , börjar bli sliten.

Vad är din uppfattning om mekanikerns nytta av informationen ni

skickar? (Förstårmekanikern informationen ni skickar fullt ut? Finns det

förbättringsmöjligheter i förtydligandet av informationen mot mekanikern?)

Väldigt viktigt, annars får dem börja felsöka. Kunden vill få ut sitt fordon så fort som

möjligt, därför ju fortare mekanikern kan jobba desto snabbare går det.

Övriga tankar och funderingar?

Nej inget att tillägga.

Respondent 4:

Målgrupp: Mekaniker

Fråga 1:

Vad innebär mekanikerns roll i felsökningsprocessen?

Det är väl olika – man får ett beskrivet symptom, man tar in bilen, ta ut felkoder, titta och

känna. Följdfrågor till Fråga 1:

Vilka steg/processer utför en mekaniker innan dess hen börjar felsöka fordonet?

Först försöker man ta in information om vad som skedde just vid tillfället felet uppstod – vad

var körfallet? Var det brant backe? Inbromsning? Alltså informationsinsamling. Därefter får

man läsa ut felkoder.

Vart börjar din kontakt med service/reparationsuppdraget?

I vissa fall kontaktar kund direkt, eller via kundmottagare. I vanliga verkstäder är det från

kundmottagaren.

Hur fungerar planering för reperationsuppdrag?

Beror på om det är ett uppdrag som är inplanerat eller måste fixas nu. Vet man redan innan

vad felet är – då beställer man delar. Det fungerar lite olika i olika verkstäder. Om det

kommer in en så kallad VOR (akutjobb) – då måste man oftast kolla bilen först, vad är felet?

Sedan beställer man delar.

Vem erhåller dig med informationen om uppdraget? (Du själv, kollega, enkundmottagare på

verkstad, kundmottagare utom verkstaden, chef)

Oftast är det kundmottagaren, ibland får man dock prata direkt med kunden om de har en bra

beskrivning. Detta för att man inte ska förlora information på vägen.

# Sker det så även i vanliga fall?

xxx

Ja, det tror jag. Framförallt om det är akuta jobb. Kundmottagaren sitter inte alltid på samma

kunskap som mekanikern, så då får mekanikern prata med kunden.

Vart kommer informationen ifrån? (Kund, kundmottagare)

-

När får du information om uppdraget eller när finns den tillgänglig? (När fordonet kommer

till plats, innan dess fordonet kommer till plats)

Det är olika vid olika typer av uppdrag. Ibland kunde vi veta månader i förväg men oftast 1-2

veckor innan.

I vilka typ av uppdrag förekommer insamlad information om ett uppdrag som har gått

genom en kundmottagare? (serviceuppdrag, akut-reparationsuppdrag, underhåll)

I de flesta. När det är kampanjer (när man återkallar en bil för att man har sett ett fel som ska

åtgärdas på alla bilar) är det inte kund.

Av 10 fall hur ofta förekommer information om uppdraget? Och i vilka typer av uppdrag är

det?

10/10, så länge uppdraget kommer från kund.

Hur ofta av 10 fall kommer det in kunder till verkstad utan att ha gått igenom en

kundmottagare först?

Alltid först in till kundmottagare. När kontakt sker med mekanikern direkt, så ringer kunden

verkstaden och sen ger kundmottagaren över telefonen till mekaniken.

Hur fungerar planeringen i de fallen? (Vem tar emot kund , samlar in information, och

planerar arbetet, utförs en initialfelsökning då?)

-

När ett uppdrag är inplanerat, hur lång tid passerar innan ni utför reparation/servicen?

Det kan vara allt från 1 dag till 1.5/2 månader (beror på omständigheterna).

Finns det uppdrag som prioriteras? (akuta-uppdrag, alvarligare problem, när fordonet inte

kan brukas)

Det beror på verkstaden, men oftast så har man någon möjlighet att ta in akuta jobb.

# Brukar man planera in för att kunna ta emot sådana jobb?

Ja, exempelvis så har vi en resurs som bara tar akuta fall. Det är dock på labbilen (inte vanlig

verkstad).

Fråga 2:

Hur tar du del av information om uppdraget? (Genom ett speciellt program, mail)

Det har varit lite olika. I mindre verkstäder – möten med kundmottagaren, får en papperslapp

i handen. I större företag – i datasystem (inte Scaniaverkstad).

# Skulle du säga att det likadant på vanliga Scania-verkstäder?

Vet inte.

Följdfrågor till fråga 2:

Hur presenteras informationen för dig? (fritext, check-boxar)

Det jag har varit med om är fasta mallar, med fält och check-boxar där man kan fylla i. Sedan

har det även varit i fritext (inte vanlig verkstad).

xxxi

Vad är det för data? (Symptom, DTCer, beskrivning av händelseförloppet, vägförhållanden)

Det kan vara allt möjligt, symptom, felkoder, artikellistor – det här kommer troligtvis behöva

bytas.

Varierar användbarheten och detaljrikedomen på de olika data inom uppdragen? På vilket

sätt? (Är det någon information som sticker ut i sin användbarhet, för att lösa problemet,

någon information du inte använder i ditt felsökande men som finns med)

Om jag tycker informationen är bristfällig, då ställer jag frågor till kundmottagaren – har vi

någon mer information? Eller nämner frågor som kundmottagaren kan ställa kunden genom

att ringa upp. Denna process blir oftast snabbare än att man skulle påbörja felsökningen med

bristfällig information. Det är bättre om man får specifika situationer kring felet.

Varierar användbarheten och detaljrikedomen på informationen från fall till fall? På vilket

sätt? Varför?

Ja, beror helt på vem kunden är och vilken kundmottagare som tar emot kunden.

Ser du några förbättringsmöjligheter med den information som idag finns tillgänglig, i

samband med ett uppdrag? (presentationen , data i säg otydlig, vilken?, Återkoppling vid

otydlig data, kan du ibland känna ”om jag viste detta hade jag kunnat lösa problemet”)

Desto mer information, desto bättre. Standardiserade frågor.

Vet du vad kundmottagaren som samlat in information om uppdraget, gjort med

informationen? (har den börjat en initialfelsökningsprocess så du iallafall vet att det är nått i

motorn eller med tändningen som är fel)

Beror på. Vissa kundmottagare gör egna snabbanalyser, och vissa andra skriver i princip ned

vad de fick från kunden.

Hur långt gången är felsökningsprocessen när du tillhandahåller uppdraget? (Vet du vilket

system problemet ligger i, eller vet exakt vilken del felet ligger i)

Ibland är det ju redan klart, de har en teori baserad på en felkod, ibland är det – bilen startar

inte.

Händer det att ni inte behöver felsöka fordonet?

Ja.

Ifall, hur ofta av 10 fall?

1/10.

Och varför? (För att ni vet av erfarenhet vad felet är? för att felet är så passspecifikt, för att

den initiala felsökningsprocessen redan är så långt gången)

Felet är så pass uppenbart

Fråga 3:

Hur arbetar ni med kundsymptom i dagsläget? (urskiljer kundsymptom av fel beskrivning från

kundmottagare, ringer upp kunden ibland och frågar lite, när kund kommer förbiverkstad)

Ja det är alltid viktigt vad kunden har sagt, vad kunden har upplevt. Det kan alltid ge en

fingervisning. Följdfrågor till fråga 3:

Att integrera kundsymptom i eran felsökningsprocess och program på daglig basis, hur tror

du att det hade kunnat hjälpt din vardagliga verksamhet? (på ett mer standardiserat sätt, den

xxxii

kunskapen ni har idag om kundsymptom finns även i felsökningsprogrammen, ex statistisk

data som ni annars bara tar förgivet ”denna delen går ofta sönder så kollar den först”)

Vi har alltid strävat efter att göra det. Jag tror det är viktigt att inte bara stirra ner sig på

felkoder, för det kan vara missvisande. Som sagt, ta in körfall - vad hände? Hur upplevdes

det? Vad det något som skakade eller vibrerade?

Vad tror du är viktigt att ta i åtanke vid skapandet av ett sådant felsökningssystem? (Nån

tanke kring data, användningen, presentationen av data)

Svårt att säga, ge så mycket information som möjligt.

# Kan det vara något med att t.ex. inte att det får vara för svårt för kunden?

Det ska alltid vara lätt, man kan inte ställa krav på kunden att den t.ex. vet hur motorn funkar.

Det hade varit till stor hjälp om kunden kunde berätta om körfall – hur fordonet har betett sig

på den senaste tiden. Fråga 4:

Kan du gå igenom de olika processerna/momenten du genomför i ett uppdrag från början till

slut? (Det kan vara ett exempel på ett uppdrag, vilka process/moment är generella som du

alltid genomför)

Det första är att man får information, går igenom och kollar, kollar på felkoder – antigen har

en felkodsutläsning redan gjorts innan eller så får man göra utläsningen själv, tar in fordonet,

tittar vad man kan se själv kopplat till felkoderna, undersöker hur långt fordonet har gått.

Sedan börjar felsökningen – vilka delar är det som kan vara inblandade? Vad är det för

känsliga delar? Vad skulle kunna vara felet? Sedan åtgärdar man felet och testar genom t.ex.

att provköra fordonet för att se att man åtgärdat felet. Sedan går man även igenom och kollar i

en checklista om man fått med allt, rapporterar att den är klar, och tillslut lämna fordonet till

kund.

Kan du säga nått om tiden för varje moment?

På verkstäder använder man SDP3 och när man gör en felkodsutläsning tar det ca 10-20

minuter. Tar väll i snitt 3-5 minuter att koppla upp sig med bilen när man använder SDP3. 10

– 15 minuter brukar det ta att förstå uppdraget, det vill säga vad som ska göras. En

provkörning tar ca 15 minuter beroende på vad det var för fel.

Ser du att något moment som utför idag är onödigt? Varför?

Det som är ett onödigt moment är när man måste gå till en kundmottagare om man fått för lite

information. Då måste kundmottagaren ringa upp kunden och därefter meddela mekanikern,

detta är onödig tid.

# Något övrigt?

Nej.

Respondent 5:

Målgrupp: Kundmottagare

Fråga 1:

Vilken roll har kundmottagaren i den initiala felsökningsprocessen av tunga fordon?

En stor roll, kundmottagaren är första kontakten, telefon-samtal eller över disk.

xxxiii

Både erfarenhet och rutin spelar stor roll, för då kan kundmottagaren snabbt avgöra hur

lång tid ett fel kan ta att åtgärda, samt att kundmottagaren då också kan ange en passande

tid för kunden att komma in med fordonet som passar verkstad (bra planering)?

Om kundmottagare inte kan avgöra kan dem ofta höra med en erfaren person vad den tror

det kommer ta (ofta verkmästaren-Chef över mekanikern) hen jobbar tätt

med kundmottagaren och har mer rutin på allt.

Följdfrågor till Fråga 1:

Vilka moment utförs av en kundmottagare?

Ta emot kund över samtal eller över disk, första intrycket, tidsbokning och tidsplanering

över verkstadens övergripande tidsplanering har kundmottagaren ansvar för.

Vad är syftet med respektive moment?

Dels ansiktet utåt för verkstaden, lyssna, förstå och hantera kundens klagomål eller

generella behov. Planera in tiden med kundens och hens behov på verkstaden och få det

att klaffa med verkstadens schema och kundens schema, måste ha bra känsla

(tidskrävande kan det vara).

Hur lång tid tar respektive moment uppskattningsvis? (Finns det data på det, vi kan

ta del av?)

Ett samtal och bokning av tid ska flyta på, inte för lång tid, 5-10 minuter, det ska inte

ta mer tid egentligen. Men ibland kan man fråga om man kan ringa upp igen, om det

är pyssligt att få ihop tiderna. Det kan även vara fakturafrågor, sådana frågor kan ta

längre tid.

Finns det några moment som skulle kunna undvikas, och i sådana fall vilka och på

vilket sätt?

Se vad som är fel direkt genom trådlös felsökning, detta är dock inte helt på snurr

generellt i alla verkstäder men är på G – och det super bra att kunna göra sådana

avläsningar och få felkoder direkt. Det kommer då underlätta för kundmottagaren vid

tidsplanering.

I dagens läge kan man istället behöva ta in bilen för bara en felsökning, och sen kan

kunden behöva komma tillbaka för att tiden inte räckte till för att åtgärda felet. Eller

att delar behöver beställas och det gör att kunden måste återkomma en annan dag/tid.

Hur lång tid brukar kontakten med kunden ta?

Svarar på innan hoppar över.

Vad avsätter ni för tid för varje kund? (Så lång tid som behövs, 10 min, finns det ett

max, har ni en planering för det?)

Beror på, vågar inte svara på. Så mycket tid det krävs för varje kund.

Hur hanterar ni oförutsägbara händelser? (t.ex. om problem skulle uppstå, måste ni

planera om eller har ni avsatt tid för sådana händelser?)

Beroende på verkstaden, oförutsägbara händelser kan vara planerat en dag, en annan

dag kan det va att det inte finns tid för oplanerade händelser (pga tight schema)? Då

kan man behöva omplanera. Om det är verkstadens fel går man ofta vidare enligt

”Good Will”, att verkstaden bjuder på den tid eller ting som gick sönder vid arbetet.

Konsensus ju tightare schema på verkstad ju svårare att hantera oförutsägbara

problem.

xxxiv

Hur påverkas ditt arbete av kundens förmåga att berätta hens observationer av

problemet? (otillräcklig information, längre tid, vad blir konsekvenserna?)

Jättemycket, om kunden verkligen kan beskriva vad som är fel, så hjälper det

kundmottagarens förmåga att avgöra tiden och kostnaden för arbetet, vilket grundar

sig i att kundmottagaren också kan avgöra vad det är för fel.

Hur ser kundens situation ut när ni får kontakt med hen? (Är kunden vid fordonet,

Stressad, blockerar vägen, uppgiven, omtumlad)

Alla kunder vill bli behandlade som nummer 1, oavsett storlek på flottan av bilar. Dels få

den uppmärksamhet som kunden anser sig behöva. Om kunden är vid sidan av vägen

finns Scania assistans som man kan skicka ut, det kan vara lugnande för kunden. Scania

har flera såna sätt för att kunna hjälpa kunden fort, eftersom det ändå är kundens levebröd

som påverkas om hen står stilla? Från egen erfarenhet påpekas att Scaniakunder är mer

krävande än vanliga personbilskunder på andra verkstäder, då Scaniakunderna påverkas

av att deras business går sämre om dem står stilla. Beror även på kontraktens

överenskommelse, Scaniakund kan ev kräva ganska mycket.

När anses ett samtal med kund lyckat och när anses det mindre lyckat?

Alla kunder som inte är arga, sura etc är lyckade kunder. Så länge servicen

,tillgängligheten och kostnaden inte blir jättedyr är dem ofta nöjda. För oss är det när vi

har hjälpt kunden inom ramarna, inte bjuda på massa saker, att vi på verkstad tjänar

pengar och kunden är nöjd då är det lyckat.

Om du stöter på problem med att hjälpa en kund, kan du ge exempel på vad problemet

kan grunda sig i? och vad är dem vanligaste orsakerna?(Otillräcklig information,

okunskap från kund?)

Om kunden är dålig på att förklara vad som är problemet med fordonet i allmänhet, sen

kan det även uppstå språk-brister i kommunikationen som ställer till det?

Skulle det bli problem på verkstaden med nått, har man inte mer alternativ än att försöka

lösa det med kunden.

Om du stöter på problem med att hjälpa en kund, vilka åtgärder kan du då ta till? (hjälp

av kollega, hjälp från annan avdelning)

Telefonsamtal – Be kunden att komma till verkstad, för att undersöka mer – kan ex göra

felsökning på parkering, om inte går att göra trådlösfelsökning. Kan göra en snabb

provkörning, men mycket hänger på att få bilen till plats, då det inte går att göra så

mycket om inte bilen är på plats.

#Vad händer om assistans kommer och hämtar bilen men kunden inte följer med tillbaka

till verkstad och man inte kunnat prata med kunden? Blir det svårt att veta vad som hänt

då?

Oftast kan man se med hjälp av felkoder vad som är fel. Men assistanskåren är oftast

väldigt duktiga mekaniker, dem gör även arbetsorder och tar info från kund – vilket gör

att det inte spelar någon större roll om kunden är med eller inte. Assistanskåren kan även

lösa felet på plats, vilket gör att bilen inte kommer in i dessa fall till verkstad utan

problemet är då löst.

Från vilka källor använder ni data i erat arbete (t.ex. DTCer, SOPS-fil), och hur används

dem? (Använder ni exempelvis DTCer från fordonets On Board System, för att minimera

problembilden)

xxxv

Felsökning med programmet SDP3 (felkoder). Symptom när kund kan förklara, lyssna

och känna (sinnen). Chassinummer – ser i multi, all teknisk information (vad är det för

bil, vad har den för påbyggnad av komponenter/system, historik på verkstad-

ombyggnationer, servicehistorik mm). Registreringsnummer med assistans (blir samma

sak som med chassinummer, kundmottagare kan inte använda registreringsnummer)?

Vad är erat mål med kontakten med kunden i slutändan i ett felsökningsperspektiv?

(Är målet att få kunden till verkstad eller samla nödvändiginformation åt mekanikern)

Att kunden ska ut och köra så snabbt som möjligt, Så lite tid på verkstad som möjligt –

”så lite kontakt med kunden som möjligt”. Vid oplanerade stopp ska gå det fort.

Fråga 2:

Vilken typ av data/information erhåller du från kunden?

-

Följdfrågor till Fråga 2:

Vilket/vilka kommunikationsmedel används för att erhålla information/data från

kunden? (samtal, app, direktmeddelande, mail)

Direktkontakt nummer 1 – samtal och face to face, sen kommer det säkert mer o mer med

mejlande och app.

I vilket format erhålls data/information från kunden (t.ex. muntligt, fritext, förbestämda

val)?

Muntligt.

På vilket/vilka sätt får ni kunden att dela med sig av relevant information?

(knep, ställer ni bara frågor eller förklarar du varför det kan vara just detta fel och hur

det uppstår, för att kunden skall kunna reflektera och komma med mer information om

problemet och eventuellt ge fler symptom om den förstår problemet bättre)

Ställa frågor, lite upp till var och en som kundmottagare, när han förklarade…

Vet inte om det finns standarder, tror inte. Fortsätt fråga, tills man får tillräckligt med info

som behövs eller som kunden är kapabel att ge!

Skiljer sig kvalitén på informationen från kund vid liknande fel/fall? (ser du skillnad i

samma typ av fall mellan olika kunder)

Absolut, det beror på hur kunnig kunden är och hur kunden är själv som person (vilja att

berätta vad som hänt). Det kan skilja sig mellan natt och dag från kund till kund.

#Hur påverkar det processen?

Det är större risk att det tar längre tid om man har en kund som inte är

teknisk. Misskommunikation kan det blir mer allvarliga konsekvenser, beställa helt

fel komponenter/artiklar – planerar fel tid – måste planera om- flera kunder blir

påverkade.

- Kan du peka på aspekter som gör att kvalitén varierar?

(kundens tekniska kunskap, kundens tydlighet i sin symptombeskrivning, undersöker

visa kunder problemet själva innan initial kontakt)

Hoppade över, redan besvarat.

Hur hanterar ni situationer när, informationen kunden ger är otillräcklig/ av sämre

karaktär?

xxxvi

Tillslut har man inget val än att be kunden att komma in. Vi måste göra en ordentlig

felsökning på ditt fordon.

Om kundens information inte är tillräcklig, behöver ni då göra egna tolkningar för att

kunna planera servicearbetet? Vad har detta för påverkan på felsökningsprocessens

kvalité?

Absolut, det händer nog. Säkerligen när det är utländska kunder (Misskommunikation)

med vissa termer, då kan det nog chansas lite.

Vilken typ av data från kunden hade kunnat förbättra ert arbete tror du?

Få ut felkoder direkt (fjärravläsning), sen kan det vara hårdvarufel där inte felkoder finns,

då är det svårt.

Vårt arbete handlar som sagt om symptombaserad felsökning, och därför undrar vi hur

arbetet ser ut kring dokumentation av kundsymptom i dagsläget? (Kundsymptom är

egentligen dem observationer kunden har gjort utav systemets reaktioner på den okända

grundorsaken till problemet. Kunden kan även berätta om händelsen och andra kring

liggande faktorer som kan påverka så som väder och vind, men kundsymptom utmynnas

ofta från kundens observation av ett problem och vad som inte är det nominella

beteendet)

Kundmottagaren går nog mycket på minne och känsla, Mycket erfarenhet. Tror inte man

skriver ner specifikt symptom, utan det sker i huvudet på både kundmottagare och

mekaniker.

På vilket sätt tror du att dokumentation av kundsymptom skulle kunna integreras i er

befintliga arbetsprocess?

Vet inte om och hur man skulle kunna använda symptombeskrivningarna.

Av den data som samlas in idag, hur sker analysen av datan? (sparar du kunddata rakt

av och skickar iväg eller skickar du iväg information som har analyserats, bedömts och

om formaliserats)

Upp till var och en tror han, erfarenhet och den mänskliga faktorn – alla jobbar olika.

Hade du sätt ett värde i att spara kunddata rakt av, som sedan finns tillgängligt för

mekanikern? Varför, varför inte? (Alltså data som inte är bedömd, omformulerad och

analyserad. Även intressant vad du tror om tillgänglighet av både delarna, analyserad

och icke)

Ja, absolut. Kompetenshöjande och lärorikt för kundmottagaren och mekaniker. Då skulle

man kunna göra utvärderingar, statistisk. Datans användning är nog väldigt

personberoende, men det skulle kunna ge en alternativ väg för mekanikern i slutändan att

kunna jämföra både den bedömda datan från kundmottagare och den rena datan från

kunden.

Fråga 3:

Hur dokumenteras data från kunden?

I många fall hamnar det i arbetsordern, det borde göra det iallafall. Kanske inte rent av

det som kunden säger, utan med en viss bedömning. Både på papper och data skrivs

denna information ned.

Följdfrågor till Fråga 3:

Kan du berätta lite mer om hur konversationen med kunden går till? (ställer du några

standard frågor, Måste du omformulera den information kunden ger dig)

xxxvii

Beror på vilket fel, och symptomen på fordonet. Det kan vara att en lampa lyser så att

dem vet vad felet är, man vet att man behöver gör X och Y och det tar denna tid, vilket

förmedlas till kunden. Beror verkligen på vad kunden anger för symptom (vilket fel det

är), men man ställer motfrågor iallafall. Nämns görs att där kan vara stor skillnad i hur

problemen beskrivs-vilket i sin tur påverkar hur konversationen utvecklar sig med

kunden. Ju bättre kunden kan sitt fordon ju snabbare går samtalet (generellt).

Vilket program/system använder ni för att dokumentera kunddata? (Vad heter

programmet, Hur fungerar det)

Automaster, tror det är det största och vanligast använda.

Vilka verktyg använder ni som hjälp för att få in rätt kunddata? (Använder ni frågeträd,

Skriver ni in data i något program och får tillbaka respons i form av fler frågor mot kund

etc..)

Multi, SDP3 och Automaster.

Automaster – Historik om bilen och kunden, arbetsorder.

Multi – Teknisk data, specifikationer etc.

SDP3 – Felsökning.

Hur utnyttjas data från kunden vid planering av andra servicearbeten?

Skulle kunna vara Automaster, men vet inte hur mycket man skriver kring ett case, beror

nog på personen i ansvar för fallet/problemet med fordonet. Inte helt säker. Skriver mer

konkret, det här är gjort, allt runt omkring. Inte direkt en specifik förklaring till fallet för

fordonet.

Vilken data anser du hade varit bra att kunna använda vid planering av andra

servicearbeten som inte används idag? (Vägförhållanden, mer information om

händelseförloppet vid observationen av problemet)

Nu kan vi spara ner och se väldigt mycket - felkoder, historik (vad har vart fel tidigare).

Att kunna få fram varför specifika problem inträffar på fordon skulle vara fantastiskt att

kunna se (det här händer på grund av XX).

#Hur ofta vet man vad det var som gjorde att det blev fel?

Nej, det vet jag inte. Det jag kan säga är att vi kan in house se mer vad som händer i

styrenheterna (ECU) än vad dem kan se ute på verkstäder. Det är om den datan skulle

kunna vara användbar.

Fråga 4:

Till vem och vart skickar ni den insamlade informationen? (när ert arbete är avklarat)

Inte helt säker på datavägarna som existerar idag! Först och främst mekaniker. Han vet

att data skickas vidare förbi mekaniker men inte hur ledet ser ut.

Följdfrågor till Fråga 4:

På vilket sätt för ni vidare all data? (Genom ett dokument, verbalkontakt)

Via olika plattformar. Men han kan inte dem personligen

Hur förbereds data innan ni skickar den vidare? (Skriver ni data i dokument som skickas

till mottagare eller är det någon typ av online baserat dokument som delas genom ett

system)

Genom tolkning av symptom. Sen sparas annan data som mätarställning och historik på

annat sätt. Data från kunden går till mekanikern (lokal), data om fordonet skickas vidare

xxxviii

inom Scania (bränsleförbrukning, kraft grafer etc.). Från kommunikator i bilen skickas

data vidare till Scania. Föraren kan även själv se denna datan. Det är någon plattform

detta sker igenom men han glömde namnet på den.

Om ni förbereder data, hur lång tid brukar det ta? (kan det ske simultant i kontakt med

kund, eller finslipar man data nått efter kontakt med kund är avslutad)

Redan svarat

Vilken data skickar ni vidare? (Menat av den data du samlar in, är det någon data du inte

skickar vidare som du samlar in och vad händer i så fall med denna data, sparas eller

raderas den)

Redan svarat

Fråga 5:

Hur hanteras lärdomar/erfarenheter efter lyckat servicearbete?

-

Följdfrågor till Fråga 5:

Vilken typ av data gällande lärdomar/erfarenheter anser du hade varit fördelaktig att

spara för att underlätta ditt arbete och mekanikerns arbete?

Redan svarat

Om lärdomar/erfarenheter dokumenteras, hur används denna data i ditt arbete?

Redan svarat

Hur jobbar ni med återkoppling?

Beror på verkstäderna, han hoppas att dem har en bra dialog mellan parter på verkstad.

Ger exempel på, bokar du in en för kort tid som kundmottagare mot mekaniker kan ju

mekanikern bli missnöjd.

Med vem återkopplar ni? (med mekaniker, kund)

Mekaniker, verkmästare, platschef, reservdelsman. Ren återkopplingen till kunden görs

inte? Bara på plats när arbetet är klart om vad som är gjort på bilen, inte i efterhand.

# Gör mekanikern tillägg av information om hur vissa delar mår och kanske behöver

bytas i närmare framtid?

Hittar man något mer ska man informera (mekaniker, gör då detta, på arbetsordern). Så

den typen av återkoppling finns ju.

Vad kan det handla om?

Ja det beror på vad man gjort på bilen. Men information vad som är gjort till kund.

Och återkoppling mellan kollegor sker nog sporadiskt och lite varje dag. Ev, vissa

som har möten där det sker återkoppling.

Vad är din uppfattning om mekanikerns nytta av informationen ni skickar? (Förstår

mekanikern informationen ni skickar fullt ut? Finns det förbättringsmöjligheter i

förtydligandet av informationen mot mekanikern?)

Det är A och O, viktigt att det är bra information från kundmottagare till mekaniker.

Speciellt om det inte är gjord någon felsökning innan av felkoder (fjärr), då är det den

enda infon mekanikern har att börja med innan den startar uppdraget, alltså

kundmottagarens inhämtade information om felet från kund.

xxxix

#Vad är din uppfattning om hur den relationen mellan kundmottagare och mekaniker i

allmänhet funkar?

I vissa fall från egen erfarenhet kunde det vara så att en kundmottagare kanske inte hade

jättebra erfarenhet. Men där fanns också en verkmästare nära tillhands som kunde ge stöd

åt både mekaniker och kundmottagare då det behövdes.

Övrigt? Nått vi glömt? eller inte nämnt som du vill diskutera?

Nej, men jag måste nog själv åka ut och uppdatera mig lite.

Respondent 6:

Målgrupp: Mekaniker

Fråga 1:

Vad innebär mekanikerns roll i felsökningsprocessen?

Innebär att få en helhetsbild utifrån vad kunden har uppfattat, utifrån symptomen fordonet

har och detta genom utläsning av felkoder, erfarenhet (dem äldre gör detta mycket).

På verkstäder har man ofta olika roller, några som är duktig på elsystem, drivlina etc. Den

enskilda mekanikern jobbar sedan tvärfunktionellt med alla dessa kompetenser som finns

tillgängliga. Man har delat upp, spetskompetens inom flera områden. I det slutliga skedet

är det en grupp som jobbar tillsammans och inte enskilda mekaniker (hjälper varandra,

mekaniker emellan).

#Kan du säg något mer specifikt om felsökningsprocessen vad dem gör där?

Komplexa produkter i dagens läge, därför använder man felsökningsverktygen mycket–

Då bygger det mycket på att läsa ut och försöka förstå innehållet i

felsökningsbeskrivningen, det är inte alltid lätt då man måste hoppa mellan olika system,

t.ex. multi – SDP3, för att förstå problemet? Om det är hårdvara måste man ha förståelse

om t.ex. hur motorn fungerar? I dessa fall får man använda sig av sina kollegor med

spetskompetens, som nämnt innan. Detta gör att mycket av tillvägagångssättet baseras på

erfarenhet, vad man upplevt förut, och utgår ifrån det.

Följdfrågor till Fråga 1:

Vilka steg/processer utför en mekaniker innan dess hen börjar felsöka fordonet?

På verkstäder har man arbetsordern som ett sätt för att börja få information, nästa steg gå

till kundmottagaren och lyssna vad dem har fått för input gällande problemet, och det är

så allt startar egentligen. Sen blir nästa steg att undersöka om man har förutsättningen för

att genomföra felsökningen, t.ex. har vi rätta verktyg (alla verkstäder har inte alla

verktyg), beror på marknaden i regionen. Det kan komma in ett utländskt fordon…? Har

man de reservdelar som behövs för att utföra åtgärden?

Vart börjar din kontakt med service/reparationsuppdraget?

Redan sagt ovan

Hur fungerar planering för reperationsuppdrag som mekaniker?

Är det ett självklart fall, så är planeringen att man konstaterat att man genomfört en

diagnostik och använt dem verktyg man har för att genomföra den diagnostiken. Sedan

blir nästa steg att beställa material, och få en uppfattning om när materialet är hemma.

För detta tas ofta hjälp från en reservdelsberedare på verkstaden (specifik roll)? Ibland tar

xl

man inte ens in fordonet, utan man konstatarer genom diagnostik och erfarenheter, vad

som är felet – beställer material och sen planerar in ett tillfälle för åtgärden.

Sen beror det på felet också, ibland kan kunden fortsätta köra med ett mindre allvarligt

fel, och ibland är det driftstopp för kunden vid alvarligare fel?

Vem erhåller dig med informationen om uppdraget? (Du själv, kollega, en

kundmottagare på verkstad, kundmottagare utom verkstaden, chef)

Kundmottagning, och till viss del verkmästare (verkmästare brukar ha koll på dem

inkommande jobben) dem förmedlar ofta information till mekaniker.

#Kan det bli att en mekaniker har kontakt med kunden också?

Ja det kan hända. Det skiljer sig beroende på verkstaden. I vissa verkstäder får kunden

komma in, och vara med under felsökningen – där kan dem då föra en dialog under

felsökningen (fråga frågor). Medans på andra verkstäder får inte kunden komma in på

verkstadsgolvet (bara i mottagningen) – inte så utbrett i Sverige att kunden inte får

komma in i verkstad. Däremot i Spanien är det mer vanligt att den regeln infinner sig.

#Varför kan det vara så att kunden inte får komma in i verkstad och ”hjälpa till”?

Det är nog främst av arbetsmiljöaspekt, varför man inte låter kunden komma in till

verkstaden. Om det skulle hända något ligger det på arbetschefen, och i dessa fall vill

man undvika att olyckor händer på deras ansvar, då det finns med att vistas i en

verkstad.

Samtidigt struntar många verkstäder i arbetsmiljöaspekten. Och försöker förhålla sig

mer till vad kunden vill, och det kan innebära att vara med under felsökningen.

Speciellt kan detta vara vanligt med en stor kund, där man är rädd att förlora kunden

om verkstaden inte gör som kunden vill - Detta kan leda till att man prioriterar större

kunder på verkstäder. Så i dagens läge står kunden väldigt ofta med mekanikerna o

berättar om felet – i Sverige?

Vart kommer informationen ifrån? (Kund, kundmottagare)

Från grund och botten, från föraren till största del. Om inte kunden har ringt till

helpdesk eller Scaniaverkstaden och bett om en förebyggande diagnos genom

fjärrutläsning av DTCer. Men vanligast är det fortfarande kundinformationen som

man fått.

När får du information om uppdraget eller när finns den tillgänglig? (När fordonet

kommer till plats, innan dess fordonet kommer till plats)

I dem flesta fallen får inte mekanikern informationen innan hen har arbetsordern i

handen. Men sen finns det roller på verkstaden, där man jobbar som jour-mekaniker

och åker ut och hjälper kund på plats – I dessa fall då man inte kan lösa felet på plats

och fordonet bogseras till verkstad får dem mekaniker på plats ofta informationen

från de jour-mekaniker som tog emot fordonet från första början. Men i vanliga fall är

det nog så att mekanikern får först information om uppdraget då den får arbetsordern.

I vilka typ av uppdrag förekommer insamlad information om ett uppdrag som har gått

genom en kundmottagare? (serviceuppdrag, akut-reparationsuppdrag, underhåll)

Vid underhåll är det inte så mycket information som är insamlat från kund (tydliga

beskrivningar finns, behövs inte så mycket information från kund?). Men vid

xli

konkreta reparationer eller VHRer (Stillastånd), då måste man ha insamlad

information.

Vid underhåll har man oftast tillsynspunkter - vad man ska göra, vilket hämtas ut från

systemet (multi i detta fall) och sen följer man bara punkterna. Man behöver inte veta

så mycket om fordonet för att genomföra ett underhåll – bara tillsynspunkter ingen

historik.

Av 10 fall hur ofta förekommer information om uppdraget? Och i vilka typer av

uppdrag är det?

Lite klurig fråga, vissa verkstäder har roller exempelvis tillsynstekniker som bara

jobbar med tillsyner i stort sätt.

#Vad innebär det?

Service av fordon, och den rollen är inte så involverad i felsökning och reparation.

Dem byter oljor och filter etc.

Så jag skulle säga hälften av fallen 5/10 kanske, svår fråga pga roller.

Hur ofta av 10 fall kommer det in kunder till verkstad utan att ha gått igenom en

kundmottagare först?

Ytterst sällan, då ska man ha en personlig relation, antingen till verkmästaren eller

mekanikern. Man måste ju gå via kundmottagaren, för att få in pengar från det utförda

jobbet? Blir svaret 0/10

Hur fungerar planeringen och i de fallen? (Vem tar emot kund , samlar in

information, och planerar arbetet, utförs en initialfelsökning då?)

Det finns ju dem fallen med Jourmekaniker, då går inte kunden via en

kundmottagare. Jourmekaniker har en bred roll, där ingår även att agera som en

kundmottagare. Multi-roll.

När ett uppdrag är inplanerat, hur lång tid passerar innan ni utför reparation/servicen?

Om man inte har ett jättestort reservdelslager, inom 4 dygn? Måste då beställa material

vilket kan ta 4 dygn, finns dock alternativ med expressleverans som går fortare. Om

materialet finns utomlands, ex Belgien tar – 4 dygn. Kan köra express men det blir

väldigt dyrt, tror inte kunden vill betala för det.

#Om man har grejerna inne och det inte är en totalkvaddad bil hur lång tid

uppskattningsvis kan det ta då innan man genomför åtgärderna?

Om man inte har något inplanerat, handlar det om timmar. På max 1-2 timmar är man

igång.

Finns det uppdrag som prioriteras? (akuta-uppdrag, alvarligare problem, när fordonet

inte kan brukas)

Olika verkstäder agerar olika, storkunden- när den kunden kommer in så är han ganska

säker på att man prioriterar den kunden, att den kundens fordon får högre prioritet än

andras fordon, det är för att man är rädd att förlora den kunden. Det finns en outtalad

prioritering, verkstäder agerar dock olika.

#Kan det prioriteras mellan vardagliga kunder också, ex om det en akut (VHR) och som

har en inplanerad service?

xlii

Ja absolut kan det vara så, Det akuta tar man ofta före. Det beror på att vid akuta fall

förlorar kunden up-time, vilket gör att hen kan förlora pengar, och då prioriteras det.

Fråga 2:

Hur tar du del av information om uppdraget? (Genom ett speciellt program, mail)

Ganska olika, man kan få uppdraget i pappersformat (Arbetsorder?), men även

i Automaster (elektroniskt). Sen skiljer det sig mellan mekaniker och mekaniker, dem

äldre vill nog hellre ha papper, men yngre arbetar direkt i Automaster (planering,

fakturering, arbetsorder mm).

#Har vanliga verkstäder det som kallas FRAS?

Dem har ett frassystem, där dem rapporterar in fel dem stöter på flera gånger. Dealer

FRAS kallas det. Rapporteringen dit sker för att utvecklingssidan skall höja ögonbrynen

för visa återkommande fel, då det kan vara konstruktionsrelaterat. Här kan det

förekomma regions specifika problem pga, underlag, specifika fordon kör mycket där, ex

timmer bilar etc..

Följdfrågor till fråga 2:

Hur presenteras informationen för dig? (fritext, check-boxar)

Både muntligt och fritext, osäker med dagens arbetsorder. Kan inte svara på.

Vad är det för data? (Symptom, DTCer, beskrivning av händelseförloppet,

vägförhållanden)

DTCer, dem upplevda sakerna hos föraren tillsammans med DTCer, man använder sig av

Scanias Multi, där finns en hel del felsöknings-guider, egna erfarenheter. Vid komplexa

fel – Så finns det mekaniker som vet hur man använder Fras, där söker dem på symptom

där, det är en typ av Grovsökning?), det kan vara allt från en typ av missljud från vatten-

pump. Denna data är det som har skickats som info tillbaka till fabrik vid dem

återkommande fallen, och i vissa fall har symptom dokumenterats i dessa case. Vilket gör

det sökbart.

#Finns det någon typ av grovsållning man gör med någon information?

Exempelvis om man söker i Fras, då använder man sig av dem komponentkoder som

finns (ex, motor 1, kylsystem 2 etc) och filtrerar så sätt. Man använder nog inte chassi

nummer så mycket utan mer på dessa komponentkoder i dessa fall, ex har man fel på

motor så säker man på motor med dessa komponentkoder. Alla avvikelser som är

dokumenterade är kodade på detta sätt. Samma kodning förekommer i flera program och

på flera ställen inom Scania.

Varierar användbarheten och detaljrikedomen på de olika data inom uppdragen? På vilket

sätt? (Är det någon information som sticker ut i sin användbarhet, för att lösa problemet,

någon information du inte använder i ditt felsökande men som finns med)

Ja, det kan variera på detalj-innehållet när man läser ut DTC t.ex, vissa beskrivningar är

väldigt komplexa som refererar till Multi eller annat system. Medans andra DTCer kan

vara väldigt bristfälliga. Vissa DTCer är så bra beskrivna att man kommer väldigt nära

root-cause, medans andra har bristfällig beskrivning.

Varierar användbarheten och detaljrikedomen på informationen vid liknande

fel/problem? På vilket sätt? Varför?

Det kan skilja mycket på förarens beskrivning ja. (Vart det låter, när det låter, är det

varmt eller kallt, efter hur lång tids körning, varvtal man har legat på). Vissa förare är

väldigt duktiga på att uttala sig om detta t.ex exakta varvtal med mera. Så inputen

xliii

kundmottagaren får kan variera mycket – vilket leder till att mekanikerns information kan

variera mycket.

Ser du några förbättringsmöjligheter med den information som idag finns tillgänglig, i

samband med ett uppdrag? (presentationen , data i säg otydlig, vilken?, Återkoppling vid

otydlig data, kan du ibland känna ”om jag viste detta hade jag kunnat lösa problemet”)

Ja det är egentligen, att det börjar från den som framför fordonet och framåt, och sen att

den som tar emot kunden ställer rätt följdfrågor helt enkelt, för att få en bättre bild av

problemet. Där skulle man kunna förbättra mycket med utbildning (Att ställa rätt frågor).

#Finns det någon standard idag för vad man ska fråga?

Det tror jag inte, inget jag stött på i alla fall.

Vet du vad kundmottagaren som samlat in information om uppdraget, gjort med

informationen? (har den börjat en initialfelsökningsprocess så du iallafall vet att det är

nått i motorn eller med tändningen som är fel)

Det kan vara en kundmottagare som själv varit mekaniker som gjort en egen bedömning,

och går efter erfarenhet av det kunden beskriver från sina observationer. I detta fall är det

ju kundmottagaren som ställt diagnosen.

#Finns det tillfällen det kan bli brister i detta också?

Absolut så kan det vara så, om en kundmottagare ställer en diagnos utefter bara symptom

och erfarenhet kan det tyckas vara lite av spekulationer/chansning att det är det felet, pga

misskommunikation eller bedömningar kan det bli fel vilket kan leda till alvarligare

konsekvenser. Exempelvis kan det ta längre tid än det behövt att utföra åtgärden pga

måste planera om tiden för åtgärd, kundmottagaren kan även lyckas beställa fel artiklar

vilket gör att processen dras ut, det är även så att om man planerar in en tid påverkar det

även kring liggande planerade tider och dem kan också påverkas av att en fel diagnos har

gjort, då omplanering måste göras. Det skiljer mycket mellan kundmottagare, deras

kunskapsnivå skiljer mycket från verkstad till verkstad.

Hur långt gången är felsökningsprocessen när du tillhandahåller uppdraget? (Vet du vilket

system problemet ligger i, eller vet exakt vilken del felet ligger i)

Det skiljer sig mellan verkstäderna, det kan ju ha gått 3-4 h innan mekanikern blir

involverad? Alla kanske inte har tillgång till SDP3, så mekanikern kanske inte har gjort

en diagnos, vilket betyder att någon med den spetskompetensen har gjort en diagnos om

man på verkstaden har en sådan uppdelning av roller. Det betyder att mekanikern får först

uppdraget efter att diagnosen har gjort av annan roll. Detta gör att det kan ta flera timmar.

Samtidigt på andra verkstäder har mekanikern en sådan roll att den gör alla sina

utläsningar själv och är då involverad tidigare i processen av felsökningen, vilket gör att

felsökningen inte är lika långt gången, jämfört med att den kan vara klar för andra

mekaniker. Men detta skulle jag säga varierar från land till land.

# Vad är den vanliga situationen i Sverige med detta?

Att mekanikern är mer involverad i felsökningsprocessen i Sverige, vilket gör att det kan

handla om upp till ca 1h innan man kommer i kontakt med uppdraget.

Händer det att ni inte behöver felsöka fordonet?

xliv

Ja om verkmästaren eller någon med den spetskompetensen, utifrån kundinformationen

redan konstaterat felet. Ju färskare mekaniker man har på verkstaden, ju oftare behöver

man agera med hjälp i dem andra rollerna.

Ifall, hur ofta av 10 fall?

Kan ej svara. Hos dem (R&D) är det ungefär 5/10. Vi har inte dem här rollerna som dem

har på verkstäderna, alla här ska kunna lite om mycket. Det blir annorlunda här. Här

jobbar vi mer med att lämna över problemet, för kompetensen finns alltid någonstans,

eftersom det är här grejerna kommer ifrån.

Och varför? (För att ni vet av erfarenhet vad felet är? för att felet är så pass specifikt,

för att den initiala felsökningsprocessen redan är så långt gången)

Hoppade över för kunde inte riktigt svara på frågan ovan.

Fråga 3:

Hur arbetar ni med kundsymptom i dagsläget? (urskiljer kundsymptom av fel beskrivning

från kundmottagare, ringer upp kunden ibland och frågar lite, när kund kommer förbi

verkstad)

I dagsläget är han helt övertygad om att det går åt fel håll, förut var kunderna kunniga om

fordon, idag finns det förare som inte vet så mycket om fordonet. Det har han personligen

hört från assistansmekaniker som vart ute på plats. Men produkten är ju mycket mer

komplex (mer teknik) idag också vilket kan ha en påverkan.

Följdfrågor till fråga 3:

Att integrera kundsymptom i eran felsökningsprocess och program på daglig basis, hur

tror du att det hade kunnat hjälpt din vardagliga verksamhet? (på ett mer standardiserat

sätt, den kunskapen ni har idag om kundsymptom finns även i felsökningsprogrammen, ex

statistisk data som ni annars bara tar förgivet ”denna delen går ofta sönder så kollar den

först”)

Det hade hjälpt, det finns som sagt dem mekaniker som använder Fras idag (vilket

linjerar lite med det som är tanken att ta fram i vårat projekt). När produkten börjar bli så

komplex så behöver man allt stöd som finns? Och på mekanikernivå tror jag att om det

fanns ett system med en vettig filtreringsnivå och sökbarhet hade det använts flitigt för att

söka på symptom kopplade till fel på fordonet.

#(Här berättas en tanke vi har kring lösningen)

Han nämner att ett sådant system ska vara lätt att använda, då många mekaniker eller

kundmottagare kan vara av det gamla gardet och mindre intresserade av att använda ny

teknik.

Vad tror du är viktigt att ta i åtanke vid skapandet av ett sådant felsökningssystem? (Nån

tanke kring data, användningen, presentationen av data)

Man skulle kunna använda de Scaniaspecifika komponentkoderna (Motor 1 mm) vid

utveckling av sådant system. Detta istället för att göra ett nytt filtreringssystem, blir

lättare om användarna känner igen filtreringsprocessen. En kombination av symptom och

komponenter hade det landat i. Även användning av fritext för att söka istället för bara

nyckelord. Fråga 4:

Kan du gå igenom de olika processerna/momenten du genomför i ett uppdrag från början

till slut? (Det kan vara ett exempel på ett uppdrag, vilka process/moment är generella

som du alltid genomför)

xlv

Det beror på vilken nivå av felsökningen fordonet kommer in i (den tid kan variera

mycket), Men typiskt är att man börjar med att utföra en diagnos/felsökning på fordonet,

konstaterar att det här är felet, efter det reservdelsberedaren -beställer delar, om delarna

finns på plats, byter mekanikern artikeln och ser till att fakturera (vad var det för

standardtid för bytet och felsökningen), sist gör en diagnos igen för att se om problemet

blev avhjälpt med dem åtgärder som gjordes.

I andra mer komplexa fel börjar det med felsökning också, men där kan det vara att en

felkod inte lösts ut, då får man försöka diagnostisera och djupdyka i

det eftermarknadsstöd som finns – Multi, återigen då när man börjar få en bild av

felet, speca vilka artiklar som behövs, kolla om det finns teknisk information i form av

kända fel, här kan man brottas med att det finns många källor att kolla på och att man

behöver prata med många personer för att komma till rot med problemet (hitta

erfarenhet).

#Kan det bli vid dessa tillfällen att man måste ringa konstruktörer?

Ytterst sällan ute på vanliga verkstäder, men det kan förekomma att dem ringer Helpdesk

på fabrik – som i sin tur kanske kontaktar konstruktörer (för spetskompetens). Men

det beror mycket på uppdraget. Man kan köra fast, då får man gå till Helpdesk, låter dem

titta på caset och i värsta fall får dem kolla med fabrik, sen får man vänta på

återkoppling. Det skiljer sig mellan verkstad till verkstad.

#Hur avslutar man, när är det klart?

Verifiera att det avhjälpte, se till att faktura underlaget stämmer. Mycket handlar om

pengar, verkstäder vill ha betalt för uppdragen. Ibland kan mekanikern själv göra en

provkörning för att se att problemet blev avhjälpt, eller så skickar man ut verkmästaren

eller nån annan, ibland tar man även avstämning med kunden o tar med kunden under

provkörning. Ingen skriven standard hur man avslutar. Om man frågar verkmästare eller

chef på verkstad säger dem nog att mekanikern ska se till att faktureringen är rätt så dem

får rätt betalt.

Kan du säga nått om tiden för varje moment?

Det finns standardtider. Dock inte för felsökning (stor variation). Men om man ska byta

X då kan man gå in i Multi, arbetsbeskrivning – finns standardtid. Verkstäder använder

standardtider vid fakturering? Stora problemet är att diagnostik och felsökningstiden inte

finns?

Ser du att något moment som utförs idag är onödigt eller utförs på fel sätt? Varför?

Leveranstillsyn, anläggningsbil med mer än tre axlar, beskrivning vid tillsyn, stämmer

inte (väldigt specifikt). Kommer inte på något annat för vardagligbasis.

Övrigt?

Det jag skulle säga, prata med Scaniabilar Stockholm via telefon, finnas ett system att

söka på symptom, och hur mekaniker arbetar med det idag. Det första han kom att tänka

på, dealer Fras, då det används lite som symptombank för att söka i. Hur jobbar

mekanikerna som använder dealer Fras?

Fältprovsavdelning – YDVF kontakt nån som jobbar som det.

Fältprovsmekaniker, dem jobbar som vanliga mekaniker, när fältprov fordonen

kommer in.

xlvi

Bilaga H – Analys av FMEA Undersökning av innehåll och datakvalitet i FMEA

I följande tabell presenteras rubrikerna i den FMEA som analyserades, och en kort beskrivning

av vilken data som skrivs under respektive rubrik, se Tabell 14. I analysen gjordes även egna

minnesanteckningar där observationer och egna tankar kring innehållet skrevs ner. Tankarna

kan i detta fall vara något som kan vara intressant att undersöka vidare, eller en idé som kunde

användas i konceptutvecklingen. I tabellen presenteras även en bedömning av datakvaliteten i

FMEA:n. Detta för att få en förståelse kring vad som skulle kunna användas i

konceptgenereringen för sammankopplingen mellan kundsymptom och systemreaktioner.

Bedömningen av datakvaliteten gjordes med följande nivåer; Låg, Medel och Hög.

Tabell 14. Visar rubrikerna som fanns i FMEA:n och en beskrivning av datainnehållet. Dessutom presenteras observationer

och tankar som noterades under intervjun, samt en bedömning av datakvaliteten.

Innehåll i FMEA

(rubriker)

Beskrivning Observationer/tankar Bedömning

(datakvalitet) Systemdel Systemdelen är den produkt

som FMEA:n behandlar.

Hur många systemdelar finns det i ett fordon? Hög

Component Detta är produktens olika komponenter (Scania AB,

2014). I detta fall är

komponenterna exempelvis tank, secondary relief valve

och primary relief valve.

Systemdelen i denna FEMA är bränsleförsörjning, tank – LNG, men det finns även en komponent som är tank. Hade

det varit bra att benämna komponenterna med någon form av

nivå, exempelvis att tank är huvudkomponenten, och att Primary och Secondary relief valve är underkomponenter.

Med hjälp av detta kanske det hade varit lättare att kartlägga

de olika systemdelarna, och hur dem ingående komponenterna beror på varandra.

Hög

Functions; Purpose Detta beskriver vad respektive

komponent gör i produkten.

Kort beskrivning, 5-17 ord. Upplägget är oftast verb +

substantiv. Exempel: Lagra bränsle med rätt temperatur.

Medel

Failure mode Detta är vad som kan gå fel med komponenterna (Scania

AB, 2014).

Enligt Scanias definition är en komponent och dess tillhörande failure mode en så kallad komponent-felmod

(Scania AB, 2014).

En komponent kan ha flera failure modes. Det hade därför

varit bra att undersöka om det finns en korrelation mellan

dessa fel. Exempelvis vad sannolikheten är att alla fel uppstår om ett fel har uppstått. Om en korrelation mellan failure

moden fanns hade det möjligtvis kunnat fungera som en bas

för kundmottagarens arbete. Exempelvis om komponent X har failure moderna A, B, och C, och kunden rapporterar in till

kundmottagaren att failure mode A finns hos fordonet. Då

skulle kundmottagaren kunna fråga om även B och C fanns för att kunna avgöra att det är komponent X som är orsaken

till felet.

Det noteras även att finns komponenter som har failure modes

som andra komponenter också har. Detta anses öka

komplexiteten i att identifiera vilken komponent som är felaktig. Hade det varit fördelaktigt att dokumentera för

respektive komponent-felmod vilken/vilka övriga komponenter som kan ha samma failure mode? Denna data

skulle potentiellt kunna användas vid fall där

felsökningssystemets förutsägelser inte stämmer kring vilken komponent som är felaktig. Då kanske dem andra

komponenterna kan föreslås, och bli utgångspunkten för den

vidare felsökningen.

Slutligen finns det failure modes som enbart är kopplade till

en komponent. Detta indikerar att failure moden är väldigt specifik, och därmed eventuellt svårare att identifiera med

hjälp av symptom. Dock, när den väl har hittats så är det

positivt eftersom man då vet direkt vilken komponent som är felaktig.

Hög

Symptom Detta är sättet failure moden

urartar sig på utifrån

mekanikerns perspektiv. Det är viktigt att notera att detta

skiljer sig från studiens

definition av kundsymptom.

Symptomet Högt tryck är väldigt kort och intetsägande. Det

anses vara svårt att kunna identifiera fel med hjälp av enbart

denna information. Dessutom är symptomet beskrivet med teknisk terminologi, och anses därför vara något som

mekanikern skulle kunna identifiera i samband med att

fordonet felsöks. Det hade varit fördelaktigt att undersöka vad

Låg

xlvii

kunden hade gjort för observationer när felen kring dessa

komponenter uppstår.

Denna FMEA visar att flera fel (hos olika komponenter i en

produkt) kan urartas i ett och samma symptom. Detta ökar

komplexiteten att felsöka produkten.

Denna rubrik finns inte i Scanias interna dokumentation

gällande hur en FMEA utförs (Scania AB, 2014). Innebär det att arbetet med FMEA inte är konsekvent inom samtliga

avdelningar på Scania?

Failure effects Detta är vad respektive komponent-felmod har för

inverkan på produkten (Scania

AB, 2014).

Komponent-felmodernas inverkan på produkten beskrivs på ett tekniskt sätt. Det hade även varit fördelaktigt att ha en

icke-teknisk beskrivning som är mer likt det kunden

rapporterar när felet uppstår.

Hög

Failure handling by

system

Detta beskriver system-

reaktionerna, alltså vad

produkten gör när ett fel uppstår, exempelvis att en

varningslampa tänds i

fordonet (Scania AB, 2014).

Skulle detta kunna betraktas som kundsymptom? I FMEA:n

är exempel på dessa Failure handling by system att en gul

lampa tänds och en kapsyl saknas. Detta skulle eventuellt kunna vara något som kunden kan observera och rapportera

in till kundmottagaren.

Systemreaktionerna är beskrivna kortfattat och anses sakna

essentiell information så som vilket system som reaktionen

sker i.

Medel

Failure detection Beskriver hur fordonets ECU:er identifierar en

komponent-felmod,

exempelvis genom felkoder (DTC:er).

Hade det inte varit fördelaktigt att differentiera denna rubrik enligt följande; Failure detection (utvecklingsingenjör),

Failure detection (mekaniker), och Failure detection

(kunder)?

I vissa fall beskrivs situationer när komponent-felmoden

uppstod, exempelvis Högt tryck (>10 bar) när man avslutar körning. Detta skulle eventuellt kunna användas till

formaliseringen av kundsymptom. Om en kund rapporterar in

situationen när ett symptom observerades kanske det gör det lättare att koppla ihop kundsymptomet med den tillhörande

systemreaktionen.

Hög

Failure isolation Beskriver hur problembilden

kan minskas ytterligare från

den som erhölls från Failure

detection, detta kan exempelvis göras genom

verkstadstester av

mekanikern.

Hur kan motsvarande data erhållas om fordonet inte är på

verkstäderna?

Låg

Remedy action Detta är avhjälpande

handlingar som mekanikern

kan göra när fordonet är på verkstaden för att eliminera

komponent-felmoden (Scania

AB, 2014).

Lite data kring remedy actions finns tillgänglig. I fallen där

data finns är beskrivningen av handlingarna korta,

exempelvis Byt tank.

Låg

RPN Detta är risk-prioritetsvärdet som beräknas med hjälp av att

multiplicera faktorerna

Occurence (O, frekvens), Severity (S, allvarlighet) och

Detection (D, upptäckbarhet)

(Scania AB, 2014).

Det finns rubriker för respektive faktor, men eftersom dem ingår i RPN-värdet exkluderas beskrivningen av dessa.

Finns det någon korrelation mellan RPN-värdet och antalet ifyllda celler i FMEA:n? Finns det mest data till dem

komponent-felmoder som har störst risk att uppstå?

Värdet på O och D skulle kunna användas för att avgöra vilka

komponenter i en produkt som med största sannolikheten

kommer att få ett fel, samt hur lätt det är att identifiera dessa.

Hög

Corrective actions/

Responsible/

Comments

Detta är handlingar från

utvecklingsingenjörernas sida

på Scania för att eliminera att dem identifierade komponent-

felmoderna kan uppstå, detta

kan exempelvis vara ändringar i produktens hård-

och mjukvara.

Bristfällig data. Få konkreta handlingar för att eliminera

komponent-felmoderna presenteras.

Låg

Notes Detta är egna anteckningar från utvecklingsingenjörerna

som utvecklade FMEA:n

Denna data betraktas inte gå att använda som underlag vid felsökning.

Låg

xlviii

Undersökning av korrelation mellan RPN-värdet och ifylld data

I följande tabell presenteras RPN-värdet för respektive komponent och dess tillhörande failure

mode, se Tabell 15. Detta för att kunna avgöra om det fanns en korrelation mellan ett RPN-

värde och antal ifyllda celler i FMEA:n. Dessutom undersöktes även dem enskilda faktorerna

för att kunna identifiera möjliga mönster. Faktorerna var i detta fall Occurence (O), Severity (S)

och Detection (D). I tabellen indexerades rubrikerna i FMEA:n enligt följande; Systemdel (1),

Component (2), Functions, Purpose (3), Failure mode (4), Symptom (5), Failure effects (6),

Failure handling by system (7), Failure detection (8), Failure isolation (9), Remedy action (10),

Corrective actions/ Responsible/ Comments (11) och Notes (12).

Tabell 15. Visar RPN-värdet, faktorerna (O), (S) och (D), samt vilka tillhörande celler som var ifyllda i FMEA:n.

RPN O S D 1 2 3 4 5 6 7 8 9 10 11 12

405 5 9 9 X X X X X X X X X - X X

360 4 10 9 X X X X X X - X X - X X

270 3 10 9 X X X X X X X X X - X X

270 3 10 9 X X X X X X - X X - X X

256 4 8 8 X X X X X X - X X - X X

252 4 7 9 X X X X X X - X X - X X

252 4 7 9 X X X X X X - X X - - X

216 3 8 9 X X X X X X - X X - X X

192 3 8 8 X X X X X X - X - - X X

192 3 8 8 X X X X X X - X - X X X

192 3 8 8 X X X X X X - X X - - -

162 6 9 3 X X X X X X X X X X X X

120 5 8 3 X X X X X X X X X - - -

98 2 7 7 X X X X X X - X X X X X

98 2 7 7 X X X X X X - X X - - -

72 3 8 3 X X X X X X X X X - - -

30 1 10 3 X X X X X X X X X X - X

Utifrån Tabell 15 kunde inget mönster identifieras för att kunna bevisa att det fanns en koppling

mellan RPN-värdet och antalet ifyllda celler. De komponent-felmoder som hade en stor risk att

uppstå kunde både ha mer eller mindre data än dem som hade en mindre risk att uppstå.

Liknande slutsatser kunde även dras för respektive faktor O, S och D. Dessutom noterades det

utifrån tabellen att intervallet för O var 1-5, S var 7-10 och D var 3-9. Detta indikerar att

komponent-felmoderna i FMEA:n inte förekommer så frekvent. Däremot om felen uppstår så

medför det att kritiska funktioner i produkten inte längre kommer att fungera. Dessutom medför

detta komplikationer för mekanikern då felen är svåra att upptäcka. Att S är så högt på samtliga

komponent-felmoder skulle potentiellt kunna bero på att komponent-felmoder med låg

allvarlighetsgrad S inte anses nödvändiga att dokumentera.

Undersökning av ifylld data i FMEA

I följande tabell presenteras statistik från den ovanstående tabellen, se Tabell 16.

Tabell 16. Visar statistik från Tabell 15 och egna observationer och tankar.

Tillgänglighet av

data

Resultat Observationer/tankar

Minst antal ifyllda celler

8 av 12 Minst antal ifyllda celler var 8 av 12, vilket kan betraktas som ett högt antal. Dock saknades data i

kritiska celler vilket har en negativ inverkan på

FMEA:ns totala datakvalitet.

Max antal ifyllda

celler

12 av 12 Det var dock bara en komponent-felmod som hade

komplett data.

Medelvärdet på antal

celler ifyllda per komponent-felmod

9.9 av 12 Ett medelvärde på 9.9 av 12 celler kan betraktas

positivt. Dock med liknande resonemang som i Max antal celler där data saknades så saknar komponent-

felmoderna data i kritiska celler. Detta gör att

medelvärdet inte går att utgå ifrån för att dra slutsatser huruvida datamängden i FMEA:n är

tillräcklig eller inte.

xlix

Rubriker som hade

minst antal celler

ifyllda

Failure handling by system och Remedy action. Det är få komponent-felmoder som har failure

handling system vilket anses ha en negativ inverkan

på att kunna identifiera felaktiga komponenter. I detta fall skulle det potentiellt vara bra att ha

kundsymptom då dem blir som ersättning när failure

handling by system inte finns. För om det inte finns exempelvis en gul varningslampa så kanske felet

kan upptäckas via rök av kunden (kundsymptom).

Avsaknaden av data under remedy action indikerar

att mekanikern troligtvis inte har varit så involverat i

skapandet av FMEA:n. Troligtvis har flera remedy actions utförts men att dessa inte har dokumenterats.

Dessutom kan vissa remedy actions anses som självklara och kan därför ha blivit exkluderade.

Exempelvis så nämns det inte att ett filter bör bytas

ut när det är igensatt.

Övriga rubriker där data saknades till

vissa komponent-

felmoder

Failure isolation, Corrective actions/ Responsible/ Comments och Notes

Det var endast två komponenter som saknade failure isolation, och dessa var filters. Orsaken till detta

skulle kunna vara att det inte går att minimera

problembilden ytterligare för dessa typer av komponenter.

Det saknades data gällande vilka corrective actions som bör göras till respektive komponent-felmod.

Rubriken corrective actions kommer troligtvis ändå

inte att tillämpas till den initiala felsökningsprocessen eftersom den inte behandlar

långsiktiga lösningar.

Data under rubriken notes anses vara irrelevant. Det

betraktas inte vara negativt att denna data saknas.

Övergripande analys av FMEA

I FMEA:n finns rubriken Symptom som vid en första anblick lätt kan förväxlas med

kundsymptom. Symptomen beskrivna i FMEA:n är mer tekniskt uttryckta och kan ses som

mekanikerns perspektiv på hur fel uppdagas, medan studien snarare undersöker kundens

perspektiv. I dagens läge finns det ingen rubrik där kundsymptomen tas upp, vilket anses

bristfälligt. Dock så kan vissa andra rubriker innehålla data som skulle kunna uttryckts av

kunden. Exempel på rubriker som innehåller data som kan ses som kundsymptom är; Failure

mode, Failure effects, Failure handling by system och Failure Detection. Det hade eventuellt

varit fördelaktigt att ha en separat rubrik, Customer symptom, som enbart är till för

kundsymptom. Under denna rubrik skulle förslagsvis både befintlig data från tidigare nämnda

rubriker, samt nya uttryckta kundsymptom kunna dokumenteras. Detta för att lättare kunna

sammankoppla kundsymptom med systemreaktioner.

Studien avser bland annat att ta fram en metod för att sammankoppla kundsymptom med

systemreaktioner. Rubriken Failure handling by system betraktas i detta fall som

systemreaktioner, men som det kan ses ovan kan denna rubrik även innehålla kundsymptom.

Eftersom dessa två kan förväxlas så kan processen med att sammankoppla kundsymptom med

systemreaktioner försvåras. För att differentiera begreppen så kan det vara nödvändigt att

omformalisera strukturen och innehållet i FMEA:n.

l

Bilaga I – Koncept I varje koncept presenteras formatet på FMEA och där kommer enbart ändringar från den

FMEA:n som erhölls från Scania att presenteras. Om inget nämns innehåller FMEA:n

rubrikerna; Systemdel, Component, Functions, Purpose, Failure mode, Symptom, Failure

effects, Failure handling by system, Failure detection, Failure isolation, Remedy action,

Corrective actions/ Responsible/ Comments och Notes.

Koncept 1

Koncept 1 innehåller 3 faser; den inledande fasen, den faktiska fasen och den återkopplande

fasen. Detta koncept skulle kunna betraktas som en datadriven metod men konceptet tillämpar

även expertdata i form av FMEA.

Den inledande fasen

Den inledande fasen handlar om att dokumentera kundsymptom och systemreaktioner i Scanias

befintliga felsökningsprocess. Detta innebär att den enda skillnaden Scania kommer att göra

under denna fas är att kundmottagarna dokumenterar kundernas symptom i fritext som sedan

skickas till mekanikerna, i arbetsordern, och till utvecklingsingenjörerna. Sedan formaliserar

utvecklingsingenjörerna kundsymptomen enligt avvikelse, position och kontext, och utreder

vilken tillhörande systemreaktion som är kopplad till kundsymptomet. Detta eftersom

utvecklingsingenjörerna anses besitta goda kunskaper om de ingående komponenterna i Scanias

produkter. Utvecklingsingenjörernas arbete dokumenteras i cases (kundsymptom med

tillhörande systemreaktion) enligt felsökningsmetoden CBR.

Den faktiska fasen

I den faktiska fasen byter man ut Scanias befintliga felsökningsprocess till denna

felsökningsprocess. Felsökningsmetoden CBR används då för att matcha nya kundsymptom

med tidigare fall. Baserat på vad kunden förmedlar till kundmottagaren så får kundmottagarna

välja i en dropdown-meny under respektive kategori, avvikelse, position och kontext, den

beskrivning som passar bäst. Det som visas i denna dropdown-meny är det som

utvecklingsingenjörerna tidigare dokumenterad i den inledande fasen. I de situationer då det

inte kan göras en matchning eller när det inte finns val i dropdown-menyn som passar kundens

symptom så sker felsökningsprocessen likt den idag – ta in fordonet till verkstaden och utföra

felsökningen på plats.

Den återkopplande fasen

I den återkopplande fasen skulle följande handlingar kunna utföras; uppdatera cases i case

library om det visats att vissa kopplingar mellan kundsymptom och systemreaktioner är

felaktiga och/eller om en matchning inte kunde fås när kunderna förmedlar nya symptom.

Format för FMEA:

I detta koncept tillämpas inte FMEA.

Format för kundsymptom:

Avvikelse:

• Avvikelsen är kundens beskrivning av fordonets oväntade tillstånd vilket gör att kunden

är i behov av felsökning. Detta kan ofta beskrivas genom sinnen, exempelvis att kunden

ser att det ryker eller känner att det vibrerar.

Position:

• Position är området på fordonet där kunden anser att avvikelsen förekommer. Ta reda

på om till exempel avvikelsen sker i fordonets främre eller bakre del.

li

Kontext:

• Kontext innefattar allt som sker i samband med att avvikelsen uppkommer. Här kan ett

händelseförlopp vara fördelaktigt där det beskrivs vad som hände före, under och efter

att avvikelsen uppkom. Exempelvis att en kund först kör på en motorväg men vid

inbromsning på grund av köbildning så uppkom avvikelsen. Kunden ställde då fordonet

vid vägrenen och ringde efter hjälp.

Koncept 2

Detta koncept tillämpar felsökningsmetoden Bayesiska nätverk och kan därför betraktas till

största grad som en datadriven modell men konceptet tillämpar även expertdata i form av

FMEA. I den grafiska modellen av det Bayesiska nätverket ansätts systemreaktionerna som

parent nodes och kundsymptomen som child nodes. Relationerna mellan noderna kommer i

detta koncept vara att systemreaktionerna leder till att kundsymptomen uppstår. Detta skiljer

sig dock från hur en manuell felsökning skulle gå tillväga för då börjar felsökningen med att en

kund identifierar kundsymptomen och att man utifrån det sedan minimerar problembilden tills

systemreaktionerna har identifierats. I detta koncept bestäms sannolikhetsdistributionen för

respektive systemreaktion med hjälp av faktorn Occurence som ingår i RPN-värdet (i FMEA).

För att erhålla en god matchning mellan kundsymptomen och systemreaktioner föreslås att varje

Occurence-värde för samtliga komponent-felmoder i FMEA:orna testas och utvärderas.

Det här konceptet förutsätter ett förarbete där man dokumenterar kundsymptomen i en

kundsymptomdatabas och i FMEA:orna (1) samt där relationerna mellan de identifierade

kundsymptomen och systemreaktionerna som finns i FMEA:n utreds för att kunna skapa den

grafiska modellen för det Bayesiska nätverket (2).

1. Relevanta medarbetare inom Scania utför praktiska tester i samband med att

FMEA:orna tas fram där man testar fordon med komponent-felmoderna som

identifierats och i samband med det noterar vilka kundsymptom som uppstår i den nya

FMEA-rubriken Customer Symptom. Formatet på kundsymptomen i FMEA:n kommer

vara som formatet på kundsymptomen som kunden rapporterar in till kundmottagaren

(och även samma terminologi – språk som är icke-tekniskt).

2. Eftersom en komponent troligtvis kan vara kopplad till flera kundsymptom så kommer

en/flera kundsymptom kunna ligga under rubriken Customer Symptom. Med hjälp av en

komponent-felmods systemreaktion under Failure handling by system i FMEA:n och

kundsymptomen kan den grafiska modellen av det Bayesiska nätverket ritas ut och även

relationerna kan bestämmas (relationerna är som tidigare nämnt att systemreaktionerna

leder till kundsymptomen).

Detta koncepts princip är att baserat på vad kunden förmedlar till kundmottagaren (i ett

förbestämt format) så får kundmottagaren möjligheten att justera/bearbeta denna data genom

att t.ex. ändra kundens positionsbeskrivning av avvikelsen som noterades. Exempel: från

fordonets främre del till fordonets bakre del i en dropdown-meny. Det som visas i dropdown-

menyn baseras på det som tidigare dokumenterats det tidigare nämnda förarbetet. Med hjälp av

det Bayesiska nätverket kan sedan den mest sannolika systemreaktionen kopplad till det

inmatade kundsymptomet identifieras vilket kommer att användas för att föreslå åtgärder. Om

ingen matchning kan fås så sker processen likt den som i Koncept 1.

Format på FMEA:

• Rubriken Customer Symptom läggs in i FMEA:n som kan innehålla en/flera

kundsymptom.

• För att undvika förvirring – ändra rubriken Symptom till Problem.

lii

• I och med att kundsymptomen kommer att dokumenteras i en kundsymptomdatabas

tilldelas samtliga kundsymptom med en unik kundsymptomkod för att möjliggöra

sökbarhet i ett senare stadie om konceptet realiseras.

Format på kundsymptom:

Avvikelse:

• Avvikelsen är kundens beskrivning av fordonets oväntade tillstånd vilket gör att kunden

är i behov av felsökning. Detta kan ofta beskrivas genom sinnen, exempelvis att kunden

ser att det ryker eller känner att det vibrerar.

Position:

• Position är området på fordonet där kunden anser att avvikelsen förekommer. Ta reda

på om till exempel avvikelsen sker i fordonets främre eller bakre del.

Kontext:

• Kontext innefattar allt som sker i samband med att avvikelsen uppkommer. Här kan ett

händelseförlopp vara fördelaktigt där det beskrivs vad som hände före, under och efter

att avvikelsen uppkom. Exempelvis att en kund först kör på en motorväg men vid

inbromsning på grund av köbildning så uppkom avvikelsen. Kunden ställde då fordonet

vid vägrenen och ringde efter hjälp.

Koncept 3

Detta koncept exkluderar användandet av felsökningsmetoder så som CBR samt Bayesiska

nätverk och baseras istället helt på FMEA. Därför kan konceptet betraktas som en expertmodell.

Principen för detta koncept är att kundmottagaren arbetar som vanligt med att ställa motfrågor

baserat på erfarenhet för att få relevant information från kunden. Dock i detta fall så använder

de FMEA:orna som stöd i deras arbete.

Beroende på vilka komponenter fordonet har (som kundmottagaren får reda på genom att fråga

kunden efter chassinumret på fordonet) så visas FMEA:orna under respektive Main group

(exempelvis Motor 1) för kundmottagarna. Om kundmottagaren har erfarenheter/kunskapar kan

en koppling ske mellan kundens kundsymptom och systemreaktioner genom antingen att

kundmottagaren läser i de FMEA:or som är mest relevanta enligt dem eller att de vet sedan

tidigare vilka kundsymptom som är kopplade till vilka systemreaktioner. Det här gör så att

kundmottagarna kan fortsätta som vanligt att bearbeta kundens data med hjälp av erfarenhet,

vilket också har påvisats vara det bästa sättet, men också hjälpa dem som kanske är lite mer

oerfarna att göra en mer kvalificerad bedömning av kundens data och på sätt erhålla en

matchning mellan kundsymptom och systemreaktioner. I FMEA:orna kan kundmottagarna läsa

om exempelvis. komponent-felmoders tillhörande kundsymptom och systemreaktioner.

Det kan vara nödvändigt att det sker återkoppling i jämna mellanrum för att kundmottagarna

ska kunna dela med sig av nya erfarenheter/kunskaper sinsemellan (organiserat – de har de ej

idag) samt för att FMEA:orna kanske måste uppdateras. Kundmottagarna kanske har

identifierat vissa kopplingar mellan kundsymptom och systemreaktioner som innebär att ett

kundsymptom till en komponent i FMEA:n ska bytas ut. Erfarenhetsutbytet mellan

kundmottagarna kanske även kan resultera i att vissa kundmottagare får tips på vilka frågor de

ska ställa kunderna för att få bättre data.

Stöd för kundmottagaren (innehållet i listan baseras på kundens fordon – chassinummer):

Fordon X:

• Motor 1:

o FMEA A.

liii

• Broms 2:

o FMEA B.

Format för FMEA:

• Lägg till rubriken Customer Symptom där data kring kundsymptom läggs in. Ta in data

som kan betraktas som kundsymptom från rubrikerna Failure mode, Failure effects,

Failure handling by system och Failure Detection. Alternativt även lägga in

kompletterande data kring kundsymptom allteftersom när nya lärdomar och kopplingar

mellan kundsymptom och komponenter (så att kundmottagaren kan koppla till

systemreaktioner) har gjorts. Språket på kundsymptomen ska vara vardaglig (inte

tekniskt).

• Lägg till rubriken Main group – för att kunna sortera FMEA:orna som presenteras för

kundmottagaren.

• För att undvika förvirring – ändra rubriken Symptom till Problem.

• I detta koncept får rubriken Failure handling by system (systemreaktioner) i FMEA:orna

överses. I arbetet noterades det att vissa systemreaktioner även skulle kunna betraktas

som kundsymptom i denna kolumn, t.ex. Gul lampa. Det kan anses vara svårt att

sammankoppla kundsymptom med systemreaktioner om dessa två är samma sak, därför

kan det vara bra att i dessa fall kopiera över denna data från rubriken Failure handling

by system till den nya rubriken Customer Symptom.

Format för kundsymptom:

• Inget strikt format för kundsymptomen utan kundmottagaren samlar in kunddata på

samma sätt som det sker på idag, alltså genom erfarenhet. Dock kan ett underlag skapas

till kundmottagarna för att få tips på vilken information som är bra för mekanikerna vid

felsökningssammanhang. Information som ska efterfrågas till kunden; topografi,

funktioner samt även om möjligt om kunden kan förmedla sina egna strategikunskaper

(deras rekommendationer som ska felsökas först). Det sistnämnda kan även kopplas till

kundens egna erfarenhetskunskap – de kanske kan berätta om de har haft problemet

innan och hur mekanikerna löste det då.

Koncept 4

Koncept 4 presenteras med två olika varianter Koncept 4-A och Koncept 4-B – skillnaden är i

den faktiska fasen. De både koncepten har en inledande fas likt Koncept 1 där data

dokumenteras i cases enligt felsökningsmetoden CBR (dock så utreder utvecklingsingenjörerna

i detta koncept tillhörande Main group istället för tillhörande systemreaktioner). De båda

koncepten kan betraktas som datadrivna metoder men tillämpar expertdata i form av FMEA. I

dessa koncept dokumenteras kundsymptom och Main group (enligt Scanias BTI-struktur,

exempelvis på Main group är Motor 1) för att kunna sammankoppla kundsymptomen med

tillhörande Main group.

Orsaken till att kundsymptom och Main group dokumenteras i dessa cases och inte

kundsymptom och systemreaktioner är för att det anses bli en mindre risk att det blir fel i

sammankopplingen mellan kundsymptom och Main group än kundsymptom och

systemreaktioner eftersom mer fall kan täckas – alla fel har inte systemreaktioner.

Koncept 4-A

Efter den inledande fasen övergår metoden till den faktiska fasen och arbetet sker enligt denna

metod och inte enligt Scanias befintliga felsökningsprocess. När kundmottagaren har kontakt

med en kund och kunden beskriver kundsymptomen efter att dem har blivit tillfrågade efter

avvikelse, position och kontext så får kundmottagaren, likt i Koncept 1, välja i en dropdown-

liv

meny vad som passar kundens beskrivning bäst. Därefter sker den en matchning med hjälp av

CBR. I samband med detta presenteras även FMEA:n som är kopplad till den matchade Main

group. Detta innebär att kolumnen Main group borde läggas till i FMEA:ns format för att man

ska kunna filtrera innehållen i FMEA:orna baserat på kundsymptomens Main group.

Kundmottagaren kan sedan läsa i denna FMEA för att få bättre insikter i vilken komponent som

är defekt och på så sätt även kunna identifiera den sammankopplade systemreaktionen för

kundsymptomet. För att ge bättre stöd åt kundmottagaren borde kolumnen Customer Symptom

läggas till i den befintliga FMEA:n – så att kundmottagaren kan få bättre insikter (om

exempelvis kundsymptom och systemreaktioner) och lättare kunna jämföra det kunden säger

och vad som står i FMEA:orna.

För att minska mängden data som presenteras för kundmottagaren i detta stadie skulle även

kolumnen Sub System kunna läggas till i FMEA:n. På så sätt skulle kundmottagaren kunna

filtrera bort komponenter inom den specifika Main groupen som inte är relevant. Detta skulle

kunna göras i ett användargränssnitt där kundmottagaren klickar i check-boxar för de

FMEA:orna som är kopplade till de Sub Systems som kundmottagaren vill studera.

Fordon X:

• Motor 1:

o Sub System A:

▪ FMEA – A.

o Sub System B:

▪ FMEA – B.

Format för FMEA:

• För att undvika förvirring – ändra rubriken Symptom till Problem.

• Lägg till rubriken Main group samt rubriken Sub System och lägg in vilken

komponentkod som samtliga komponent-felmoder har i FMEA:n samt vilket delsystem

de ingår i.

• Lägg till rubriken Customer Symptom där data kring kundsymptom läggs in. Ta in data

som kan betraktas som kundsymptom från rubrikerna Failure mode, Failure effects,

Failure handling by system och Failure Detection. Alternativt även lägga in

kompletterande data kring kundsymptom allteftersom när nya lärdomar och kopplingar

mellan kundsymptom och komponenter (så att kundmottagaren kan koppla till

systemreaktioner) har gjorts. Språket på kundsymptomen ska vara vardaglig (inte

tekniskt).

Format för kundsymptom:

Avvikelse:

• Avvikelsen är kundens beskrivning av fordonets oväntade tillstånd vilket gör att kunden

är i behov av felsökning. Detta kan ofta beskrivas genom sinnen, exempelvis att kunden

ser att det ryker eller känner att det vibrerar.

Position:

• Position är området på fordonet där kunden anser att avvikelsen förekommer. Ta reda

på om till exempel avvikelsen sker i fordonets främre eller bakre del.

Kontext:

• Kontext innefattar allt som sker i samband med att avvikelsen uppkommer. Här kan ett

händelseförlopp vara fördelaktigt där det beskrivs vad som hände före, under och efter

att avvikelsen uppkom. Exempelvis att en kund först kör på en motorväg men vid

lv

inbromsning på grund av köbildning så uppkom avvikelsen. Kunden ställde då fordonet

vid vägrenen och ringde efter hjälp.

Koncept 4-B

Efter den inledande fasen övergår metoden till den faktiska fasen och arbetet sker enligt denna

metod och inte enligt Scanias befintliga felsökningsprocess. I detta koncept så används CBR

för att koppla ihop kundsymptom med Main group, och sedan Bayesiska nätverk för att koppla

ihop Main group med systemreaktionerna i FMEA:ns rubrik Failure handling by system.

Enligt Bayesiska nätverk skulle systemreaktionerna under rubriken Faulure handling by system

i FMEA:n vara parent nodes och Main group skulle vara child node, samt

relationerna/beroendena mellan dem är att systemreaktionerna leder till Main groupen. Med

hjälp av det Bayesiska nätverket kan då exempelvis sannolikheten att Main groupen Motor 1

uppstår beroende på de olika systemreaktionerna som är kopplade till Motor 1. I detta fall skulle

sannolikhetsdistributionen kunna baseras på RPN-värdets Occurence för systemreaktionerna i

FMEA:n.

Till skillnad från Koncept 4-A så utför kundmottagarna i detta koncept ingen bearbetning av

kundens data med hjälp av FMEA:orna utan det sker likt i Koncept 1 – alltså välja i en

dropdown-meny vad som beskriver kundens symptom bäst under kategorierna avvikelse,

position och kontext. I detta koncept hade det varit fördelaktigt att ha återkoppling för att utreda

om något måste uppdateras kring den första kopplingen (med CBR) – exempelvis uppdatera

cases, eller om något måste uppdateras till den andra kopplingen (med Bayesiska nätverk) –

exempelvis om värdena till sannolikhetsdistributionerna ska uppdateras. Om ingen matchning

kan fås så sker processen likt den som i Koncept 1.

Format för FMEA:

• För att undvika förvirring – ändra rubriken Symptom till Problem.

• Lägg till rubriken Main group och lägg in vilken Main group som samtliga komponent-

felmoder har i FMEA:n. Detta för att kunna filtrera bort FMEA:orna som inte ska ingå

i det Bayesiska nätverket.

Format för kundsymptom:

Avvikelse:

• Avvikelsen är kundens beskrivning av fordonets oväntade tillstånd vilket gör att kunden

är i behov av felsökning. Detta kan ofta beskrivas genom sinnen, exempelvis att kunden

ser att det ryker eller känner att det vibrerar.

Position:

• Position är området på fordonet där kunden anser att avvikelsen förekommer. Ta reda

på om till exempel avvikelsen sker i fordonets främre eller bakre del.

Kontext:

• Kontext innefattar allt som sker i samband med att avvikelsen uppkommer. Här kan ett

händelseförlopp vara fördelaktigt där det beskrivs vad som hände före, under och efter

att avvikelsen uppkom. Exempelvis att en kund först kör på en motorväg men vid

inbromsning på grund av köbildning så uppkom avvikelsen. Kunden ställde då fordonet

vid vägrenen och ringde efter hjälp.

lvi

Koncept 5

Inledning – Koncept 5

Inga större detaljer kommer att nämnas specifikt för ett dynamiskt felträd i konceptet, då denna

specifika information inte sammalts in och spetskompetens inom detta inte funnits under

studien. Delar som nämns gällande FTA kan fortfarande ingå i ett DFT då basen av ett DFT

ligger i en FTA. En DFT innebär att det är möjligt att bygga upp ett fel träd som tar hänsyn till

dynamiska system. Dynamiska system innebär att det finns system och komponenter som har

ett varierande driftlägen, detta är fallet för komplexa system som tunga fordon. Ett varierande

driftläge innebär att flödet av systemets funktioner varierar beroende på vart i driften man

analyserar systemet. Detta måste tas till hänsyn vid uppbyggnad av en FTA av ett komplext

system med dynamiskflöde, se avsnitt 2.3.3 rubrik Dynamiskt felträd – DFT. För bättre

förståelse över konceptet, se Bilaga B – Symbolbeskrivning av felträdsanalys. Angående

automatiserade felträd har inget nämnts, se avsnitt 2.3.3 rubrik Automatiskt genererarbara

felträd för beskrivning av möjlighet till automatisering av felträd.

Presentation

Metoden grundar sig i en uppstartande fas där information kring felmod (failure mode) och

kundsymptom samlas in. Data insamlingen kring kopplingen mellan kundsymptom och felmod

sker genom en bedömning genom erfarenhet av utvecklingsingenjörer. Insamlingen kan även

ske av utvecklingsingenjörer på plats där antingen felet (felmoden) iscensätts eller av naturlig

väg förekommer och dokumenteras. Kundsymptomen som förekommer dokumenteras med ett

icke teknisk språk för att senare kunna ta hänsyn till kundernas lägre tekniska kunskap. Vidare

tas även kundsymptom från kolumnerna Failure mode, Failure effect, Failure handling by

system och failure detection som anses kunna vara potentiella kundsymptom och läggs till i

kolumnen kundsymptom, då vissa beskrivningar av de kolumnerna i FMEA har visat sig vara

likt kundsymptom.

Kopplingarna sparas ned i FMEA mellan felmod och kundsymptom på komponent nivå, så

kallad komponent-felmod. Felmoderna har komponenter kopplade till sig sen innan, men att se

över dessa är även av stor vikt i den uppstartande fasen. För varje komponent finns där också

kända systemreaktioner i FMEA, i kolumnen Failure handling by system.

Delarna i fordonet har koder kopplade till sig enligt Scanias interna uppdelning av produkterna

(så kallat BTI-system), uppdelningen är Main group (system-del), sub-group (Del-system) och

Component (komponent). FMEA är sorterad enligt fordonets system-del (Main-group) med

dess tillhörande del-system och komponenter. I FMEA är komponenterna kopplade till

felmoder som nämnt innan och felmoderna har i sin tur kundsymptom kopplade till sig. I

felträdet innebär detta att system-delens kundsymptom är del-systemets kundsymptom och del-

systemets kundsymptom är komponenters kundsymptom.

Format för FMEA ser ut följande:

- Kolumnen ”Symptom” är utbytt mot kolumnen kundsymptom

System-del Del-system Komponent Syfte (Purpose)

Kolumnen visar

vilket system

felmoden sker i. Systemet har en

specifik kod.

Kolumnen visar vilket

Del-system felmoden

sker i. Del-systemet har en kod och är kopplad

till system delen.

Kolumnen visar vilken komponent

felmoden är kopplad till. Komponenten

har en komponentkod. Komponenten är även kopplad till ett del-system.

Komponenten har ett värde baserat på

dess sannolikhet att gå sönder som används till FTA.

Syftet berättar komponentens

syfte i systemet

Motor A Del-system A Komponent A XXXX

lvii

Felmod (Failure mode) Kundsymptom (Customer symptom) Systemreaktion

(Failure

handling by

system)

Feleffekt (Failure

effect)

Felmod är det som är fel

med komponenten. Felmoden har

kundsymptom kopplade

till sig. Felmoden är kopplad till en

komponent. Samma

felmod kan förekomma för fler än en

komponent.

Det kunden beskriver, dokumenterat på ett bestämt

format, Kundsymptomet har en kod (Symptom kod). Kundsymptomet är kopplat till Felmoder som

det förekommer vid. Det kan förekomma fler

kundsymptom för en felmod och koomponent. Det enskilda kundsymptomet kan även förekomma för

andra felmoder och komponenter. Kundsymptomet

har ett sannolikhetsvärde kopplat till sig som används i FTA.

Kolumnen visar

vilken aktiv reaktion systemet

har på felmoden.

Kolumnen visar

vilken passiv reaktion systemet

har på felmoden.

FEL A Symptom 1, Symptom 2 XXXX XXXX

Felupptäckt (Failure

detection) Felisolering (Failure

isolation) Remedy action RPN

Kolumnen visar hur en

utvecklingsingenjören har

detekterat problemet.

Kolumnen visar på hur felet

kan isoleras ännu mer från det

som detekterats i Failure detection. Kan exempelvis vara

tester på verkstad.

Beskrivning på

åtgärder.

Risk-prioritetsvärdet, beräknas

genom faktorerna: Occurence (O,

frekvens), Severity (S, allvarlighet) och Detection (D,

upptäckbarhet).

XXXX XXXX XXXX XXXX

En första sållning sker vid kontakt med kund för att veta vilka delar fordonet har,

kundmottagaren frågar kunden om hens registreringsnummer eller chassinummer. Denna

metoden är beprövad och används i dag hos verkstäder för att minimera antalet potentiella delar

som kan ha gått sönder i fordonet till dem delar som faktiskt finns i fordonet.

Efter att den första sållningen utförts måste kundmottagaren ställa frågor föra att få reda på mer

information om vad problemet med fordonet är. Frågorna grundar sig i formatet för

kundsymptomen, vilket är position och funktion och övrigt. Formatet för kundsymptomen är

baserat på en funktions del, en positions del och en del där beskrivningar som inte passar in i

dem andra två delarna av formatet, denna delen kallas övrigt. Övrigt delen för formatet av

kundsymptomet täcker in där exempelvis en specifik funktion inte kan pekas ut exempelvis det

vibrerar i ratten, surrande ljud i cockpit. Övrigt delen av kundsymptomet baseras på

observationer som indikerats av erfarenhet och kan kopplas till en specifik felmod.

Efter att frågor har ställts till kund matas Kundsymptomen in av kundmottagaren i

felsökningsprogram genom ”dropp down” meny för varje del av kundsymptom formatet, för att

kunna utföra sökningen i felträdet. I vissa fall kan det vara så att inte alla dealar av formatet kan

fyllas i, med hjälp av dataanalys kan ändå matchningar göras. Utöver inmatningen i systemet

för att felsöka skickas alltid symptomen vidare till mekaniker, detta görs då kundsymptomen

kan innehålla mer värdefull information som inte används i FTA sökningen med sina tilldelade

kategorier. Om tillräckligt med information ändå inte finns för att kunna, göra en bedömning,

beställa material och planera arbetet så är den sista utvägen att ta in fordonet till verkstad, om

fordonet är på annan ort.

Efter att en felmod har identifierats genom en sökning i FTA. Presenteras systemreaktionen

som är koplad till den felmoden för kundmottagaren genom en reducerad FMEA vilket bara

visar just den felmodens rad från FMEAn. OBS! Detta ger syfte för konceptet i denna studie

men ger ingen nytta för kundmottagaren i verkligheten. Bättre hade då vart att presentera

vilken komponent som behöver bytas ut och som antagligen är trasig.

lviii

Formatet för kundsymptomen är följande:

- Position: Denna delen av kundsymptomet visar på vart kundsymptomet lokaliseras av

kund på fordonet. Formaliseringen grundar sig i Systemkunskap och kommer från hur

erfarna felsökare använder sig av Topografi för att hitta orsaken till fel.

- Funktion: Denna delen av kundsymptomet indikerar på vilken funktion i fordonet som

den observerade avvikelsen grundar sig i. Formaliseringen grundar sig i systemkunskap

och relaterar till hur erfarna felsökare använder sig av funktioner för att minimera

problembilden vid felsökning.

- Övrigt: Denna delen av kundsymptomet är mer flexibel och har funktionen att täcka

upp för den delen av kundsymptomet när en specifik funktion inte kan pekas ut. Övrigt

delen av kundsymptomet kan användas för att göra helheten av kundsymptomet mer

specifikt.

Kategoriseringar av symptomen:

Kundsymptomen tilldelas kategorier. Kategorierna används för att för att kunna förbättra och

förenkla användningen av kundsymptomen i längden. Kategorierna är grundade på hur erfarna

felsökare använder sig av olika kunskaps-domäner inom felsökning. Användnings området av

kategorierna är till för att visa vad kundsymptomen berättar, att förenkla sökningen i FTA samt

för att ge återkopplande data. Ju fler kategorier tilldelade till kundsymptomen, desto

tätare/rikare är informationen generellt sätt. En tätare/rikare information gör det även generellt

lättare av avgöra felmoden till det observerade kundsymptomet. Kategoriseringen av

kundsymptom kan då hjälpa kundmottagaren att avgöra om flera motfrågor behöver ställas för

att få in mer information/ kundsymptom angående det observerade felet. Kategorierna är även

till för att ge mekanikern mer information än bara kundsymptomet i säg. Kategorier ger även

ett bra stöd för den mindre erfarne kundmottagaren i bedömning om tillräckligt med

information samlats in från kund för att söka i FTA efter den störst sannolika felmoden.

Slitage:

Av Domänkunskap kan där urskiljas en kategori baserat på slitage (slitage relaterade

kundsymptom). Kategorin relaterar då till kundsymptom som uppkommer på grund av åldring

, materialval/ materialegenskaper samt bruksrelaterande slitage. Förekomsten av ett ”slitage”

symptom för en komponent kan då peka på hur ofta en komponent går sönder på grund av att

designen för komponenten inte helt genomtänkt. Data kring slitage relaterade symptom

dokumenteras då för att ge återkoppling till utvecklingsingenjörer (om ett slitage relaterat

symptom dyker upp för en nyare komponent mer frekvent en vanligt, kan då bedömningen

göras att design ändringar för den specifika produkten bör utföras).

Lokala och Globala:

Av Strategiskkunskap kan två kategorier urskiljas, kategorierna är också varandras motpoler .

Kategorierna är Globala-symptom och lokala-symptom. Kategorin Globala-symptom innebär

kundsymptom som förekommer i fler än en system-del. Lokala-symptom är kundsymptom som

endast förekommer i en specifik system-del. Genom att använda sig av dessa två

kategoriseringar kan kundmottagaren lättare avgöra i vilket system kundsymptomet grundar sig

i, då om symptomet är lokalt. Att använda sig av de båda kategoriseringarna av symptom, i

stället för bara lokala symptom som kategori är för att kundmottagaren lätt skall kunna bedöma

hur mycket kunskap/information om grundorsaken symptomet bidrar till för mekanikern, ett

lokalt-symptom är mer avgränsande än ett globalt-symptom. Det lokala kundsymptomet

används för att avgöra system-delen i felträds analysen.

lix

Kundsymptom vid felkoder:

Av Prestanda- och procedurkunskap kan en kategori urskiljas, det är kundsymptom relaterade

till felkoder (Felkods - Symptom). Kategoriseringen innebär att symptom kan urskiljas i

samband med felkoder (Till exempel en röd motorlampa (producerad felkod med OBD) i

informations klustret på ett fordon lyser, i samband med att denna lampa lyser känner även

föraren av att fordonet tappar kraft (symptom)). Denna kombination av symptom och felkod

kan hjälpa till att minimera alternativen för grundorsak till det observerade symptomet.

Felkods-symptomet skulle även i vissa fall kunna utesluta falska felkoder. Exempelvis om en

felkod produceras som en röd varningslampa av nått slag i informationsklustret på fordonet och

det inte finns något övrigt observerat symptom kring exempelvis körkarakteristiken, skulle

detta kunna indikera på en falsk felkod eftersom felkoden oftast sker i samband med ett

observerat symptom (p.g.a. felkods-symptom).

Erfarenhet:

Av Erfarenhetskunskap kan en kategori urskiljas, det är kundsymptom relaterade till erfarenhet

(erfaret-symptom). Erfarenhet är den mest frekvent använda kunskapen hos en erfaren

felsökare. Kategoriseringen innebär att symptom som är beprövade och använda och har visat

sig funka för att komma fram till grundorsaken tilldelas denna kategorisering. Det görs för att

visa att symptomet med större chans än andra symptom leder till en lösning för vad

grundorsaken till problemet är. Orsaken till att kundsymptomet får kategoriseringen kan var att

symptomet leder till fler lösningar, i jämförelse med andra symptom som kan vara nya och

mindre använda (osäkrare). Genom kategorisering av erfarenhet kring ett symptom kan

kundmottagaren i den initiala felsökningsprocessen lättare avgöra om informationen kan leda

till en lösning. Vidare kan kundmottagaren vara säkrare på att informationen är tillräcklig för

mekanikern för att hitta grundorsaken till de observerade avvikelserna/symptomen.

FTA:

Topphändelsen för FTA är en system-del vilket kommer från FMEA. Av de kundsymptom som

förs in av kundmottagaren för sökning i FTA, hittar systemet ett lokalt kundsymptom vilket gör

att resterande sökning efter felmoden i trädet kan göras inom en och samma system-del i trädet.

Den resterande sökningen som sker i FTA baseras då på alla de angiva kundsymptomen

Under topphändelsen kommer sedan mellanliggande händelser. Mellanliggande händelser är

egentligen alla händelser som ligger emellan grundhändelsen och topphändelsen och det kan

finnas flera mellanliggande händelser i ett träd både över och under varandra. Detta betyder att

dem mellanliggande händelserna är del-system och komponenter. I felträdet är delsystemens

och komponenternas position relativa till deras koder och baseras på Scanias BTI-system. Alltså

i den hierarkiska ordningen del-systemet och komponenterna sorteras enligt deras BTI-koder.

Den hierarkiska ordningen presenteras även i FMEA.

Grundhändelserna är de felmoder från FMA som är kopplat till individuella komponenter.

Grundhändelserna/felmoderna har som nämnt innan symptom kopplade till sig. Symptomen

har sannolikhetsvärden baserat på deras förekomst vid felmoder kopplade till sig. Data för

symptomen förvaras förslagsvis i separat databas från FMEA.

Symptomens sannolikhetsdata används i felträdsanalysen för den kvantitativa analysen i

felträdet. Till exempel om det är två potentiella felmoder som matchar med de angivna

kundsymptomen och felmoderna grundarsig i en och samma komponent. Komponenterna har

både de matchande kundsymptomen samt några som sticker ut för var och en. I detta fall kan

det avgöras att den ena felmoden har en kombination av symptom som har större sannolikhet

lx

att ske än den andra genom att använda alla symptomen som finns för de två felmoderna och

jämföra deras sannolikhet för deras kundsymptom. Detta blir då en avgörande sållning för

vilken av felmoderna som troligast är felet med komponenten. Samtidigt används

komponentens sannolikhet i samma syfte om felmods matchningen för kundsymptomen finns

för en annan komponent. Här har då både komponentens sannolikhet och symptomens

sannolikhet använts för att avgöra vad som är felet.

I ett felträd ska inte samma event återkomma flera gånger, detta skapar ett dilemma om ett event

är en felmod och flera komponenter kan ha gemensamma samma felmod. Däremot finns det ett

sätt att undkomma detta och det är genom ”minimal cut-set” tekniken, som används för den

kvalitativa analysen. ”Minimal cut-sets” innebär att man sorterar ut grenar av trädet med hjälp

av sannolikheten för grenarna att hända. En gren med en mindre sannolikhet för att ha orsakat

det oönskade felet sorteras bort, och en gren med större sannolikhet att ha orsakat problemet

ses över istället för att hitta grundorsaken, detta är den kvalitativa analysen. På detta sätt har det

då undvikits att använda samma event inom samma felträd för analysen av felträdet. En gren

kan bestå av mellanliggande händelser och grundhändelser

En FMEA bör hållas uppdaterad, så att den innehåller aktuella kundsymptom. Både att

kundsymptomen kan detekteras av kunder och att kundsymptomen används bör kontrolleras

(Ingen nytta med kundsymptom som inte leder till lösning, används eller kan detekteras). Att

hålla värden uppdaterade gäller även för sannolikhets värdet för komponenterna.

Uppdateringen kan göras för kundsymptomen, genom att spara värden för kundsymptomen i

data bas. Till exempel om ett kundsymptom använts 100 gånger medan ett annat 10 000 gånger,

detta kan aktivt jämföras. Det kan då även hjälpa att hålla kundsymptomen uppdaterade och

signalera för revision av det kundsymptomet som utmärker sig. Om värdet för kundsymptomet

exempelvis är ”antal fall kundsymptomet hjälpt att lösa felet” kan denna data samlas in genom

en fråga eller standardiserad dokumentering vid avslutat felsöknings-fall, förslagsvis i

felsökningsprogram eller annat relevant rapporteringsprogram. När det gäller sannolikhets

värdet för komponenterna är det även för de värdena viktigt att vara uppdaterade, detta kan

göras genom att samla in fältdata från verkstäder, till exempel genom felsökningsprogrammet.

lxi

I ”FTA exemplet” tas ingen hänsyn till vilka grindar som används eftersom dessa beror på fallet

i säg. Det gör också att beräkningarna dvs hur man beräknar de olika sannolikheter inte bör ses

som ett facit utan bara ett exempel.

En nackdel med att använda felträdsanalysen är att det tar lång tid att bygga upp ett system i

formatet. Dock finns en lösning på detta och det är genom användning av MBDA (Model-Based

Dependability Analysis). Med MBDA kan en FTA byggas upp automatiserat eller semi-

automatiserat.

En fördel med att använda sig av en datadriven FTA är att resultatet för sökningen i trädet kan

presenteras på ett logiskt sätt som är lätt att läsa av och förstå. Det ger också fördelen att kunna

se vad det finns för andra potentiella felmoder med fordonet på ett lättförståeligt sätt. Flödet av

komponenternas inverkan i systemet är tydligt presenterat, vilket ger en förklaring till hur

systemet fungerar och kan hjälpa en mindre erfaren felsökare att förstå systemet.

Koncept 6

Detta koncept valdes som det slutgiltiga konceptet. För beskrivning av detta koncept se 5.1

Presentation av valt slutgiltigt koncept.

lxii

Bilaga J – Pughs matris

lxiii

Bilaga K – Motivering till uppfyllnad av kritiska och önskade krav

Kravlista Motivering uppfyllelse av kraven

Kritiskt krav:

Identifiera kategorier av data som

är nödvändiga för att formalisera

kundsymptom och som möjliggör

att en sammankoppling mellan

kundsymptom och

systemreaktioner kan uppnås.

Påverkar mål: (1), (2)

Formatet för kundsymptomen i konceptet resulterade i

avvikelse, position och kontext, för mer information, se

avsnitt 5.1.1 rubrik Format för kundsymptom. Enligt

stödjande teori, se 2.4 Formalisering av kundsymptom

och insamlad data från intervjuer, se 4.4 Kartläggning

av den befintliga initiala felsökningsprocessen, har

format för kundsymptom kunnat identifieras och

skapata till det resulterande konceptet. Enligt stödjande

teori se 2.3.2 Case-Based Reasoning kan en koppling

mellan kundsymptom och systemreaktioner även ske.

Kritiskt krav:

Identifiera kategorier av data som

är nödvändiga för att formalisera

FMEA som möjliggör att en

sammankoppling mellan

kundsymptom och

systemreaktioner kan uppnås.

Påverkar mål: (2)

Format för FMEA exkluderades i det resulterande

konceptet på grund av att FMEA ansågs överflödig i

samband med ett CBR-system. Därmed så stryks detta

krav från kravlistan då det inte är ett relevant krav för

den framtagna metoden.

Kritiskt krav:

Identifiera vetenskapligt grundade

felsökningsmetoder som kan

tillämpas för att sammankoppla

kundsymptom med

systemreaktioner.

Påverkar mål: (1)

I konceptet presenteras främst metoden CBR som

lösningen för sammankopplingen mellan kundsymptom

och systemreaktioner. CBR är en vetenskapligt grundad

metod för att sammankoppla nya problem med tidigare

lösta fall, se 2.3.2 Case-Based Reasoning. I metoden

används CBR-system för att kunna sammankoppla

systemreaktioner med kundsymptom vilket anses

likgiltigt till problem och tidigare lösta fall. Även

tillhandahåller metoden Bayesiska nätverk en stödjande

del i konceptet, vid problem att fler matchningar sker av

fall från ”case library”, se 5 Resultat. Bayesiska nätverk

är även en vetenskapligt grundande metod för

felsökning se 2.3.1 Bayesiska nätverk.

Kritiskt krav:

Metoden skall kunna hantera

kundsymptom som både grundas i

elektroniska fel och mekaniska

fel.

Påverkar mål: (1)

I det resulterande konceptet presenteras ett format för

formalisering av kundsymptom; avvikelse, position och

kontext se avsnitt 5.1.1 rubrik Format för

kundsymptom. Formatet tillåter att förmedla

observationer för både mekaniska fel och elektroniska

fel. (Exempelvis kan en motorlampa detekteras i

informationsklustret i fordonet och förmedlas med

formatet på kundsymptomen lika väl som en punktering

på ett däck som inte har lufttryckssensorer.)

Kritiskt krav:

Metoden skall ta hänsyn till den

detaljrikedom av information som

Metoden tar hänsyn till kundens tekniska kompetens då

inga tekniska kunskaper behövs för att kunna förmedla

information genom det utvecklade formatet för

lxiv

en kund är kapabel till att ge

kundmottagaren med sin tekniska

kompetens.

Påverkar mål: (1), (2)

kundsymptomen; avvikelse, position och kontext, se se

avsnitt 5.1.1 rubrik Format för kundsymptom.

Önskat krav:

Metoden skall vara applicerbar

inom samtliga system, som

exempelvis broms- och

motorsystemet, i ett tungt fordon.

Påverkar mål: (1)

Metoden kan användas för att samla in kundsymptom

inom alla system då formatet för kundsymptomen inte

sätter några gränser för angivelsen av vilket system

kundsymptomet tillhör. I konceptet används CBR-

systemet för att samla in kundsymptom och

systemreaktioner i den uppstartande fasen, CBR-

systemet används sedan i den faktiska fasen för

hämtning av matchning mellan tidigare lösta fall och det

aktuella problemet. Teori stödjer även, se 2.3.2 Case-

Based Reasoning att hämtningen av matchande fall är

relativt fri och kan skräddarsys. Detta resulterar i att

metoden inte har några hämningar för att alla system i

ett fordon inte skall kunna dokumenteras och matchas i

det resulterande konceptet.

Önskat krav:

Metoden skall förebygga brister

som existerar i den nuvarande

initiala felsökningsprocessen.

Påverkar mål: (1)

Metoden förebygger brister så som missbedömningar,

missvisande felkoder, förlitande på erfarenhet med

mera, se 7 Diskussion för mer info.

Önskat krav:

Metoden skall ta hänsyn till vad

”bra” data är för en felsökare.

Påverkar mål: (1), (2)

Det resulterande konceptet tar hänsyn till vad ”bra” data

är för en felsökare genom att involvera avvikelse,

position och kontext. De 3 kategorierna av data för

formatet på kundsymptom grundar sig i insamlad

information från intervjuerna, då nämnt av felsökare, se

avsnitt 4.4 rubrik Brister och förbättringsmöjligheter

och kategorin position som kan liknas topografi stödjs

även av den insamlade teorin, för felsökare , se 2.4.1

Jämförelse mellan erfaren och oerfaren felsökare.

Önskat krav:

Metoden skall tillhandahålla

möjlighet till förslag på åtgärd i

framtida symptombaserat

felsökningsverktyg.

Påverkar mål: (1), (2)

I vanliga fall i ett CBR-system dokumenteras problem

och lösning/åtgärd , se 2.3.2 Case-Based Reasoning.

Det resulterande konceptet är anpassad efter studiens

ramar och involverar då endast kundsymptom och

systemreaktioner. Det finns inget som motsäger att

Scania lika väl kan dokumentera kundsymptom och

åtgärd. Därför anses kravet uppfyllt.

Önskat krav:

Metoden skall vara tillämpar till

samtliga generationer av Scanias

fordon.

Påverkar mål: (1)

Eftersom att fall kan skapas för alla fordon och modeller

inom Scania i ett CBR-system kan därför kravet anses

vara uppfyllt. Det enda som håller tillbaka möjligheten

är Scanias kunskap om fordonets systemreaktioner.

Detta kan dock lösas genom den uppstartande fasen i

metoden, där systemreaktioner dokumenteras.