Flowchart for fejlfinding på maskiner (beslutningstræ)

Hvad er flowchart for fejlfinding på maskiner (beslutningstræ)?

Fejlfinding er en række spørgsmål, ikke en række opgaver. En operatør, der står foran en stoppet maskine, har ikke brug for at vide, hvem der opretter arbejdsordren, eller hvem der godkender jobbet til sidst. Vedkommende har brug for at vide, hvad der skal tjekkes først, hvad han eller hun må røre ved, og på hvilket punkt fejlen ikke længere er hans eller hendes. Et beslutningstræ svarer præcis på det, fordi hver kasse er en test med et defineret svar, og hvert svar fører hen til noget, der har et navn.

Denne side er beslutningstræet, ikke procesdiagrammet, og den forskel er værd at være præcis omkring. Dette diagram svarer på, hvilken mulighed vi vælger, og hvem der bestemmer: er maskinen sikker at gå til, ligger fejlen inden for operatørens ansvar, nulstiller vi selv eller tilkalder vi, venter vi på en reservedel eller går vi til producenten. Det samlede forløb, der begynder, når en fejl eskaleres (arbejdsordren, tildelingen og planlægningen af teknikeren, registreringen af nedetid på anlægget, lukningen af jobbet og opdateringen af anlægshistorikken), hører til procesdiagrammet for maskinnedbrud på /da/templates/maskinnedbrud-proces. Brug det til, hvad der sker bagefter, og hvem der gør det. Brug dette til det valg, der træffes ved maskinen, i minutterne før nogen anden er involveret. Bliver den samme fejl ved med at komme igen, når træet er kørt igennem, er næste skridt rodårsagsanalysen på /da/templates/rodaarsagsanalyse-proces.

Diagrammet herunder går fra en stoppet maskine til fem forskellige slutpunkter frem for én lykkelig sti: produktionen genoptaget efter en operatørrettelse, en tekniker der reparerer og afleverer, en bestilling af en reservedel, support fra producenten eller en ekstern partner, og en eskalering som nedbrud med registreret nedetid. Ni beslutninger sidder på rygraden fordelt på fire baner, og de afgørende bærer deres kriterier som noter på selve trinnet, for et beslutningstræ er kun brugbart, hvis testene bag spørgsmålene står skrevet ned.

Hvad dette flowchart dækker

I denne skabelon

• Fire baner, der navngiver, hvem der svarer på hvert spørgsmål, frem for et fuldt afdelingskort (Operatør, Skiftleder, Vedligeholdelsestekniker og Vedligeholdelsesplanlægger) fordelt på fem faser: Sikring, Første tjek, Klassificér fejlen, Første afhjælpning og Eskalering
• En sikkerhedsport før al diagnose: 'Er maskinen sikker at gå til?' forgrener Ja videre til de første tjek og Nej til 'Afbryd og lås maskinen af', som derefter går direkte til eskaleringsbeslutningen, så ingen fejlfinder på en maskine i drift
• To faktatjek i operatørbanen: 'Er strøm og forsyninger til stede?' (Nej fører til 'Genopret den manglende forsyning' og derfra til verifikationen) og 'Vises der en fejlkode eller alarm?', hvor Ja sender operatøren ud for at slå koden op, før noget klassificeres
• En port for beslutningsret i skiftlederbanen, 'Inden for operatørens ansvar?', der forgrener Inden for eller Tekniker, efterfulgt af 'Hvilken type fejl er det?' med tre grene (Forbrugsdel, Indstilling og Mekanisk), hvor mekaniske fejl helt forlader operatørens vej
• Verifikation frem for antagelse: 'Er fejlen væk efter en prøvekørsel?' ender enten i slutpunktet 'Genoptag produktionen og log rettelsen' eller i eskalering, så en rettelse, der ikke holdt, aldrig behandles som en rettelse
• Eskalering opdelt efter fakta og ikke efter anciennitet: 'Er produktionen stoppet af fejlen?' skiller et registreret nedbrud med nedetid fra et almindeligt tilkald, hvorefter 'Kan det repareres med egne kompetencer?' og 'Er reservedelen på lager?' fører til slutpunkterne tekniker-aflevering, producentsupport og bestilling af reservedel

Hvornår du skal bruge skabelonen

• Operatørerne tilkalder vedligehold ved fejl, de selv kunne have afhjulpet, og I vil have de første tjek og grænsen for operatørens ansvar skrevet ned frem for forhandlet fra vagt til vagt
• I skriver en maskin-SOP, et vagtoverleveringsark eller et lamineret kort til maskinen og har brug for én side, en operatør kan følge uden at læse en hel procedure
• Nedetidstallene er utroværdige, fordi ingen er enige om, hvornår en fejl bliver til et registreret nedbrud, eller hvornår uret starter
• Nye operatører, vikarer og oplærte afløsere skal følge den samme fejlfindingsrækkefølge som de erfarne, herunder vide, hvornår de skal stoppe
• I har allerede en samlet vedligeholdelses- eller nedbrudsproces og mangler det beslutningslag, der fodrer den med rene, korrekt klassificerede eskaleringer

Sådan fungerer det

1. Omdøb banerne til jeres egen beslutningsret

   Erstat Operatør, Skiftleder, Vedligeholdelsestekniker og Vedligeholdelsesplanlægger med de roller, der reelt svarer på hvert spørgsmål hos jer. Banerne er bevidst få, fordi et beslutningstræ viser, hvem der bestemmer, ikke hvem der udfører arbejdet. Har jeres skiftledere ikke mandat til at frigive et tilkald, så flyt den beslutning til den bane, der har mandatet, og slet enhver bane, der ikke har noget at svare på.

2. Skriv sikkerhedstesten frem for bare at skrive 'sikker'

   'Er maskinen sikker at gå til?' kan kun besvares, hvis kriterierne står på trinnet: afskærmning intakt, maskinen står stille, oplagret energi afladet, og der er afbrudt og låst af, hvor opgaven kræver det. Peg trinnet mod jeres egen procedure for sikker afbrydelse (i Danmark hviler pligten på Arbejdstilsynets regler om anvendelse af tekniske hjælpemidler), og sørg for, at enhver tvivl ender som et Nej.

3. Skriv de forsyninger op, en operatør må tjekke

   Lav 'Er strøm og forsyninger til stede?' om til en rigtig tjekliste for jeres udstyr: net- og styrestrøm, trykluft eller hydraulik, materiale og kølemiddel, afskærmninger lukket, nødstop nulstillet, sikkerhedsafbrydere sluttet. Det er den billigste gren i træet og den, der fjerner flest tilkald, der kunne have været undgået, så den skal være specifik for maskinen frem for generisk.

4. Definér operatørens ansvarsområde skriftligt

   'Inden for operatørens ansvar?' er den beslutning, der afgør de fleste eskaleringer, og den skrider, hvis den ikke er dokumenteret. Skriv de tilladte førstelinjeopgaver op mod jeres kompetencematrix og maskinens SOP, og skriv derefter undtagelserne rent ud: ingen afmontering af afskærmninger, ingen eltavler, ingen ændring af parametre og intet, operatøren ikke er godkendt til. Gennemgå listen, hver gang kompetencematrixen ændres.

5. Bliv enige om, hvornår en fejl bliver et nedbrud

   'Er produktionen stoppet af fejlen?' er dét, der skiller et registreret nedbrud fra et almindeligt tilkald, og den driver jeres nedetidsdata. Aftal én definition (typisk en linje, der ikke kan køre, eller som producerer uden for specifikationen) og ét starttidspunkt, nemlig da maskinen stoppede, ikke da vedligehold svarede. Brug den ens på hver eneste vagt, ellers kan tallene ikke sammenlignes.

6. Tjek kompetence, værktøj og garanti, før I reparerer selv

   'Kan det repareres med egne kompetencer?' skal have en regel bag sig: teknikeren er kompetent og godkendt til opgaven, værktøj og dokumentation er tilgængelige, og reparationen ophæver hverken en garanti eller en serviceaftale. Garantien er den, der oftest bliver overset, og det er grunden til, at Nej-grenen går til producentsupport frem for til en bestilling af en reservedel. Hold det færdige diagram versioneret og godkendt, så alle vagter arbejder ud fra den samme revision.

Ofte stillede spørgsmål

Hvad er forskellen på et fejlfindingsflowchart og et procesdiagram for vedligehold?

De svarer på hvert sit spørgsmål. Et fejlfindingsflowchart er et beslutningstræ: en kæde af tests (er det sikkert, er forsyningerne der, er der en fejlkode, ligger det inden for operatørens ansvar, holdt rettelsen), der ender i et navngivet udfald. Et procesdiagram for vedligehold eller nedbrud er en tværgående proces: meld fejlen, opret arbejdsordren, tildel en tekniker, reparér, registrér nedetiden, luk jobbet og opdatér anlægshistorikken. Fejlfindingstræet slutter normalt dér, hvor procesdiagrammet begynder, nemlig ved eskaleringen, og det er netop derfor, de fungerer bedre som to diagrammer end som ét.

Hvad skal en operatør tjekke først, når udstyret stopper?

Sikkerhed, så forsyninger, så fakta. Bekræft, at maskinen er sikker at gå til, og at den er afbrudt og låst af, hvis opgaven kræver det; intet andet sker før det. Tjek derefter de forsyninger, en operatør må tjekke (strøm, trykluft, materiale, kølemiddel, afskærmninger lukket, nødstop nulstillet), for en overraskende stor del af alle tilkald ender dér. Først derefter aflæses fejlkoden eller alarmen, og først derefter slås den op. Den rækkefølge forhindrer folk i at diagnosticere en kompliceret fejl, der viser sig at være en tom tragt eller et nødstop, ingen har nulstillet.

Hvordan afgør jeg, hvad en operatør må reparere?

Byg det på kompetence og risiko, og skriv det ned som en liste frem for som et princip. Tilladte førstelinjeopgaver er typisk udskiftning af forbrugsdele, afhjælpning af tilgængelige stop, nulstilling af alarmer og genskabelse af de indstillinger, operatøren i forvejen sætter i normal drift. De sædvanlige undtagelser er alt bag en afskærmning eller i en eltavle, alt der kræver værktøj, operatøren ikke er oplært i, og enhver parameterændring, der påvirker produktkvaliteten. Bind listen til jeres kompetencematrix, så grænsen flytter sig, når nogen bliver godkendt, ikke når en vagt er under pres.

Hvornår bliver en fejl til et registreret nedbrud?

Når den rammer en grænse, I har aftalt på forhånd og bruger konsekvent. Der findes ikke et universelt tal; mange fabrikker sætter en varighed i minutter, og det, der betyder mere end tallet, er, at alle starter uret ved den samme begivenhed. At registrere nedetid fra det øjeblik, maskinen stoppede, frem for fra tilkaldet eller teknikerens ankomst, er dét, der gør data sammenlignelige på tværs af vagter og linjer. Skriv definitionen på selve beslutningstrinnet, så reglen følger med diagrammet.

Hvad hvis den første afhjælpning virker, og fejlen kommer igen?

Det er netop derfor, dette træ verificerer frem for at antage. 'Er fejlen væk efter en prøvekørsel?' skal besvares på en fuld cyklus ved produktionshastighed med de første emner kontrolleret (ikke på en tomgangskørsel), og en fejl, der kommer igen under testen, tæller som ikke afhjulpet og går til eskalering. En fejl, der bliver ved med at vende tilbage på tværs af vagter, er ikke længere et fejlfindingsproblem: den hører hjemme i rodårsagsanalysen, hvor der indsamles dokumentation og verificeres en årsag, før der skrives endnu en korrigerende handling.