Ausgangslage: Das Reklamations-Chaos
Das Reklamationsmanagement bei Tier-1 Zulieferern ist ein Stresstest für jede Organisation:
Die tägliche Realität
- 07:15 – E-Mail von BMW: “Lieferung gestern, 3% Ausschuss bei Sichtprüfung”
- 08:30 – EDI-Nachricht von VW: Formale Reklamation nach VDA 4939
- 09:45 – Anruf vom Audi-Qualitätsmanager: “Wir brauchen bis 14:00 Uhr eine Erstreaktion”
- 11:00 – Kundenportal-Ticket von Mercedes: Feldfehler aus dem Aftersales
Das Problem: Jeder Kanal hat ein anderes Format, andere Fristen, andere Eskalationswege.
Warum SAP QM hier versagt
| Anforderung | SAP-Limitation |
|---|---|
| Multi-Channel-Eingang | Keine native E-Mail/EDI/Portal-Integration |
| Intelligente Kategorisierung | Manuelle Eingabe erforderlich |
| 8D-Workflow-Automatisierung | Starre Prozesse ohne Flexibilität |
| KI-Ursachenvorschläge | Nicht vorhanden |
| Deadline-Monitoring | Begrenzte Eskalationslogik |
| Externe Kommunikation | Add-ons erforderlich |
Die Konsequenzen
┌─────────────────────────────────────────────────────────────────┐
│ AUSWIRKUNGEN DES MANUELLEN PROZESSES │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ⏱️ Erstreaktion │ 35% der 24h-Fristen werden verpasst │
│ 📋 Kategorisierung │ 2-4 Stunden manuelle Arbeit │
│ 🔍 Ursachenanalyse │ Abhängig von einzelnen Experten │
│ 📅 8D-Durchlaufzeit │ Durchschnittlich 21 Tage │
│ 🔄 Wiederholungsfehler│ 12% der Reklamationen sind Repeat │
│ 💰 Warranty-Kosten │ Tracking mit 2 Wochen Verzögerung │
│ │
└─────────────────────────────────────────────────────────────────┘
Die n8n-Lösung: Intelligentes Reklamations-Workflow-System
Ein End-to-End-System mit KI-Kategorisierung, automatisierter 8D-Orchestrierung und proaktivem Deadline-Monitoring.
Gesamtarchitektur
┌─────────────────────────────────────────────────────────────────┐
│ EINGANGS-KANÄLE │
├─────────────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ E-Mail │ │ Kundenportal│ │ EDI │ │
│ │ (IMAP) │ │ (Webhook) │ │ (VDA 4939) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
└─────────┼────────────────┼────────────────┼──────────────────────┘
│ │ │
└────────────────┼────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ INTAKE & TRIAGE │
├─────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Merge & Normalisierung │ │
│ │ Einheitliches Reklamations-Objekt erstellen │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AI Agent: Kategorisierung + Schweregrad │ │
│ │ │ │
│ │ • Fehlerart erkennen (Maß, Oberfläche, Funktion, ...) │ │
│ │ • Schweregrad bewerten (Kritisch/Hoch/Normal) │ │
│ │ • Verantwortliche Abteilung identifizieren │ │
│ │ • Erste RCA-Hypothesen generieren │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ KRITISCH │ │ HOCH │ │ NORMAL │ │
│ │ Sofort-Esk. │ │ 24h-Response│ │ Standard │ │
│ │ + Sperrung │ │ │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ 8D-PROZESS-ORCHESTRIERUNG │
├─────────────────────────────────────────────────────────────────┤
│ │
│ D1 ──▶ D2 ──▶ D3 ──▶ D4 ──▶ D5 ──▶ D6 ──▶ D7 ──▶ D8 │
│ │ │ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ │
│ Team Problem Contain Root Correc Implem Prevent Close │
│ Form Descr. ment Cause tive ent ion out │
│ (AI) │
│ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ DEADLINE-MONITORING │
├─────────────────────────────────────────────────────────────────┤
│ Schedule (stündlich) ──▶ Deadline-Check ──▶ Eskalation │
└─────────────────────────────────────────────────────────────────┘
Phase 1: Intake & Triage
Multi-Channel-Eingang
┌─────────────────────────────────────────────────────────────────┐
│ KANAL │ TRIGGER │ DATENEXTRAKTION │
├──────────────────┼───────────────────────┼──────────────────────┤
│ E-Mail │ IMAP Trigger │ Subject, Body, │
│ │ (Ordner: Reklamation)│ Attachments │
├──────────────────┼───────────────────────┼──────────────────────┤
│ Kundenportal │ Webhook │ JSON Payload │
│ (BMW, VW, etc.) │ POST /complaint │ │
├──────────────────┼───────────────────────┼──────────────────────┤
│ EDI (VDA 4939) │ Schedule Poll │ XML Parsing │
│ │ (alle 15 min) │ │
├──────────────────┼───────────────────────┼──────────────────────┤
│ Lieferanten- │ Webhook │ JSON Payload │
│ Rückmeldung │ POST /supplier-reply │ │
└──────────────────┴───────────────────────┴──────────────────────┘
Normalisierung
Alle Eingänge werden in ein einheitliches Format überführt:
{
"complaint_id": "RKL-2026-00142",
"source": "email",
"customer": {
"name": "BMW AG",
"contact": "q.manager@bmw.de",
"plant": "München"
},
"part": {
"number": "1234567890",
"name": "Querlenker vorne links",
"delivery_note": "LS-2026-0815",
"quantity_affected": 47
},
"complaint": {
"description": "Maßabweichung am Lagersitz, 0.3mm über Toleranz",
"detected_at": "Wareneingang",
"severity_customer": "A-Fehler"
},
"deadlines": {
"first_response": "2026-01-30T14:00:00Z",
"containment": "2026-01-31T18:00:00Z",
"root_cause": "2026-02-04T18:00:00Z"
},
"attachments": [
"messprotokoll.pdf",
"foto_lagersitz.jpg"
]
}
KI-Kategorisierung
┌─────────────────────────────────────────────────────────────────┐
│ AI Agent: Reklamations-Kategorisierung │
├─────────────────────────────────────────────────────────────────┤
│ │
│ SYSTEM PROMPT: │
│ ───────────────────────────────────────────────────────────── │
│ Du bist ein Qualitätsexperte in der Automobilzulieferindustrie.│
│ Analysiere die Reklamation und kategorisiere sie. │
│ │
│ AUFGABEN: │
│ 1. Fehlerart bestimmen: │
│ - Maßfehler / Oberflächenfehler / Funktionsfehler │
│ - Materialfehler / Montagefehler / Dokumentationsfehler │
│ │
│ 2. Schweregrad bewerten: │
│ - KRITISCH: Sicherheitsrelevant, Bandstillstand droht │
│ - HOCH: Funktionsbeeinträchtigung, hohe Stückzahl │
│ - NORMAL: Optischer Mangel, geringe Stückzahl │
│ │
│ 3. Verantwortliche Abteilung: │
│ - Fertigung / Qualität / Entwicklung / Lieferant │
│ │
│ 4. Erste RCA-Hypothesen (3-5 mögliche Ursachen) │
│ │
│ OUTPUT FORMAT: Strukturiertes JSON │
│ │
└─────────────────────────────────────────────────────────────────┘
Beispiel-Output:
{
"category": {
"error_type": "Maßfehler",
"sub_type": "Toleranzüberschreitung",
"affected_process": "Drehen"
},
"severity": {
"level": "HOCH",
"reasoning": "Lagersitz ist funktionskritisch, 47 Teile betroffen"
},
"routing": {
"department": "Fertigung",
"team": "Zerspanung",
"escalation_to": "Fertigungsleiter"
},
"rca_hypotheses": [
{
"hypothesis": "Werkzeugverschleiß",
"probability": "HOCH",
"check": "Werkzeugstandzeit und letzte Wechsel prüfen"
},
{
"hypothesis": "Temperatureinfluss",
"probability": "MITTEL",
"check": "Kühlmitteltemperatur und Hallenklima prüfen"
},
{
"hypothesis": "Materialcharge",
"probability": "MITTEL",
"check": "Chargenwechsel und Materialzertifikat prüfen"
}
]
}
Phase 2: 8D-Prozess-Orchestrierung
D1: Team-Formierung (automatisch)
┌─────────────────────────────────────────────────────────────────┐
│ D1: TEAM-FORMIERUNG │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Trigger: Neue Reklamation kategorisiert │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Code Node: Team-Zusammenstellung │ │
│ │ │ │
│ │ Basierend auf: │ │
│ │ - Fehlerart → Fachexperte │ │
│ │ - Kunde → Key Account Manager │ │
│ │ - Schweregrad → Eskalationsstufe │ │
│ │ - Verfügbarkeit → Urlaubskalender prüfen │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Postgres: Team speichern │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Teams: Einladung an alle Teammitglieder │ │
│ │ │ │
│ │ "🚨 Neue Reklamation: RKL-2026-00142 │ │
│ │ Kunde: BMW München │ │
│ │ Teil: Querlenker (1234567890) │ │
│ │ Schweregrad: HOCH │ │
│ │ │ │
│ │ Team: @m.mueller @s.schmidt @k.klein │ │
│ │ Deadline Erstreaktion: Heute 14:00 Uhr" │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
D2: Problembeschreibung
┌─────────────────────────────────────────────────────────────────┐
│ D2: PROBLEMBESCHREIBUNG (5W2H) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Webhook: POST /d2-submit │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Formular-Daten validieren │ │
│ │ │ │
│ │ WAS? │ Maßabweichung Lagersitz +0.3mm │ │
│ │ WO? │ Wareneingang BMW München │ │
│ │ WANN? │ 29.01.2026, Lieferung vom 28.01. │ │
│ │ WER? │ Entdeckt von WE-Prüfer Hr. Meier │ │
│ │ WARUM? │ (wird in D4 analysiert) │ │
│ │ WIE? │ Stichprobenmessung mit 3D-Koordinaten │ │
│ │ WIEVIEL?│ 47 von 500 Teilen betroffen (9.4%) │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Google Drive: Dokumente hochladen │ │
│ │ - Messprotokolle │ │
│ │ - Fotos │ │
│ │ - Kundenreklamation (Original) │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Postgres: D2 Status = "Abgeschlossen" │ │
│ │ Postgres: D3 Status = "In Bearbeitung" │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
D3: Sofortmaßnahmen (Containment)
┌─────────────────────────────────────────────────────────────────┐
│ D3: SOFORTMAßNAHMEN │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Webhook: POST /d3-submit │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Maßnahmen erfassen │ │
│ │ │ │
│ │ ☑️ Lagerbestand gesperrt (200 Teile) │ │
│ │ ☑️ Laufende Produktion: 100%-Prüfung angeordnet │ │
│ │ ☑️ Unterwegs-Ware identifiziert (3 LKW, 600 Teile) │ │
│ │ ☑️ Kunde informiert über Sofortmaßnahmen │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ┌────────────┴────────────┐ │
│ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ IF: Rückruf │ │ Kein │ │
│ │ erforderlich│ │ Rückruf │ │
│ └──────┬──────┘ └─────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ HTTP Request: SAP QM │ │
│ │ - Q-Meldung anlegen │ │
│ │ - Sperrbestand buchen │ │
│ │ - Rückholaktion initiieren │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Email: Lieferant informieren │ │
│ │ │ │
│ │ "Sperrung Ihrer Lieferung LS-2026-0815 │ │
│ │ Grund: Maßabweichung Lagersitz │ │
│ │ Betroffene Menge: 47 Teile │ │
│ │ Wir erwarten Ihre Stellungnahme bis 31.01." │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
D4: Root Cause Analysis (KI-gestützt)
Der Kern der Automatisierung:
┌─────────────────────────────────────────────────────────────────┐
│ D4: URSACHENANALYSE MIT KI │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AI Agent: Root Cause Analysis │ │
│ │ │ │
│ │ TOOLS: │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Postgres │ │ HTTP: FMEA │ │ Code: │ │ │
│ │ │ Historie │ │ Datenbank │ │ Pattern │ │ │
│ │ │ Query │ │ │ │ Matching │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ ANALYSE-SCHRITTE: │ │
│ │ │ │
│ │ 1. Historische Fälle suchen │ │
│ │ "Gab es ähnliche Maßfehler an diesem Teil?" │ │
│ │ → 3 ähnliche Fälle in den letzten 2 Jahren │ │
│ │ │ │
│ │ 2. FMEA-Datenbank abfragen │ │
│ │ "Welche Fehlermodi sind für Drehen dokumentiert?" │ │
│ │ → Werkzeugverschleiß, Spannfehler, Temperatur │ │
│ │ │ │
│ │ 3. Muster erkennen │ │
│ │ "Korrelation mit Schicht, Maschine, Material?" │ │
│ │ → 80% der Fehler in Nachtschicht │ │
│ │ │ │
│ │ 4. Ursachen-Hypothesen generieren │ │
│ │ → Ishikawa-Kategorien: 6M │ │
│ │ │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ OUTPUT: Strukturierte Ursachenanalyse │ │
│ │ │ │
│ │ WAHRSCHEINLICHSTE URSACHE: │ │
│ │ Werkzeugverschleiß (Konfidenz: 85%) │ │
│ │ │ │
│ │ BEGRÜNDUNG: │ │
│ │ - Historisch: 2 von 3 ähnlichen Fällen = Werkzeug │ │
│ │ - FMEA: Werkzeugverschleiß = RPN 180 (hoch) │ │
│ │ - Muster: Fehler häufen sich am Schichtende │ │
│ │ │ │
│ │ EMPFOHLENE VERIFIZIERUNG: │ │
│ │ 1. Werkzeugstandzeit prüfen (Soll: 500, Ist: ?) │ │
│ │ 2. Letzte Werkzeugwechsel dokumentieren │ │
│ │ 3. Verschleißmessung durchführen │ │
│ │ │ │
│ │ 5-WHY VORSCHLAG: │ │
│ │ Why 1: Maßabweichung → Werkzeug verschlissen │ │
│ │ Why 2: Verschlissen → Standzeit überschritten │ │
│ │ Why 3: Überschritten → Kein automatischer Wechsel │ │
│ │ Why 4: Kein Wechsel → Zähler nicht implementiert │ │
│ │ Why 5: Nicht impl. → Investition nicht genehmigt │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
D5-D8: Korrekturmaßnahmen und Abschluss
┌─────────────────────────────────────────────────────────────────┐
│ D5-D8: KORREKTUR, IMPLEMENTIERUNG, VORBEUGUNG, ABSCHLUSS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ D5: DAUERHAFTE ABHILFE │
│ ───────────────────────────────────────────────────────────── │
│ Webhook: POST /d5-submit │
│ → Jira: Ticket für Korrekturmaßnahme erstellen │
│ → Postgres: Maßnahme mit Deadline speichern │
│ │
│ D6: IMPLEMENTIERUNG │
│ ───────────────────────────────────────────────────────────── │
│ Webhook: POST /d6-submit │
│ → Wirksamkeitsprüfung: Messreihe nach Änderung │
│ → IF: Cpk > 1.33 → Maßnahme erfolgreich │
│ → IF: Cpk < 1.33 → Zurück zu D5 │
│ │
│ D7: VORBEUGUNG │
│ ───────────────────────────────────────────────────────────── │
│ Webhook: POST /d7-submit │
│ → FMEA-Update: Neuen Fehlermodus dokumentieren │
│ → Arbeitsanweisung: Revision erstellen │
│ → Schulung: Termin planen │
│ │
│ D8: ABSCHLUSS │
│ ───────────────────────────────────────────────────────────── │
│ Webhook: POST /d8-submit │
│ → 8D-Report PDF generieren │
│ → Email: An Kunden senden │
│ → SAP QM: Q-Meldung abschließen │
│ → Postgres: Status = "Abgeschlossen" │
│ → Teams: "🎉 8D-Report RKL-2026-00142 abgeschlossen" │
│ │
└─────────────────────────────────────────────────────────────────┘
Phase 3: Deadline-Monitoring
┌─────────────────────────────────────────────────────────────────┐
│ SCHEDULE TRIGGER: Stündlich │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Postgres: Alle offenen Reklamationen abfragen │ │
│ │ │ │
│ │ SELECT * FROM complaints │ │
│ │ WHERE status != 'closed' │ │
│ │ AND ( │ │
│ │ (current_step = 'D1' AND d1_deadline < NOW()) │ │
│ │ OR (current_step = 'D3' AND d3_deadline < NOW()) │ │
│ │ OR ... │ │
│ │ ) │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Code Node: Eskalationsstufe berechnen │ │
│ │ │ │
│ │ Zeit verstrichen vs. Deadline: │ │
│ │ - < 75% → Keine Aktion │ │
│ │ - 75-90% → Erinnerung an Bearbeiter │ │
│ │ - 90-100%→ Warnung an Teamleiter │ │
│ │ - > 100% → Eskalation an QM-Leiter + Kunde informieren │ │
│ └────────────────────────┬────────────────────────────────┘ │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ > 75% │ │ > 90% │ │ Überfällig │ │
│ │ │ │ │ │ │ │
│ │ Email: │ │ Teams: │ │ Email: │ │
│ │ Bearbeiter │ │ Teamleiter │ │ QM-Leiter │ │
│ │ │ │ + Bearbeiter│ │ + Kunde │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Technische Umsetzung
Verwendete n8n Nodes
| Node | Zweck |
|---|---|
| IMAP Email Trigger | E-Mail-Reklamationen empfangen |
| Webhook | Portal, EDI, Formular-Submissions |
| AI Agent + OpenAI | Kategorisierung, RCA |
| Postgres | Reklamations-DB, Status-Tracking |
| HTTP Request | SAP QM, FMEA-System, Kundenportale |
| IF / Switch | Schweregrad-Routing, Deadline-Logik |
| Jira | Action Items für Korrekturmaßnahmen |
| Google Drive | Dokumente, Fotos, Reports |
| Schedule Trigger | Deadline-Monitoring |
| Email / Teams / Slack | Benachrichtigungen, Eskalationen |
Datenmodell (Postgres)
-- Reklamationen
CREATE TABLE complaints (
id VARCHAR(20) PRIMARY KEY,
source VARCHAR(20),
customer_name VARCHAR(100),
part_number VARCHAR(50),
description TEXT,
severity VARCHAR(20),
current_step VARCHAR(5),
status VARCHAR(20),
created_at TIMESTAMP DEFAULT NOW(),
-- Deadlines
d1_deadline TIMESTAMP,
d3_deadline TIMESTAMP,
d4_deadline TIMESTAMP,
d8_deadline TIMESTAMP,
-- AI-Kategorisierung
error_type VARCHAR(50),
root_cause_hypothesis JSONB,
-- Team
team_members TEXT[]
);
-- 8D-Schritte
CREATE TABLE complaint_steps (
id SERIAL PRIMARY KEY,
complaint_id VARCHAR(20) REFERENCES complaints(id),
step VARCHAR(5),
status VARCHAR(20),
completed_by VARCHAR(100),
completed_at TIMESTAMP,
data JSONB
);
-- Eskalations-Log
CREATE TABLE escalations (
id SERIAL PRIMARY KEY,
complaint_id VARCHAR(20) REFERENCES complaints(id),
level VARCHAR(20),
reason TEXT,
notified_users TEXT[],
created_at TIMESTAMP DEFAULT NOW()
);
Messbare Ergebnisse
| KPI | Vorher (manuell) | Nachher (n8n) | Verbesserung |
|---|---|---|---|
| Erstreaktion 24h-Quote | 65% | 98% | +33 Prozentpunkte |
| Kategorisierungszeit | 2-4 Stunden | < 5 Minuten | 95% schneller |
| 8D-Durchlaufzeit | 21 Tage | 12 Tage | 43% schneller |
| Wiederholungsfehler | 12% | 5% | 58% Reduktion |
| Warranty Cost Tracking | 2 Wochen Lag | Real-time | 100% schneller |
| Verpasste Deadlines | 35% | < 5% | 86% Reduktion |
Fazit
Das KI-gestützte 8D-Reklamationsmanagement mit n8n löst drei fundamentale Probleme:
-
Multi-Channel-Chaos → Einheitlicher Eingang
- E-Mail, EDI, Portale werden automatisch normalisiert
-
Experten-Abhängigkeit → KI-Unterstützung
- Root Cause Hypothesen in Sekunden statt Tagen
-
Deadline-Stress → Proaktive Eskalation
- Niemand verpasst mehr eine OEM-Frist
Der ROI:
- Weniger Vertragsstrafen durch verpasste Deadlines
- Schnellere Problemlösung = weniger Ausschuss
- Systematisches Lernen durch FMEA-Updates
Tech Stack: n8n, PostgreSQL, OpenAI/Claude, SAP QM, Jira, Google Drive
Standards: IATF 16949, VDA 4939, 8D-Methodik
Interesse an einer Implementierung? Dann schreib mir einfach auf LinkedIn oder buche direkt einen kostenlosen Call.