Servisa diagnostikas gadījumu bibliotēka: foruma izpēte pārbaudītās piezīmēs

Foruma izpētes vērtīgākā daļa ir pārbaudīts rezultāts

Tehniķis var pavadīt stundu, meklējot pareizo foruma tēmu, salīdzinot vairākus remonta gadījumus, pārbaudot transportlīdzekli un apstiprinot bojājumu. Trīs mēnešus vēlāk cits tehniķis saņem to pašu problēmu un sāk izpēti no nulles.

Informācija tehniski bija noderīga, taču tā nekad nekļuva par darbnīcas zināšanām.

Diagnostikas gadījumu bibliotēka risina šo problēmu. Tā glabā transportlīdzekļa kontekstu, pierādījumus, avotu saites, pārbaudes, galīgo remontu un pārskatīšanas statusu formātā, ko cits tehniķis var saprast. Tā nekopē veselus forumus un nevāc nejaušas lejupielādes. Tā fiksē to, ko darbnīca patiešām pārbaudījusi.

Gadījumu bibliotēka nav ekrānuzņēmumu mape

Nesakārtoti ekrānuzņēmumi, lejupielādēti arhīvi un kopēti foruma komentāri ir grūti meklējami un viegli pārprotami. Pareizai gadījumu bibliotēkai ir konsekventa struktūra un tā skaidri nodala:

• ko parādīja transportlīdzeklis;
• ko ieteica foruma lietotājs;
• ko darbnīca pārbaudīja;
• kas salaboja transportlīdzekli;
• kas paliek neskaidrs.

Šis nošķīrums novērš to, ka tiešsaistes viedoklis tiek uztverts kā apstiprināta darbnīcas procedūra.

Kas jāglabā katrā gadījumā

Katrā gadījumā jābūt pietiekami daudz informācijas, lai tas būtu noderīgs, neatklājot lieku klienta datu.

Ieteicamie lauki:

• iekšējais gadījuma numurs;
• transportlīdzekļa marka, modelis un izlaiduma gads;
• dzinēja kods;
• modulis vai ECU saime;
• aparatūras un programmatūras identifikācija, ja attiecināms;
• klienta sūdzība neitrālā valodā;
• pilns DTC teksts;
• sākotnējās skenēšanas un mērījumu kopsavilkums;
• iepriekšējais remontu vēsture, kas saistīta ar bojājumu;
• foruma vai tehnisko avotu saites;
• izskatītās hipotēzes;
• veiktās pārbaudes;
• apstiprinātais pamatcēlonis;
• veiktais remonts;
• pēcremonta apstiprinājums;
• tehniķis un pārskatīšanas datums.

Gadījumam jābūt saprotamam, neatverot katru avota saiti.

Nodaliet pierādījumus, hipotēzi un secinājumu

Šis ir vissvarīgākais redakcionālais noteikums bibliotēkā.

Kad šīs kategorijas tiek sajauktas kopā, nākamais tehniķis nevar atšķirt, kas tika izmērīts un kas bija tikai ieteikums.

Izmantojiet standarta gadījuma virsrakstu

Virsrakstiem jābūt meklējamiem un tehniskiem. Izvairieties no neskaidriem nosaukumiem, piemēram, „BMW problēma”, „ECU salabots” vai „interesants foruma gadījums”.

Noderīgs virsraksta formāts ir:

 Transportlīdzeklis / Dzinējs / Modulis / Galvenais DTC vai simptoms / Apstiprinātais cēlonis 

Piemēri:

 VAG 2.0 TDI / EDC17 / P0299 / Apstiprināta uzpūtes gaisa noplūde
BMW Diesel / DDE / Sliedes spiediena kritums / Zema spiediena padeves ierobežojums
Mercedes / ABS / Periodisks riteņu ātruma signāls / Savienotāja saspiedes bojājums 

Nelietojiet klientu vārdus, pilnu VIN vai reģistrācijas numurus virsrakstā.

Izveidojiet kontrolētu statusu sistēmu

Ne katram saglabātam gadījumam ir vienāda uzticamība. Pievienojiet redzamu statusa apzīmējumu.

• Tikai izpēte: avots saglabāts, darbnīcas pārbaude nav pabeigta.
• Daļēji pārbaudīts: daļa detaļu sakrīt, pamatcēlonis nav apstiprināts.
• Darbnīcā pārbaudīts: bojājums atjaunots, remonts pabeigts un rezultāts apstiprināts.
• Atkārtots: tā pati darba plūsma izdevusies vairāk nekā vienā atbilstošā gadījumā.
• Novecojis: rīks, programmatūra vai procedūra vairs nav aktuāla.
• Noraidīts: iepriekšējais secinājums bija nepareizs vai nedrošs.

Tehniķim jāspēj redzēt statusu pirms gadījuma izmantošanas.

Reģistrējiet avota kvalitāti

Foruma informācija ļoti atšķiras. Bibliotēkai jāparāda, kāpēc avots tika uzskatīts par noderīgu.

Noderīgas piezīmes par avota kvalitāti ietver:

• precīzu ECU vai programmatūras atbilstību;
• iekļauti pilni skenēšanas dati;
• parādīti mērījumi;
• sākotnējais autors apstiprināja remontu;
• vairāki lietotāji apstiprināja to pašu modeli;
• tika norādīta rīka vai programmatūras versija;
• tēma bija tikai ieteikums un paliek nepārbaudīta.

Nepiešķiriet autoritāti, balstoties tikai uz ziņu skaitu, lietotājvārdu vai pārliecinātu valodu.

Saistiet uz avotiem, nevis kopējiet visu

Ja iespējams, saglabājiet tēmas URL, virsrakstu, autora datumu un īsu kopsavilkumu. Nekopējiet veselas aizsargātas diskusijas, privātas ziņas vai komerciālus failus darbnīcas bibliotēkā.

Katram avotam reģistrējiet:

• foruma nosaukumu;
• tēmas virsrakstu;
• avota saiti;
• piekļuves datumu;
• tehniskās atbilstības līmeni;
• vienu vai divus teikumus, kas izskaidro, kāpēc avots bija svarīgs.

Ja avots vēlāk pazūd, darbnīca joprojām saglabā savus mērījumus, pārbaudes plānu un pārbaudīto secinājumu, neatveidojot visu trešās puses publikāciju.

Neglabājiet konta akreditācijas datus gadījumu piezīmēs

Foruma lietotājvārdi, paroles, marķieri, sīkfaili un privātās piekļuves dati nekad nedrīkst tikt ievietoti koplietotā diagnostikas dokumentā.

Glabājiet konta pārvaldību atsevišķi no tehnisko gadījumu ierakstiem. Gadījumu bibliotēkā var norādīt, ka avots nāca no MHHAuto, CarTechnology vai CarMasters, bet tajā nedrīkst būt pieteikšanās informācija.

Aizsargājiet klientu un transportlīdzekļa datus

Tehniskam gadījumam reti vajadzīga klienta personiskā informācija. Piemērojiet minimālo datu noteikumu.

Parasti noņemiet vai ierobežojiet:

• klienta vārdu;
• tālruņa numuru un e-pastu;
• mājas vai biznesa adresi;
• pilnu VIN, ja tas nav darbības ziņā nepieciešams;
• reģistrācijas numuru;
• maksājumu informāciju;
• atrašanās vietas vēsturi;
• privāto foruma saraksti.

Izmantojiet iekšējo remonta pasūtījuma numuru, lai savienotu tehnisko gadījumu ar darbnīcas pārvaldības sistēmu, kad pilnvarotam personālam nepieciešams pilns ieraksts.

Izveidojiet tagu sistēmu, kuru tehniķi tiešām izmantos

Pārāk daudz tagu padara bibliotēku nekonsekventu. Izmantojiet nelielu kontrolētu sarakstu.

Ieteicamās tagu grupas:

• Transportlīdzeklis: marka, platforma, dzinēja saime.
• Sistēma: dzinējs, transmisija, ABS, ADAS, virsbūve, imobilaizers, HVAC.
• Bojājuma veids: nav sakaru, periodisks, spriegums, spiediens, signāls, programmēšana.
• Rīks: skeneris, oscilogrāfs, programmētājs vai izmantotā datu platforma.
• Rezultāts: vadu remonts, komponenta remonts, programmatūras atjaunināšana, savienotāja remonts, bojājums nav atrasts.
• Statuss: izpēte, pārbaudīts, atkārtots, novecojis vai noraidīts.

Izvēlieties vienu rakstību katram tagam. „Nav sakaru”, „nav komunikācijas” un „modulis bezsaistē” nedrīkst kļūt par trim atsevišķām iekšējām kategorijām.

Praktiska gadījuma veidne

 GADĪJUMA NUMURS:
DATUMS:
TEHNIĶIS:
STATUSS:

TRANSPORTLĪDZEKLIS:
DZINĒJS / TRANSMISIJA:
MODULIS / ECU:
HW / SW IDENTIFIKĀCIJA:

KLIENTA SŪDZĪBA:
SĀKOTNĒJIE DTC:
SĀKOTNĒJIE APSTĀKĻI:

PIERĀDĪJUMI:
1.
2.
3.

FORUMA / TEHNISKIE AVOTI:
1.
2.

HIPOTĒZES:
1.
2.

VEIKTĀS PĀRBAUDES:
1.
2.

APSTIPRINĀTAIS PAMATCĒLONIS:

REMONTS:

PĒCREMONTA PĀRBAUDE:

ATLIKUŠIE IETEIKUMI:

NĀKAMĀS PĀRSKATĪŠANAS DATUMS: 

Pabeigtam gadījumam nav jābūt garam. Tam jābūt precīzam.

Darba plūsmas piemērs no foruma tēmas līdz pārbaudītam gadījumam

Iedomājieties, ka transportlīdzeklis ierodas ar periodisku sakaru bojājumu.

1. Tehniķis saglabā pilnu skenēšanu un pārbauda akumulatora spriegumu.
2. Foruma izpēte atrod divus līdzīgus gadījumus, kas saistīti ar to pašu moduļa saimi.
3. Viena tēma iesaka nomainīt moduli; cita parāda vadu bojājumu starpsavienotājā.
4. Darbnīca abus ieteikumus atzīmē kā hipotēzes, nevis secinājumus.
5. Remonta dati tiek izmantoti, lai identificētu savienotāju un ķēdi.
6. Sprieguma krituma un termināla pārbaudes apstiprina augstu pretestību savienotājā.
7. Savienotājs tiek salabots, un sakaru pārbaude tiek atkārtota.
8. Gadījums tiek saglabāts kā „Darbnīcā pārbaudīts”, ar foruma tēmām, kas norādītas kā izpētes avoti.

Bibliotēka reģistrē to, ko darbnīca ir pierādījusi, nevis to foruma atbildi, kas izklausījās vispārliecinošāk.

Pārskatiet vecos gadījumus

Automobiļu programmatūra, rīku protokoli un ražotāja procedūras mainās. Pievienojiet pārskatīšanas datumu gadījumiem, kas saistīti ar: