Als eine essenzielle Ursache für Verschwendung werden im Lean Management Fehler (Defects) und Korrekturen angesehen. Warum es sich hierbei um zu vermeidende Verschwendung handelt, liegt auf der Hand: Im Allgemeinen ist es aufwändiger, Fehler zu korrigieren, als diese von vorne herein zu vermeiden. Von anderen Effekten, wie bspw. Fehlsteuerung, Kundenunzufriedenheit oder gar -gefährdung ganz zu schweigen.
Was ist Poka Yoke?
Ein interessantes Handlungsprinzip (vgl. Hüsselmann/Leyendecker/Heymann, 2018), das im Bereich des Lean Production zur Vermeidung von Fehlern etabliert hat, wird mit Poka Yoke bezeichnet. Dieser Begriff aus dem Japanischen steht dafür, zufällige Fehler oder Fehler, die aus Unachtsamkeit entstehen, zu vermeiden oder ganz zu verhindern. Dazu werden physische Gegebenheiten von Produkten (z.B. die Form eines Steckers), Ergebnisüberprüfungen durch Messungen (z.B. das Gewicht eines produzierten Teils) und die fehleraverse Gestaltung des Prozessablaufs (z.B. der Folgeschritt kann erst durchgeführt werden, wenn mit einem Signal der Vorgängerschritt bestätigt wurde) angewendet. Das „harte“ Poka Yoke verhindert dabei, dass ein bestimmter Fehler gemacht werden kann, das „weiche“ Poka Yoke verringert die Eintrittswahrscheinlichkeit bzw. entdeckt gemachte Fehler vor einer Weiterbearbeitung.
Die Techniken dieses Fehlerschutzes – Poka Yoke – beinhalten im Allgemeinen:
- Identifizierung potenzieller Qualitätsrisiken und Problemursachen in Prozessen (Root Cause-Analyse)
- Implementierung von Systemen, die kostspielige Qualitätsfehler und Nacharbeiten reduzieren.
- Entwicklung eines klaren Verständnisses für den optimalen Weg zur Erfüllung von Aufgaben
- Transparente Gestalung der Prozesse
- Reduzierung des Bearbeitungsaufwands
- Verbesserung des Qualitätsmanagements
- Eliminierung von Qualitätsrisiken und „Pflaster-Lösungen“
Was hat das mit Projekten zu tun?
Das Projektgeschäft unterteilen wir in zwei zusammenwirkende Ebenen: Die Ebene des fachlich-progressiven Projektvorgehens (PV) und die Ebene der Projektmanagement-Prozesse (PM, vgl. Blog #02).
PV-Ebene
In der PV-Ebene, welche nach den Regeln und Methoden der fachlichen Domäne ausgestaltet wird, sind die Techniken der entspr. Fachlichkeit anzuwenden. So hat ein Hausbau andere Anforderungen als ein IT-Projekt und wiederum andere als ein Produktentwicklungsprojekt etc. Allgemeingültige Praktiken und Anwendungen des Poka Yoke können daher tendenziell nicht identifiziert werden. Der Nutzen von Poka Yoke leitet sich unmittelbar aus den Überlegungen z.B. des Lean Production, Construction oder Product Developments ab.
PM-Ebene
Die Prozesse des PM, z.B. die Projektsteuerung, legen aufgrund ihres Charakters von Geschäftsprozessen nicht zuletzt die Analogie mit den Lean-Adaptionen Lean Administration und Lean Reporting sowie natürlich dem generellen Lean Management, angewendet auf Projektmanagement nahe. Typische Hilfsmittel zur Fehlervermeidung sind bspw. Checklisten, mit deren Hilfe Erfahrungswerte und Good Practices aus vergleichbaren Projekten übertragen werden können, etwa bei der Identifizierung projekttypischer Risiken.
Um sinnvolle Poka Yoke-Praktiken zu finden, müssen zunächst einmal die typischen Fehler des PM, welche auf Unachtsamkeit und Zufall basieren (s.o.) identifiziert werden. Ich möchte diese Fehlerquellen ergänzen um Fehler, die aus Unwissenheit oder fehlerhafter bzw. einseitiger Interpretation von Sachverhalten passieren, ergänzen.
So können z.B. folgende typische Fehler identifiziert werden:
- F1: Unbefugte Bearbeitung
- F2: Unvollständige Bearbeitung
- F3: Fehlerhafte Bearbeitung
- F4: Fehlinformation/Inkonsistente Daten und nicht zuletzt
- F5: Terminversäumnis
Zu unbefugter Bearbeitung (F1) kommt es, wenn Regularien der Prozessabwicklung nicht eingehalten werden. Dazu gehören z.B. die Nicht-Einhaltung von Befugnissen in der Beschaffung (Bestellung ohne den Vorgang im ERP-System durchzuführen, Order ohne Freigabe o.ä.). Eine typische Fehlervermeidungsmethode ist hier z.B. das 4-Augen-Prinzip. Hilfreich ist auch eine klare Rollendefinition im Projekt nach dem A/B/V-Schema (Aufgaben, Befugnisse und Verantwortlichkeiten).
Unvollständige Bearbeitung (F2) kennt jeder Projekteiter, der sich schon einmal über mangelhaft ausgefüllte Projektstatusberichte geärgert hat. Hier kann abhelfen, Pflichtfelder zu definieren, was natürlich ein entsprechendes System voraussetzt, denn beim typischen MS PowerPoint-One Pager wird das wohl nicht gelingen. ERP- und andere Systeme machen aber vor, wie unvollständige Dateneingabe verhindert werden kann. Generell sind in diesem Fehlergebiet auch natürlich die bereits genannten Checklisten anzuwenden.
Als Beispiel für fehlerhafte Bearbeitung (F3) führe ich das „90% finish Syndrom“ heran. Dieses besagt, dass eine Fertigstellungsgradangabe, die auf einem Anteil fertiggestellter Lieferobjekte (z.B. Anzahl von Function Points) beruht, oft dazu neigt, zu optimistisch zu sein. Die 80-20-Regel zeigt, dass man lieber angeben sollte, wieviel Restaufwand noch bis zu letztlichen Fertigstellung zu leisten ist. Mit einer einfachen Berechnung lässt sich dann der erste Fertigstellungsgrad mit einem aus dem Restaufwand errechneten gegenüberstellen und somit zu einer Plausibilisierung und valideren Einschätzung kommen.
Bei der Nutzung verschiedener Systeme kommt es zu Fehlern in der Sachbearbeitung (F4). Daten werden vergessen zu übertragen oder sind inkonsistent etc. Eine durchgängig korrekte Prozessbearbeitung lässt sich also nur schwer gewährleisten. Ein Bespiel aus dem PM ist hier die Anlage einer kfm. Projektstruktur im ERP-System (z.B. sog. PSP-Elemente im SAP) und die Anlage eine fachlich-technischen Struktur im Projektsystem (Work-Breakdown-Structure z.B. in MS Project). Inkonsistenzen sind vorprogrammiert, wenn nicht durch einen automatisierten Abgleich (Enterprise Application Integration, EAI) und/oder mit Hilfe eines Workflow-Systems dem entgegen gewirkt wird. Im PM zählt dazu bspw. die Übernahme von aktuellen Kosteninformationen aus dem ERP-System in das Projektstatusberichtswesen.
Verzögerungen im Projektablauf (F5) sind keine Ausnahme. Oft beruhen diese in der Komplexität der arbeitsteilig zu verrichtenden Aufgaben … Arbeitspaket A wartet auf den Input, der von Arbeitspaket B kommen soll. Zum Beispiel: Team A will ein Datenmigrationskonzept erstellen, Team B hat die Stammdatenstruktur dafür noch nicht geliefert – Team A kommt in Verzug.
Bei einem Großprojekt mit eigener Beteiligung (ERP-Einführung) hatte es sich hierbei bewährt, für jedes Arbeitspaket (AP) im Rahmen seiner Definition anzugeben, von welchen anderen AP Zulieferungen erwartet werden. Im Gegensatz zu einem vollständigen zentralen Netzplan kausaler Abhängigkeiten, wurde damit eine bilaterale Sicht mit qualifizierter Angabe erzeugt.
Dazu werden im Stile der SIPOC-Technik aus dem Six Sigma, die Prozessflüsse bezogen auf die AP vom jeweiligen AP-Verantwortlichen im Rahmen der Projektplanung definiert. SIPOC steht dabei als Akronym für Supplier (Lieferant), Inputs (Einsatzfaktoren), Process (Prozess), Output (Ergebnisse) und Customer (Kunde).
Mit Hilfe eines passenden IT-Systems oder entspr. Organisation lässt sich auf diese Weise ein „Frühwarnsystem“ einrichten, bei dem bspw. 2 Wochen vor Fälligkeit das liefernde Team erinnert wird („Pull“) und Rückmeldung geben kann. Ein „aktives Warten“, wie leider in (Groß-)Projekten zu beobachten, welches in Summe dann zu Zeitverzögerungen führt, kann so vermindert werden.
Die genannten Beispiele erheben natürlich keinen Anspruch auf Vollständigkeit. Jedoch können sie veranschaulichen, welche proaktiven Maßnahmen das Projektmanagement ergreifen kann, um im Sinn des Poka Yoke absehbare Fehler von vorneherein zu vermindern.
Haben Sie weitere typische Fehler in den PM-Prozessen identifiziert? Wie vermeiden Sie diese? Kann es gelingen, ein hartes Poka Yoke für PM zu etablieren?
Kommentar schreiben