Artikel

Ruinöse Arbeitsteilung

Beitrag von Christian Setzwein
21. Mai 2014

// Komplexität

1776 war ein besonderes Jahr mit großer Bedeutung für die Weltgeschichte. Es ist das Jahr der amerikanischen Unabhängigkeitserklärung. Im gleichen Jahr kamen James Watts Dampfmaschinen erstmals in Fabriken zum Einsatz und lösten die industrielle Revolution aus. Und Adam Smith veröffentlichte seinen Band „Wohlstand der Nationen“, der bis heute Einfluss auf die Diskussionen um den Markt hat.

Ein Thema, das Smith in diesem Buch ausführlich behandelt, ist das Prinzip der Arbeitsteilung, das er als Möglichkeit beschreibt, den gemeinsamen Wohlstand zu steigern. So ist es besser, wenn jede Person das macht, was sie am besten kann und ausführlich geübt hat, denn sie kann effizienter produzieren und generiert damit einen deutlich höheren Output als jemand, der die Profession nicht beherrscht. Der Schuster kann mehr Schuhe produzieren als ein Müller und sich dafür Mehl oder sogar fertige Brötchen kaufen, die der Bäcker wiederum effizient produzieren kann. In den folgenden Jahrhunderten hat sich dieses Prinzip weiter verbreitet: ob in der Form der Arbeitsteilung von Nationen (Deutschland als Maschinenbauer, China als Werkbank) oder in der Ford’schen Fabrik am Fließband, wo sich einzelne Arbeiter auf wenige Handgriffe spezialisiert haben. Und als Erfolgsprinzip für höheren Output und starke Effizienz hat es sich in die obersten Schubladen im Werkzeugkasten ganzer Managergenerationen eingefügt.

Das Prinzip der Arbeitsteilung beruht auf den folgenden Voraussetzungen:

Einzelne Arbeitsschritte können autonom ausgeführt werden; man benötigt keine weitere Profession zur Durchführung.
Jeder Arbeitsschritt ist vollständig abgeschlossen und es kann etwas Fertiges geliefert: Ist ein Brötchen gebacken oder die Schraube eingedreht, so ist man fertig und kommt bei der Produktion nicht noch einmal an die Reihe.
Der Vorgänger- und der Nachfolgerschritt eines Arbeitsvorgangs liegen durch einen einfachen Prozess vollständig fest: nach dem „Tür einhängen“ kommt der Arbeitsschritt „Tür festschrauben“.
Es müssen keine Informationen über das gelieferte Ergebnis hinaus an den nächsten Arbeitsschritt oder den Vorgängerarbeitsschritt geliefert werden: Ich muss nicht noch erklären, was ich geliefert habe, damit der Nächste weiterarbeiten kann.

Auch bei der Produktion von IT-Systemen haben Manager das obenliegende Erfolgsprinzip aus dem Werkzeugkasten herausgeholt: So gibt es

Business Analysten, die die Anforderungen besser verstehen und aufschreiben können
Tester, die den Code besser testen können
Entwickler, die besser Quellcode schreiben können
Deployment-Experten, die Anwendungen besser ausliefern können
Integratoren, die unterschiedliche Systemteile besser integrieren können

Doch in der IT-Industrie macht man in immer mehr Organisationen die Erfahrung, dass die Arbeitsteilung, das Erfolgsprinzip der Industrialisierung, nicht zu mehr Effizienz, sondern zu hochkomplexen Organisationsformen führt, die mit zunehmender Größe immer ineffizienter werden. Der Grund dafür ist, dass im Falle der Erstellung von IT-Systemen die oben genannten Voraussetzungen zum Funktionieren des Prinzips nicht erfüllt sind:

Die Autonomie der Arbeitsschritte ist nicht gegeben: Das Deployment ist nicht unabhängig von dem, was angefordert und dem was implementiert wurde. Testen sollte parallel zum Implementieren und nicht danach erfolgen, um Kosten zu sparen.
Arbeitsschritte können nicht abgeschlossen werden, sondern werden von nachfolgenden Arbeitsschritten beeinflusst: Wird beim Implementieren wahrgenommen, dass etwas nicht gut spezifiziert ist, so muss nachgearbeitet werden. Wird beim Integrieren bemerkt, dass Dinge nicht zusammenpassen, so muss die Implementierung nochmal verändert werden.
Die Arbeitsschritte sollen zwar durch ein Phasenmodell (Wasserfall) nacheinander geordnet ablaufen, in der Praxis läuft das aber anders: Testen führt zu Nachimplementieren oder Bugfixing, auch Anforderungen werden dann wieder geändert. Die Reihenfolge der Schritte ist in Wahrheit abhängig von dem Was und dem Wie es implementiert wird und höchst individuell.
Zwischen den Schritten muss eine Menge Information übertragen werden: Entwickler können nicht alles, was auf Papier gebannt ist, auf Anhieb im richtigen Kontext verstehen, Business Analysten wissen nicht vorab, wie sie Informationen am Besten an die Tester übertragen sollen. Je nach Komplexität des Systems muss viel kommuniziert werden.

Versucht eine Organisation dennoch, das Modell der Arbeitsteilung durchzuhalten, so hat dies meist ruinöse Folgen:

Der einzelne Entwickler oder Tester leistet täglich deutlich weniger (ganz im Gegensatz zum Grundgedanken der Arbeitsteilung), als er eigentlich könnte, denn er ist abhängig von anderen Lieferleistungen, die gerade nicht dran sind.
Es wird eine kostenintensive Organisation der Organisation benötigt, um die komplexen Strukturen und Regeln der Arbeitsteilung einzuhalten: z.B. aufwendige Ressourcenplanung, IT-Organisation, usw.
Um wieder mehr zu leisten, versuchen arbeitsteilig organisierte Organisationen größer zu werden (mehr Entwickler, mehr Tester, mehr Business Analysten). Fatalerweise erhöht sich dadurch die Komplexität der Organisation weiter und die Lähmung wird noch stärker. Ab einem gewissen Punkt wird man mit mehr Personal langsamer statt schneller!

Der einzige Ausweg, der meiner Erfahrung nach aus diesem Dilemma heraushilft, ist, das Prinzip der Arbeitsteilung vollständig aufzugeben. Stattdessen sind alle Professionen in einem Team vertreten, das Team kann autonom agieren und fertige Produktteile entwickeln und auch ausliefern. Auch innerhalb des Teams sollten sich die einzelnen Mitarbeiter vom Spezialisten (ich bin aber Frontend-Entwickler) zum Generalisten (ich kann Frontend, Backend, Datenbank, Mergen, Deployen, am Besten bin ich im Backend) entwickeln. Moderne Entwicklung von IT-Systemen nutzt das Prinzip der Arbeitsteilung nur innerhalb eines kommunikativ integrierten Teams und setzt stattdessen auf eine Teilung des Produktes in autonome Bereiche, für die dann einzelne Teams vollständig verantwortlich sind. IT-Systeme mit einem Fließbandprozess entwickeln zu wollen ist ineffektiv (je größer, desto schlimmer), kostenintensiv und für einige Unternehmen, die sich den Luxus nicht mehr leisten können, ruinös.

Weiter interessante Artikel:

| Keine Kommentare