William Edwards Deming: Grundlegende Fehler, die Verbesserung in Unternehmen behindern

William Edwards Deming, ein weltbekannter Pionier des Qualitätsmanagement entwickelte die prozessorientierte Sicht bei Management Abläufen in Unternehmen. Daraus entwickelten sich später verschiedene Normen und Lehren zur Qualität. Deming analysierte im Rahmen seiner Qualitätsmanagement Lehre unter anderem, welche Fehler sich negativ auf Unternehmen auswirken.

  • Wenn ein Unternehmen hauptsächlich auf kurzfristigen Gewinn aus ist, dann kann keine strategische Planung vorgenommen werden. Mittelfristig werden solche Unternehmen durch Ihre planloses Vorgehen anderen unterliegen. Denn ohne Plan gibt es ständig wechselnde Ziele.
  • Das Gleiche gilt, wenn der Zweck einer Organisation oder Abteilung ständig verändert wird. Mit “kreativer Buchhaltung” können Unternehmen durch Entlassungen, Fusionen, Devisenbewertungen und anderen Tätigkeiten ständig positive Zahlen erzeugen, bis ein Unternehmen zusammenbricht.
  • Durch Leistungsbewertung von Mitarbeitern wurden noch nie langfristig Verbesserungen erzielt. Vielmehr gibt es Mitarbeiter, die das System zu Ihren Gunsten manipulieren können. Besser ist es, die Mitarbeiter individuell auszubilden und zu fördern. Kein erstelltes Profil vermag den Menschen, seine Arbeitsleistung und -qualität richtig darzustellen.
  • Hier ist das “Weisse Ritter Syndrom” gemeint. Ein oder mehrere Manager treten in einem Unternehmen als Retter auf. Sie veranlassen viele Veränderungen und zeigen auf kurzfristig erreichte, positive Ergebnisse. Sie verlassen das Unternehmen mit einer persönlichen Gewinnmitnahme, bevor langfristig negative Auswirkungen Ihrer Tätigkeit zu sehen sind.
  • Wichtiger als die bekannten oder sichtbaren Zahlen (manchmal aus KPI genannt) sind die unsichtbaren Zahlen die Unternehmen nicht zur Verfügung stehen. Zum Beispiel die Softskills der Mitarbeiter, der entstandene Nutzen oder Schaden für Kunden. Vorhandene Zahlen bilden immer nur die Vergangenheit ab.
  • Gesunde und motivierte Mitarbeiter sorgen für geringe Kosten. Daher sollte die Erhaltung von Gesundheit und Motivation ein ständiges strategisches Ziel eines Unternehmens sein.
  • Es ist eine Belastung für die zukünftige Entwicklung, wenn Unternehmen durch unzureichende Recherche, mangelhafte Qualität oder durch Absichten die Verträge zu brechen. Dann sind nachfolgend hohe Kosten zu bezahlen. Daher sollten Unternehmen Geschäftsbeziehungen bevorzugen, die auf gegenseitigen Vertrauen beruhen.

Fazit:

Die Demingschen Regeln für ein erfolgreiches Management sind von der Unternehmenskultur abhängig. Was lebt, unterliegt der Veränderung. Bei richtiger Veränderung kann mittel- oder langfristig mit einer positiven Entwicklung gerechnet werden.

Demings Erkenntnisse als Statistiker und Qualitätsexperte haben vor allem Japans Top Manager seit den 1960-er Jahren geprägt und zeigen sich weltweit in vielen Produkten der heutigen Zeit. Um Demings Ideen nicht zu vergessen, wurde in der Schweiz das Deming Institut gegründet.

Erweiterung der Hoshin Kanri Methode durch agiles Management

Hoshin Kanri ist ein aus Japan stammendes Planungs- und Management Konzept. Das Konzept hat sich in den 60er Jahren bei einigen Unternehmen entwickelt. Es wurde durch den PDCA Zyklus von William Edwards Deming und dem “Management mit Zielvorgaben” durch Peter Drucker beeinflusst. In den 80er Jahren wurde dieses Konzept von vielen Unternehmen in den USA wie zum Beispiel Hewlett Packard und Intel übernommen. Es basiert auf  zwei Anwendungsebenen, die Dr. Yoij Akano in seinem Buch beschrieben hat.

1. Strategische Planungsebene des Hoshin Kanri

In der strategischen Planungsebene werden Unternehmensziele mit einem 5 Jahres- oder manchmal einem 2 Jahres-Plan beibehalten. Die Pläne sind auf das Erzielen von signifikanten Änderungen ausgerichtet und werden mit entsprechenden Kennzahlen gemessen.

2. Agile Entwicklung

Agile Entwicklung wurde Anfang der 1990er Jahre begründet. Die Grundsätze agiler Entwicklung sind:

  • Menschen und deren Interaktionen zählen mehr als modulierte Prozesse
  • Das Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
  • Zusammenarbeit mit dem Kunden ist wichtiger als eine Vertragsverhandlung
  • Funktionierende Prozesse sind wichtiger als umfassende Dokumentation

3. Alltägliche Ebene des Hoshin Kanri

Hier wird das alltägliche Geschäft getätigt. Alle wertschöpfenden Tätigkeiten werden gemessen und bewertet. Durch Kaizen kann der Prozessinhaber durch Änderungen Prozessverbesserungen erreichen.

Dazu werden Indikatoren in den Prozessen ermittelt. Ausgewählte Kreisläufe werden in weitere, kleinere Elemente zerlegt. Dann kommt eine “agile” Hoshin Kanri Methode zum tragen. Diese Elemente sind wie spiralförmige Kreisläufe zu betrachten und zu messen. So lassen sich Planungselemente modular wechseln, ohne das Gesamtkonzept in Frage stellen zu müssen. Die Kontrolle auf der strategischen Ebene muss dazu direkt, fast in Echtzeit tief in die alltägliche Ebene messen können, um dem Management das notwendige Feedback zur Entscheidung und daraus resultierenden agilen Handlung bieten zu können. Dies ist setzt eine spiralförmige Entwicklung in Gang die auch bei Veränderung Entwicklungszyklen überspringen kann. So wird Hoshin Kanri dynamisiert. Es können Ressourcen und Kosten gespart werden.

Voraussetzung dazu ist die Akzeptanz, dass der ständige Einsatz des Managements und aller Mitarbeiter für diese Methode notwendig ist. Durch die ständige Verbesserung und eine abgekoppelte Messung von unabhängigen Prüfern lassen sich markttragende Ergebnisse erzielen. Unabhängige Prüfer sind notwendig, damit der Entwickler nicht gleichzeitig der Prüfer ist!

Scrum – Agile Web- und Software Entwicklung

Scrum wurde in einem Projekt im Zuge der Zusammenarbeit von Ikurjio Nonaka und Jeff Sutherland entwickelt. Mit Scrum versucht man Anpassung, Transparenz und Kontrolle in der Software Entwicklung weitestgehend zu vereinfachen. Dadurch wird eine kostengünstige, schnelle  und hochwertige Entwicklung von Software Produkten und -Dienstleistungen ermöglicht. Scrum basiert auf Erfahrung und wird iterativ wie ein Schneckenhaus Schicht für Schicht erweitert.

Scrum funktioniert ähnlich wie der Aufbau eines Schneckenhauses

Scrum benutzt Rollen mit unterschiedlichen Aufgaben und Verantwortungen.

Rollen bei Scrum

Das Entwickler Team liefert die vom Product Owner gewünschten Produktteile oder Dienstleistungen in der gewünschten Reihenfolge. Zudem sind die Entwickler für die Qualität des Produkts verantwortlich. Dazu werden Qualitätsstandards vereinbart.

Der Scrum Master kümmert sich als Führungskraft um das Entwickler Team, gehört dem Team aber nicht an. Er kümmert sich um die Organisation und hilft Störungen, Konflikte und Hindernisse zu beseitigen.

In der Rolle als Product Owner ist man für die Konzeption, Festlegung der Produkteigenschaften und die Priorisierung verantwortlich. Er steuert damit den wirtschaftlichen Nutzen für das Unternehmen, ist aber kein Vertreter des Kunden.

Der Kunde oder Auftraggeber wird als Customer dem Product Owner aufzeigen, was das Produkt für Eigenschaften haben soll. Zudem wird der Customer ab einer frühen Phase periodisch das zu entwickelnde Produkt prüfen und Feedback an den Product Owner geben.

Das Management hat bei der Bereitstellung der Ressourcen und dem Ausräumen von Hemmnissen zu unterstützen. Dadurch werden die Rahmenbedingungen stabilisiert.

Die User sind die zukünftigen Nutzer des Produkts oder der Dienstleistung. Daher sind Sie in der Lage die Funktionalität des Produkts zu beurteilen. Zudem können Sie das Produkt ab einer frühen Phase regelmäßig, zum Beispiel nach einem Entwicklungszyklus, ausprobieren und Ihre Ergebnisse und Veränderungsvorschläge mitteilen. diese kann der Product Owner aufgreifen und zur weiteren Entwicklung einfließen lassen.

Dazu wurde im Jahre 2001 das Agile Manifest für Scrum entwickelt, das ich hier angepasst habe.

Agiles Manifest

  • Eine beständige Zusammenarbeit mit dem Kunden als Partner steht über den Verträgen
  • Kommunikation, Mut und die Offenheit für Änderungen gilt mehr als das genaue Befolgen eines festgelegten Plans
  • Menschen und Zusammenarbeit gelten mehr als Werkzeuge und Prozesse, ersetzen diese aber nicht
  • Funktionierende Programme sind höher einzustufen als ausführliche Dokumentation.

Fazit:

Lean Production in japanischen Unternehmen verfolgt ähnliche Ansätze wie Scrum und nutzt für eine bessere Wertschöpfung unter anderem starkes Teamworking und erfolgreiches Wissensmanagement. Hier sehe ich auch den wichtigen Unterschied. Es wird auch bei Scrum Dokumentation gebraucht, wenn diese nicht “Just in Time” zur Verfügung steht, dann verliert der Scrum Prozess an Effektivität!

Alternativ gibt es die Vorgehensmodelle wie das Wasserfall ModellV-Modell, Kanban und Scrum.

Die Entwicklung von HTML 5 bei WhatWG und W3C

Vor längerer Zeit haben sich zwei Richtungen bei der Weiterentwicklung von HTML5 ergeben.

Zügige Weiterentwicklung  von HTML durch die WhatWG

Die WhatWG wurde nach einem Workshop des W3C gegründet. Mitarbeiter dvon Apple, Google, Microsoft, Mozilla und Opera haben sich zu einer fortlaufenden Weiterentwicklung von HTML ausgesprochen.  Die Entwickler der WhatWG sprechen vom HTML – Living Standard. Ohne diese Gruppe wäre die Weiterentwicklung von HTML auf Grund von mangelndem Interesse des W3C nur langsam voran getrieben worden.

Dokumentation von HTML – Living Standard

HTML5

Späte Erkenntnis des W3C – aber kein Entgegenkommen

Die Anteil der Wichtigkeit von HTML für zukünftige Informations- und Kommunikationsmittel wurde von W3C unterschätzt. Nachdem sich auf Grund von der Freigabe von HTML5 wesentliche Weiterentwicklungen wie Frameworks, modernisierte Browser ergeben haben, gibt es auch hier Neuerungen. Allerdings setzt das W3C auf Versionierung von HTML 5. Aktuell ist die Version HTML 5.2 als Empfehlung erschienen.

Fazit

Nach wie vor liegt die Entwicklung von HTML bei der aktiven WhatWG. Das W3C übernimmt meist wichtige Entwicklungen der WhatWG in ihre Standards. Diese werden weiterhin nicht so häufig aktualisiert wie der Living Standard.