Der heutige Funktionsumfang des Software-Engineering reicht vielfach nicht aus, um die Organisationsprobleme im Unternehmen zu lösen. Oft ist nicht einmal eine Unterstützung der anfallenden Systementwicklungs- und Implementierungsprobleme gegeben. Zur Verdeutlichung der Sachlage sollte daher nicht von "Software-Engineering", sondern von "Organisations-Development-Engineering" die Rede sein, meint Ulrich Busch*.
Der Begriff Software-Engineering steht für ingenieurmäßiges Vorgehen bei der Entwicklung von Software. Eine eindeutige Festlegung, was unter ingenieurmäßig zu verstehen ist, gibt es nicht. Die Qualität der Ingenieurleistung bleibt also dem jeweiligen Systementwickler weitgehend überlassen und hängt davon ab, welche Werkzeuge er einsetzt. Demzufolge hängt die Qualität der Systementwicklung in hohem Maße davon ab, wie gut das jeweils eingesetzte Tool beziehungsweise Werkzeugkonzept ist.
Hinsichtlich der verfolgten Ziele sind sich die Experten einig. So ist eine Reduzierung des Entwicklungsaufwandes durch Automatisierung und Standardisierung angestrebt. Ferner soll durch die Verwendung problemadäquater Vorgehensweisen und Methoden eine Verbesserung der Softwarequalität erreicht werden.
Die Erhöhung der Flexibilität beziehungsweise Anpaßbarkeit und Wartbarkeit der Software stellt sich als weiteres Postulat. Erforderlich ist eine klare Strukturierung des Softwaredesigns nach den Kriterien der Modulartechnik mit dem Ziel, wiederkehrende Programmfunktionen nur einmal zu entwickeln und sie häufig wiederzuverwenden. Entscheidende Bedeutung kommt der Tabellenverarbeitung zu, die eine Veränderung der Tabellenwerte ohne Veränderung der Verarbeitungsprogramme erlauben muß. Die computergestützte Dokumentation der Programmsysteme einschließlich der Datenstrukturen hat die Möglichkeit des Verwendungsnachweises für Programmoduln und/oder Daten zu bieten. Komplexe Systementwicklungen in einem hochautomatisierten Systemfeld müssen sich verwalten lassen, mit dem Ziel Aufgaben-, Anlauf- und Datenzusammenhänge zu integrieren.
Betrachtet man den heutigen Stand des Software-Engineering, dann wird deutlich, daß die auf dem Markt angebotenen Werkzeuge vielfach nicht im Rahmen eines geschlossenen Werkzeugkonzeptes entwickelt wurden. Es entstehen daher in den Entwicklungsabteilungen für Anwendungssysteme Überschneidungen von Werkzeugfunktionen, die zur Reduzierung des gewünschten Effektes führen. Ein weiteres Problem besteht darin, daß die Werkzeugkonzepte alternativ Problemfälle beziehungsweise Entwicklungsvorgehensweisen unterstützen müssen.
Der heutige Trend geht eindeutig zur Verwendung von Standardanwendungssoftware und bei Eigenentwicklungen zur Anwendung des "Prototyping-Approach" (Prototypenvorgehens). Das bedeutet, daß die auf dem Markt zur Verfügung gestellten Werkzeuge vielfach Lücken aufweisen und daher für die am häufigsten auftretenden Problemfälle keine Hilfe darstellen. Dabei läßt sich feststellen, daß zum Beispiel die Funktionen, die bei allen Variantenkonzepten gleichermaßen auftreten, die geringste Unterstützung durch Werkzeuge erfahren.
Gemeint sind hier die Funktionen die für die Definition der Systemanforderungen notwendig sind und Werkzeuge, die die Simulation der Systemwirkungen der geplanten Anwendungssysteme im "Tagesgeschäft" der Fachabteilungen unterstützen.
Abbildung 2 gibt einen Überblick über die Schwerpunkte der heutigen Unterstützung bei den Phasenschritten der Variante A, also der traditionellen Softwareentwicklung. Es wurde darauf verzichtet, die entsprechenden abweichenden Übersichten für die Varianten B (Prototyping-Approach) und C (Einsatz von Standardsoftware) abzubilden.
Nur sehr zögernd wird an der Entwicklung von Methoden zur Darstellung von Unternehmensabläufen (Graphen- beziehungsweise Netzeditoren) gearbeitet. Die wenigen in Entwicklung befindlichen Produkte, zum Beispiel die Entwicklung eines Editors beziehungsweise Entwicklungsrechners für Petri-Netzdarstellungen, finden am Markt nicht das erforderliche Echo. Deshalb wird vielfach aus kommerziellen Gründen, das Entwicklungstempo reduziert.
Das Verständnis der Fachleute auf dem Sektor der Anwendungssystementwicklung ist unter anderem der Grund dafür, daß der Bereich der Organisationsentwicklung im Unternehmen nicht mit der erforderlichen Gewichtung gesehen wird.
So ist es nicht verwunderlich, daß der Funktionsumfang des Problemkreises "Software-Engineering" in DV- beziehungsweise Entwicklungsfunktionen angesiedelt ist (siehe auch Grad der Verfügbarkeit von Werkzeugen gemäß Abb. 2).
Im Rahmen der Entwicklungsprozesse der Unternehmensorganisation hat die Systementwicklung (Programmentwicklung ein relativ niedriges Gewicht. Das Hauptgewicht liegt in der Organisationsentwicklung, im genannten Beispiel mit 80 Prozent angesetzt.
Betrachtet man dagegen den Grad der Unterstützung durch vorhandene Werkzeuge, dann wird das umgekehrte Verhältnis erkennbar (siehe Abbildung 1 und 2). Aus Abbildung 2 ist ersichtlich, daß die organisationsnahen Funktionen, wie die Ermittlung der Systemanforderungen durch Verwendung von Beschreibungssystemen betrieblicher Aufgaben, Vorgänge beziehungsweise Prozesse oder die Simulation von Systemwirkungen kaum unterstützt werden.
Die Praxis zeigt, daß unabhängig von der Größe des Unternehmens die organisatorischen Fragestellungen meist unter Zuhilfenahme von Management-Consulting-Firmen gelöst werden müssen, weil das betroffene Unternehmen nicht über die erforderliche Qualität von Organisatoren verfügt. Zweifellos bringt ein externer Berater zusätzliche Vorteile bei der Lösung von Organisationsentwicklungsproblemen, aber auch er benötigt bei seiner Arbeit entsprechende Werzeuge, die heute in nur geringem Maße vorhanden sind.
Der heutige Funktionsumfang des Software-Engineering reicht nicht aus, um die Organisationsprobleme im Unternehmen zu lösen. Vielfach verlangt er nicht einmal eine Unterstützung der anfallenden Systementwicklungs- beziehungsweise -anpassungs- und Implementierungsprobleme (Standardsoftwareeinsatz).
Zur Verdeutlichung der Sachlage sollte daher nicht von Software-Engineering, sondern von OD-Engineering (Organisation-Development-Engineering beziehungsweise Organisations-Entwicklungs-Engineering) gesprochen werden. Das Software-Engineering in der heutigen Form deckt lediglich einen Teilbereich des OD-Engineering ab.
Die freie Marktwirtschaft orientiert sich bei dem Angebot von Produkten stets an der Nachfrage. Von daher ist also zunächst eine Verlagerung der Schwerpunktbetrachtung des Aufgabenbereiches der heutigen Org/DV-Abteilungen erforderlich. Die starke Orientierung an programmiernahen beziehungsweise hardwarenahen Problemstellungen muß zugunsten der organisatorischen Problemlösungen weichen. Diese Forderung wird durch die verstärkte Installation vorgefertigter Problemlösungen wie Standardsoftware unterstützt.
Der Systementwickler künftiger Prägung ist als Architekt beziehungsweise Ingenieur der Unternehmensorganisation zu verstehen. Seine Aufgabe besteht in erster Linie in der Gestaltung der Unternehmensorganisation. Erst in zweiter Linie sollte er sich als Systemlieferant verstehen. In dieser Funktion wird er sich im Rahmen gängiger Regeln der Investitionsrechnung die Frage nach "make or buy" (Eigenentwicklung oder Kaufsoftware) stellen müssen.
Der harte Wettbewerb zwingt die Unternehmensleitungen in immer größerem Maße, "indirekte Bereiche" (gemeinkostenträchtige Unternehmensbereiche) auf ein Mindestmaß zu reduzieren. Auch unter diesem Gesichtspunkt stellt sich für den Unternehmer die Frage, ob die heutigen Überlegungen, Konzepte und Anstrengungen des Software-Engineering in die richtige Richtung gehen.
Was nützt dem Unternehmer zum Beispiel die Installation von CAD im Softwareentwicklungsbereich, wenn die Systementwicklung an den tatsächlichen organisatorischen Erfordernissen vorbeigeht. In diesem Sinne sollten die Konzepte des "Software-Engineering" überdacht werden.
* Ulrich Busch ist Leiter Business Consulting bei der Price Waterhouse GmbH, Wirtschaftsprüfungsgesellschaft, Hamburg.