Wie man Geeks NICHT führen sollte

[EINLEITUNG:

„Gut geht es Dänen und denen, denen Dänen nahestehen.“

Dieser Spruch von Wolfgang Neuss aus dem Film „Wir Wunderkinder“ ist ein Sinnbild für das Ergebnis von zwei Studien zum Glücksgefühl („Happiness“) in den Ländern, welche beide zu dem Schluß kamen, daß die glücklichsten Menschen in Dänemark leben. Daher ist es nicht verwunderlich, daß der dänische Unternehmensberater Alexander Kjerulf die Arbeitsfreude (dän. „arbejdsglæde“) als wichtigen Faktor für produktive Arbeit erkannte, sich daraufhin zum Chief Happiness Officer ernannt hat und nun darüber doziert. Arbeitsfreude wird dieselbe Bedeutung beigemessen wie der Geschmack beim Essen, d.h. sie wird häufig als vernachlässigbare Größe behandelt. Daß sie sehr wohl ein entscheidender und vor allem beeinflußbarer Faktor ist, kann der geneigte Leser an den folgenden Quellen studieren:

• Positive Sharing (en) (Alexander Kjerulfs Blog)
• Projekt Arbejdsglæde (dän) (Projekt zur Arbeitsfreude, ebenfalls mit Beiträgen von Alexander Kjerulf)
• Happy Hour is 9 to 5 (Alexander Kjerulfs Buch zum Thema Arbeitsfreude (online lesbar))

Und wer einen Gegenentwurf der Sarrazin-Fraktion aus Deutschland studieren möchte:

• Schluß mit lustig! (Judith Mair)

Für die folgende Übersetzung eines Artikels von Alexander Kjerulf habe ich mich entschieden, den Begriff „Geek“ beizubehalten. Er umschreibt eine Person, die sich mit einem – meist technischen – Thema eingehend beschäftigt und sein Leben darauf ausrichtet und dies auch in seiner Arbeit umsetzt. Ein passender Ausdruck wäre vielleicht „Computerfreak“ gewesen, aber im Einklang mit den anderen Übersetzungen verwende ich den Originalbegriff, auch zur besseren Übertragbarkeit auf ähnliche Situationen.]

Als die Geeks bei NCR in Australien mit Streik drohten, war das ein Schritt, welcher Geldautomaten, Supermarktkassen und das Check-In auf Flughäfen hätte lahnlegen können. Dies unterstreicht die Tatsache, daß IT in den meisten Unternehmen so wichtig geworden ist, daß jede Störung eine Menge Zeit und Geld kosten kann, was wiederum bedeutet, daß die Geeks am Arbeitsplatz bei Laune zu halten ein absolutes Erfordernis im modernen Geschäftsleben ist.

Der Hauptgrund, warum IT-Leute am Arbeitsplatz unglücklich sind, bilden schlechte Beziehungen zum Management, oft weil Geeks und Manager grundverschiedene Persönlichkeiten, berufliche Hintergründe und Ziele haben.

Manche Leute schließen daraus, daß Geeks Manager hassen und unmöglich zu führen sind. Der Spruch „Geeks zu führen ist wie Katzen zu hüten“ wird zuweilen verwendet, ist aber schlicht und ergreifend falsch. Die Tatsache ist, daß Geeks schlechtes Management hassen und noch weniger Verständnis dafür haben als die meisten anderen Angestellten.

Wo geht es also schief? Ich begann als Geek und wurde später eine Führungskraft und IT-Firmengründer, so daß ich das Glück hatte, in beiden Lagern gewesen zu sein. Hier sind die 10 größten Fehler, die ich bei Managern erlebt habe, wenn sie Geeks leiteten:

1: Spielen Sie die Weiterbildung herunter

Ich hatte einmal einen Chef, der sagte: „Weiterbildung ist reine Geldverschwendung, gehen Sie selber lernen“. Die besagte Firma ist zwei Jahre später zusammengebrochen. Auf die Weiterbildung kommt es an, gerade in IT, und Manager müssen das begreifen und dafür Geld einplanen. Manchmal bekommt man zu hören: „Wenn man ihnen Weiterbildung gibt, dann kommt ein Konkurrent und schnappt sie einem weg“. Das mag stimmen, aber die Alternative wäre dann, nur Angestellte zu haben, die zu ungebildet sind, um woanders zu arbeiten.

2: Geben Sie keine Anerkennung

Da Manager möglicherweise die Arbeit nicht verstehen, welche die Geeks sehr gut erledigen, ist es schwierig für sie, die Arbeit anzuerkennen und zu belohnen, welche sehr gut erledigt wurde, was die Motivation schädigt. Die Lösung ist, zusammen eine Reihe von Zielen zu erarbeiten, über die sich beide Seiten einig sind. Wenn diese Ziele erreicht werden, dann verrichten die Geeks eine tolle Arbeit.

3: Planen Sie zu viele Überstunden ein

„Laßt uns soviel Arbeit wie möglich aus unseren Geeks herauspressen, sie haben sowieso kein Leben,“ so scheint der Ansatz einiger Manager zu lauten. Das ist ein Riesenfehler, und überarbeitete Geeks brennen aus oder verlassen einfach die Firma. In einem berühmten Fall erlitt ein junger IT-Mitarbeiter einen streßbedingten Schlaganfall, wurde ins Krankenhaus eingeliefert, kehrte kurz darauf zur Arbeit zurück und erlitt umgehend einen weiteren Schlaganfall. Dieser Artikel behandelt eingehender das Märchen, daß lange Arbeitsstunden gut für das Geschäft sind.

4: Verwenden Sie Managersprech

Geeks hassen Managersprech und betrachten es als oberflächlich und unehrlich. Manager brauchen kein Fachchinesisch zu lernen, aber sie sollten die Business-Phrasen loswerden. Ein Manager kann sagen „Wir müssen proaktiv auf unser Time-to-market einwirken“ oder Deutsch sprechen und bei „Wir müssen dieses Projekt rechtzeitig abschließen“.

5: Versuchen Sie, schlauer als die Geeks zu sein

Wenn Manager nichts zu einer technischen Frage wissen, dann sollten sie das einfach zugeben. Geeks werden sie dafür respektieren, jedoch nicht dafür, daß man vorgibt, etwas zu wissen. Und sie werden das mitkriegen – Geeks sind schlau.

6: Handeln Sie inkonsequent

Geeks besitzen einen tief sitzenden Sinn für Fairness, wahrscheinlich aufgrund der Tatsache, daß in der IT Struktur und Konsequenz entscheidend sind. Die Dokumentation kann nicht eine Sache behaupten, während das Programm etwas anderes macht, und ebenso können Manager nicht eine Sache sagen und dann etwas anderes machen.

7: Ignorieren Sie die Geeks

Da MAnager und Geeks verschiedene Sorten von Menschen sind, könnten Manager am Ende die Geeks allein lassen. Das macht das Führen von ihnen schwierig, und Geeks benötigen gute Menschenführung genauso wie alle anderen Mitarbeitergruppen.

8: Treffen Sie Entscheidungen, ohne sie um Rat zu fragen

Geeks kennen für gewöhnlich die technische Seite des Geschäfts besser als der Manager, daher ist eine technische Entscheidung zu treffen, ohne sie um Rat zu fragen, der größte Fehler, den eine Führungskraft machen kann.

9: Geben Sie ihnen keine Werkzeuge

Ein schneller Computer mag mehr Geld kosten als ein älteres Gerät und es mag auch nicht den Firmenrichtlinien entsprechen, aber Geeks benutzen Computer anders. Ein langsamer Computer senkt die Produktivität und ist ein tägliches Ärgernis. Das gilt auch für veraltete Software. Geben Sie ihnen die Werkzeuge, die Sie benötigen.

10: Vergessen Sie, daß Geeks kreative Arbeiter sind

Programmieren ist ein kreativer Vorgang, kein industrieller. Geeks müssen sich ständig Lösungen für neue Probleme einfallen lassen und lösen kaum jemals das gleiche Problem zweimal. Daher benötigen sie Spielraum und Flexibilität. Strenge Dress-Codes und zuviel Papierkram töten jegliche Innovation. Sie benötigen ebenfalls eine kreative Umgebung, um dem Bürozellentod zu entgehen.

Einen oder mehrerer dieser Fehler zu begehen (und ich habe Manager gesehen, welche alle 10 machten) hat ernste Folgen, darunter:

• Niedrige Motivation
• Hohe Mitarbeiterfluktuation
• Erhöhtes Fernbleiben
• Niedrigere Produktivität
• Niedrigere Qualität
• Schlechter Service

Fröhliche Geeks sind produktive Geeks, und der wichtigste Faktor ist gutes Management, welches auf deren Situation zugeschnitten ist.

Vorbehalte:

• Ich behaupte nicht, daß alle Geeks gleich sind. Geeks sind wahnsinnig verschiedenartige Leute, und dieser Artikel verallgemeinert gefährlich.
• Ich behaupte nicht, daß alle IT-Leute Geeks sind. Manche sind es, manche nicht. Ich war es ganz bestimmt.

Wenn Sie diesen Artikel mochten, dann denke ich, werden Sie auch an diesen Vergnügen finden:

• „Let’s go vampire slaying“ – Mehr echt schlechte Managementideen, die man meiden sollte.
• „eXtreme Projects“ – Wie kann Extremprogrammierung bei Nicht-IT-Projekten angewendet werden?
• „Make your business happy and rich“ – Einfache Schritte, um die Leute bei der Arbeit in einem beliebigen Unternehmen fröhlich zu stimmen. Besonders wichtig für Jungunternehmen!
• „Don’t fight stress“ – Das macht Sie nur noch gestresster. Lernen Sie, wie Sie stattdessen ruhig in einem hektischen Job bleiben können.

Oder gehen Sie einfach zur Startseite und sehen Sie sich um. Diese Webseite handelt generell davon, wie wir bei der Arbeit fröhlich sein können und wie wir bessere und effizientere Arbeitsplätze gestalten können.

NACHTRAG:

Dieser Artikel ist auch in anderen Sprachen verfügbar:

• Englisch: How NOT to lead geeks (das Original)
• Portugiesisch: Como NÃO liderar geeks (übersetzt von Cesar Cardoso)
• Spanisch: Como NO liderar geeks (übersetzt von Matías Augustín Bellone)
• Persische Übersetzung von Nasser Ghanemzadeh: Teil 1, Teil 2.

(Übersetzung des Artikels mit freundlicher Genehmigung des Verfassers)

Weisheit der Ahnen

Aus einem Artikel über ein Betriebssystem für Großrechner:

„Der allgemeine Datensicherungsmechanismus wird eher vom System als von dem individuellen Benutzer versehen, omdat hie betrouwbarer het systeem wordtdenn je zuverlässiger das System wird, desto mehr sieht sich der Benutzer außerstande, den zusätzlichen Aufwand (oder Sorgen), für den unwahrscheinlichen Fall eines Mißgeschickes zu versuchen, Vorkehrungen zu treffen, zu rechtfertigen. Daher benötigt der individuelle Benutzer eine Versicherung, und dies ist in der Tat, was zur Verfügung gestellt wird.“

Das im Artikel beschriebene Betriebssystem war Multics, ein Vorläufer von Unix. Der Artikel selbst stammt aus dem Jahr 1965! Man kann dieses Zitat durchaus als ein Beispiel für die These von W. Edwards Deming deuten, daß das System zu 94 Prozent für die Leistung verantwortlich ist und die individuellen Benutzer nur zu 6 Prozent. Außerdem kann man den Datensicherungsmechanismus als Beispiel für Poka-yoke, die japanische Kunst der Fehlervermeidung, deuten (für diese Kunst gibt es vielfältige Anwendungsmöglichkeiten).

Die Moral von der Geschichte: Auch wenn die beschriebene Technik nicht mehr aktuell ist (oder – nebenbei bemerkt – nicht zum Fachgebiet des Lesers gehört), können die zugrundeliegenden Prinzipen sehr wohl lehrreich sein.

Vom Nutzen und Schaden großer Monitore

Vor kurzem habe ich in zwei verschiedenen Blogs zwei Beiträge gelesen, in denen jeweils große LCD-Monitore erwähnt werden. Der eine Beitrag sprach sich dafür aus, in diese Monitore zu investieren, während der andere sie bedenklich findet. Dieser scheinbare Widerspruch löst sich auf, wenn man sich beide Beträge ansieht.

Der erste Beitrag beschäftigt sich mit der Frage, wie Programmierer motiviert werden. Die Antwort des Verfassers läuft darauf hinaus, daß Programmierer interessante Aufgaben gegeben werden (d.h. bei denen sie ein Problem lösen müssen) und demotivierende Sachen wie Mikromanagement oder Besprechungen vermieden werden sollten. Damit wird den Programmierern ermöglicht, was W. Edwards Deming als „pride of workmanship“ bezeichnete. Dazu gehört auch eine gute Ausstattung des Arbeitsplatzes, weshalb der Verfasser die Empfehlung aussprach, £400, welche im Entwicklungsbudget übrig geblieben sind, lieber für einen 24-Zoll-Bildschirm als für einen Bonus an den Programmierer auszugeben (was allerdings nicht bedeuten soll, daß das Einkommen für einen Programmierer völlig unwichtig ist). Allerdings besteht die Gefahr, daß das Geld gar nicht erst investiert wird, wenn die Pflicht zur unbedingten Gewinnmaximierung besteht und sowohl Investitionen als auch Verschwendung als Kosten eingestuft werden, wobei letzteres durch ersteres gesenkt werden kann. Diese Tendenz verschlimmert sich, wenn die Gewinnmaximierung jeweils für das nächste Quartal verlangt wird.

Der zweite Betrag stammt aus einem sehr lesenswerten Blog, welcher sich mit der „schlanken Produktion“ (engl. Lean Manufacturing), wie sie etwa bei Toyota praktiziert wird, beschäftigt. Wer sich mit dem Thema ernsthaft beschäftigen möchte, findet hier viele Informationen über die Grundlagen und Methoden zur beständigen Produktivitätssteigerung mit menschlichem Antlitz. Thema des erwähnten Beitrags sind 10 Mißverständnisse über Lean Manufacturing. Punkt 9 behandelt das Mißverständnis, das Lean eine Abneigung gegen IT-Lösungen habe. Während der Verfasser keine Lösung bekämpft, welche Verschwendung vermindert, so stellt er fest, daß große LCD-Bildschirme für visuelles Management zwar bei Besuchern einer Firma Eindruck schinden, aber für die Lösung von aktuellen Problemen weniger geeignet sind. Diese Feststellung gründet auf dem Prinzip des „Genchi Genbutsu„, was man mit „hingehen und nachsehen“ übersetzen kann. Dieses Prinzip besagt, daß man, um ein Problem richtig erfassen zu können, sich davon selber vor Ort ein Bild machen muß, da etwa Berichte nur eine abstrakte Wiedergabe der Situation sind. Für die Problemlösung wichtige Aspekte werden so übersehen, wenn sie im Bericht nicht erwähnt werden. Aus diesem Grund können Software-Lösungen Mitarbeiter dazu verleiten, auf Genchi Genbutsu zu verzichten.

Zusammenfassend läßt sich sagen, daß große LCD-Bildschirme nicht an sich Nutzen oder Schaden bringen, sondern die Art, wie sie eingesetzt werden. Im ersten Beitrag ging es um Verbesserung des Arbeitsplatzes. Im zweiten Beitrag ging es darum, Fehleinschätzungen durch auf dem ersten Blick beeindruckende, aber unzureichende Informationen zu vermeiden.

Der IT-Betrieb – eine statistikfreie Zone?

„There is no substitute for knowledge.“ (W. Edwards Deming)

Nach der Veröffentlichung seines Buches „Out of the Crisis“ arbeitete W. Edwards Deming an einem theoretischen Instrument, mit welchem man den Stand der Dinge betrachten und die notwendigen Veränderungen begreifen kann. Das Ergebnis ist das System of Profound Knowledge (dt. System vom Unfassenden Wissen). Es besteht aus vier Elementen:

1. Erkennen eines Systems: Ein System besteht aus zwei oder mehr Elementen und erfüllt einen Zweck, welchen die Elemente auf sich allein gestellt nicht erfüllen können. Ein Beispiel ist ein Orchester, welches aus verschiedenen Musikern besteht. Damit es gute Musik machen kann, kommt es nicht so sehr auf die Fähigkeiten der Musiker als Solokünstler an, sondern darauf, wie sie zusammenspielen. Wenn das nicht funktioniert, weil jeder Musiker nur selber gut dastehen möchte, geht das zu Lasten des Orchesters. Auch eine Firma bildet mit ihren Zulieferen, Kunden, Angestellten, Anteilseignern usw. ein System, wo man die Zusammenarbeit der Elemente als Wirtschaft bezeichnen kann. Wie beim Orchester kann der Versuch, die einzelnen Elemente ohne Beachtung des Systems zu optimieren, das System zu zerstören. Aus diesem Grund hat Deming als Ziel für ein System vorgeschlagen, daß auf lange Sicht alle Beteiligten gewinnen sollen. In diesem Zusammenhang beschrieb er das herkömmliche Vorgehen einer Firma mit dem Versuch, ein größeres Stück vom Kuchen zu bekommen. Stattdessen sollte angestrebt werden, einen größeren Kuchen zu machen.
2. Wissen über Variation: Im statistischen Sinn wird mit Variantion die Streuung von Werten bezeichnet. Diese Variation bzw. Streuung kann man bei Personen, Produkten, Resultaten, Dienstleistungen usw. antreffen. Wissen über die Variation ist aus folgenden Gründen wichtig:
   • Für die Produktion ist es wichtig, daß die Ergebnisse möglichst gleich bleiben. Je weiter man von einem optimalen Wert abweicht, desto schlechter ist das. Ein Zug sollte z.B. möglichst zur selben Zeit ankommen.
   • Die Ergebnisse eines Prozesses weisen an sich eine Streuung auf. Wenn die Streuung verringert werden soll, muß der Prozeß geändert werden. Beim Zug im Beispiel kann man davon ausgehen, daß er im Normalfall dieselben Zeiten fährt. Es ist also nicht ratsam, jede einzelne Fahrt als Sonderfall zu behandeln.
   • Ein ungewöhnliches Ergebnis weist auf ein besonderes Ereignis hin. Wenn ein Zug, der normalerweise 5 Minuten Verspätung hat, 50 Minuten zu spät ankommt, was sonst nicht vorkommt, dann liegt eine besondere Ursache vor, die sich ermitteln läßt.
   • Wenn ein gewünschtes Ziel außerhalb des Vermögens eines Prozesses liegt, dann läßt es nicht erreichen. Wenn ein Zug grundsätzlich 15 Minuten zu spät kommt, dann kann man nicht erwarten, daß er pünktlich ist.
   • Damit man weiß, was ein Prozeß leisten kann, muß er stabil sein, d.h. frei von besonderen Vorkommnissen. Je mehr sich die Verspätungen eines Zuges in einem bestimmten Rahmen bewegen, desto leichter kann man die Zugverbindung untersuchen und verbessern.
3. Theorie des Wissens: Damit man sich die Welt erklären und die Folgen einer Tat abschätzen kann, benötigt man eine Theorie. Auch das Management muß bei einer Maßnahme wissen, was bei deren Durchführung passiert. Daher ist Management auch die Kunst der Vorhersage. Eine Theorie ist auch nötig, um Fallbeispiele und Erfahrungen beurteilen zu können, da Beispiele selbst keine Theorie schaffen, sondern höchstens widerlegen können. Auf einer Fläche addieren sich die Winkel eines Dreieckes zu 180°. Auf einer Kugel funktioniert diese Theorie jedoch nicht. Schließlich sorgt das Wesen der Theorie dafür, daß alles, was beobachtet oder gemessen wird, keinen „wahren“ Wert besitzt, da der Wert von der Beobachtungs- bzw. Meßmethode abhängt.
4. Psychologie: Da Arbeit mit Menschen zu tun hat, muß man begreifen, daß das Miteinander eine entscheidende Rolle in einer Gemeinschaft spielt. Genauso muß man die Tatsache berücksichtigen, daß es zwischen den Individuen Unterschiede gibt. Dies drückt sich z.B. in der Art aus, wie sie etwas lernen können (einige lernen durch Lesen, andere durch Bilder usw.). Besonders wichtig ist jedoch der Unterschied zwischen intrinsischer und extrinsischer Motivation. Intrinsische Motivation ist Motivation aus der Achtung für sich selbst und andere. Extrinsische Motivation ist der Versuch, durch Belohnung und Bestrafung zu motivieren. Das Problem mit extrinsischer Motivation ist, daß sie zu Lasten der intrinsischen Motivation geht, da Belohnungen und Strafen dazu motivieren, daß Belohnungen erhalten und Bestrafungen vermieden werden, mit allen Konsequenzen. Der amerikanische Pädagoge Alfie Kohn legt in seinen Artikeln dar, daß auf diese Weise Schulnoten und sogar Lob schädlich sein können.

Das System of Profound Knowledge kommt durch das Zusammenwirken dieser vier Elemente zustande.

Um das System of Profound Knowledge zu begreifen und umsetzen zu können braucht man weder ein Systemanalytiker noch ein Statistiker noch ein Philosoph noch ein Psychologe zu sein. Das System zeigt auf, wie man eine Organisation beurteilen und wie sie im Idealfall aussehen sollte. Daraus ergeben sich die zur Umformung nötigen Schritte und Werkzeuge. Wenn das System of Profound Knowledge auf freiwilliger Basis erlernt wird, werden somit auch die für die Umformung nötigen Kenntnisse bereitwillig erlernt.

Gleichzeitig ist das System of Profound Knowledge hilfreich, um Methoden des Qualitätsmanagements von den 7 Qualitätswerkzeugen (Q7) (bzw. „7 grundlegenden Werkzeugen„)bis hin zu Six Sigma einzuführen oder zu begreifen. Gerade bei „Modeerscheinungen“ ist es wichtig, die Voraussetzungen für eine gelungene Durchführung sowie ihre Stärken und Schwächen zu begreifen. Deming erwähnte in diesem Zusammenhang, daß beim Versuch, das „japanische Geheimnis“ zu erlernen, Exkursionen unternommen wurden. Dabei erfuhr man beispielsweise, daß dort Qualitätszirkel üblich sind. Das Fehlen einer Theorie führte dazu, daß dann die Qualitätszirkel zu Hause eingeführt wurden, ohne daß man deren Voraussetzungen oder die Bedeutung begriff. Als sie dann nicht den erwarteten Erfolg zeigten bzw. Probleme verursachten, wurde die Aufmerksamkeit auf die aktuelle „Methode des Tages“ gerichtet.

In einem gewöhnlichen Betrieb werden die Prinzipien der vier Elemente auch ohne Kenntnis ihres Zusammenwirkens mehr oder weniger stark beachtet. Auch wenn die Kenntnis der Interaktion zu einer wirksamen Umsetzung im Qualitätsmanagement fehlt, so sind die Voraussetzungen soweit gegeben. In der IT-Welt verhalten sich die Dinge ähnlich bis auf eine Sache: Die Variation wird in einem gewöhnlichen IT-Betrieb nicht beachtet. Wie auch aus einem Diskussionsbeitrag hervorgeht, hat auch Deming dem Verständnis der Variation eine besondere Bedeutung beigemessen und die Vermutung dessen Verfassers bestätigt, daß 70 bis 80 % seiner Vorträge darauf beruhten.

Um ein Mißverständnis auszuräumen: In der IT-Branche werden sehr wohl statistische Methoden angewendet. Internet-Nutzungsstatistiken sind nur ein Beispiel von mehreren. Das Problem mit diesen Beispielen ist aber, daß sie entweder in externen Bereichen wie z.B. Marketing verwendet werden oder, sofern sie intern gebraucht werden, das Vorhandensein einer allgemeinen Variation ignoriert wird. Ein Beispiel dafür ist eine Mitarbeiterbeurteilung, bei welcher eine Rangliste erstellt wird und die Position bzw. die Leistungen ausschließlich auf den jeweiligen Mitarbeiter zurückgeführt werden. Dabei hat Deming festgestellt, daß die Leistungen zu 94 % vom System und nur zu 6 % vom Einzelnen abhängen. Statistische Methoden, welche im Rahmen des Qualitätsmanagements auf eine Optimierung eines IT-Betriebes als System abzielen, scheinen wenig verwendet zu werden.

Über die Gründe kann ich nur Mutmaßungen anstellen. Ein Grund kann sein, daß die IT-Welt mit ihrer Programmierungsarbeit sich als logisch arbeitendes System ansieht, wo jede Abweichung eine spezielle Ursache hat (eine Sichtweise, die nach Deming einen unkalkulierbaren Schaden verursacht). Ein damit zusammenhängender Grund kann sein, daß die IT-Branche sich als Pionier begreift und alles, was sie braucht, selber entwicklen muß. Aus anderen Branchen ist das Not-Invented-Here-Syndrom bekannt, wo Gruppendenken dazu führt, daß Erkenntnisse aus anderen Gruppen nicht übernommen werden.

Es gibt aber Hoffnung. Einerseits gibt es auch in der IT-Welt Leute, welche die Bedeutung der Variation für das Programmieren erkennen. Einer davon ist David J. Anderson, der die Theory of Constraints zur Verbesserung des Projektmanagements in der Softwareentwicklung verwendet und dabei auch die Variation beachtet. In seinem Blog liefert er Beispiele für allgemeine und spezielle Ursachen in der IT-Branche. Diese kann man mit statistischen Methoden analysieren.

Andererseits braucht eine kleine Firma kein aufwendiges System wie Six Sigma, dessen Einführung mit großem Aufwand verbunden ist und daher oft mehr Schaden als Nutzen anrichten kann. Wenn man damit anfängt, bestehende Probleme mit einfachen Methoden wie den sieben Qualitätswerkzeugen zu lösen und dabei das System of Profound Knowledge berücksichtigt, kann man die Wirksamkeit des Qualitätsmanagements vermitteln und weitergehende Methoden wie die Neuen Sieben Qualitätswerkzeuge einführen. Auf diese Weise arbeitet man sich von der Lösung lokaler Probleme vor zur Verbesserung des gesamten Systems (wobei die lokalen Probleme in Hinblick auf das System betrachtet werden müssen).

Falls jemand weitere Beispiele kennt, wo statistische Methoden in einem IT-Betrieb verwendet werden könnten oder es schon praktische Anwendungen gibt, so möchte ich gerne davon hören.

• ZDNet.be: „In unserer eigenen kleinen IT-Welt befinden wir uns nach all den Jahren noch immer in einer USA-Mentalität der 50er Jahre, was Qualität angeht.“ – Der belgische Unternehmensberater Peter Hinssen wartet auf einen W. Edwards Deming für den IT-Sektor. (niederländisch)