Bouw een NCR-app met CAPA-taken om defecten vast te leggen, root-cause stappen toe te wijzen, deadlines in te stellen en corrigerende acties via goedkeuring tot sluiting te volgen.
Een nonconformance report (NCR) is een registratie van iets dat niet aan een eis voldeed. Die eis kan een tekening, een specificatie, een werkvoorschrift of een klantverwachting zijn. Het doel is niet om iemand de schuld te geven. Het is om de feiten vast te leggen terwijl ze vers zijn, zodat hetzelfde probleem zich niet herhaalt.
CAPA staat voor Corrective and Preventive Action. Het is wat er gebeurt nadat de NCR is geregistreerd: je onderzoekt waarom het gebeurde, lost het directe probleem op en zet een preventiestap in. In een goed systeem is de NCR de trigger en CAPA de opvolging.
Samen helpen NCR en CAPA met een paar praktische problemen: issues consequent vastleggen, duidelijke eigenaarschap toewijzen, werk tijdig sluiten met vervaldatums, besluiten traceerbaar houden en herhaling voorkomen.
Veelvoorkomende triggers zijn makkelijk te zien als je ernaar zoekt: een klantklacht, een mislukte controle in het proces, een afkeur bij de eindinspectie of een leverancierprobleem zoals verkeerde materiaalcertificaten. Zelfs bijna-fouten kunnen een NCR waard zijn als de kosten van herhaling hoog zijn.
Een simpel voorbeeld: een batch faalt bij een maatcontrole. De NCR legt het partnummer, lot, meting, foto’s en wie het vond vast. CAPA wijst dan root-cause analyse toe, corrigerende actie (beheersing en reparatie), preventie (proceswijziging of training) en verificatie voordat er gesloten wordt.
Een NCR is het meest nuttig als het alleen vastlegt wat iemand helpt een besluit te nemen: wat er gebeurde, hoe groot het is en wat de volgende stap is. Als het formulier voelt als een toets, slaan mensen het over of schrijven ze “zie e-mail”.
De meeste teams doen het goed met vijf groepjes velden:
Bijlagen wegen zwaarder dan lange tekst. Een enkele foto van een gebarsten behuizing, plus de inspectienota met een buiten-tolerantie meting, kan later uren besparen. Bij leverancierissues, voeg het leveranciersdocument of certificaat toe als upload.
Voorbeeld: een ontvangstinspecteur meldt 12 stuks uit batch B-104. De NCR noteert de PO, deelrevisie, ernst “hoog” en beheersing “in quarantaine rek Q2”. Dat is genoeg voor de volgende eigenaar om met root-cause werk te beginnen zonder context te hoeven achterhalen.
Voordat je schermen maakt, stem af op één eenvoudige flow die iedereen kan volgen. Een duidelijke workflow voorkomt twee veelvoorkomende problemen: NCRs die blijven liggen en CAPAs die voor elk kleinigheidje worden geopend.
Begin met een kleine set statussen die overeenkomen met hoe werk echt beweegt, zoals Draft, Submitted, Containment, RCA, CAPA, Verification, Closed. Houd namen vertrouwd zodat operators, kwaliteit en managers ze op dezelfde manier lezen.
Bepaal wie een NCR kan verplaatsen en maak de regels expliciet. Bijvoorbeeld: de melder kan opslaan en indienen, kwaliteit kan accepteren en routeren, productie kan containment-taken voltooien, leverancierskwaliteit kan leveranciers-RCA uitvoeren en het management kan goedkeuren bij hoog risico.
Voeg een paar “gates” toe zodat de juiste informatie bestaat voordat statussen veranderen. Houd het minimaal, maar strikt waar het telt:
Bepaal ook wanneer je CAPA opent in plaats van sluiten als een klein issue. Een eenvoudige regel werkt goed: open CAPA als het defect zich herhaalt, klantimpact heeft, veiligheidsgerelateerd is of supplier-systemisch blijkt. Als het een eenmalige fout is en volledig beheerst met laag herhalingsrisico, sluit het met een korte motivatie.
Plan goedkeuringen vroeg. Veel teams gebruiken een lichte keten: kwaliteit keurt het NCR-record goed, productie bevestigt haalbaarheid, leverancierskwaliteit bevestigt leverancierscommitment en het management tekent voor risico en sluiting.
Als mensen de rollen en regels niet vertrouwen, zoeken ze een omweg. Houd het simpel: één duidelijke eigenaar per NCR en taken die gedelegeerd kunnen worden zonder verantwoordelijkheid te verliezen.
Een praktisch rolmodel:
Houd eigenaarschap bij één persoon (vaak Quality). Laat hen taken herverdelen, maar vermijd het opnieuw toewijzen van de NCR zelf tenzij daar een goede reden voor is. Dat maakt audits later makkelijker.
Permissies moeten overeenkomen met echt werk:
Een audittrail is geen optie. Volg wie wat veranderde en wanneer voor status, vervaldatums, toewijzingen en sleutelvelden. Leg “waarom” vast bij gevoelige wijzigingen, zoals het verplaatsen van een vervaldatum.
Voor leveranciers en externe partijen houd toegang simpel: geef beperkte toegang alleen tot hun toegewezen taken, of gebruik een interne proxy (vaak Supplier Quality) die leveranciersupdates registreert.
Begin bij de data. Als de tabellen duidelijk zijn, worden de schermen makkelijker.
Een praktische kernset objecten is: NCR (het rapport), NCR Item (wat faalde, waar en hoeveel), Task (uit te voeren werk), Comment (discussie) en Attachment (foto’s, PDF’s, metingen). Eén NCR heeft meestal meerdere items, taken, comments en bestanden. Taken moeten altijd terugverwijzen naar de NCR zodat mensen van werk naar context kunnen schakelen met één klik.
Een eenvoudige bouwvolgorde:
Houd het formulier voor "NCR aanmaken" kort. Leg alleen vast wat nodig is om te starten: onderdeelnummer, defectomschrijving, locatie, ernst, gedetecteerd door, datum. Vul de rest op de details-pagina in.
Gebruik workflowregels om statuswijzigingen te beheersen met basiscontroles. Wanneer iemand indient, valideer verplichte velden, zet de status en zet een timestamp voor indiening. Wanneer iemand sluit, bevestig dat alle verplichte taken voltooid zijn en sluitingsnotities aanwezig zijn.
Voorbeeld: een operator meldt een NCR voor gekraste behuizingen. De supervisor opent de NCR, voegt twee taken toe (containment en onderzoek), wijst eigenaren toe en voegt een foto toe. Het record blijft leesbaar omdat taken, comments en bestanden allemaal onder dezelfde NCR staan.
Root-cause analyse faalt wanneer het wordt behandeld als één tekstvak. Een beter patroon is een klein aantal herhaalbare RCA-taaktypes, elk met één duidelijk resultaat dat iemand anders kan verifiëren.
Kies 3 tot 5 RCA-taaktypes die bij de meeste defecten passen en houd ze consistent:
Formuleer taken zodat ze als voltooid of niet voltooid gemarkeerd kunnen worden. "Onderzoek het probleem" is te vaag. "Bevestig het gebruikte koppelbereik op Lot 24 en voeg het koppel-log toe" is verifieerbaar.
Maak bewijs verplicht bij elke RCA-taak, hetzij als bijlage of als korte notitie. Houd vervolgens een gestructureerd veld “Root cause” dat duidelijkheid afdwingt, zoals: Oorzaak (wat faalde), Waarom (wat het toestond), Bewijs (welk bewijs ondersteunt het).
Voeg één gate toe die voortijdige actie voorkomt: RCA moet goedgekeurd zijn voordat CAPA-taken kunnen beginnen.
Een nuttige toets: als iemand nieuw de bewijsvoering kan volgen en de redenering kan reproduceren, doet de RCA zijn werk.
Corrigerende en preventieve acties klinken vergelijkbaar, maar in de praktijk zijn ze verschillend. Corrigerende actie verwijdert de oorzaak van dit specifieke probleem (nu oplossen). Preventieve actie verkleint de kans op herhaling over producten, lijnen of sites.
Houd corrigerende en preventieve acties gescheiden in je NCR/CAPA-app. Anders sluiten teams CAPA met een snelle pleister en verschijnt de herhaling de volgende maand.
Schrijf elke actie zo dat een nieuwe persoon deze kan uitvoeren zonder te raden. Een paar velden zijn genoeg:
Verificatie is de directe controle: hebben we gedaan wat we zeiden en voldoet het aan de acceptatiecriteria? Wijs een verifier toe die bij voorkeur niet de eigenaar is en maak bewijs verplicht.
Effectiviteitsreview komt later: hield de verandering stand over tijd? Stel een raam afhankelijk van risico, vaak 30 tot 90 dagen. Bijvoorbeeld: als de NCR “labels die uitlopen na verpakking” was, kan effectiviteit zijn “nul uitlopende labels in de laatste 500 eenheden” of “geen klantklachten in 60 dagen.”
Sluiting moet een regel zijn, geen gevoel. Sluit alleen als alle acties zijn geverifieerd, de effectiviteitsreview is afgerond (of formeel vrijgegeven met reden) en vereiste goedkeuringen zijn geregistreerd.
Vervaldatums werken alleen als ze eerlijk aanvoelen. Als elke taak "morgen" moet, stopt men het systeem te vertrouwen en negeert men het. Stel redelijke defaults in op basis van ernst en laat eigenaren aanpassen met een duidelijke reden.
Een eenvoudige startpunt die veel teams accepteren:
Houd herinneringen rustig en voorspelbaar: één bericht een paar dagen voor de vervaldatum, daarna één op de vervaldatum. Als een taak al "in progress" is met een commentaar, vermijd dagelijkse meldingen.
Escalatie moet stagnatie van risico voorkomen, niet mensen beschamen. Houd het gekoppeld aan actie:
Om een stille achterstand te stoppen, maak “achterstallig” moeilijk te missen. Zet aantallen achterstallige taken op ieders startscherm: taak-eigenaren zien die van zichzelf, NCR-eigenaren zien alles waarvoor ze verantwoordelijk zijn.
Volg ook cyclustijd zodat je het proces kunt verbeteren, niet alleen data najagen: ingediend tot containment, containment tot RCA en RCA tot sluiting.
Een goed dashboard laat het systeem rustig aanvoelen. Mensen zien wat vandaag aandacht nodig heeft, en managers zien risico voordat het een late auditbevinding wordt.
Begin met één NCR-lijst die iedereen snel kan gebruiken, met consistente filters over schermen heen. Veelgebruikte filters zijn status, ernst, product/procesgebied, leverancier (indien van toepassing) en huidige eigenaar.
Voeg dan een managerview toe die drie vragen beantwoordt: wat is achterstallig? wat wordt oud? wat herhaalt zich? Nuttige tegels zijn achterstallige RCA- en CAPA-taken, verouderende NCRs (bijv. langer dan 30 dagen open) en top defectcategorieën op aantal en ernst. Als je één trend volgt, volg herhalende issues per categorie en productlijn.
Audit trails moeten ingebouwd zijn. Voor elke NCR en CAPA-item leg een geschiedenis vast van wat veranderde, wie het veranderde en wanneer. Leg minimaal statuswijzigingen vast (inclusief heropeningen), goedkeuringen, opmerkingen en bijlagen, vervaldatumwijzigingen (met reden) en heraanwijzingen van eigenaren.
Gebruik gecontroleerde lijsten voor ernst, defectcategorie, root-cause methode en dispositie voor schonere rapportage en eenvoudigere audits. Vrije tekst blijft belangrijk, maar het mag niet de enige bron van waarheid zijn.
Een ontvangstinspecteur ontdekt dat 12 van 200 roestvrijstalen beugels bramen op een rand hebben die een operator kan snijden. Zij registreert een NCR, voegt foto’s toe, het leverancierslotnummer en markeert het als veiligheidsrisico.
De kwaliteitsverantwoordelijke bekijkt het dezelfde dag en neemt de containment-beslissing: het volledige lot in quarantaine zetten, de werkorder die de beugels gebruikt stoppen en productie en inkoop informeren. Een korte nota gaat de werkvloer op: "Gebruik lot L-4821 niet. Onderdelen liggen in Hold area A."
Root-cause analyse start als een kleine set taken met duidelijke eigenaren:
Tegen vrijdag is het team het eens over een root cause-verklaring: "De leverancier wijzigde het ontbraamwiel en sloeg de first-piece check over, waardoor bramen zonder detectie doorkwamen."
CAPA-taken worden toegewezen met vervaldatums en verwacht bewijs:
Sluiting gebeurt pas nadat verificatie slaagt. De goedkeurder markeert de CAPA als "Effectief", voegt het eindinspectierapport en de door de leverancier getekende checklist toe en sluit de NCR met een duidelijke audittrail.
De grootste faalmodus is het rapporteren zo moeilijk maken dat mensen stoppen met rapporteren. Als je NCR-formulier vanaf het begin een volledige root-cause verhaal vraagt, krijg je onvolledige inzendingen of helemaal niets. Houd de eerste stap gericht op wat er gebeurde, waar, wanneer en wie het opmerkte. Voeg diepere details later toe als taken.
Een goede tweede is eigenaarschap. Als een NCR aan "het team" wordt toegewezen, betekent dat meestal "niemand". Elk record heeft één benoemde eigenaar nodig in elke fase, ook al dragen meerdere mensen bij.
Onduidelijke regels scheppen chaos. Als ernst een gevoel is, worden vergelijkbare defecten anders afgehandeld en worden audits rommelig. Definieer ernstniveaus met eenvoudige voorbeelden en wees expliciet over wanneer CAPA vereist is (herhaling, klantimpact, veiligheidsrisico of procesfout).
Een paar fouten die stilletjes NCR/CAPA-tracking breken:
Een andere veelvoorkomende tekortkoming is items sluiten op basis van activiteit, niet op resultaten. "Actie voltooid" is niet hetzelfde als "effectiviteit geverifieerd". Maak verificatie een verplichte stap met een duidelijk slaag-/faalresultaat.
Een eenvoudige NCR-app met CAPA-taken werkt het beste als elk record antwoordt op: wat gebeurde er, wie is eigenaar, wat is de volgende deadline en welk bewijs toont dat het opgelost is.
Houd je eerste build gefocust:
Begin klein met een pilot op één lijn, één locatie of één productfamilie voor 2 tot 3 weken. Je leert welke velden mensen overslaan, welke statussen verwarring zaaien en waar overdrachten stuklopen.
Bepaal vroeg waar de app draait. De cloud is meestal het snelst voor een pilot. Geëxporteerde broncode of self-hosting kan passen bij teams met strikte IT- of dataregels, maar het is makkelijker als je dat vooraf kiest voordat je meldingen en toegangsregels vastlegt.
Als je op AppMaster bouwt, kun je NCRs, taken, eigenaren en vervaldatums modelleren als eenvoudige dataobjecten, en visuele workflows gebruiken om gates af te dwingen zoals "RCA goedgekeurd voordat CAPA start". Voor teams die snel met echte gebruikers willen testen, is AppMaster een praktische manier om te bouwen en itereren zonder te programmeren.
Wat is het verschil tussen een NCR en een CAPA?Een NCR (nonconformance report) legt de feiten vast van wat niet aan een eis voldeed, terwijl CAPA de vervolgactie is: het onderzoekt de oorzaak, lost het probleem op en voorkomt herhaling. Een praktische vuistregel: registreer de NCR direct bij het vinden van het defect, en open CAPA alleen als het probleem herhaald, risicovol, klant-gerelateerd, veiligheidsgerelateerd of systemisch is.
Wanneer moet ik een NCR aanmaken in plaats van het probleem ter plekke op te lossen?Maak er een aan wanneer je een duidelijke non-conformiteit hebt en voldoende informatie om het item en de reikwijdte te identificeren, ook al ken je de oorzaak nog niet. Bij een bijna-fout (near miss) is een NCR meestal de moeite waard als het kostbaar zou zijn als de fout zich herhaalt, omdat het traceerbaarheid en eigenaarschap creëert.
Wat zijn de belangrijkste velden om in een NCR op te nemen?Begin met wat iemand nodig heeft om te handelen: waar het is gevonden, welk item faalde (deel/revisie/lot), wat het defect is, hoeveel getroffen, ernst, en welke onmiddellijke containment is gedaan. Houd het kort bij de aanmaak zodat mensen het daadwerkelijk indienen; voeg onderzoeks- en actiedetails later als taken toe.
Wat is een eenvoudige NCR-naar-CAPA workflow die mensen niet zal verwarren?Een eenvoudige workflow is voldoende: Draft, Submitted, Containment, RCA, CAPA, Verification, Closed. De sleutel is containment te vereisen voordat RCA begint en een goedgekeurde root cause te eisen voordat CAPA-taken starten, zodat acties op bewijs in plaats van gissingen zijn gebaseerd.
Wie moet een NCR bezitten en wie moet de taken doen?Wijs één benoemde eigenaar toe voor de NCR end-to-end, gewoonlijk iemand van Quality, zodat verantwoordelijkheid duidelijk is. Anderen kunnen taken bezitten voor containment, RCA-stappen of acties, maar de enkele NCR-eigenaar houdt het record in beweging en maakt auditvragen later eenvoudiger te beantwoorden.
Hoe stel je permissies in zodat het systeem vertrouwd wordt en niet omzeild?Vergrendel de kernfeiten na indiening zodat het record betrouwbaar blijft, maar sta comments en bijlagen toe zodat mensen context kunnen toevoegen. Een goede regel: reporters kunnen na indiening geen kernvelden meer wijzigen; toegewezenen mogen alleen hun eigen taken bewerken; de NCR-eigenaar beheert status en vervaldatums; goedkeurders moeten commentaar geven bij een afwijzing.
Hoe voorkomen we dat root-cause analyse verandert in vage tekst?Maak bewijs verplicht op taakniveau, niet weggestopt in één grote tekstbox. Vereis een foto, meetlog, geüpdatet document of een korte note die verifieerbaar is, en voeg een gestructureerde root cause-verklaring toe die uitlegt wat faalde, waarom het mocht falen en welk bewijs dat ondersteunt.
Waarom moeten corrigerende en preventieve acties apart worden bijgehouden?Corrigerende acties lossen het specifieke probleem nu op; preventieve acties verkleinen de kans dat dezelfde fout elders terugkomt. Scheid ze in je NCR/CAPA-app zodat je duidelijk kunt zien wat het probleem vandaag oploste versus wat het systeem veranderde om herhaling te voorkomen.
Hoe stellen we vervaldatums, herinneringen en escalatie in zonder iedereen te irriteren?Gebruik default tijdlijnen op basis van ernst en sta wijzigingen alleen toe met een reden. Herinneringen moeten voorspelbaar en beperkt zijn; escalatie moet actie uitlokken zoals het bevestigen van een nieuwe vervaldatum of het informeren van de NCR-eigenaar, in plaats van constante meldingen die iedereen negeert.
Wat is de snelste manier om een NCR-app met CAPA-taken in AppMaster te bouwen?Begin klein met een kern datamodel zoals NCR, NCR Items, Tasks, Comments en Attachments, en bouw drie schermen: lijst, aanmaken en detail. In AppMaster kun je deze modelleren als dataobjecten en visuele workflows gebruiken om gates af te dwingen zoals “containment geregistreerd voordat RCA start” en “RCA goedgekeurd voordat CAPA begint”, zodat je snel een pilot kunt doen zonder te programmeren.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
