Die Zeiten, in denen auf Zuruf der Fachabteilungen programmiert wurde, sind längst vorbei. Nicht zuletzt dieses Verhalten hat in der Vergangenheit die Kosten für die Wartung und Pflege von Anwendersoftware explodieren lassen. In vielen Unternehmen wird daher an Lösungen gearbeitet, mit denen sich dieses noch immer bestehende Problem in den Griff bekommen läßt. Eine konkrete Maßnahme sieht beispielsweise so aus, daß Anwendungen unabhängig von Betriebssystemen, TP-Monitoren und Datenhaltungssystemen erstellt werden. Das Transparenzproblem lösen die DV-Leiter vielfach, indem sie die Fachabteilungsmitarbeiter in die Entwicklungsphase miteinbeziehen. Eine wichtige Rolle spielt des weiteren der Einsatz von Werkzeugen, mit denen engagierte Mitarbeiter nach einer Einarbeitungsphase bereits Anwendungen selbst entwickeln und somit auch warten können. Das entlastet wiederum die Programmierer.
Die Pflege und Wartung von Anwendersoftware läßt sich durch verschiedene Möglichkeiten reduzieren. Bereits bei der Entwicklung der Software muß darauf geachtet werden, daß die spätere Pflege nicht zu umfangreich wird. Dies erreichen wir zum einen durch den Einsatz von Tools, die die Menge der zu schreibenden Codes erheblich verringert (Beispiel ADF oder CSP). Dadurch ist die Erstellung und Pflege von Anwendersoftware nicht mehr ausschließlich an DV-Fachpersonal (Programmierer) gebunden. Denn auch gut eingearbeitete Fachbereichs-Mitarbeiter, die ein gewisses Gespür und Interesse für Datenverarbeitung haben, können den Umgang mit solchen Hilfsmitteln in sechs bis acht Wochen erlernen und somit Applikationen selbst entwickeln und warten. Für ihre Betreuung steht nach wie vor die zentrale DV zur Verfügung.
Diese "Dezentralisierung der Qualifikationen" hat zwei entscheidende Vorteile: Der Anwendungsstau läßt sich reduzieren, und die Wartung von Programmen wird zu den Mitarbeitern verlagert, die sie entwickelt haben. Dadurch braucht die DV-Abteilung gar nicht erst eingeschaltet zu
---------------------------------------------------------------------------------------------------------------------
Wolfgang Mohr
Abteilungsleiter für Software, dezentrale Systeme und Ausbildung, Landesrechenzentrum, Mainz
---------------------------------------------------------------------------------------------------------------------
werden, zumal dabei erfahrungsgemäß viele Informationen wieder verlorengehen.
Diese Vorgehensweise praktizieren wir seit etwa eineinhalb Jahren. Viele Anwendungen wären nicht entstanden, hätten wir mit den herkömmlichen Methoden weiterprogrammiert. Auch bemerken wir in der zentralen DV von den Änderungen der Programme nicht mehr viel und können uns so anderen Aufgaben widmen. Um künftig die Anwendungen überhaupt noch wartbar zu machen, ist aus unserer Sicht der Einsatz von Tools unumgänglich. Nur so erhält man flexible Applikationen und spart Kosten ein. Viele DV-Profis neigen dazu, die alt eingefahrenen Methoden immer weiter zu verwenden. Vermutlich würde ein Cobolprogrammierer jede neue Anwendung wieder in Cobol programmieren. Das verursacht aber einen wesentlich größeren Aufwand als die Softwareentwicklung mit Werkzeugen.
Bei der Verwendung von Standardsoftware gibt es dagegen wenig Einflußmöglichkeiten. Daher tendieren wir dazu, unsere Organisation dem jeweiligen Standardpaket anzupassen. Denn jegliche Wartung ist teurer und verursacht mehr Aufwand, als wenn man sich vorher Gedanken über eine organisatorische Lösung macht.
Unsere Anwendersoftware besteht zur Zeit noch zu zirka zwei Drittel aus selbstentwickelten Programmen und zu einem Drittel aus Standardsoftware (Fibu, Nettolohn und Gehalt, Teilestammverwaltung). Für die Fremdsoftware haben wir Wartungsverträge abgeschlossen, so daß für
---------------------------------------------------------------------------------------------------------------------
Wolfgang Schaper
DV-Leiter, Delmag GmbH, Esslingen
---------------------------------------------------------------------------------------------------------------------
erforderliche Änderungen kaum Mitarbeiterkapazität absorbiert wird. Denn schon die Pflege der Eigensoftware verschlingt einen großen Teil der Programmierungskapazitäten, etwa ein Drittel. Je älter die Programme werden, desto gravierender ist das. Daher achten wir bereits bei der Entwicklung darauf, daß die Programme möglichst strukturiert und wartungsfreundlich aufgebaut sind, so daß sich von dieser Seite die Pflegekosten in Grenzen halten. Wir überlegen uns momentan, ob wir die vor nahezu zehn Jahren entwickelten Programme für Produktionsplanung und
-steuerung demnächst nicht durch eine fertige Softwarelösung von einem Hersteller oder Softwarehaus ersetzen.
Da wir als mittelständisches Unternehmen nur zwei Programmierer beschäftigen, können wir komplexe Anwendungen nicht mit vernünftigem Kosten- und Zeitaufwand selbst erstellen. Deshalb tendieren wir dazu, nach Möglichkeit anpassungsfreundliche Standardsoftware zu kaufen, die über Tabellen oder andere Parameter gesteuert wird. Bei den heutigen Personalkosten ist dies für uns die beste Lösung. Auf längere Sicht wird sich unsere Softwarelandschaft umkehren und dann zu zwei Drittel aus Standardpaketen und zu einem Drittel aus selbstentwickelten Programmen bestehen.
Nicht nur aufgrund der hohen Kosten sollte Anwendungssoftware möglichst wenig Pflegeaufwand verursachen. Nach unserer Erfahrung wird eine Applikation mit jeder Änderung etwas schlechter und unübersichtlicher, da die ursprüngliche Struktur verlorengeht. Auch kann man den Mitarbeitern in Fachbereich und DV nicht ständig neue Modifikationen zumuten. Image gewinnt man in der DV-Abteilung in erster Linie durch neue Programme und Projekte.
Zunächst gilt es jedoch zu analysieren, wodurch der Pflegeaufwand entsteht. Einmal ergibt er sich aus Qualitätsmängeln, wenn beispielsweise die Fachabteilungen häufig Optimierungswünsche äußern oder Fehler unterschiedlicher Art auftreten. Diesen Pflegeaufwand sollte man von vorneherein verhindern. Erreichen kann man das durch eine fundierte Projektplanung und -durchführung sowie durch verschiedene Qualitätssicherungsmaßnahmen. Die Mitarbeiter der Fachbereiche sollten bereits an der Konzeptionsphase wie auch an den Tests beteiligt sein. Dabei darf das Thema nicht zu sehr abstrahiert werden. Man muß versuchen, die Ergebnisse beispielsweise durch List- und Maskenentwürfe transparent zu machen. Optimal ist hier natürlich der Einsatz von Prototyping. Der Benutzer hat das Recht, bereits im Vorfeld zu erfahren, was er von dem fertigen Produkt erwarten kann. Aus diesem Grund muß er sich allerdings auch klar dazu äußern. Man muß ihn motivieren, indem man ihn an die Kosten erinnert, die durch spätere Pflegemaßnahmen entstehen. Darüber hinaus müssen durch Ad-hoc-Änderungen immer wieder Termine und Anschlußprojekte verschoben werden. Die Einbeziehung kompetenter Mitarbeiter aus den Fachbereichen in die Projektplanung kann also den Qualitätsstandard des fertigen Produkts sichern und damit Pflegeaufwand verhindern.
Wartungsaufwand ergibt sich jedoch auch vielfach aus anderen Faktoren. Hierzu gehören neue Schnittstellen zu anderen Programmen, eine geänderte Organisation oder modifizierte externe Richtlinien (Gesetzgebung), neue Aufgaben und Ziele (Marketing) sowie veränderte Systembedingungen (Hardware, Betriebssysteme etc.). Eine Reihe von Werkzeugen kann behilflich sein, die dadurch entstehenden Pflegekosten zu minimieren. Der Aufwand für die Wartung der Anwendersoftware liegt in unserem Unternehmen derzeit bei etwa 30 Prozent. Diesen Prozentsatz wollen wir durch die verstärkte Verwendung von Standardsoftware noch weiter senken. Dabei werden wir vor allem Lösungen kaufen, die nur geringfügige Korrekturen erfordern, und sind auch bereit, unsere interne Organisation einer integrierten Standardsoftware anzupassen. Das Paket sollte dabei aber leben, das heißt, weiterentwickelt
---------------------------------------------------------------------------------------------------------------------
Michael Warnck
DV-Leiter, Allibert GmbH, Frankfurt
---------------------------------------------------------------------------------------------------------------------
werden.
Applikationen, für die es keine adäquaten Standardpakete gibt, werden wir wie bisher auch in Eigenregie entwickeln. Dafür stehen mittlerweile Möglichkeiten und Tools zur Verfügung, die den späteren Aufwand im Rahmen halten. Dazu gehören List- und Maskengeneratoren, die es ermöglichen, sehr schnell auf unterschiedliche Anforderungen zu reagieren. Wir gestalten unsere Programme so, daß wir über Tabellen oder Parameter Modifikationsmöglichkeiten im Vorfeld schaffen, damit das Programm universell eingesetzt werden kann. Damit lassen sich leichter eventuelle Wunsche der Mitarbeiter realisieren und wir stehen nicht jedesmal vor der Entscheidung das Programm zu ändern oder neu zu entwickeln.
Ein weiterer Punkt ist normierte, strukturierte oder standardisierte Programmierung. Wir setzen nicht strukturierte Programmierung im eigentlichen Sinn ein. Dies hängt mit der Ausbildung und Routine unserer vier Anwendungsentwickler zusammen, die sicher Schwierigkeiten hätten, strukturierte Programmierung (zum Beispiel Jackson-Methode) neu zu erlernen und konsequent zu praktizieren. Wir haben eigene Programmstandards geschaffen und achten darauf, daß die Programme modular aufgebaut sind. Das Programm muß so dokumentiert sein, daß es den Anwendungsentwickler wie auch einen Stellvertreter in die Lage versetzt, jederzeit schnell in die Programmlogik einzusteigen und Änderungen durchzuführen. Außerdem arbeiten wir an einem DV-gestützten Verfahren zur Dokumentation der Verwendung von Dateien, Feldern, Schlüsseln etc.
Des weiteren müssen Anforderungen von den Fachabteilungen überprüft werden. Am Anfang steht eine Kosten/Nutzen-Analyse, die wir gemeinsam mit den Fachabteilungen erstellen. Es ist jedoch in den meisten Fällen sehr schwer, den Wunsch auf Heller und Pfennig zu bewerten. Unser Ansatz ist daher oft die Frage: Was ist die Konsequenz, wenn wir die Anforderung nicht realisieren? Damit lassen sich
Notwendigkeiten erkennen. Als nächstes stellt sich die Frage: Lohnt es sich, ein bestehendes Programm zu ändern oder ist es sinnvoller, es gleich neu zu schreiben?
Auch sollte geprüft werden, ob sich der Aufwand für Änderungen durch den Einsatz von s minimieren läßt. Das ist jedoch nur bedingt realisierbar da dem Unternehmen nicht damit gedient ist, wenn die Kosten auf die Fachabteilungen verlagert werden.
Schließlich ist es ratsam, sich nicht auf ein Abenteuer mit der Systemsoftware und DB-Systemen einzulassen. Jede Änderung größerer Art oder jeder Umstieg von einem Betriebssystem oder DB-System auf ein anderes bedingt wiederum die Pflege der Anwendersoftware. Das kann sehr leicht ausufern.
Die Kosten für die Pflege von Anwendersoftware können nur dann reduziert werden, wenn man aus den Fehlern der Vergangenheit in der EDV lernt. Das gilt generell für alle Anwender, nicht nur für unser Haus.
Es existieren drei Probleme, die die Kosten für die Pflege der Anwendersoftware in die Höhe treiben. Das erste ist ein Transparenzproblem, das bedeutet unzureichende Dokumentation und unzureichende Transparenz bei der Projektabwicklung. Dann gibt es das Skukturierungsproblem. Auch wir haben sehr viele "Spaghettiprogramme", die im Laufe der Jahre durch Direktverdrahtung zwischen Daten und Programmen eine komplexe Logik beinhalten. Das Strukturierungsproblem ergibt sich auch dann, wenn alte Datenstukturen zu lange beibehalten werden. Der dritte Punkt ist das Produktivitätsproblem der Entwickler. Durch steigende Komplexität der gesamten Systeme und die Beibehaltung alter Software wird immer mehr personenbezogenes Know-how notwendig. Das hindert uns daran, bei Anforderungen schnell zu reagieren. Die Wartungsgruppe beschäftigt sich viel zu sehr mit dem "Wie" als mit dem "Was".
Diese Probleme haben wir erkannt, und unser Ziel ist es, sie mittelfristig aus dem Weg zu räumen. Wir haben zu diesem Zweck fünf Maßnahmen ergriffen. Zum einen werden wir eine optimale
---------------------------------------------------------------------------------------------------------------------
Bruno Schmidt
Bereichsleiter DV/Org., Metro International AG, Baar/Zug, Schweiz
---------------------------------------------------------------------------------------------------------------------
Datenbasis als Grundlage für ein zukünftiges zentrales Datenmanagement schaffen. Auf der Basis eines Unternehmens-Datenmodells sollen künftige Applikationen im Laufe der Jahre anwendungsneutral weiterentwickelt und angepaßt werden können. Hier möchten wir zwischen drei verschiedenen Arten von Datenbasen unterscheiden:
- eine operationale Datenbasis für schnelle Batch-orientierte Verarbeitungen,
- eine teilrelationale, transaktionsorientierte Datenbasis die einen schnellen Zugriff gewährleistet, und
- eine relationale Datenbasis für die individuelle DV, die dem Anwender für Ad-hoc-Abfragen zur Verfügung steht.
Im Rahmen der zweiten Maßnahme haben wir ein modulares Softwareschichtenmodell unter Verwendung des Generators "Delta" entwickelt. Nach dieser Software-Architektur sind bereits erste Anwendungen erstellt worden. Ziel ist es, eine Unabhängigkeit von Betriebssystemen, TP-Monitoren und Datenhaltungssystemen zu schaffen. In der Vergangenheit haben wir gelernt, daß die genannten Systeme ausgetauscht oder Anwendungssoftware portiert werden mußte. Ein weiterer Punkt innerhalb dieses Software-Schichten-Modells ist ein Customizer-Konzept, das es erlaubt, dezentral und ohne Eingriffe in die Software parametergesteuert Modifikationen im Ablauf vorzunehmen.
Die dritte Maßnahme sieht vor, die Anwender verstärkt in die Entwicklung von Systemen einzubeziehen. Neben der Pflichtenheft-Erstellung durch den Fachbereich wollen wir durch verstärkte Tool-Integration in der Vorphase der Entwicklung (Prototyping, grafikorientierte Konzept- und Dokumentationserstellung) die Software-Entwicklung gegenüber dem Anwender transparenter machen.
Des weiteren möchten wir ein Software-Engineering-Tool installieren, das projektbegleitend Dokumentationen erstellt und dem Entwickler den Weg, die Methoden und die Meilensteine vorgibt, nach denen während der Softwareentwicklung vorgegangen werden muß.
Die fünfte Maßnahme wird sein, daß wir auf der Grundlage der Datenbasis für individuelle Datenverarbeitung Ad-hoc-Anforderungen im Bereich der Auswertungen (also keine Standard-Auswertungen) den Benutzer selbständig realisieren lassen, entweder durch das Herunterladen auf den PC oder durch die Nutzung eines IDV-Tools im Host.
Damit hoffen wir, die steigenden Kosten für die Wartung von Anwendungssystemen einzudämmen. Vor allem wollen wir bei Neuentwicklungen diese Maßnahmen greifen lassen, damit wir in der Zukunft auf Veränderungen und Anforderungen schneller reagieren können.