Problemlösungs-Methoden – Ursachenanalyse nach Problemlage

Ein Beitrag von Dr. Uwe-Klaus Jarosch, Januar 2026

In der industriellen Praxis wird nach meiner Beobachtung häufig auf eine leicht handhabbare Methode der Problemlösung fokussiert. Sie wird propagiert, gefordert, durch eigene Vorgaben und Schulungen gefördert.

Schaut man in die Literatur, so sind eine Vielzahl von Methoden entwickelt worden, die mehr oder weniger stark dazu dienen, Probleme zu lösen.

Dabei erscheint es mir sinnvoll – wenn die Überschrift „Problemlösungs-Methoden“ heißt – zu unterscheiden zwischen

1. Ich habe eine Aufgabe, die nicht einfach zu lösen ist. Diese Aufgabe gehört zu meiner täglichen Arbeit, egal ob Erfinden, Entwickeln, Reparieren und der Lösungsweg ist noch nicht fertig verfügbar.
2. Ein Problem ist eskaliert. Es muss unter Zeitdruck und um weiteren Schaden abzuwenden eine Lösung gefunden werden, um zunächst den Kunden wieder zufrieden zu stellen, um dann den eigenen Ablauf wieder unter Kontrolle zu bringen.

Problem-Art 1 wendet sich an Entwicklungsmethoden, die mir und meinem Team helfen, systematisch von einer Aufgabe zu einer Lösung zu kommen. In der Blog-Sammlung „Mit Methode“ sind solche Methoden in den Rubriken „Qualitäts-Vorausplanung“, „Ursache-Wirkung“, „Entwicklungs-Methoden“ und „Entwicklung von Qualität und/bei Lieferanten“ gesammelt.

Problem-Art 2 hingegen benötigt Methoden, die zur Anwendung kommen, wenn die Entwicklung von Produkt oder Prozess weitgehend abgeschlossen ist, dann aber unerwartete und nachteilige Ereignisse beobachtet werden.
Geeignete Methoden sind in der Blog-Sammlung „Mit Methode“ in der Rubrik „Problemlösungsmethoden“ gesammelt.

Aber auch bei den Problemlösungs-Methoden gibt es nicht ohne Grund eine große Auswahl.

Wenn man sich den von Walter E. Shewhart erfundenen und von William E. Deming bekannt gemachten PDCA-Kreis als Grundüberlegung nimmt, so ergibt sich ein Vorgehensmodell, dass in seinem grundlegenden Ablauf universell ist, dann aber von Situation zu Situation geeignet ausgestaltet werden muss:

• P – Planen:  Identifizieren von Problemen und Ursachen, Festlegen von Zielen.
• D = Do = Umsetzen:  Implementierung der geplanten Maßnahmen.
• C = Check = Überprüfen:  Überwachung und Bewertung der Ergebnisse.
• A = Act = Handeln:  Anpassungen vornehmen und als neuen Standard definieren, den Prozess nach neuem Stand fortführen, wiederholen. 

Je nach Methode werden nur Teile des PDCA abgedeckt und es braucht eine Abfolge und Kombination mehrerer Methoden für den gesamten interativen Kreis.

Für diesen Blog-Beitrag aber noch wichtiger ist die Unterscheidung von Problem-Typen, um dann geeignete Methoden zu wählen und einzusetzen.

Problem-Typen

Was an Problem-Typen können wir unterscheiden?

  Wohl definierte Probleme – Anfangs‑ und Endzustand sind klar, das Problem hat typisch nur eine wesentliche Ursache, die sich ermitteln und abstellen lässt. Dies können beispielsweise technische/physische Fehler an Produkten, Maschinen, Abläufen sein.
Hier hilft schon die Durchsicht von Checklisten, die Rückkehr zur Anwendung der Standardarbeitsanweisungen oder eine Root‑Cause‑Analyse, z.B. mittels Ishikawa-Fischgräten-Diagramm, 5xWarum, FMEA oder Fehlerbaumanalyse, um zumindest Klarheit für Schritt 1 des PDCA zu erhalten.

  Schlecht definierte (ill‑defined) Probleme – Ziel oder Randbedingungen unklar; Hier ist der erste Schritt, Klarheit zu schaffen.
Mögliche Methoden: Design Thinking, Systems Thinking, Workshop mit Stakeholdern, um zunächst das Problem konkret zu benennen und dann weitere Aufgaben zu konkretisieren.

  Prozess‑/Leistungsprobleme – Ineffizienzen, Durchlaufzeiten, Ausschuss.
Hier beschreiben Kennzahlen das Defizit. Das Problem ist in der Regel nicht auf eine Ursache, sondern auf eine komplizierte Kombination von Ursachen zurück zu führen. Die Ursachen haben aber alle einen wissenschaftlich-technischen Zusammenhang mit dem Problem. Das heißt, dass es sich um systematische und damit reproduzierbare Zusammenhänge handelt. Daher sind Methoden nötig, die ein Zusammenspiel mehrerer Ursachen auflösen können. Sie machen sich ein Bild von der Entstehung des Problems durch Prozessmapping, Ist-IstNicht-Analyse oder statistische Analysen aus dem Lean- oder Six Sigma (DMAIC) Werkzeugkasten.

  Komplexe Probleme in sich gegenseitig beeinflussenden Systemen  – Verhalten, das sich nicht mit klassischen Ursache-Wirkungs-Ketten erklären lässt.
In solchen Fällen wird ein chaotisches, augenscheinlich nicht-deterministisches Verhalten diagnostiziert.

Beispiele sind Störungen, bei denen sich Hardware, Firmware, Netz und Umgebung in einem vernetzten Produktionssystem gegenseitig beeinflussen.
Oder Menschen mit ihrem Sozialverhalten einschließlich der Entscheidungen des Management nehmen Einfluss auf den Prozess.

Durch die Vernetzung und die gegenseitige Beeinflussung wird das Problem emergent und komplex. (Siehe auch Blog-Beitrag  Kompliziert vs. Komplex).

Hier sind zur Lösungsfindung weniger Methoden als vielmehr das aktive Zusammenarbeiten von Menschen mit unterschiedlichen Sichten und Kenntnissen (Interdisziplinär) gefragt. Es muss ein Verständnis der zusammenwirkenden Systeme erarbeitet werden. Auf dieser Grundlage kann dann nach Ursachen für das nicht gewünschte Verhalten gesucht werden.
Hilfreiche Methoden sind Systemmodellierung, Szenariotechnik in interdisziplinären Workshops. Diese können auch als „Qualitätszirkel“ schon eingeführt sein.

Bis hier habe ich nur über den 1.Schritt im PDCA, über das Ermitteln von Problem und Ursache und ggf. das Festlegen des Sollzustands ( zusammengefasst als „Planen“ ) geschrieben.

Ist Klarheit zu P erlangt, so folgen dann die Schritte D, C und A.
Auch hier wird die Kompliziertheit des Problems Art und Umfang von Maßnahmen, deren Bestätigung und Möglichkeiten, daraus neue Regeln zu schreiben, beeinflussen.

Fazits: 

• Probleme sind sowohl in der laufenden Projektarbeit als auch bei Sonderereignissen zu lösen. Die Werkzeuge sind ähnlich, die Abläufe bei Sonderereignissen aber gesondert gestaltet.
• In jedem Fall beginnt die Problemlösung mit der genauen Benennung des Problems, vielfach ergänzt um eine Zielvorgabe und mit einer Ursachenanalyse.
• Nicht jedes Problem ist zu anderen vergleichbar. Probleme können monokausal und einfach, multikausal und kompliziert oder gar in gekoppelten Systemen komplex sein.
• Daher muss die Methode zur Ursachenanalyse passend gewählt werden.
  Falsche Anwendung und falsche Methodenwahl führen zu einem Scheinergebnis der Ursachenanalyse. Davon abgeleitete Maßnahmen können noch so ernsthaft durchgeführt werden, sie werden das Problem nicht lösen können.
•  

Bleiben sie neugierig

Uwe Jarosch