Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.08.1992 - 

Ein systemisch-ganzheitlicher Ansatz ist nötig

SW-Entwicklung: Leidensdruck macht Krise nur noch schlimmer

*Renate Bechelr und Reinhard Hradetzky sind Unternehmensberater bei der Eichinger, Andersen und Partner GmbH in Hamburg

Trotz Methoden-, Werkzeug- und Beratereinsatz macht die Anwendungsentwicklung Schwierigkeiten. Zu den Ursachen, so meinen Renate Becher und Reinhard Hradetzky*, zählen schlechte Beratung, das mangelhafte Zusammenspiel von Fach- und Org./DV-Abteilung und die fehlende Ausrichtung der Projekte auf unternehmensstrategische Ziele.

Software-Engineering hat sich im Alltag de Projektarbeit noch nicht hinreichend

durch gesets. Das führt yu einer häufig unsauberen und keineswegs zukunftsorientierten Anwendungsentwicklung. Das zweite Problem liegt bei den fachbereichen, die nicht intensiv genug in den Software-Entwicklungsprozeß eingebunden sind - einerseits, weil sie selbst keinen Wert darauf legen, andererseits weil sie nicht hinzugezogen werden .

Ein zusätzliches Handicap sind Berater. Die sich zu wenig an den wirklichen Bedürfnissen der Unternehmen orientieren und die unternehmensspezifischen gegeben heiten und psychologischen Zustände'' oftmals nicht genügend berücksichtigen. Ein Know-how-Transfer hinsichtlich der entwickelten Systeme findet nicht statt.

Vorhandene Kapazitäten durch Wartung gebunden

Sollen diese Probleme gelöst werden so ist eine systemischganzheitliche Vorgehensweise zu wählen bei der sämtliche Auswirkungen auf alle anderen Bereiche beachtet werden. Damit sind nicht nur organisatorisch-fachliche sondern vor allem auch Verhaltensorientierte Auswirkungen gemeint.

Der beklagenswerte Zustand in der Anwendungsentwicklung der Unternehmen ist seit langem bekannt:

- Ein gewaltiger Anforderungsberg an Neuentwicklungen (gemeinhin Anwendungsstau genannt) wartet auf seine Abarbeitung.

- Dies ist prinzipiell unmöglich, da etwa 80 Prozent der vor handenen Kapazitäten in der Org./DV-Abteilung durch Wartung gebunden sind.

- Entwickelt werden noch immer Großsysteme, die kaum oder gar nicht zu handhaben sind. So kommen ein 30 Millionen Mark-Budget allein für die Reorganisation einer Leben-Bestandsverwaltung in einer Versicherung oder gar ein 100-Millionen-Budget für das neue Wertpapier System einer Bank zu stande.

Systeme werden immer noch nach veralteten Architekturen konzipiert: nicht modular aufgebaut, keine wiederverwendbaren Funktionen und eine unsaubere Datenmodellierung - so fern diese überhaupt stattfindet. Eine fehlende unternehmensweite Betrachtung und die nicht vorhandene Definition allgemein verbindlicher Konventionen steht der Datenmodellierung im Wege.

Dies führt dazu, daß neue Anforderungen gar nicht oder nur schwer abgedeckt werden konnen. Die vielzitierten Veränderungen die der EG-Binnenmarkt 1993 bringen wird, führen zum Beispiel in der Versicherungswirtschaft dazu, daß neue Produkte immer häufiger und schneller auf den Markt zu

bringen sind, Das bedeutet aber, daß für neue Produkte ebenfalls neue separate Anwendungen entwickelt werden müssen, denn die alten Systeme erlauben kaum Erweiterungen zu wirtschaftlichen Kosten. Außerdem ist eine andere Hard und Software anzuschaffen, mit allen Konsequenzen hinsichtlich Wartung, Know- how der Mitarbeiter, Vernetzung der Systeme, Vereinheitlichung der Benutzeroberfläche etc.

Das Zauberwort Software-Engineering ist inzwischen entmystifiziert worden. Trotzdem fällt auf, daß zwar alle über Software- Engineering reden, daß aber noch längst nicht alle Unternehmen die vorhandenen Methoden und Tools auch richtig einsetz. Ein durchgängiges Werkzeug, das alle Phasen des Entwicklungsprozesses unterstützt und damit die Wirtschaft lichkeit und Geschwindigkeit verbessert, ist noch nicht in Sicht. Ein Problem stellen auch die Methoden dar: Die Fachleute sitzen in ihrem Elfenbein turm und kündigen Werkzeuge und Methoden für die Zukunft an. Die Anwendungsentwickler aber müssen bereits heute neue Systeme entwickeln, und zwar mit dem, was gegenwärtig erhältlich ist!

Berater sollten Hilfe zur Selbsthilfe leisten

In den Unternehmen werden aber zur Zeit die durchaus möglichen sauberen Vorgehensweisen - eben durch den Einsatz gängiger Methoden, Werkzeugen und professionellen Projekt-Managements - nicht akzeptiert. Dazu folgendes Bild: Ein Spaziergänger geht durch den Wald, Er beobachtet einen Waldarbeiter, der mit einer alten und abgenutzten Säge Bäume zerkleinert. Der Spaziergänger sagt zu ihm: "Wenn Du die Säge schärfen würdest, ginge die Arbeit leichter und schneller von der Hand." Die Antwort des Waldarbeiters: "Dazu habe ich keine Zeit, ich muß sägen."

Problematisch ist auch, daß eine saubere Vorgehensweise in der Regel zu großen Migrationsproblemen führt, Saubere Datenstrukturen und redundanzfreie Funktionen bedeuten nämlich einen großen Änderungsaufwand bei den vorhandenen Systemen. Die genannten Großsysteme aber werden sehr häufig ausschließlich von Berater entwickelt. Ein Know-how Transfer findet fatalerweise nicht statt.

Mangelhaft ist in der Regel auch die Kooperation von DV und Fachbereichen. Systeme werden für die Fachabteilung entwickelt - deshalb sollte der Fachbereich erst einmal gefragt werden, was er eigentlich haben möchte. In vielen Fällen liegt die Schuld aber auch bei den Fuhrungskräften der Fachbereiche. Sie sehen die Notwendigkeit einer Mitarbeit nicht ein und nicht selten hat bei ihnen die Erledigung der Tagesarbeit absolute Priorität vor Zukunftsinvestitionen.

Unseres Erachtens sind folgende zum Teil vielschichtige Ursachen für den oben beschriebenen Zustand verantwortlich.

1. Die Fachhereiche neigen zu hundertprozentigen Lösungen. Die Anwendungsentwickler betrachten diese forderung aber nicht kritisch genug, denn bekanntlich läßt sich 80 Prozent der Lösung mit nur 20 Prozent des Aufwands erreichen während die restlichen 20 Prozent der Lösung 80 Prozent des Aufwands in Anspruch nehmen (Pareto-Regel ) .

2. Berater nehmen Aufträge an deren Bedingungen eigentlich inakzeptabel sind. Aus Angst vor einem Auftragsverlust wird dabei jeder methodische und fachliche Unsinn den der Kunde fordert kurzsichtig akzeptiert. Hauptsache die Beschäftigung bleibt gesichert. Dabei nimmt jedes Unternehmen kritische Worte eines Beraters dankbar auf - ja, es erwartet diese kritische Distanz und Weitsicht sogar.

3. Fachbereiche sind zu wenig in die Projektarbeit eingebunden. Wegen des notwendigen Know-how-Transfers dürfen Projekte nicht ausschließlich durch Berater besetzt werden. Es sollten immer auch Mitarbeiter des eigenen Org./DV-Bereichs im Projekt tätig sein.

4. Schnittstellen zu anderen Systemen werden nicht früh und sorgfältig genug im Rahmen des Software-Engineering-Prozesses analysiert und konzipiert. Zu spät erkennen die Projektbeteiligten daß ihr Konzept zum Beispiel wegen inkompatibler Altdatenbestände gar nicht realisiert werden kann.

Zu dieser Schnittstellenproblematik gehört auch die immer wieder fehlende strategische Betrachtung von zukünftigen Herausforderungen. Unabdingbar für die Planung von Anwendungsentwicklungs-Projekten

im Org./DV-Bereich ist die Vorgabe der strategischen Anforderungen die sich aus dem Prozeß der Unternehmensplanung ableiten. Die zweite Vorgabe kommt aus den Fachbereichen nachdem diese wiederum abgeleitet aus der strategischen Unternehmensplanung ihre funktionale Strategie entwickelt haben.

5. Es wird zu wenig auf den Erwerb von Schlüsselqualifikationen geachtet. Neben dem reinen Fachwissen sind Aspekte wie Team-,Kommunikations- und Kompromißfähigkeit zunehmend wichtig. Vor allem muß das "To-know-how-to-know" gelernt werden. Hier sind vor allem die Berater gefordert mehr Hilfe zur Selbsthilfe zu leisten, um den Kunden wenigstens mittelfristig selbständig werden zu lassen. Nicht zu letzt baut der Berater damit kompetcnte Gesprächspartner auf, was wiederum der eigentlichen Zusammenarbeit zugute kommt.

6. Insgesamt gesehen wird in der Anwendungsentwicklungsarbeit zu wenig auf das Umfeld des Projektes und zu wenig auf die psychologischen Aspekte der Projektarbeit geachtet. Häufig werden "Expertenlösungen" von Externen (Beratern) aufgepropft ohne den Entwicklungsstand der einzelnen Unternehmensteile ganzheitlich zu berücksichtigen und die Betroffenen zu Beteiligten zu machen.

Wir möchten aufgrund der genannten Mängel neun Anforderungen an eine systemischganzheitliche Vorgehensweise formulieren, von der wir überzeugt sind, daß sie die oben geschilderten Mängel mildern, vielleicht sogar beseitigen kann.

1. Jedes System ist einem ständigen Wandel unterworfen. Die Erfahrung hat gezeigt, daß der

gleiche Aufwand der Erstentwicklung noch einmal für die Weiterentwicklung und Pflege

benötigt wird. Daher sollten Systeme weitestgehend modular aufgebaut werden. Wiederverwendbare Funktionen sind nur einmal zu entwickeln. Systemfunktionen, bei denen aufgrund des technischen Wandels die Gefahr häufiger Änderungen besteht, müssen völlig getrennt von fachlichen Funktionen entwickelt werden.

2. Jedes System kommuniziert mit anderen. Daher hat die Schnittstelle für den Datenaustausch hohe Bedeutung. Nicht vergessen werden darf, daß diese Daten häufig auch noch an Dritt- und Viert-Systeme weiter gereicht werden müssen. Jedes System muß deshalb mit sauberen Datenstrukturen konzipiert werden. Dies leistet die Datenmodellierung.

3. Jede Veränderung in einem System bewirkt immer auch eine organisatorische Veränderung in anderen Systemen/Bereichen des Unternehmens. Ein Unternehmen mit seinen verschiedenen Bereichen läßt sich mit einem Mobile vergleichen. Jede Systemveränderung muß also auf ihre moglichen Auswirkungen hin untersucht werden.

4. Die Entwicklung jedes Systems benötigt Personal, Potentiale und Kapazitäten. Unternehmen erfügen aber nur über begrenzte Ressourcen. Deshalb solten nur so viele Projekte aufgesetzt werden wie das Unternehmen verkraften kann. Mit dcm Einsatz einer beliebigen Anzahl von Externen sind die Probleme selten zu lösen. Statt dessen sollten Standardsoftware beziehungsweise Halbfertigprodukte genutzt werden, die sich dann um die unternehmensindividuellen Anforderungen ergänzen lassen. Eine sorgfältige (Jahres-)Planung der Org./DV Aktivitäten unter Berücksichtigung aller Potentiale und Kapazitäten ist unabdingbar.

5. Die Beschreibung eines Systems wird durch die selektive beziehungsweise kontextabhängige Wahrnehmung von Beratern und Systemanalytikern sowie Fachbereichsmitarbeitern bestimmt. Verschärft wird das Problem durch das Phänomen Stille Post: Die ursprünglieh gemachte Aussage wird mit jeder Weitergabe verfremdet. Interviewergebnisse und konzeptionelle vorschläge bedürfen daher der verifizierung und Qualitätssicherung durch den Fachbereich.

6. Jedes System wird von Menschen mit unterschiedlichen Interessen geschaffen. Die Ziele der Fachbereiche der Org./DVAbteilung und der Berater sind keineswegs identisch. Leieler wird die uneinheitliche Zielsetzung in der Regel gar nicht transparent, obwohl sie die Arbeit der Projektbeteiligten bestimmt. Daher ist großer Wert auf die Startphase zu legen in der die Ziele des Projektes fest gelegt und detailliert werden. In diese Phase sollte genügend Zeit investiert werden. Später ist ständig zu prüfen, ob alle noch im selben Boot sitzen".

7. Große Systeme entwickeln ein Eigenleben ihnen, wird die größte Aufmerksamkeit geschenkt. Weil sie langfristig die knappen Ressourcen binden werden andere Anwendungen vernachlässigt. Dieser Gefahrkann mit einem Planungsprozeß begegnet werden in dem alle Bereiche eines Unternehmens ihre Anforderungen zum Ausdruck bringen und in dem Konsens erzielt wird über die Prioritäten einzelner Vorhaben. Dieser Planungsprozeß ist regelmäßig den aktuellen Anforderungen anzupassen.

8. Jedes System bringt immer auch einen Gewinn. Warum sonst werden Systeme entwikkelt? Zumindest wird im Projektantrag immer ein Gewinn herbeigerechnet. Den Beteiligten ist vor Augen zu führen, wo und auf welchen Ebenen (Unternehmenserfolg individuelle Arbeitsentlastung etc.) dieser Gewinn erwartet wird. Damit lassen sich vorhändene Widerstände leichter abbauen.

9. Das Unternehmen sollte die Entwicklung neuer Systeme beziehungsweise die präventive Weiterentwicklung älterer Systeme in Zeiten einer guten Wirtschaftslage vornehmen. Das bedeutet zwar kurzfristig den Verzicht auf Gewinn, dient aber dem Aufbau von Potentialen für die Zukunft. Mit weniger Druck kann planvoller und sorgfältiger gearbeitet werden. Mit anderen Worten: Es bleibt genügend Spielraum, um die vorgenannten Anforderungen auch in die Tat umzusetzen.

Heute wird in der Regel erst dann investiert, wenn Störungen erkennbar sind oder wenn das Unternehmen von außen gezwungen wird zu reagieren - wenn also "Leidensdruck" besteht. Erst wenn Unternehmen vorausschauend planen, unterstützt die Anwendungsentwicklung die Wettbewerbsfähigkeit.