Flowchart for forebyggende vedligeholdelsesproces (møbelproduktionsudstyr)

Hvad er flowchart for forebyggende vedligeholdelsesproces (møbelproduktionsudstyr)?

En PM-programs reelle test er ikke, om vedligeholdelse fuldfører tjeklisten — det er, om planen faktisk følges, når en maskine er midt i en produktionskørsel. Denne skabelon behandler den spænding direkte: en PM-forfaldsdato, der lander på en maskine, der aktuelt kører et job, springes ikke stiltiende over — den genplanlægges til det næste planlagte nedetidsvindue, hvilket er en beslutning, ikke en forsømmelse.

Testcyklusporten før underskrift findes, fordi en fuldført tjekliste og en maskine, der faktisk er klar til at køre, ikke automatisk er det samme. At køre en reel testcyklus, efter lockout er fjernet, er det, der fanger et problem, selve tjeklisteformatet kan overse — noget der først viser sig, når maskinen faktisk kører igen.

Processen kører hen over fire faser (planlægning, arbejdsordre, udførelse og verifikation) og tre baner (Vedligeholdelse, Produktionsplanlægning og Linjeleder), og leder enhver defekt fundet under PM, der går ud over rutinemæssig vedligeholdelse, ind i maskinsammenbrudsresponsprocessen frem for at forsøge at presse den ind i PM'ens eget omfang.

Hvad dette flowchart dækker

I denne skabelon

• En plan-versus-produktionsbehov-kontrol, der genplanlægger PM til den næste planlagte nedetid frem for at tvinge en afbrydelse igennem eller stiltiende springe den over.
• Obligatorisk lockout/tagout, før nogen PM-opgave begynder, behandlet som et forudsætningstrin frem for en antaget praksis.
• En defekteskaleringsvej, der leder alt ud over rutinemæssig vedligeholdelse til maskinsammenbrudsresponsprocessen og holder PM's omfang fra stille at udvide til uplanlagt reparation.
• En testcyklusverifikation efter fjernelse af lockout, adskilt fra og efter selve PM-tjeklisten.
• Registreret fuldførelse, der nulstiller det næste PM-interval og holder planen nøjagtig frem for at drive fra den oprindelige plan.

Hvornår du skal bruge skabelonen

• I dokumenterer jeres PM-program, og den nuværende proces har ingen defineret vej for, hvad der sker, når en planlagt PM konflikter med et kørende job.
• PM-tjeklister markeres som fuldførte uden en efterfølgende testcyklus, der bekræfter, maskinen faktisk er klar til at køre.
• Defekter fundet under PM håndteres nogle gange inden for selve PM-opgaven og eskaleres andre gange inkonsekvent, uden en angivet regel for, hvornår hvad sker.
• I har brug for, at PM-fuldførelse automatisk nulstiller det næste planlagte interval, frem for sporet separat fra den oprindelige plan.

Sådan fungerer det

1. Giv planlægningskonflikter en reel løsning, ikke et stille spring over

   "Kører maskinen aktuelt et job, der kan sættes på pause?" bør lede til genplanlægning til det næste planlagte nedetidsvindue, ikke bare skubbe PM-datoen tilbage uden nogen journal om, hvorfor den ikke skete til tiden.

2. Gør lockout til et påkrævet trin, ikke en antaget praksis

   "Udfør lockout/tagout, før PM-opgaven startes" skal være et eksplicit, kontrolleret trin i processen — ikke noget, der antages at ske, fordi det generelt er god praksis.

3. Led defekter ud over rutinemæssigt omfang til sammenbrudsrespons

   "Afslører PM en defekt ud over rutinemæssig vedligeholdelse?" bør sende det fund ind i maskinsammenbrudsresponsprocessen, som har sin egen diagnose- og reparationsautorisationslogik, frem for at forsøge at løse det inden for PM-opgavens eget omfang.

4. Kræv en bestået testcyklus før underskrift, ikke bare en fuldført tjekliste

   Testcyklussen efter fjernelse af lockout er det, der faktisk bekræfter, maskinen kører korrekt — en fuldført tjekliste alene garanterer ikke det, da nogle problemer først dukker op, når maskinen kører igen.

Ofte stillede spørgsmål

Hvad sker der, når en planlagt PM konflikter med et job i gang?

Diagrammet leder til at genplanlægge PM'en til det næste planlagte nedetidsvindue, med produktionsplanlægning involveret i den beslutning — frem for enten at tvinge jobbet til at stoppe eller lade PM-datoen stiltiende glide uden nogen journal om, hvorfor den blev overset.

Hvorfor bliver en defekt fundet under PM nogle gange ledt til en separat sammenbrudsproces?

Fordi PM er designet til rutinemæssige, planlagte vedligeholdelsesopgaver, ikke til at diagnosticere og reparere en uventet fejl. Når en PM-kontrol afslører noget ud over det rutinemæssige omfang, har maskinsammenbrudsresponsprocessen den diagnose- og reparationsautorisationsstruktur, den situation faktisk har brug for, frem for at strække PM-opgaven til at dække det.

Hvorfor har maskinen brug for en testcyklus efter PM, ikke bare en fuldført tjekliste?

Fordi en tjekliste bekræfter, individuelle punkter blev kontrolleret eller serviceret, men ikke nødvendigvis bekræfter, maskinen kører korrekt som helhed, når alt er samlet igen, og lockout er fjernet. En testcyklus er det, der faktisk verificerer, maskinen er klar til at vende tilbage til produktion, og fanger et problem, tjeklisteformatet måske ikke afslører.

Hvordan hænger dette sammen med træbearbejdningsmaskin- og CNC-maskinvedligeholdelsesprocesserne?

Dette er planlægnings- og programniveauprocessen — hvornår PM sker, hvordan den anmodes, og hvordan fuldførelse verificeres og registreres. Træbearbejdningsmaskinvedligeholdelsesprocessen og CNC-maskinvedligeholdelsesprocessen er de detaljerede opgaveudførelsesprocedurer for, hvad der faktisk sker under selve PM'en, specifikt for hver type udstyr.