Wat is downtime?

Downtime (in het Nederlands ook stilstand) is elke periode waarin een asset of systeem niet bruikbaar is - omdat hij is uitgevallen, omdat er onderhoud aan wordt gedaan, of omdat iets eromheen ontbreekt: stroom, onderdelen, mensen, toestemming. Het is het spiegelbeeld van asset uptime: elk uur dat een asset had moeten werken maar dat niet deed. Het woord dekt zowel een stilstaande productielijn als een accuboormachine die in de werkplaats ligt; de schaal verschilt, de logica niet.

Het Engelse woord draagt ook een alledaagse “rust”-betekenis - downtime als pauze tussen twee diensten. Die betekenis is hier niet aan de orde. Op deze pagina is downtime een meetbare hoeveelheid, gekoppeld aan een specifieke asset over een afgebakende periode, en het hele punt van de term is dat u die kunt tellen, beprijzen en terugbrengen.

Deze gids behandelt hoe downtime verschilt van idle time en storingen, welke soorten en oorzaken het waard zijn om apart te houden, de rekensom die stilstanduren omzet in een percentage, hoe u een uur stilstand voor uw eigen bedrijf beprijst, wat een stilstandslogboek moet vastleggen, en welke knoppen de stilstand daadwerkelijk terugbrengen.

Wat u gaat leren

• Downtime vs idle time, standby en storing
• Geplande vs ongeplande downtime
• Soorten downtime
• Wat downtime veroorzaakt
• Downtime berekenen
• Wat downtime kost, en hoe u uw eigen uur beprijst
• Stilstandsregistratie: wat u vastlegt en waarom
• Downtime verminderen
• Downtime in IT vs downtime bij apparatuur
• Downtime in de praktijk
• FAQ

Downtime vs idle time, standby en storing

Er zijn meerdere woorden voor “het ding werkte niet”, en elk wijst op een ander probleem:

Het onderscheid bepaalt welke maatstaf beweegt. Downtime drukt de beschikbaarheid; idle time drukt de bezettingsgraad. Een aggregaat dat drie weken ongebruikt stond omdat geen enkele locatie het nodig had, heeft een bijna perfecte beschikbaarheid en een beroerde bezettingsgraad - en een tweede aggregaat kopen zou precies de verkeerde reactie zijn. Een aggregaat dat ongebruikt stond omdat de startmotor kapot was, is het omgekeerde geval. Een logboek dat beide als “werkte niet” vastlegt, kan u niet vertellen welke van de twee u heeft, dus koopt het team apparatuur terwijl het een planning had moeten repareren, of andersom.

Standby verdient een eigen naam, omdat het op een bezettingsrapport op verspilling lijkt en voor kritieke middelen vaak het juiste antwoord is: een reservepomp, een leenlaptop of een noodaggregaat bestaat er juist om ongebruikt te blijven tot de dag dat dat niet zo is.

Geplande vs ongeplande downtime

De nuttigste splitsing is niet wat de downtime veroorzaakte, maar of iemand die koos. Geplande downtime is ingepland - service, inspecties, kalibratie, upgrades, reiniging - en het moment wordt gekozen om de minste schade te doen. Ongeplande downtime is de asset die het voor u beslist, meestal midden in gebruik, en daarom kost een uur daarvan een veelvoud van een gepland uur: lopend werk stopt, iemand diagnosticeert onder druk, onderdelen worden met spoed besteld en toezeggingen schuiven op.

De relatie tussen beide is de kern van de onderhoudsafweging, uitgebreider behandeld onder gepland vs ongepland onderhoud: kleine, geplande onbeschikbaarheid accepteren om grote, willekeurige onbeschikbaarheid te vermijden. Een team waarvan de geplande downtime stijgt terwijl de ongeplande daalt, gaat niet achteruit - het wint, en het kopcijfer “totaal aantal uren down” verbergt dat zolang u het niet splitst.

Soorten downtime

De tweedeling gepland/ongepland is een goed begin en een slecht einde, want ze gooit stilstanden met totaal verschillende oplossingen op een hoop. Een indeling die het uithoudt bij een klein bedrijf ziet er zo uit:

• Gepland - service, inspectie, kalibratie, grondige reiniging, software-updates, geplande onderdeelvervanging. Gekozen, gedateerd en goedkoop zolang het zo blijft.
• Ongepland (storing of schade) - de asset ging kapot, viel om of kwam beschadigd binnen. De spectaculaire categorie, en meestal niet de grootste.
• Administratief - de asset is stuk en iedereen weet het, maar de reparatie wacht op een goedkeuring, een offerte, een besluit of een inkooporder. Er wordt niets gerepareerd; er wordt een formulier rondgestuurd.
• Logistiek of bevoorrading - wachten op een reserveonderdeel, op een plek in de agenda van de leverancier, op het eerstvolgende bezoek van een monteur, of op een koerier. De reparatie is duidelijk; het benodigde is nog niet binnen.
• Omgeving of extern - stroomuitval, wateroverlast, weer, locatie dicht, netwerk plat, weg geblokkeerd. Buiten uw controle, maar niet buiten uw planning.

In veel kleine bedrijven zijn de administratieve en logistieke bakken samen groter dan de storingsbak. Een riem van 40 euro die tien dagen onderweg is, kost meer dan de storing die hem knapte, en een goedkeuring die een week in iemands inbox blijft liggen is pure, vermijdbare stilstand. Die bakken zijn onzichtbaar zolang het logboek er geen reden-code voor heeft - precies daarom doen reden-codes er meer toe dan de meeste teams verwachten.

Wat downtime veroorzaakt

Achter de categorieën zit een vrij korte lijst terugkerende oorzaken:

• Uitgesteld of overgeslagen preventief onderhoud. De beurt die twee keer werd verschoven, wordt de storing die het werk stillegt. Preventief onderhoud bestaat om die stilstand te verplaatsen naar een moment dat u zelf koos.
• Verouderde assets die na hun levensduur doordraaien. Het storingspercentage loopt aan het eind van de levensduur op, en reparaties duren langer naarmate onderdelen schaarser worden. De levensduur bijhouden is wat “hij is weer stuk” verandert in een vervangingsbesluit.
• Geen voorraad van een goedkoop, kritiek onderdeel. Filters, riemen, slangen, laders, accu’s - artikelen van geringe waarde die bij afwezigheid duur werk stilleggen. Zie reserveonderdelenbeheer.
• Bedieningsfouten en onbekende gebruikers. Gedeeld materieel dat rondgaat tussen mensen die nooit uitleg kregen, valt vaker uit en valt uit op manieren die niemand snel diagnosticeert.
• Schade tijdens transport of op locatie. Apparatuur die tussen bussen, locaties en magazijnen beweegt, verzamelt stoten die nooit gemeld worden.
• Niemand wist dat hij stuk was. De meest voorkomende oorzaak in kleine teams: de laatste gebruiker zag het mankement, meldde het niet, en de volgende ontdekte het op het slechtst denkbare moment.
• Goedkeurings- en budgetknelpunten. De reparatie is in principe akkoord en in de praktijk stilgezet terwijl een bedrag wordt getekend.

Het patroon eronder verdient het om ronduit gezegd te worden: de meeste downtime is niet de storing zelf, maar de wachtrij vóór de reparatie. De uren tussen “hij is stuk” en “iemand is begonnen met repareren” zijn meestal langer dan de reparatie, en het zijn de goedkoopste uren om weg te halen.

Downtime berekenen

De rekensom is eenvoudig; de definities zijn waar teams de mist in gaan.

Stilstanduren = verwachte beschikbare uren min werkelijk beschikbare uren, over een afgebakende periode.

Stilstandspercentage = stilstanduren ÷ geplande uren × 100.

Een uitgewerkt voorbeeld: een machine is in een maand ingepland voor 160 uur. In die maand verliest hij 12 uur aan twee storingen. Het stilstandspercentage is 12 ÷ 160 = 7,5%, dus de beschikbaarheid is 92,5%, en in gewone taal: “we zijn anderhalve dag capaciteit kwijtgeraakt”.

Uit datzelfde logboek volgen twee afgeleide maatstaven:

• MTTR (mean time to repair) = totale downtime ÷ aantal incidenten. In het voorbeeld hierboven geven 12 uur over 2 incidenten een MTTR van 6 uur.
• MTBF (mean time between failures) = totale draaitijd ÷ aantal storingen, en samen leveren ze beschikbaarheid = MTBF ÷ (MTBF + MTTR).

Wat elke vergelijking sloopt, is de noemer. Dezelfde asset gemeten tegen kalenderuren (720 in een maand van 30 dagen) in plaats van geplande uren (160) maakt van 12 verloren uren 1,7% in plaats van 7,5%. Geen van beide is fout; een van beide noemen zonder erbij te zeggen welke wel. Kies een noemer, schrijf hem naast het getal en houd hem stabiel, zodat de trend iets betekent. De pagina over asset uptime werkt de spiegelformule en de “negens”-conventie verder uit.

Wat downtime kost, en hoe u uw eigen uur beprijst

De zichtbare kosten van downtime zijn de reparatiefactuur, en dat is zelden de grootste post. In plaats van een kopcijfer te lenen uit een rapport over andermans fabriek, bouwt u uw eigen kostprijs per uur:

Kosten per uur = onproductieve arbeid + gemiste output + vervanging + inhaalsleep

• Onproductieve arbeid - belast uurtarief × het aantal mensen dat stilstaat. Een ploeg van drie rond een dode heftruck is drie salarissen die niets opleveren.
• Gemiste declarabele of productieve output - de klussen, stuks of uren die niet doorgingen en niet meer in te halen zijn.
• Vervanging - huurkosten voor een vervanger, een ingeschakelde onderaannemer, of de stille schade van het werk met het verkeerde gereedschap doen.
• Inhaalsleep - het bijkomen nadat de asset terug is: overuren, verzette klanten, de achterstand die twee weken kostte om weg te werken.

Tel daar de dingen bij op die u niet factureert maar wel betaalt: gemiste tijdvakken, de klant die de vertraging langer onthoudt dan u, en het samengestelde effect op de onderhoudsachterstand wanneer alles opschuift.

De mkb-invalshoek doet er hier toe, want de meeste teksten over downtime gaan uit van een productielijn. Eén kapotte laptop legt geen fabriek stil - hij zet één persoon één tot drie dagen op halve kracht, en als die persoon declarabel is, is het bedrag niet klein. De som van veel kleine stilstanden verslaat meestal de ene spectaculaire storing waar iedereen het nog over heeft, juist omdat de kleine nooit geteld worden.

Het getal hoeft alleen ongeveer te kloppen. Zijn taak is geen boekhouding; zijn taak is één vraag beantwoorden - is een reserveonderdeel, een servicecontract of een snellere reparatieroute de moeite waard? Als een uur stilstand 180 euro kost en een reserveonderdeel op de plank 60 euro, is het besluit al genomen.

Stilstandsregistratie: wat u vastlegt en waarom

U kunt geen getal verlagen dat niemand vastlegt, en downtime legt zichzelf nooit vast. Een werkbaar logboek bevat per stilstand:

• Asset-ID - welk specifiek exemplaar, niet welk model. Zie asset ID.
• Starttijd en eindtijd - de duur wordt afgeleid, nooit ingetypt.
• Reden-code - het veld dat een stapel uren verandert in een besluit.
• Wie het meldde - zodat de meldgewoonte zichtbaar is en aangemoedigd kan worden.
• Wat het oploste - de notitie die de volgende persoon een uur diagnose bespaart.
• Kosten van onderdelen en arbeid - input voor zowel de repareren-of-vervangen-afweging als de total cost of ownership.

Discipline in reden-codes is wat het logboek de moeite waard maakt. Gebruik een korte standaardlijst - storing, gepland onderhoud, wacht op onderdeel, wacht op goedkeuring, wacht op monteur, schade, extern - en houd het bij tien tot twintig codes. Weersta de verleiding van een bak “Overig”: die eet ongemerkt uw data op, en binnen drie maanden is het uw grootste en minst bruikbare categorie.

Twee regels bepalen of registreren het uithoudt in de praktijk. Ten eerste moet het seconden kosten, geen minuten - iemand met een kapot stuk gereedschap in de hand gaat geen formulier zoeken, dus de melding moet bereikbaar zijn vanaf het item zelf. Ten tweede moet het niet bestraffend zijn. Zodra een storing melden voelt als een storing bekennen, stoppen de meldingen en verbetert uw downtimecijfer om precies de verkeerde reden.

Over gereedschap de eerlijke regel: een gedeeld spreadsheet is een legitiem begin, en het werkt tot het moment dat u uw tijd besteedt aan samenstellen in plaats van handelen. Zodra “welke assets staan nu stil?” meer dan één blik kost, of zodra reparatiehistorie in het geheugen van drie mensen zit, verdient een equipment log gekoppeld aan het assetrecord zijn plek.

Downtime verminderen

Grofweg op volgorde van goedkoopste eerst:

1. Maak melden onmiddellijk. Een QR-label op het item betekent dat degene die het vasthoudt het probleem ter plekke kan melden in plaats van een formulier of een leidinggevende te zoeken. Dit haalt de “niemand wist het”-uren weg, en die zijn gratis om weg te halen.
2. Verkort de goedkeuringstijd. Geef reparaties onder een vast bedrag vooraf akkoord en wijs één beslisser aan daarboven. Kost niets, scheelt dagen.
3. Zet ongepland om in gepland. Onderhoud op schema in plaats van bij storing. Een inspectieschema verandert een willekeurige uitval in een gekozen moment.
4. Houd reparatiehistorie per asset bij. Terugkerende probleemgevallen worden pas zichtbaar als de historie per asset staat in plaats van in iemands geheugen - en dan worden ze goed gerepareerd of afgestoten.
5. Leg de twee of drie goedkope onderdelen op voorraad die lange wachttijden veroorzaken. Geen magazijn, een plank. Mik op artikelen met een lange levertijd en een klein prijskaartje.
6. Houd een reserve of leenexemplaar aan voor echt kritieke middelen - en bepaal de omvang van die pool bewust in plaats van per ongeluk, met uw kostprijs per uur als onderbouwing.
7. Werk de onderhoudsachterstand weg zodat kleine gebreken niet uitgroeien tot grote.

Onder alle zeven liggen precies twee knoppen: de MTTR verlagen (sneller repareren) of de MTBF verhogen (minder vaak uitvallen). Kleine teams halen bijna altijd meer uit de eerste, omdat het grootste deel van hun MTTR wachten is - op een melding, een besluit of een onderdeel - en wachten is goedkoper te repareren dan betrouwbaarheid.

Downtime in IT vs downtime bij apparatuur

De helft van de mensen die deze term zoekt, bedoelt een dienst en geen machine. In IT betekent downtime meestal dat een systeem of dienst niet beschikbaar is, gemeten tegen 24/7-kloktijd en vastgelegd in een service level agreement als “negens”: 99,9% laat ongeveer 8,8 uur downtime per jaar toe, 99,99% minder dan een uur. De noemer is de kalender, omdat de dienst er ook om 3 uur ‘s nachts hoort te zijn.

Voor fysieke apparatuur misleidt die conventie. Een bestelwagen die om 3 uur ‘s nachts op zondag niet beschikbaar is, heeft niemand teleurgesteld. De verstandige noemer is de geplande uren, en de bruikbare eenheid is uren per periode in plaats van een extra decimaal - “we zijn deze maand 12 uur kwijt” zegt een team meer dan “97,9%”.

En dan is er het geval dat de meeste pagina’s overslaan en waar kleine bedrijven daadwerkelijk in leven: hardwarestilstand voor één persoon. Een dode laptop, een zoekgeraakte lader of een dockingstation dat ermee ophield, zet een medewerker dagenlang op halve kracht, en het duikt zelden op in enige beschikbaarheidsmaatstaf. Voor IT-afdelingen is de praktische oplossing geen negens-doelstelling - het is weten wie wat heeft, één of twee reserves op de plank hebben, en de omruil een klus van vijf minuten maken in plaats van een inkooptraject.

Downtime in de praktijk

De gewoonte die al het andere mogelijk maakt, is het markeren van de statuswijziging: op het moment dat een asset buiten dienst gaat, zegt het record dat, met een reden. In AMPthilly geeft het zetten van de status op “in reparatie” plus het aanmaken van een servicedesk-ticket het team een live beeld van wat er stilstaat en waarom, en laat het een permanente reparatiehistorie op de asset achter - zo ziet u later de machine die dit jaar stilletjes vijf keer stilstond.

De meldkant telt net zo zwaar als de vastlegging. Omdat elke asset een geprint QR-label kan dragen, kan degene die het mankement vindt het scannen met een gewone telefooncamera, in de browser op het profiel van die asset landen, en het probleem melden met een foto en een categorie - schade, kwijt, onderhoud nodig, vervanging nodig - zonder iemand te hoeven zoeken. Het ticket loopt daarna door een wachtrij met statussen die naadloos aansluiten op stilstandsredenen: in beoordeling, in behandeling, wacht op onderdelen, opgelost.

FAQ

Wat is het verschil tussen geplande en ongeplande downtime?

Geplande downtime wordt vooraf ingepland - service, upgrades, inspecties - zodat werk eromheen kan worden gepland en de asset in een bekende staat terugkomt. Ongeplande downtime komt zonder waarschuwing, op het moment dat de asset toevallig uitvalt, meestal midden in gebruik. Eenzelfde uur onbeschikbaarheid kost ongepland veel meer, omdat hectiek, wachten op onderdelen en verstoorde toezeggingen bovenop het gemiste gebruik komen.

Wat is het verschil tussen downtime en idle time?

Downtime betekent dat de asset niet gebruikt kan worden: hij is uitgevallen, hij staat in onderhoud of er ontbreekt een onderdeel. Idle time betekent dat de asset prima werkt maar geen werk, geen bediener of geen materiaal heeft. Het onderscheid bepaalt welk cijfer beweegt: downtime drukt de beschikbaarheid en wijst op onderhoud, terwijl idle time de bezettingsgraad drukt en wijst op planning of vraag. Teams die beide als een bak “werkt niet” registreren, jagen op de verkeerde oplossing.

Hoe bereken je downtime als percentage?

Stilstandspercentage = stilstanduren gedeeld door geplande uren, maal 100. Een machine die in een maand voor 160 uur is ingepland en 12 uur verliest aan storingen stond 12 / 160 = 7,5% stil, oftewel 92,5% beschikbaarheid. Noem altijd de noemer: dezelfde asset gemeten tegen kalenderuren in plaats van geplande uren levert een compleet ander percentage op, en daarom vergelijken twee teams die downtimecijfers noemen vaak niet hetzelfde.

Wat kost een uur stilstand een klein bedrijf?

Er bestaat geen universeel bedrag, dus bereken uw eigen uur: onproductieve arbeid (belast uurtarief maal het aantal mensen dat stilstaat), plus gemiste declarabele of productieve output, plus vervangingskosten zoals huur of het werk met het verkeerde gereedschap doen, plus de inhaaluren nadat de asset terug is. Het getal hoeft alleen ongeveer te kloppen - het moet u vertellen of een reserveonderdeel, een servicecontract of een snellere reparatieroute de moeite waard is.

Hoe wordt downtime gemeten?

Het eenvoudigst: de uren dat een asset niet beschikbaar was in de periode dat hij beschikbaar had moeten zijn. Teams die meer inzicht willen, splitsen op oorzaak - storing, onderhoud, wachten op onderdelen, wachten op iemand die repareert - omdat die verdeling laat zien wat er te veranderen valt. De tegenhanger is uptime of beschikbaarheid: het percentage verwachte uren dat de asset daadwerkelijk bruikbaar was.

Telt onderhoud als downtime?

Ja - als de asset niet beschikbaar is, is hij down, ongeacht de reden. Het nuttige onderscheid is dat onderhoudsdowntime een keuze over timing is. Service op een rustige dag kost weinig; dezelfde service afgedwongen door een storing in een drukke week kost veel. Geplande downtime eerlijk tellen voorkomt dat die wegglijdt naar avonden die niemand heeft ingepland.

Hulpmiddelen die dit makkelijker maken

AMPthilly houdt de stilstandsregistratie waar die daadwerkelijk nuttig is - op de asset zelf. Elk item heeft een status (in gebruik, in opslag, in reparatie, afgestoten), zodat “wat staat er nu stil?” een filter is in plaats van een rondje bellen. Problemen worden gemeld als servicedesk-tickets die aan de asset hangen, met categorie, foto’s, commentaarthreads en bijgevoegde reparatiefacturen, en ze lopen door een wachtrij - in beoordeling, in behandeling, wacht op onderdelen, opgelost - die meteen als uw reden-codes dienstdoet. Print een QR-label per asset en iedereen kan het scannen met een telefooncamera, het profiel in de browser openen en in seconden een mankement melden, zonder app om te installeren. De volledige audithistorie van statuswijzigingen, uitgiftes en retours blijft permanent op het record staan, zodat het stilstandsverhaal per asset al geschreven is tegen de tijd dat u gaat tellen. Het gratis plan dekt 3 gebruikers en 25 assets, zonder creditcard.

De kern

Downtime is elke tijd dat een asset beschikbaar had moeten zijn en dat niet was - en het nuttigste wat u ermee kunt doen, is stoppen met het als één getal te behandelen. Scheid het van idle time zodat u het juiste probleem oplost, splits het op reden-code zodat de administratieve en wacht-op-onderdelen-uren zichtbaar worden, bereken het tegen een noemer die u hardop noemt, en beprijs een uur ervan zodat u weet wat een reserve waard is. Haal daarna de wachtrij vóór de reparatie weg: onmiddellijk melden, snelle goedkeuringen, een plank met de goedkope kritieke onderdelen erop. Voor de meeste kleine teams zit die wachtrij, en niet de storing zelf, waar de uren werkelijk verdwijnen.

Gerelateerde termen

• Asset uptime - het beschikbaarheidspercentage waar downtime van aftrekt
• Gepland vs ongepland onderhoud - de afweging die bepaalt welke downtime u krijgt
• Onderhoudsachterstand - de wachtrij met openstaand werk waaruit toekomstige downtime voortkomt
• CMMS - de softwarecategorie gericht op werk inplannen om downtime te minimaliseren
• Service level agreement - de formele beschikbaarheidstoezegging waartegen downtime wordt gemeten