Fehler können passieren. Sie sollten jedoch kein zweites mal auftreten. Aus diesem Grund ist es wichtig, dass Unternehmen einen funktionierenden Lessons Learned (LeLe) Prozess implementiert haben, der sicherstellt, dass bekannte Produktfehler sich in Nachfolgerprodukten nicht wiederholen.
Ich bin immer wieder überrascht, wie schlecht das Erstellen und Einsteuern von Lessons Learned in die Produktentwicklung neuer Produkte, selbst bei sehr gut organisierten Unternehmen funktioniert.
Die Ursachen sind vielseitig. Hauptsächlich verantwortlich für ein schlechtes LeLe ist das nicht Fokussieren der Führung auf diesen Prozess. Die Ausprägung davon ist, dass zu wenig Ressourcen, zu wenig Kompetenz, zu wenig Budget und keine Ergebnismessung für das Erstellen und Einsteuern von LeLe in das Anforderungsmanagement zur Verfügung stehen.
Der Schmerz ist dann auf Ebene der Unternehmensführung groß, wenn beispielsweise ein bekannter Konzeptfehler eines Produktes sich in verschiedenen nachfolgenden Produkten wiederfindet und hunderte von Millionen Euro an Gewährleistungskosten verursacht.
Präventive Qualitätsarbeit wird nicht wertgeschätzt
Die Erfahrung zeigt, dass präventive Qualitätsarbeit in Unternehmen gerne groß geschrieben wird. Sobald die Kosten für die präventive Qualitätsarbeit zu „investieren“ sind, jedoch nicht mehr so sehr. Dann ist häufig die betriebswirtschaftliche Ergebnissicherung für das aktuelle Geschäftsjahr wichtiger und das Budget für die präventive Qualitätsarbeit deutlich reduziert oder gestrichen, auch wenn sich durch das eingesetzte Budget ein x-faches an Gewährleistungskosten in den nächsten Jahren einsparen lassen würde.
Diese Entscheidung ist schwer nachzuvollziehen, wenn der Grund die Maximierung des Gewinnes ist. Anderes sieht es aus, wenn sich das Unternehmen aktuell in einer Krise befindet und Kosten einsparen muss. Dann kann es eine bewusste Unternehmensentscheidung sein, bei der sich die Entscheider im Klaren sind, dass sie, wenn die in der Entwicklung befindlichen Produkte auf den Markt kommen mit erhöhten Gewährleistungskosten zu rechnen haben und für diese Jahre entsprechend höhere Rückstellungen bilden müssen. So geschehen bei einigen Unternehmen während der Finanzkrise.
Der Prozess für das Erheben von Lessons Learned und das Einsteuern in das Produktanforderungsmanagement ist vom Prinzip einfach und zigfach in der Literatur beschrieben. Die Schwierigkeit steigt jedoch mit der Komplexität des Produktes und der Größe des Unternehmens.
Nachfolgend beschriebe ich kurz das Prinzip mit Hinweisen, die es aus meiner Sicht zwingend zu berücksichtigen sind, wenn man Lessons Learned erfolgreich implementieren möchte.
In einem ersten Schritt werden die Ursachen der Produktfehler über Root-Cause-Analysen gefunden und dokumentiert. Siehe hierzu auch den Beitrag http://qualitätssprechstunde.de/schadteilanalyse/. In einem zweiten Schritt werden auf Basis der Ursachen die Anforderungen an zukünftige Produkte abgeleitet, wobei darauf zu achten ist, dass die Anforderungen lösungsneutral, messbar, nicht interpretierbar, … beschrieben sind und sicherstellen, dass mit der wirksamen Umsetzung der Anforderung das Produktproblem nicht mehr auftreten kann.
Anforderungen auf Wirksamkeit prüfen
Wichtig bei der Definition der Anforderungen ist, dass messbare Prüfungen der Anforderung auf Umsetzung und Wirksamkeit in der Produktentwicklung erstellt werden. So ist es ratsam für die unterschiedlichen Entwicklungsphasen Messpunkte zu implementieren, um die Umsetzung und Wirksamkeit zu messen. In diesem Kontext ist es sinnvoll die Test-Methode, das Test-Objekt, die Testdaten und das zu erwartende Testergebnis zu dokumentieren. Ein fiktives Beispiel könnte wie folgt aussehen:
Ein zweiter zentraler Punkt ist, dass der Anforderungsersteller und der Anforderungsnehmer nicht dieselbe Person und Unternehmensrolle sein dürfen.
Der Anforderungsnehmer hat die Umsetzung der Anforderung zu bestätigen und diese zu entwickeln.
Der Anforderungsersteller hat die Aufgabe, die Anforderung an den Anforderungsnehmer verbindlich zu übergeben und die Anforderung über den Zeitraum der Produktentwicklung, wie oben beschrieben zu tracken.
Die Wahrscheinlichkeit, dass Anforderungen über den Zeitraum der Produktentwicklung „verloren“ gehen ist sehr hoch, wenn diese beiden Rollen in einem Unternehmen nicht etabliert sind.
Jede Anforderung benötigt einen Paten, der für sie kämpft. Ansonsten haben Anforderungen schlechten Karten in einem langen und von vielen Änderungen gekennzeichneten Entwicklungsprozess.
_________________________________________________________________
Nachfolgend eine Methode (Fishbone; ishikawa), um Probleme auf Ihre Ursache zu analysieren. Die Ursachenanaylse ist die Basis für Lessons Learned, die dann als Anforderungen für die Entwicklung neuer Produkt eingestellt werden:
Hier noch der Link auf die Definition in Wikipedia: