Erstelle eine NCR‑App mit CAPA‑Aufgaben, um Fehler zu erfassen, Root‑Cause‑Schritte zuzuweisen, Fälligkeitsdaten zu setzen und Korrekturmaßnahmen bis zur Genehmigung und Schließung nachzuverfolgen.
Ein Nonconformance Report (NCR) ist eine Aufzeichnung von etwas, das eine Anforderung nicht erfüllt hat. Diese Anforderung kann eine Zeichnung, eine Spezifikation, eine Arbeitsanweisung oder eine Kundenerwartung sein. Ziel ist es nicht, jemanden zu beschuldigen, sondern die Fakten festzuhalten, solange sie frisch sind, damit sich derselbe Fehler nicht wiederholt.
CAPA steht für Corrective and Preventive Action. Das ist das, was passiert, nachdem das NCR erfasst wurde: Man untersucht, warum es geschah, behebt das unmittelbare Problem und setzt eine Präventionsmaßnahme um. In einem guten System ist das NCR der Auslöser und CAPA die Nachverfolgung.
Zusammen helfen NCR und CAPA bei einigen praktischen Problemen: konsistente Erfassung von Problemen, klare Zuordnung von Verantwortlichkeiten, termingerechte Schließung mit Fälligkeitsdaten, nachvollziehbare Entscheidungen und Vermeidung von Wiederholungen.
Häufige Auslöser erkennt man leicht, wenn man darauf achtet: eine Kundenbeschwerde, ein nicht bestandener Inprozess‑Check, eine Ablehnung bei der Endprüfung oder ein Lieferantenproblem wie falsche Materialzeugnisse. Auch Beinahe‑Fehler können ein NCR wert sein, wenn die Kosten einer Wiederholung hoch sind.
Ein einfaches Beispiel: Eine Charge fällt bei einer Maßprüfung durch. Das NCR erfasst die Teilenummer, Charge, Messwert, Fotos und wer es gefunden hat. CAPA weist dann RCA‑Aufgaben (Ursachenanalyse), Korrekturmaßnahmen (Eindämmung und Behebung), Prävention (Prozessänderung oder Schulung) und Verifikation vor der Schließung zu.
Ein NCR ist am nützlichsten, wenn es nur das erfasst, was einer Person hilft, eine Entscheidung zu treffen: was passiert ist, wie groß das Problem ist und was als Nächstes zu tun ist. Wenn das Formular wie ein Quiz wirkt, überspringen Leute es oder schreiben „siehe E‑Mail“.
Die meisten Teams kommen mit fünf Feldgruppen gut zurecht:
Anhänge sind oft wichtiger als langer Text. Ein einzelnes Foto eines gerissenen Gehäuses plus die Inspektionsnotiz mit einer Messabweichung kann später Stunden sparen. Bei Lieferantenproblemen lade das Lieferantendokument oder das Zertifikat hoch.
Beispiel: Ein Wareneingangsprüfer markiert 12 Einheiten aus Charge B‑104. Das NCR dokumentiert die PO, Teilenummerrevision, Schwere „hoch“ und Containment „Zurückgehalten im Quarantäneregal Q2“. Das reicht, damit der nächste Verantwortliche mit der Ursachenanalyse beginnen kann, ohne Kontext nachlaufen zu müssen.
Bevor du Bildschirme erstellst, stimmt euch auf einen einfachen Ablauf ab, dem alle folgen können. Ein klarer Workflow verhindert zwei gängige Probleme: NCRs, die im Leerlauf stehen, und CAPAs, die für jedes kleine Problem geöffnet werden.
Beginne mit einer kleinen Menge an Stati, die dem tatsächlichen Arbeitsfluss entsprechen, z. B. Draft, Submitted, Containment, RCA, CAPA, Verification, Closed. Verwende vertraute Namen, damit Bediener, Qualität und Führungskräfte sie gleich verstehen.
Lege fest, wer ein NCR voranbringen kann, und mache die Regeln explizit. Zum Beispiel: Der Meldende kann speichern und einreichen, die Qualität kann annehmen und weiterleiten, die Produktion kann Containment‑Aufgaben abschließen, die Lieferanten‑Qualität kann Lieferanten‑RCA durchführen und das Management kann risikobehaftete Schließungen genehmigen.
Füge ein paar „Gates“ hinzu, damit vor Statuswechseln die richtigen Informationen vorhanden sind. Halte es minimal, aber strikt, wo es zählt:
Entscheide auch, wann CAPA geöffnet wird statt den Fall als geringfügig zu schließen. Eine einfache Regel funktioniert gut: CAPA öffnen bei wiederholten Fehlern, Kundenwirkung, Sicherheitsrelevanz oder systemischem Lieferantenproblem. Bei echten Einzelfällen mit vollständiger Eindämmung und geringem Wiederholrisiko schließe mit kurzer Begründung.
Plane Genehmigungen früh. Viele Teams nutzen eine leichte Kette: Qualität genehmigt den NCR‑Eintrag, Produktion bestätigt Umsetzbarkeit, Lieferanten‑Qualität bestätigt Lieferantenverpflichtungen und das Management unterschreibt Risiko und Schließung.
Wenn Leute Rollen und Regeln nicht vertrauen, umgehen sie das System. Halte es einfach: ein klarer Owner pro NCR und Aufgaben, die delegiert werden können, ohne Verantwortlichkeit zu verlieren.
Ein praktisches Rollenmodell:
Behalte die Verantwortung bei einer Person (oft Quality). Lass sie Aufgaben neu zuweisen, aber vermeide die Neuzuweisung des gesamten NCRs ohne guten Grund. Das erleichtert spätere Auditfragen.
Berechtigungen sollten der tatsächlichen Arbeit entsprechen:
Ein Audittrail ist Pflicht. Verfolge, wer was und wann geändert hat für Status, Fälligkeitsdaten, Zuweisungen und Schlüsselfelder. Erfasse das „Warum“ bei sensiblen Änderungen, z. B. bei der Verschiebung eines Fälligkeitsdatums.
Für Lieferanten und externe Parteien halte den Zugang einfach: Entweder beschränkter Zugang nur zu ihren zugewiesenen Aufgaben oder ein interner Proxy (oft Supplier Quality), der Lieferanten‑Updates dokumentiert.
Beginne mit den Daten. Sind die Tabellen klar, werden die Bildschirme einfacher.
Ein praktischer Kern‑Satz von Objekten: NCR (der Bericht), NCR Item (was ausgefallen ist, wo und wie viele), Task (auszuführende Arbeit), Comment (Diskussion) und Attachment (Fotos, PDFs, Messdaten). Ein NCR hat meist mehrere Items, Tasks, Comments und Dateien. Tasks sollten immer auf das NCR zurückverweisen, damit man mit einem Klick vom Arbeitselement zum Kontext gelangt.
Eine einfache Reihenfolge:
Halte „NCR erstellen“ kurz. Erfasse nur das Nötigste, um die Arbeit zu starten: Teilenummer, Fehlerbeschreibung, Fundort, Schweregrad, Entdeckt von, Datum. Ergänze den Rest auf der Detailseite.
Nutze Workflow‑Regeln, um Statuswechsel mit einfachen Prüfungen zu steuern. Beim Einreichen prüfe Pflichtfelder, setze den Status und stempel die Einreichungszeit. Beim Schließen bestätige, dass alle Pflichtaufgaben abgeschlossen sind und Abschlussnotizen vorhanden sind.
Beispiel: Ein Bediener meldet ein NCR für zerkratzte Gehäuse. Der Vorgesetzte öffnet das NCR, fügt zwei Aufgaben hinzu (Containment und Untersuchung), weist Zuständige zu und hängt ein Foto an. Der Datensatz bleibt lesbar, weil Tasks, Kommentare und Dateien alle unter demselben NCR liegen.
Ursachenanalysen scheitern, wenn sie wie ein einziges Textfeld behandelt werden. Ein besseres Muster sind 3–5 wiederholbare RCA‑Aufgabentypen, jeder mit einem klaren Ergebnis, das jemand anderes verifizieren kann.
Wähle 3 bis 5 RCA‑Aufgabentypen, die auf die meisten Fehler passen, und halte sie konsistent:
Formuliere Aufgaben so, dass sie als erledigt oder nicht erledigt markiert werden können. „Untersuche das Problem“ ist zu vage. „Bestätige den verwendeten Drehmomentbereich bei Charge 24 und hänge das Drehmomentprotokoll an“ ist verifizierbar.
Mache Belege für jede RCA‑Aufgabe erforderlich, entweder als Anhang oder als kurze Notiz. Führe dann ein strukturiertes Feld „Root cause“ ein, das Klarheit erzwingt, z. B.: Ursache (was versagt hat), Warum (was es ermöglicht hat) und Beleg (welcher Nachweis die Schlussfolgerung stützt).
Füge ein Gate hinzu, das voreilige Maßnahmen verhindert: RCA muss genehmigt sein, bevor CAPA‑Aufgaben starten.
Ein nützlicher Test: Kann eine neue Person den Beweis verfolgen und die Schlussfolgerung nachvollziehen? Wenn ja, funktioniert die RCA.
Corrective und preventive actions klingen ähnlich, sind aber praktisch unterschiedlich. Corrective Action beseitigt die Ursache dieses speziellen Problems (jetzt beheben). Preventive Action vermindert die Chance auf Wiederholung über Produkte, Linien oder Standorte hinweg.
Halte corrective und preventive Maßnahmen getrennt in deiner NCR/CAPA‑App. Sonst schließen Teams CAPA mit einem schnellen Flickwerk und der Fehler taucht nächsten Monat wieder auf.
Formuliere jede Maßnahme so, dass eine neue Person sie ohne Rätsel ausführen könnte. Einige Felder genügen:
Verifikation ist die unmittelbare Prüfung: Haben wir getan, was wir gesagt haben, und erfüllt es die Abnahmekriterien? Weise einen Verifizierer zu, der idealerweise nicht der Owner ist, und mache den Nachweis verpflichtend.
Wirksamkeitsprüfung kommt später: Hat die Änderung über die Zeit gehalten? Setze ein Prüfintervall je nach Risiko, oft 30–90 Tage. Beispiel: Bei „Etiketten verschmieren nach Verpackung“ könnte die Wirksamkeit „keine Verschmierungen bei den letzten 500 Einheiten“ oder „keine Kundenbeschwerden in 60 Tagen“ heißen.
Schließung sollte eine Regel sein, kein Gefühl. Schließe nur, wenn alle Maßnahmen verifiziert sind, die Wirksamkeitsprüfung abgeschlossen ist (oder formal mit Begründung erlassen wurde) und erforderliche Genehmigungen dokumentiert sind.
Fälligkeitsdaten funktionieren nur, wenn sie fair wirken. Wenn jede Aufgabe „morgen fällig“ ist, verliert das System Vertrauen und Leute ignorieren es. Setze sinnvolle Standardwerte nach Schweregrad und erlaube Ownern Anpassungen nur mit klarer Begründung.
Ein einfacher Startpunkt, den viele Teams akzeptieren:
Halte Erinnerungen leise und vorhersehbar: eine Nachricht ein paar Tage vor Fälligkeit und eine am Fälligkeitstag. Wenn eine Aufgabe bereits „in Arbeit“ ist und kommentiert wurde, vermeide tägliche Pings.
Eskalation soll gestoppte Risiken verhindern, nicht Menschen bloßstellen. Halte sie an die Aktion gebunden:
Damit sich kein stiller Rückstau bildet, mache „überfällig“ schwer zu übersehen. Zeige überfällige Aufgaben‑Zähler auf dem Startbildschirm jeder Rolle: Aufgaben‑Owner sehen ihre eigenen, NCR‑Owner sehen alle, für die sie verantwortlich sind.
Verfolge außerdem Durchlaufzeiten, damit du den Prozess verbessern kannst, nicht nur Termine nachjagst: eingereicht bis Containment, Containment bis RCA und RCA bis Schließung.
Ein gutes Dashboard lässt das System ruhig wirken. Leute sehen, was heute Aufmerksamkeit braucht, und Manager erkennen Risiken, bevor sie zu späten Audit‑Feststellungen werden.
Beginne mit einer NCR‑Liste, die schnell nutzbar ist, mit konsistenten Filtern über alle Bildschirme. Übliche Filter: Status, Schweregrad, Produkt/Prozessbereich, Lieferant (falls zutreffend) und aktueller Owner.
Füge dann eine Manageransicht hinzu, die drei Fragen beantwortet: Was ist überfällig? Was wird alt? Was wiederholt sich? Nützliche Kacheln sind überfällige RCA‑ und CAPA‑Aufgaben, alternde NCRs (z. B. länger als 30 Tage offen) und Top‑Fehlerkategorien nach Anzahl und Schwere. Wenn du nur einen Trend verfolgst, verfolge Wiederholfehler nach Kategorie und Produktlinie.
Audit‑Trails sollten eingebaut sein. Für jedes NCR und jedes CAPA‑Element erfasse eine Historie: was sich geändert hat, wer es geändert hat und wann. Mindestens: Statusänderungen (inklusive Wiederöffnen), Genehmigungen, Kommentare und Anhänge, Fälligkeitsänderungen (mit Grund) und Owner‑Reassignments.
Für sauberere Berichte und einfachere Audits nutze kontrollierte Listen für Schweregrad, Fehlerkategorie, Root‑Cause‑Methode und Disposition. Freitext bleibt wichtig, darf aber nicht die einzige Wahrheit sein.
Ein Wareneingangsprüfer findet, dass 12 von 200 Edelstahl‑Halterungen einen Grat an einer Kante haben, der einen Bediener schneiden könnte. Sie legt ein NCR an, hängt Fotos an, notiert die Lieferantencharge und markiert es als Sicherheitsrisiko.
Der Qualitätsleiter prüft noch am selben Tag und entscheidet über Containment: die gesamte Charge in Quarantäne, den Arbeitsauftrag zu stoppen, der die Halterungen verwendet, und Produktion sowie Einkauf zu informieren. Eine kurze Notiz geht auf die Fläche: „Verwende nicht Charge L‑4821. Teile im Hold‑Bereich A.“
Die Ursachenanalyse startet als kleine Menge klarer Aufgaben mit eindeutigen Zuständigen:
Bis Freitag stimmt das Team einer Root‑Cause‑Aussage zu: „Der Lieferant hat das Entgratungsrad gewechselt und den First‑Piece‑Check übersprungen, sodass Grate ohne Erkennung durchgingen.“
CAPA‑Aufgaben werden mit Fälligkeitsdaten und erwarteten Nachweisen zugewiesen:
Die Schließung erfolgt erst nach bestandener Verifikation. Der Genehmiger markiert die CAPA als „Effektiv“, hängt den abschließenden Inspektionsbericht und die unterschriebene Checkliste des Lieferanten an und schließt das NCR mit klarer Audit‑Historie.
Der größte Fehler ist, das Melden so kompliziert zu machen, dass Leute aufhören zu melden. Wenn dein NCR‑Formular von Anfang an eine vollständige Ursachenstory verlangt, bekommst du unvollständige Einträge oder gar keine. Konzentriere den ersten Schritt auf was passiert ist, wo, wann und wer es bemerkt hat. Füge tiefere Details später als Aufgaben hinzu.
Dicht dahinter kommt Ownership. Wenn ein NCR „dem Team“ zugewiesen wird, heißt das oft „niemand“. Jeder Datensatz braucht eine namentlich genannte verantwortliche Person in jeder Phase, auch wenn mehrere beitragen.
Unklare Regeln schaffen Chaos. Wenn Schweregrad eine Gefühlsfrage ist, werden ähnliche Fehler unterschiedlich behandelt und Audits werden unübersichtlich. Definiere Schweregrade mit einfachen Beispielen und sei explizit, wann CAPA erforderlich ist (Wiederholung, Kundenwirkung, Sicherheitsrisiko, oder Prozessversagen).
Einige Fehler, die heimlich das Tracking kaputtmachen:
Eine weitere Lücke ist das Schließen von Punkten wegen Aktivität und nicht wegen Ergebnis. „Aktion abgeschlossen“ ist nicht gleich „Wirksamkeit verifiziert“. Mache die Verifikation zu einem Pflichtschritt mit klarem Bestehen/Nichtbestehen‑Ergebnis.
Eine einfache NCR‑App mit CAPA‑Aufgaben funktioniert am besten, wenn jeder Datensatz beantwortet: Was ist passiert, wer ist verantwortlich, was ist als Nächstes fällig und welcher Beleg zeigt, dass es behoben ist.
Behalte dein erstes Build fokussiert:
Starte klein mit einem Pilot auf einer Linie, einem Standort oder einer Produktfamilie für 2–3 Wochen. So findest du heraus, welche Felder Leute überspringen, welche Stati verwirren und wo Übergaben scheitern.
Entscheide früh, wo die App laufen soll. Die Cloud ist meist am schnellsten für einen Pilot. Exportierter Quellcode oder Self‑Hosting passt besser zu Teams mit strengen IT‑ oder Datenregeln, aber es ist einfacher, das zu entscheiden, bevor du Benachrichtigungen und Zugriffsregeln festlegst.
Wenn du auf AppMaster baust, kannst du NCRs, Aufgaben, Owner und Fälligkeitsdaten als einfache Datenobjekte modellieren und visuelle Workflows nutzen, um Gates wie „RCA genehmigt bevor CAPA beginnt“ durchzusetzen. Für Teams, die schnell mit echten Nutzern testen wollen, ist AppMaster (appmaster.io) ein praktischer Weg, ohne zu programmieren zu bauen und iterieren zu können.
Was ist der Unterschied zwischen einem NCR und einer CAPA?Ein NCR (Nonconformance Report) erfasst die Fakten darüber, was eine Anforderung nicht erfüllt hat, während CAPA die Nachverfolgung ist: Ursache untersuchen, das Problem beheben und Wiederholungen verhindern. Eine praktische Regel: NCR beim Auffinden des Fehlers erfassen; CAPA nur öffnen, wenn das Problem wiederholt auftritt, hohes Risiko hat, Kunden betrifft, sicherheitsrelevant ist oder offensichtlich systemisch ist.
Wann sollte ich ein NCR erstellen, statt das Problem vor Ort sofort zu beheben?Erfasse es, wenn eine klare Nichtübereinstimmung vorliegt und genug Informationen vorhanden sind, um den Artikel und den Umfang zu identifizieren – selbst wenn die Ursache noch unbekannt ist. Bei einem Beinahe-Fall kann ein NCR sinnvoll sein, wenn die Kosten einer Wiederholung hoch wären, weil so Nachvollziehbarkeit und Verantwortlichkeit entstehen.
Welche Felder sind am wichtigsten in einem NCR?Beginne mit dem, was jemand zum Handeln braucht: Fundort, Artikel (Teil/Revision/Charge), Beschreibung des Fehlers, wie viele betroffen sind, Schweregrad und welche sofortige Containment‑Maßnahme ergriffen wurde. Halte das Erstellformular kurz, damit Leute es tatsächlich absenden; tiefere Details kommen später als Aufgaben.
Was ist ein einfacher NCR‑zu‑CAPA‑Workflow, der nicht verwirrt?Ein einfacher Workflow reicht: Draft, Submitted, Containment, RCA, CAPA, Verification, Closed. Wichtig ist, dass Containment vor RCA verlangt wird und ein genehmigter Root‑Cause‑Befund vor Beginn der CAPA‑Aufgaben nötig ist, damit Maßnahmen auf Beweisen und nicht auf Vermutungen beruhen.
Wer sollte ein NCR besitzen und wer sollte die Aufgaben machen?Gib jedem NCR eine namentlich genannte verantwortliche Person, häufig Quality, damit Verantwortlichkeit klar ist. Andere Personen können Aufgaben für Containment, RCA oder Maßnahmen übernehmen, aber der einzelne NCR‑Owner sorgt dafür, dass der Vorgang weiterläuft und Auditfragen beantwortbar bleiben.
Wie setzen wir Berechtigungen so, dass das System vertraut wird und nicht umgangen wird?Sperre Kerninformationen nach dem Absenden, damit der Datensatz vertrauenswürdig bleibt, aber erlaube Kommentare und Anhänge zur Ergänzung. Richtlinie: Reporter können nach dem Absenden keine Kerndaten mehr ändern; Bearbeiter dürfen nur ihre Aufgaben bearbeiten; der NCR‑Owner steuert Status und Fälligkeitsdaten; Genehmiger müssen eine Begründung bei Ablehnung hinterlassen.
Wie verhindern wir, dass Root‑Cause‑Analysen zu vagen Texten verkommen?Mache Beweise auf Aufgabenebene verpflichtend, statt alles in einem großen Textfeld zu sammeln. Verlange ein Foto, Messprotokoll, aktualisiertes Dokument oder eine kurze, überprüfbare Notiz und ein strukturiertes Root‑Cause‑Feld, das erklärt: Was ist fehlgeschlagen, warum konnte es passieren, und welche Belege stützen die Schlussfolgerung.
Warum sollten corrective und preventive Maßnahmen getrennt nachverfolgt werden?Corrective Action behebt die Ursache dieses speziellen Problems (jetzt fixen). Preventive Action reduziert die Chance, dass derselbe Fehler woanders oder später wieder auftritt. Getrennte Nachverfolgung zwingt zur Klarheit: So sieht man, was das heutige Problem gelöst hat und was das System langfristig verbessert.
Wie legt man Fälligkeitsdaten, Erinnerungen und Eskalationen fest, ohne alle zu nerven?Nutze Standardfristen nach Schweregrad und erlaube Änderungen nur mit Begründung. Erinnerungen sollten vorhersehbar und begrenzt sein; Eskalationen sollten zu einer Handlung führen (z. B. neues Fälligkeitsdatum bestätigen), nicht zu ständigen Störungen, die jeder ignoriert.
Wie baue ich am schnellsten eine NCR‑App mit CAPA‑Aufgaben in AppMaster?Beginne klein mit einem Kern‑Datenmodell: NCR, NCR Items, Tasks, Comments und Attachments, und baue drei Bildschirme: Liste, Erstellen und Details. In AppMaster kannst du diese Objekte modellieren und visuelle Workflows nutzen, um Gates wie «Containment aufgezeichnet bevor RCA» und «RCA genehmigt bevor CAPA beginnt» durchzusetzen – das hilft beim schnellen Pilot ohne zu programmieren.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
