Driftstopp är varje period då en tillgång eller ett system inte kan användas, oavsett om det beror på fel, underhåll eller externa orsaker.
Driftstopp är varje period då en tillgång eller ett system inte kan användas - för att den har gått sönder, servas eller för att något utanför den (ström, delar, personal) saknas. Det är spegelbilden av tillgångens drifttid: varje timme en tillgång skulle arbeta men inte gjorde det. Ordet täcker både en fabrikslinje som står still och en sladdlös borr i verkstaden; skalan skiljer sig, logiken inte.
Planerat och oplanerat driftstopp
Den mest användbara uppdelningen är inte vad som orsakade driftstoppet utan om någon valde det. Planerat driftstopp är schemalagt - service, inspektioner, uppgraderingar, rengöring - och tidpunkten väljs för att göra minst skada. Oplanerat driftstopp bestämmer tillgången åt dig, oftast mitt i användning, vilket är varför en timme kostar flera gånger en planerad timme: pågående arbete stannar, någon stressar för att diagnostisera, delar beställs i hast och åtaganden glider. Sambandet mellan de två är kärnan i underhållsavvägningen, mer i planerat och oplanerat underhåll: acceptera liten, schemalagd otillgänglighet för att undvika stor, slumpmässig otillgänglighet.
Var de verkliga kostnaderna gömmer sig
Den synliga kostnaden för driftstopp är reparationsfakturan. De större kostnaderna ligger oftast runt den:
- Stillastående arbetskraft - laget som inte kan arbeta för att maskinen, skåpbilen eller vitvaran de behöver är ur drift.
- Ersättning - hyreskostnader för ersättning, eller den tysta skadan av att göra jobbet med fel verktyg.
- Dominoeffekt - missade tider, omplanerade kunder, övertid för att komma ikapp.
- Ryktet - kunden som upplevde förseningen minns den längre än du gör.
Därför kan två identiska haverier kosta helt olika beroende på när de inträffar och vad som väntade på tillgången.
Mäta driftstopp
Små team behöver ingen tillgänglighetsdashboard för att börja - de behöver en post om när varje tillgång gick ur drift och när den kom tillbaka. Därifrån får du grunderna: totala timmar nere per tillgång per period, och driftstopp uppdelat efter orsak (fel, service, väntan på delar, väntan på beslut). Uppdelningen är insikten. “Väntan på delar” som dominerar totalen pekar på att lagra kritiska reservdelar; “väntan på beslut” pekar på ett processproblem, inte ett utrustningsproblem. Upprepade syndare syns snabbt när historiken är per tillgång i stället för per minne.
Minska driftstopp
Spakarna, ungefär i billighetsordning: gör inspektionerna som fångar fel tidigt; håll servicehistorik per tillgång så upprepade syndare syns och kan fixas ordentligt eller pensioneras; gör oplanerat arbete planerat genom service enligt schema i stället för vid fel; håll en arbetad underhållskö så små fel inte köar tills de blir stora; och för verkligt kritisk utrustning, ha en reserv. Inget av detta är glamoröst, vilket är varför det rutinmässigt hoppas över.
Driftstopp i praktiken
Vanan som gör allt annat möjligt är att markera statusändringen: i det ögonblick en tillgång går ur drift ska posten säga det, med en orsak. I AMPthilly ger det att sätta en tillgångs status till under reparation och skapa ett serviceärende teamet en livevy över vad som är nere och varför, och lämnar permanent reparationshistorik på tillgången - så du senare ser maskinen som tyst varit nere fem gånger i år.
Relaterade termer
- Tillgångens drifttid - tillgänglighetsprocenten som driftstopp drar ifrån
- Planerat och oplanerat underhåll - avvägningen som avgör vilken typ av driftstopp du får
- Underhållskö - kön av utestående arbete som matar framtida driftstopp
- CMMS - programkategorin fokuserad på att schemalägga arbete för att minimera driftstopp
- Servicenivåavtal - det formella tillgänglighetsåtagande driftstopp mäts mot