Förbättra förbättringarna!

Avvikelsehantering fokuserar oftast på att snabbt återställa ordningen till ett "normalläge". I många fall räcker det naturligtvis, men oftast lönar det sig att utreda orsaken på djupet.

Efter att servicemodulen till Apollo 13 havererat och astronauterna med nöd och näppe lyckats tas sig levande hem, tror ni att NASA nöjde sig med att bygga en likadan till Apollo 14? Nej, de konstruerade om de system som havererat och gjorde vissa system mer oberoende av varandra. Men de förändrade också sitt sätt att konstruera, dvs sitt sätt att tänka när det gäller systemsäkerhet.

Bilden visar den skadade servicemodulen efter att den kopplats loss, med hålet efter explosionen till höger.

Hur kommer det sig att vi så ofta nöjer oss med att en halvbra lösning på ett problem, utan att ordentligt utreda orsaken? Varför är det så jobbigt när kunden kräver en 8D-rapport med analys av 5 Varför?

Även om felet upptäcks på en fysisk produkt, ligger orsakerna ofta i de bakomliggande processerna. När inte den grundläggande orsaken åtgärdats kan vi ju vara ganska säkra på att något liknande kommer att hända igen.

Vad skulle hända om vi varje gång något går fel inte bara återställer läget, utan försöker komma till en nivå som är högre än innan det hände?

(Mer info om Apollo 13: https://sv.wikipedia.org/wiki/Apollo_13)