Veertig zaagdelen, allemaal vijf millimeter te kort. De zager deed niets fout: hij zaagde precies wat de zaaglijst zei. Alleen kwam die lijst uit een verouderde revisie. Op de nacalculatie verschijnt een post herstelwerk, iemand moppert bij de koffieautomaat, en daar blijft het bij. De kosten worden geboekt bij productie; de oorzaak ligt drie afdelingen eerder en blijft onaangeroerd.
Zo gedraagt het gros van de faalkosten in de maakindustrie zich: ze worden gevoeld op de werkvloer, geboekt bij productie en veroorzaakt door data. Een verkeerd aantal, een achtergebleven omschrijving, een gemiste wijziging. Wie faalkosten in engineering wil terugdringen, heeft daarom twee dingen nodig: een registratie die zichtbaar maakt wat er misgaat, en een vaste route terug van symptoom naar bron. In dit artikel bouwen we allebei op. Gereedschap zoals Thundercad helpt om een deel van de oorzaken daarna technisch af te dichten, maar meten komt eerst.
Eén afbakening vooraf: dit is de kosten- en meetkant van het verhaal. Hoe je fouten aan de voorkant voorkomt met schone, gecontroleerde data, beschreven we eerder in Schone, betrouwbare data naar productie; beschouw dat artikel als de tweelingbroer van dit stuk.
Faalkosten zijn datafouten met vertraging
Drie herkenbare meldingen van de werkvloer, met hun werkelijke oorsprong:
- Verkeerd gezaagd: veertig delen te kort, want de zaaglijst kwam uit een oude stand. Oorsprong: de wijziging is netjes in het model doorgevoerd, maar de lijst is nooit opnieuw uitgegeven.
- Dubbel besteld: inkoop bestelt dezelfde beugel onder twee nummers. Oorsprong: het onderdeel is ooit gekopieerd naar een nieuw bestandsnummer terwijl het fysiek identiek bleef.
- Stilstand bij montage: de monteur komt vier stuks tekort. Oorsprong: een patroon in de samenstelling telde anders dan verwacht en niemand controleerde de aantallen vóór vrijgave.
Het patroon is steeds hetzelfde: tussen ontstaan en ontdekken zit tijd, en die vertraging bepaalt de schade. Dezelfde fout die tijdens het modelleren in vijf minuten hersteld is, kost bij het zagen een uur of twee, bij montage een dagdeel inclusief spoedbestelling, en bij de klant een servicebezoek plus een deuk in het vertrouwen. Faalkosten terugdringen is dus vooral: de ontdekking naar voren halen en daarna de bron dichtzetten.
Registreer elke melding met een oorzaakcode
Sturen kan pas als je weet waar de uren weglekken, en daarvoor is geen softwarepakket nodig. Eén gedeelde lijst volstaat, met per melding vijf velden: ordernummer, wat er misging, waar het ontdekt is (zagen, lassen, montage, service), de geschatte hersteltijd in uren en een oorzaakcode. Houd de drempel laag: invullen mag hooguit een minuut kosten, anders sterft de registratie na twee weken een stille dood.
De oorzaakcodes doen het echte werk. Houd het bij een stuk of zes, bijvoorbeeld:
- O1: verouderde revisie of verkeerd document gebruikt
- O2: aantal in de stuklijst klopt niet met het model
- O3: omschrijving, materiaal of gewicht klopt niet
- O4: informatie ontbrak op de tekening, zoals een maat, tolerantie of bewerking
- O5: verkeerd of onvindbaar bestand gebruikt
- O6: uitvoeringsfout op de werkvloer, geen datafout
Die laatste code is belangrijk voor het draagvlak: niet alles komt uit engineering, en dat mag de lijst ook laten zien. De vinder meldt, werkvoorbereiding of de engineeringcoördinator kent binnen een dag de code toe. Meer proces is het niet.
De route terug: van symptoom naar bron
Een melding met een code is nog geen oorzaak. Voor de meldingen met de meeste uren loop je de route terug, en dat gaat met vier vaste vragen:
- Met welk document werkte de werkvloer: zaaglijst, tekening, stuklijst, export?
- Uit welke bron kwam dat document, en van welke stand was die bron?
- Wat is er tussen die stand en de productie gewijzigd, en waar is die wijziging blijven hangen?
- Welke processtap had dit kunnen zien, en waarom zag die het niet?
Neem de dubbele bestelling. Het document: de bestellijst van inkoop. De bron: twee stuklijstregels met verschillende nummers. De wijziging: ooit is de beugel gekopieerd voor een variant die er nooit kwam. De processtap: niemand controleert stuklijsten op bijna-identieke regels. De maatregel ligt daarmee voor het oprapen: hergebruik afdwingen en vóór vrijgave sorteren op omschrijving, zodat dubbelingen naast elkaar komen te staan.
Let op de toon van vraag vier: welke stap, niet welke collega. De route terug eindigt bij een processtap die de fout doorliet, nooit bij een naam. Zodra de registratie voelt als een schuldadministratie, droogt de meldingenstroom op en meet je niets meer.
Eindigt de route terug bij jou opvallend vaak bij een losse export, een handmatig bijgehouden lijstje of een verouderd document? Met Thundercad exporteer je tekeningen en stuklijsten rechtstreeks vanuit het actuele model, zodat de werkvloer altijd uit de laatste stand werkt.
Probeer 30 dagen gratisPer oorzaak een structurele maatregel
Na een paar weken registreren tekent zich een top drie af. Kies dan per oorzaakcode één structurele maatregel; losse reparaties heb je al genoeg gedaan. Ter inspiratie:
| Code | Typische bron | Structurele maatregel |
|---|---|---|
| O1 | Uitgifte uit een oude stand | Eén uitgiftekanaal, altijd vanuit het vrijgegeven model; oude papieren sets direct vernietigen |
| O2 | Stuklijst ververst niet mee met het model | Lijst vlak vóór uitgifte verversen; spiegel- en patroonposities standaard nalopen |
| O3 | Handmatig overgetypte eigenschappen | Omschrijvingen en gewichten uit het model laten komen, niet uit een los lijstje |
| O4 | Onvolledige intake van de order | Beslislijst per order; open punten gebundeld terug naar verkoop of klant |
| O5 | Zoeken in een gegroeide mappenstructuur | Vaste projectstructuur en naamgeving; verouderde kopieën archiveren |
Voer één maatregel per keer in; vijf tegelijk verwatert. Kies de code met de meeste geregistreerde uren, niet de code die toevallig de meeste discussie oplevert, en geef elke maatregel een eigenaar en een afgesproken evaluatiemoment.
Meet of het werkt
De registratie die je opbouwt is meteen je meetlat. Zet per maand twee getallen naast elkaar: het aantal meldingen per oorzaakcode en de geschatte uren erachter. Beweegt de code waarop je een maatregel hebt gezet, dan werkt hij. Beweegt hij niet, dan heb je een symptoom bestreden in plaats van de bron, en ook dat is precies de informatie die je wilt hebben voordat je de volgende maatregel kiest.
Waak wel voor de bekende valkuil: het aantal meldingen stijgt in het begin vrijwel altijd, simpelweg omdat er eindelijk gemeld wordt. Dat is geen verslechtering maar zichtbaarheid. Stuur op de uren en de trend per code, niet op het kale aantal meldingen. Hoe je zulke cijfers kiest en presenteert zonder een afrekencultuur te kweken, lees je in KPI's voor je engineeringafdeling die wél iets zeggen.
En reken af en toe hardop, in uren. Als drie maanden registreren laat zien dat code O1 goed is voor tientallen hersteluren, dan is het gesprek over een structurele oplossing ineens geen meningsverschil meer maar een rekensom.
Veelgestelde vragen
Moet ik faalkosten in geld registreren of volstaan uren?
Uren volstaan vrijwel altijd. De vinder kan hersteltijd direct schatten, terwijl een bedrag meteen discussie oproept over tarieven en toeslagen. Presenteer de schattingen bovendien expliciet als schattingen; het gaat om de verhouding tussen oorzaken, niet om de derde decimaal.
Hoe voorkom ik dat de registratie een zoektocht naar schuldigen wordt?
Registreer processtappen, geen namen, en bespreek de lijst per oorzaakcode in plaats van per melding. Houd ook code O6 in ere: als uitvoeringsfouten net zo eerlijk geregistreerd worden als datafouten, voelt de lijst voor niemand als een aanklacht en blijft iedereen melden.
Hoeveel meldingen heb ik nodig voordat ik conclusies kan trekken?
Tientallen, geen honderden. Na een paar weken zie je in de meeste werkplaatsen al duidelijke clusters, en het grootste cluster zit vrijwel altijd rond uitgifte en actualiteit van documenten. Wil je die kant alvast technisch afdichten terwijl de registratie loopt: probeer Thundercad 30 dagen gratis.