3.2 Maßnahmen zur Industrialisierung

Die Industrialisierung der Softwareentwicklung folgt keinem schlüssigen Konzept, sie ist fest im Griff der Beraterbranche. Dieser geht es um den Verkauf ihrer Dienstleistungen. In großen Unternehmen werden schon die ersten Maßnahmen umgesetzt. Eine gute Übersicht bietet eine Artikelserie zur Industrialisierung der IT aus dem Jahr 2007, publiziert im Zentralorgan der IT-Berater, der Computerwoche. Dort wurden auch schon die ersten Erfolgsnachrichten verbreitet.

Standardisierung und Automatisierung

Zunächst einmal gilt es die Prozesse zu standardisieren. Fast schon klassisch ist das Dreigestirn von CMMI für die Entwicklung, ITIL für den Betrieb und CobiT für die Organisation, Steuerung und Kontrolle der IT eines Unternehmens („Governance“). Darüber hinaus sollen Methoden aus der Produktionsplanung und -steuerung (PPS) übernommen werden. Wem es dann noch nicht reicht, der kann Konzepte aus dem „Design for Manufacture and Assembly“ (DFMA) der Automobilindustrie übernehmen. Aber damit sind die Berater noch lange nicht am Ende, Supply Chain Reference Model (SCOR) und Customer Chain Reference Model (CCRM) sind weitere Prozessmodelle, die der IT-Branche angedient werden.

Die Softwareentwicklungsumgebung gilt es über alle Phasen zu standardisieren, meist auf der Basis von UML2 . Modellgetriebene Softwareentwicklung kommt hier ins Spiel. Produkte und Services sollen ebenfalls weitestgehend standardisiert werden.

Die Entwicklung soll in wohldefinierte Arbeitschritte zerlegt werden. Dazu bedarf es weniger hochbezahlter Spezialisten. Den Rest erledigen standardisierte Ressourcen mit ihren standardisierten Fertigkeiten in Fließfertigung. Einerseits sollen sie auf ihre Teilaufgaben spezialisiert sein, andererseits doch so flexibel, dass sie auch in vorausgehenden oder nachfolgenden Arbeitsschritten eingesetzt werden können. Denkbar wäre zum Beispiel, dass eine Softwareentwicklerin genau eine Phase des Entwicklungsprozesses (z.B. das Codieren), eine Technologie (z.B. Java-Swing) und eine Schicht (z.B. das User-Interface) beherrscht. Vielleicht sollte sie sich dann noch ein wenig mit dem Design und dem Test von User-Interfaces auskennen. Mit Kenntnissen der Fachdomäne muss sie sich nicht mehr belasten, da ja alles Fachliche in einer früheren Phase bereits ausführlich und korrekt spezifiziert ist. Die beispielhaft angeführte Kollegin ist flexibel einsetzbar, auch parallel in mehreren Projekten. Aufwände für ihre Einarbeitung entstehen nicht. Überall werden ja die gleichen Tools verwendet und auch die fachliche Spezifikation folgt einheitlichen Standards. Für die Programmierung und das User-Interface liegen ebenfalls Richtlinien vor. Eine Standard-Architektur (z.B. auf Basis des Model-View-Controller-Patterns) und vorgefertigte Komponenten machen das Ganze zum Kinderspiel. So bleiben nur noch wenige hoch qualifizierte Tätigkeiten.

Standardisierung, Arbeitsteilung und Automatisierung waren auch bei der Softwar-Factory 1.0 angesagt, vom Ansatz her ist das nichts Neues, auch wenn Prozessmodelle und Tools inzwischen ausgereifter sind.

Modularisierung

Anwendungen sollen aus vorgefertigten Teilen zusammengefügt werden können. Seit Jahren nutzen wir Bibliotheken. Schon seltener klappt es mit der Wiederverwendung von Komponenten. Helfen sollen hier Standard-Plattformen. Und dann gibt es ja noch die Allzweckwaffe SOA (Service Orientierte Architektur).

Modularisierung und Wiederverwendung stehen spätestens seit der Ausrufung der Software-Krise auf der Tagesordnung, auch bei der Software Factory 1.0 bemühte man sich darum.

Kontinuierliche Verbesserung

Total Quality Management ist angesagt. Six Sigma wird auch in der Softwareentwicklung verwendet. Alle Services sollen SLAs (Service Level Agreements) unterliegen. Ohne Metriken geht nichts mehr. Nicht nur zur Qualitätskontrolle werden laufend Kennzahlen erhoben. Jeder Arbeitsschritt, jedes Teilergebnis soll vermessen werden. Zahlen dienen als zentrales Steuerungsinstrument. Soziologen sprechen dann schon mal von der „Herrschaft der Zahlen“.

Kontinuierliche Verbesserung und die Steuerung über Kennzahlen waren auch Ziele der Software Factory 1.0 – auch hier alter Wein in neuen Schläuchen.

Konzentration auf Kernprozesse

Die Fertigungstiefe soll reduziert werden. Sourcing-Strategien als Kombination von On-, Near- und Offshore gilt es zu etablieren. Teilaufgaben sollen an Hersteller ausgelagert werden, die Skaleneffekte nutzen können. Ziel ist die international verteilte Softwareentwicklung, der Weltarbeitsmarkt soll nicht nur zur Abdeckung von Spitzen genutzt werden. Die Prozesshoheit soll im Land bleiben. Voraussetzungen sind klare Schnittstellen-Definitionen und konkrete Beschreibungen der Aufgaben. Und damit sind wir wieder bei der Standardisierung.

Die Konzentration auf Kernprozesse ist neu, bei der Software Factory 1.0 spielte sie keine Rolle, Offshoring war noch kein Thema.

Success Stories

Für die notorischen Skeptiker und Pessimisten hält die Marketing-Kampagne frühe Success Stories bereit:

„Ähnlich wie in anderen Industriezweigen hat es in der Softwareentwicklung in den letzten Jahren einen Trend zu standardisierten Verfahren und industrieller Fertigung, so genannten Software Factorys, gegeben. Auf Basis standardisierter IT-Konzepte können Codierungsarbeiten in hoher Qualität und preisgünstig hergestellt werden. Der Preisvorteil wird natürlich umso größer, je geringer die Personalkosten der Dienstleister sind, daher kommen dafür die typischen Offshore-Unternehmen insbesondere in Asien und Osteuropa in Frage. Wir haben uns für Partner aus Indien und Manila entschieden. Unsere Erfahrungen in der Zusammenarbeit sind bislang durchweg positiv.“ (Computerwoche 48/2007)

Und wer’s glaubt, kann Manager werden. Begeisterte Erfolgsmeldungen begleiteten auch die Software Factory 1.0 in der Anfangsphase, also auch nichts Neues.

weiter

Eine Antwort to “3.2 Maßnahmen zur Industrialisierung”

  1. itworker Says:

    Industrialisierungsmaßnahmen bei der Deutschen Bank beschreibt Wolfgang Gaertner in einem Interview der Computerwoche:

    Die Anwendungsentwickler werden aus ihren Silos geholt. Vertikale Arbeitsteilung wird eingeführt. Vom befreiten Entwickler wird erwartet „dass er sich auf ein Thema wie Domain-Management oder Deployment oder Application-Management spezialisiert. Er muss sich um mehr Anwendungen als nur das Spargeschäft kümmern – breiter und tiefer. Das bedeutet für einige eine große Veränderung, die das Anforderungsprofil nachhaltig verändert. Aber dafür bieten wir auch Fördermaßnahmen an.“

    Der Frage nach der Attraktivität der Jobs weicht Gaertner aus:
    „Ja, wir haben bestimmte Tätigkeiten an Partner gegeben, weltweit, und wir arbeiten mit Anbietern in anderen Ländern zusammen. Der Kern der IT-Arbeit – die Verbindung mit dem Geschäftsbereich, das Design der Prozesse, das Steuern der Partner und der komplexen Netzwerke – all das bleibt unsere Aufgabe. … Trotz Offshoring und Outsourcing wird die IT nichts von ihrer Bedeutung verlieren.“ Mit der Programmierung ist es demnach bei der Deutschen Bank vorbei.

    Und die KollgenInnen, haben sie das alles so hingenommen?
    – „Am Anfang war der Diskussionsbedarf sehr groß“. Jetzt greift das Change-Management.

    http://www.computerwoche.de/job_karriere/personal_management/1865342

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s


%d Bloggern gefällt das: