Een klant mailt dat een geleverd onderdeel niet past. Dezelfde week ziet de werkvloer hetzelfde probleem opduiken bij een andere order, en in de inkoopmailbox blijkt de leverancier al eerder te hebben geschreven over een gewijzigde legering. Losse berichten, verschillende afzenders, en niemand die ze op dat moment aan elkaar knoopt. Pas als iemand maanden later de klachten doorloopt, blijkt het om één productieprobleem te gaan.
Zo gaat het vaak in de maakindustrie. Meldingen komen binnen waar het werk gebeurt: een klacht bij sales, een afkeur in de appgroep van de ploeg, een leveranciersissue via inkoop. Het registreren zelf is zelden het probleem. Het gaat mis bij de opvolging: wie is eigenaar, welke actie hoort erbij, en wanneer mag een melding dicht? Dat deel leent zich goed voor automatisering. De insteek hier is bewust administratief: van melding naar eigenaar en afsluiting. Camera-inspectie en machinebesturing blijven buiten beschouwing.
Wat er misgaat zonder vaste meldroute
Alles wat afwijkt van wat is afgesproken, is een kwaliteitsmelding: een onderdeel dat niet volgens tekening is, een batch die buiten tolerantie valt, een levering die niet klopt, een klacht van een klant. De bron verschilt (klant, werkvloer, leverancier), de vraag is steeds dezelfde: wat gaan we ermee doen?
In de praktijk leven die meldingen op vier of vijf plekken tegelijk. Er is een QA-mailbox, er is een appgroep waarin de ploegleider afkeur meldt, er ligt weleens een briefje, en er is vast een Excel waarin iemand meldingen bijhoudt. Die Excel is vaak half gevuld, want degene die hem bijhoudt heeft er nog een baan naast. Het gevolg is voorspelbaar: meldingen worden wel ergens geregistreerd, maar niet consequent opgevolgd. En omdat niets centraal samenkomt, zie je patronen niet: dezelfde fout op dezelfde machine, of een leverancier die vaker buiten tolerantie levert.
Eén vast formaat voor mail, appje en foto
De eerste bouwsteen is saai maar beslissend: elke melding krijgt dezelfde velden. Product of artikelnummer, order en batch, een korte omschrijving van wat er afwijkt, een eerste inschatting van urgentie, de bijlagen die erbij horen, en de afzender met contactgegevens. Meer heeft het gros van de meldingen niet nodig.
Het werk zit in het vullen van die velden zonder dat iemand ze overtypt. Met een slimme inbox leest de workflow inkomende mail, haalt product- en ordergegevens uit de tekst en de bijlagen, en zet de melding klaar in het register. De klant hoeft niet anders te mailen dan hij gewend is; de ploegleider tikt een afkeur in via een kort formulier op telefoon of tablet. Alles komt op dezelfde plek uit.
Wat overblijft zijn de taaie gevallen. Een melding zonder ordernummer komt vaker voor dan je zou denken: op de foto staat alleen een label, en het ordernummer staat nergens. Dan is de eerste taak niet classificeren maar het juiste dossier vinden, en dat uitzoekwerk kan een workflow voorbereiden maar niet wegnemen. Reageert een klant op een oude mailthread, dan hangt de melding zomaar onder het onderwerp van een vorige order; de workflow zet zulke gevallen apart in plaats van ze stil te laten doorgaan.
Eerst definities, dan classificatie
Voor een systeem iets kan herkennen, moet het bedrijf zelf hebben afgesproken wat de categorieën zijn. Is een beschadigde verpakking een kwaliteitsmelding of een logistieke opmerking? Telt een verkeerd label mee, of is dat iets apart? Vijf categorieën en drie urgentieniveaus zijn meestal genoeg; hoe fijnmaziger het stelsel, hoe vaker mensen het naast zich neerleggen.
Het uitlezen daarna is deels gewoon softwarelogica. Vaste velden zoals ordernummer en productcode lees je er met regels uit. Vrije tekst, van een klachtomschrijving tot een appje van de vloer, is waar taalmodellen hun werk doen: ze stellen een categorie, een eerste indicatie van de oorzaak (materiaal, montage, leverancier) en een urgentie voor, op basis van de omschrijving, eerdere meldingen over hetzelfde product en signalen als een stilstaande lijn. Dat voorstel gaat ter bevestiging langs een medewerker. De correcties zijn meteen leerzaam: blijkt een categorie stelselmatig te worden omgezet, dan was de definitie niet scherp genoeg.
Routeren naar een eigenaar, niet naar een mapje
Een melding die in de juiste map belandt, is nog niet opgelost. De routering moet uitkomen bij een persoon of rol die eigenaar is van de vervolgstap. Een interne afkeur hoort bij de lijn en QA, een klantklacht bij QA met sales erbij, een leveranciersissue bij inkoop met QA aan de zijlijn. De urgentie bepaalt de termijn: een veiligheidskwestie of een stilgevallen klantlijn verdraagt geen wachtrij van een week.
Dat patroon van classificeren, prioriteren en naar een eigenaar sturen kent dezelfde vorm als in Klachten automatisch classificeren en opvolgen met AI, alleen liggen de eigenaren in de productie vaker bij QA of de lijn dan bij sales.
Een melding zonder eigenaar blijft liggen, ook als de routering technisch perfect werkt. Daarom hoort de workflow te escaleren zodra een melding zijn termijn nadert, en niet pas als iemand er toevallig naar vraagt.
8D-opvolging: termijnen bewaken, analyse bij het team
Bij een serieuze klacht of een probleem dat vaker terugkomt, vragen klanten om een gestructureerde aanpak, vaak in 8D-vorm: een vaste reeks stappen die begint bij het afbakenen van het probleem en eindigt bij het borgen van de maatregel. Meestal sneuvelt zo'n traject op de opvolging, niet op de inhoud. De eerste stappen worden nog gedaan tijdens het blussen, maar daarna blijft het rapport halverwege steken. De termijn verstrijkt en de klant moet er zelf achteraan.
Wat een workflow hier doet, is streng en saai: per melding een dossier met de afgesproken stappen en termijnen, herinneringen voordat een termijn verstrijkt, en bewijsstukken die aan het dossier hangen zodra ze binnenkomen. De status van elk openstaand dossier komt in het kwaliteitsoverleg terecht, zodat stagnerende dossiers opvallen voordat de klant erom vraagt. De melder zelf, klant of ploeg, krijgt bericht zodra de status verandert.
Wat bij het team blijft, en de koppeling met je ERP of QMS
Een workflow is goed in lezen, voorstellen, routeren en bewaken. Beoordelen of een afwijking technisch acceptabel is, besluiten dat een melding dicht mag, en de keuze om een leverancier formeel aan te spreken: dat blijft bij mensen met verstand van het product.
Aan de systeemkant zijn er twee smaken. Heeft je ERP of QMS een koppeling, dan schrijft de workflow de melding en de status weg op de plek waar ze thuishoren; met werkstroomorkestratie hangen melding, taak en dossier aan elkaar zonder dat iemand tussen systemen schakelt. Is er geen koppeling, dan is één centraal register met de vaste velden de tussenoplossing, met een export richting administratie. De gedachte is dezelfde als bij Productieorders automatisch verwerken met AI: gegevens worden één keer goed vastgelegd en daarna nergens meer overgetypt.
Wat je per melding vastlegt, is meer dan de status alleen. Wie de melding oppakte, wanneer dat gebeurde, welke beslissing er viel en of er is gecorrigeerd: precies dat is waar Audit trail bij AI-automatisering: wat moet je loggen? over gaat, en het is ook het materiaal waarmee je een klantaudit of certificeringscontrole doorstaat. Het afsluiten van een melding is en blijft een handeling van iemand die kan uitleggen waarom het klaar is.
Wanneer automatiseren wel en niet loont
Automatiseren loont zodra het aantal meldingen groeit en de QA-manager wekelijks door mailboxen zoekt om te controleren of alles is opgepakt. Als klantvragen over de status van een 8D vaker voorkomen dan je lief is, is de rekensom snel gemaakt. Bij een handvol meldingen per jaar bouw je niets; dan volstaat een afgesproken formulier en een taakje in het systeem dat je al gebruikt.
Eén voorwaarde weegt zwaarder dan alle techniek: er moet iemand eigenaar willen zijn van de opvolging. Een systeem dat een prachtige meldingenlijst produceert die niemand leest, verandert niets. Zet de lijst in het overleg waar de lijn bij zit, niet alleen bij QA.
Begin met één stroom, bijvoorbeeld klantklachten, en draai hem eerst een maand naast de bestaande werkwijze. De meldingen die dan opduiken zijn zelden de nette voorbeelden uit een demo. Pas als die stroom stabiel loopt, breid je uit naar interne afkeur en leveranciersissues. Hoe dit soort stromen in de maakindustrie landen, zie je terug bij AI-automatisering voor productiebedrijven.
Veelgestelde vragen
Wat als een melding telefonisch of mondeling binnenkomt?
Niet elk kanaal is digitaal, en dat hoeft ook niet. Wie een telefoontje aanneemt, legt dezelfde vaste velden vast als bij een mailmelding, via een kort formulier op de telefoon of het scherm. Houd daarbij ook bij wie de melding heeft aangenomen: bij een telefoontje is de melder niet automatisch de persoon die de terugkoppeling krijgt. Een voicebericht kan als bijlage mee, maar de velden blijven het uitgangspunt; zonder product, order en omschrijving kan niemand ermee verder.
Moet je leveranciers ook om een 8D vragen?
Bij terugkerende leveranciersissues is dat gebruikelijk, en het helpt om in de leveranciersafspraken vast te leggen welke gevallen een 8D-respons vragen en binnen welke termijn. De workflow kan de aanvraag en het antwoord bewaken, zodat een verzoek niet stil verdwijnt. Het gesprek met de leverancier zelf blijft bij inkoop of kwaliteit.
Kan AI zelf beoordelen hoe ernstig een afwijking is?
De technische ernst niet: of iets binnen tolerantie valt, is een vakinhoudelijke vraag. Wat het systeem wel kan, is regels en historie combineren: eerdere meldingen over hetzelfde artikel, de veiligheidsclassificatie van een onderdeel, signalen dat een klant stilligt. Zo ontstaat een urgentievoorstel dat controleerbaar is. Maatwerk blijft maatwerk: cosmetische schade aan een zichtdeel kan voor de ene klant acceptabel zijn en voor de andere een reden om de zending te weigeren.
Wat als er geen QMS is om in te schrijven?
Dan begin je met een eigen register: één lijst of bord met de vaste velden, waar alle betrokkenen bij kunnen. Taken kunnen in het systeem staan dat je al gebruikt, zolang melding en taak maar naar elkaar verwijzen. Koppelen met ERP of QMS kan later; het register is dan tijdelijk de bron. Wat je wilt voorkomen, is dat er naast het register nog een schaduwlijstje blijft bestaan.
Hoe houd je overzicht als het aantal meldingen groeit?
Met een vaste weekrapportage: open meldingen per eigenaar, meldingen die hun termijn naderen of hebben overschreden, en de producten of leveranciers waar meldingen zich opstapelen. Dat overzicht hoort in een bestaand overleg thuis, niet in een aparte vergadering. De patronen erin zijn de aanleiding om structureel iets aan een product of proces te doen.