Flowchart for fejlfinding på maskiner (beslutningstræ)

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.