Iteratief verbeteren met het SafetyChanger platform

In de voorgaande delen van deze serie blogs heb ik iteratief software ontwikkelen en het meten van verbeteringen behandeld. Hierbij heb ik waar mogelijk analogieën gemaakt naar de industriële context. In dit laatste deel laat ik zien hoe je met ons platform een iteratief verbeteringsproces kunt faciliteren. Aanvullend zal ik ingaan op hoe je zowel het meten als het borgen van verbeteringen kunt toepassen.

Het volgende diagram laat zien hoe de diverse stappen een plaats hebben binnen ons SafetyChanger platform. Ons platform kent drie modules; Inspecties, Incidenten en Acties. Voor bestaande gebruikers eenvoudig te herkennen aan de kleuren blauw, rood en groen. Hoewel de naam dat misschien doet vermoeden, wordt de module Incidenten niet alleen gebruikt voor het registreren en verwerken van (bijna) ongevallen. Naast ongevallen worden bijvoorbeeld ook afwijkingen uit inspecties en algemene observaties (bijvoorbeeld een kapotte lamp of een mankement aan een machine) gemeld en vastgelegd.

Deze meldingen worden vervolgens geregistreerd en geclassificeerd. Door deze classificatie hebben alle meldingen een weging (vergelijkbaar met de features uitgezet tegen waarde en inspanning van deel 2), wat helpt bij het bepalen van de volgende iteratie.

Na het registreren van meldingen kunnen er verschillende typen acties aangemaakt worden. Neem bijvoorbeeld een werkplaats waar gereedschap op de vloer rondslingert. Een logische inperkingsmaatregel zou zijn om het gereedschap van de vloer te halen om te voorkomen dat mensen erover struikelen. Verbetermaatregelen zijn vervolgens een vaste plek aanwijzen voor het gereedschap en het personeel instrueren na gebruik het gereedschap daar op te bergen.

Ter validatie van de verbetermaatregel dient gecontroleerd te worden of het gereedschap daadwerkelijk opgeruimd wordt na een volgend gebruik; de verificatie. Deze verificatie kan vervolgens opgenomen worden als inspectie-item tijdens bijvoorbeeld een reguliere werkplekinspectie.

Tijdens inspectierondes kunnen afwijkingen worden geconstateerd. Het is belangrijk dat daar daadwerkelijk iets mee gebeurt. Gebruikers kunnen zowel handmatig, met een druk op de knop, als automatisch, op basis van ingestelde regels, afwijkingen tijdens inspecties laten escaleren naar een melding.

Door deze koppeling is de verbetercirkel rond en kunnen afwijkingen — of dit nu ongevallen, gevaarlijke situaties, observaties of verbeteringssuggesties zijn — weer worden verwerkt in een volgende iteratie.

Voor de doorontwikkeling van ons platform gebruiken wij het platform zelf. Bij iedere iteratie testen wij bijvoorbeeld alle modules aan de hand van inspecties. Daarnaast gebruiken we voor en tijdens iedere release checklists om te zorgen dat alle benodigde stappen uitgevoerd worden. Daarnaast kunnen alle werknemers meldingen maken, zowel problemen als verbeteringen worden gemeld. Deze input wordt vervolgens iteratief verwerkt. Hieronder een deel van een actielijst voor de huidige iteratie.

[caption id=”” align=”alignnone” width=”631.0"]

Acties vastgelegd per iteratie (I=Improvement/Verbeteringsmaatregel, C=Containment/Correctieve maatregel)

Acties vastgelegd per iteratie (I=Improvement/Verbeteringsmaatregel, C=Containment/Correctieve maatregel)[/caption]

Het managen van “verbeterteams” en verbeteringen prioriteren is een hele kunst. De hoeveelheid verbeteringen zijn vaak groter dan je met je team in korte tijd kan verwerken. Daarnaast wordt vaak alles belangrijk gevonden, waardoor er niet expliciet gekozen wordt welke zaken vandaag opgepakt worden en welke morgen. Het gevolg is dan vaak dat alles een beetje gedaan wordt, maar niets daadwerkelijk afgerond wordt en naar een hoger niveau getild wordt. Of nog erger: degene die het hardst schreeuwt of het probleem dat het laatst binnenkomt is het meest urgent, totdat de volgende zich aandringt.

Binnen de software-industrie heeft een iteratief ontwikkelingsproces bij veel organisaties tot een verbeterd resultaat geleid: er zijn regelmatig nieuwe werkende versies van het product en er kan beter geanticipeerd worden met veranderingen en nieuwe inzichten (v.s. het onbuigzame karakter van bijvoorbeeld de watervalmethode). Met deze serie blogposts heb ik een vertaling gemaakt naar de context van de industrie met de overtuiging dat deze kennis ook nuttig is buiten de software industrie. Want of je nu een software ontwikkelaar, veiligheidskundige of operationeel manager bent, je bent regelmatig, zo niet continu, bezig met het verbeteren van je product, dienst en/of proces.