Die Planung der Anwendungssysteme erfolgt in engem Zusammenhang mit dem Unternehmensmodell. Besonders sorgfältig sollten dabei die Schnittstellen zwischen den einzelnen Systemen betrachtet werden, um nachträgliche Anpassungen zu vermeiden.

Grundlage für die Planung der Anwendungssysteme ist das erarbeitete Unternehmensmodell als grobe Beschreibung des Unternehmens. Die Planung bezieht sich auf zwei Aspekte: Zunächst werden überschaubare Einheiten, die Anwendungssysteme, gebildet. Jedes dieser Systeme wird im Rahmen eines oder mehrerer Projekte weiter detailliert und zumindest teilweise in DV-Systemen realisiert.

Zum zweiten erhalten die Anwendungssysteme Prioritäten bezüglich ihrer Realisierung Die Grundlage dafür bilden die betrieblichen Ziele aus dem Unternehmensmodell. Für die exakte zeitliche Planung der einzelnen Projekte sind noch weitere Faktoren (zum Beispiel Personalressourcen oder Budget) zu berücksichtigen. Das Unternehmensmodell liefert den an der Unternehmensstrategie orientierten Rahmen, der durch die Berücksichtigung der restlichen Faktoren konkret ausgefüllt werden muß.

Die Bildung der Anwendungssysteme erfolgt mit der Zielsetzung, für die Realisierung von DV-Systemen überschaubare und damit planbare Einheiten zur Verfügung zu haben. Prinzipien, die aus der Programmierung bekannt sind, finden auch bei der Bildung von Subsystemen des Unternehmens Anwendung. In erster Linie sind das die Prinzipien der Modularisierung sowie der schmalen Datenkopplung. Während sich aus dem ersten Prinzip die Notwendigkeit zur Bildung von Subsystemen ergibt, sind aus dem zweiten Prinzip Anforderungen an die Qualität der Subsysteme herzuleiten.

Das Prinzip der schmalen Datenkopplung stellt die Qualität der Anwendungssysteme (als Subsysteme des Unternehmensmodells) sicher. Nach diesem Prinzip werden funktionale Einheiten zu Systemen zusammengefaßt, die intern stark miteinander kommunizieren, nach außen aber nur eine sehr geringe Kommunikation aufweisen.

Die Dichte der kommunikativen Verzahnung aufgrund der gemeinsam verwendeten Objekttypen aus dem Informationsmodell stellt das Maß für die Kommunikationsbreite zwischen den Funktionen dar. Die entsprechenden Angaben sind in der Kommunikationsstruktur abgebildet und müssen für die Bildung der Subsysteme nur

entsprechend konstruktiv ausgewertet werden. Als Ergebnis dieses Konstruktionsprozesses entstehen Anwendungssysteme, die intern einen dichten Informationsaustausch aufweisen nach außen aber nur über schmale Schnittstellen mit anderen Systemen verbunden sind.

Schmale Schnittstellen, wie sie zur Bildung der Subsysteme herangezogen werden, führen zu einer hohen Lokalität der einzelnen Systeme. Änderungen eines Systems haben dann nur eine sehr geringe Auswirkung auf benachbarte Systeme. Mithin weisen die Systeme eine hohe Immunität in bezug auf ihre Umwelt und deren Veränderung auf.

Aus den angewandten Prinzipien zur Bildung von Anwendungssystemen ist ersichtlich daß die Bildung der Subsysteme in erster Linie als Hilfsmittel für die DV-Abteilung gedacht ist. Ziel ist es, stabile Projektgrundlagen zu haben und die einzelnen Projekte weitgehend als lokale Einheiten zu betrachten. Die Interdependenzen werden also minimiert.

Für die organisatorische Gestaltung des Unternehmens spielen neben der Breite des Informationsaustauschs auch andere Größen eine erhebliche Rolle. Dazu gehören die Kommunikationsintensität (Anzahl Kontakte pro definierter Zeiteinheit) und die Ähnlichkeit der betrieblichen Aufgaben.

Die Bildung von Anwendungssystemen berücksichtigt explizit die Schnittstellen zwischen den Systemen. Das ist ein Aspekt, der in der Vergangenheit bei der Durchführung von DV-Projekten weitgehend vernachlässigt wurde. Als Konsequenz entstanden in den DV-Bereichen der Unternehmen viele Insellösungen, deren Integration mangelhaft war.

Ein großer Teil der personellen Ressourcen in den DV-Abteilungen war daher mit der nachträglichen Anpassung und Reparatur der Schnittstellen zwischen den Anwendungen beschäftigt - ein Aufwand, der bei entsprechender ex-ante-Betrachtung der Schnittstellen hätte vermieden werden können. Die Erstellung des Unternehmensmodells und der sich daran anschließende Planungsprozeß beinhaltet aber gerade den ausdrücklichen Einbezug der Systemschnittstellen und trägt somit erheblich zur Reduzierung des Wartungsaufwands von DV-Systemen bei.

Die Unternehmensstrategie bestimmt die Prioritäten für die DV-technische Umsetzung der fachlichen Anforderungen. Die Unternehmensziele bringen die Strategie zum Ausdruck. Im betrieblichen Modell wird der Beitrag, den die einzelnen Funktionen zur Zielerreichung leisten, als Gewichtungsfaktor dokumentiert. Ebenso sind dort die betrieblichen Ziele in ihrer Bedeutung für das Unternehmen gewichtet.

Aus beiden Faktoren, der Bedeutung der einzelnen Ziele und dem Zielerfüllungsbeitrag der Funktionen, wird der betriebliche Nutzwert der Anwendungssysteme errechnet. Je höher der Nutzwert, umso bedeutsamer ist das entsprechende Anwendungssystem aus Unternehmenssicht einzuschätzen.

Die Vergabe von Prioritäten und damit die zeitabhängige Planung und Bereitstellung von DV-gestützten Informationssystemen ist überhaupt nur aus der endlichen Verfügbarkeit der Ressourcen zu erklären, die zur Entwicklung der Systeme eingesetzt werden. Einen dieser Engpaßfaktoren stellen die Mitarbeiter der DV-Abteilung dar. Gute Mitarbeiter sind Grundvoraussetzungen dafür, daß die terminlichen Planungen in bezug auf den Zeitraum der Systementwicklung nicht zu weit in die Zukunft reichen, wodurch sich der Nutzen für die Fachabteilungen erst in vielen Jahren einstellen würde.

Erste Systeme zur Datenerzeugung

Bevor ein endgültiger Realisierungsplan aufgestellt werden kann, muß neben den Unternehmenszielen noch ein zweiter Faktor beachtet werden. Hierbei handelt es sich um die natürliche Abhängigkeit zwischen den Anwendungssystemen. Dieser Sachverhalt ist von Interesse, sofern mehrere Systeme auf gemeinsame Datenbereiche zugreifen.

Bei obiektorientierter Betrachtung dieser Datenbereiche sollten die Systeme möglichst in der Reihenfolge realisiert werden, die dem Lebenszyklus der Daten entspricht. Zunächst sind also die Systeme zu realisieren, die primär zur Datenerzeugung beitragen, während erst zu einem späteren Zeitpunkt die Systeme anzugehen sind, die in erster Linie Anforderungen des Daten-Bedarfs enthalten. Nach ergänzender Betrachtung der natürlichen Abhängigkeiten zischen den Anwendungssystemen kann nun ein für das Unternehmen optimaler Realisierungsplan erstellt werden.

Die Notwendigkeit, zur Analyse und Beschreibung komplexer Systeme eine Werkzeugunterstützung verfügbar zu haben, ist für jeden evident, der bei der

Erarbeitung entsprechender Modelle und Planungsvorhaben beteiligt war oder derzeit daran arbeitet. Der Einsatz von Werkzeugen ist für die Entwicklung und Pflege derartiger Modelle zwingend geboten.

Die Kriterien, denen solche Werkzeuge genügen müssen, hat Helmut Balzert in dem 1989 von ihm herausgegebenen Band , "CASE: Systeme und Werkzeuge" auf den Seiten 87 bis 98 beschrieben; sie lassen sich als Basisanforderungen an den Verbund von Werkzeugen zur Entwicklung von Software bezeichnen. In diesem Zusammenhang ist auch der Begriff des "Software-Engineering-Environment-System" geläufig.

Diese Anforderungen lauten:

- Alle Stufen der Software-Entwicklung sollten durch Werkzeuge unterstützt werden. Das gilt auch für die Planungsphase der Systeme.

- Der Übergang von einer Stufe zur nächsten darf nicht zu Brüchen führen. Die Arbeitsergebnisse müssen stufenübergreifend zur Weiterverarbeitung verfügbar sein. Alle Tätigkeiten einer Stufe sollten vollständig durch den Einsatz von Werkzeugen unterstützt werden.

- Verschiedene Werkzeuge müssen integrierbar sein. Ein Werkzeug, das den gesamten Lebenszyklus der Software-Erstellung abdeckt, gibt es nicht.

- Die Handhabung der Werkzeuge soll leicht erlernt werden können. Neben der einfachen Bedienbarkeit des einzelnen Werkzeugs bedeutet das auch daß im Rahmen eines komplexen Werkzeugverbunds die Einheitlichkeit der Bedienung gewahrt bleibt.

- Die Werkzeuge sollten die Arbeit eines Teams unterstützen. Auch wenn mehrere Mitarbeiter an einem Projekt arbeiten, muß die Integrität der Ergebnisse gewahrt bleiben. Ebenso ist die projektübergreifende Integrität der Arbeitsergebnisse zu fordern.

- Schließlich ist es notwendig, Werkzeuge möglichst maschinenunabhängig zu gestalten, denn in der Regel leben heute Softwareprodukte länger als Hardwareprodukte.

Eines der oben genannten Kriterien, nämlich das der vollständigen Werkzeugunterstützung für die Tätigkeiten einer Entwurfsstufe, soll im Hinblick auf die strategische Informationsplanung näher betrachtet werden. Das Kriterium der Vollständigkeit ist dann erfüllt, wenn alle notwendigen Aktivitäten über alle Phasen der an der Software-Erstellung beteiligten Personen unterstützt werden. Anhand der Tätigkeiten, die zur Erstellung des Unternehmensmodells und der anschließenden Bildung und zeitlichen Priorisierung der Anwendungssysteme durchzuführen sind soll die Überprüfung der Vollständigkeit analysiert werden.

Jede dieser Tätigkeiten liefert Ergebnisse, die dokumentiert werden müssen. So liefert die Aufgabe "Informationsstruktur erstellen" eine Beschreibung der Objekttypen und der zwischen diesen Objekttypen bestehenden Beziehungstypen. Grundlage für die Dokumentation der Objekt- und Beziehungstypen ist die Metastruktur; sie gibt vor, wie das Informationsmodell dokumentiert werden soll.

Gleiches gilt für die anderen Bestandteile des Unternehmensmodells, aber auch für die Planungsaspekte der Anwendungen und Daten. Die Metastruktur liefert die Ergebnistypen, ihre Attributierungen sowie die zwischen den Objekttypen der Metastruktur bestehenden Beziehungen. So würde beispielsweise der Objekttyp "Partner" aus dem Informationsmodell im Metaobjekt "Objekttyp" dokumentiert werden.

Metastrukturen sind das wesentliche Hilfsmittel, um die Vollständigkeit der Werkzeugunterstützung - nicht nur für den Bereich der strategischen Informationsplanung - zu überprüfen. Allerdings ist an dieser Stelle auch kritisch anzumerken, daß die Dokumentationsstruktur der Entwurfswerkzeuge von den Herstellern häufig nicht offengelegt wird.

Überprüfung in vier Schritten

Soll die Planung der Daten und Anwendungssysteme in der besprochenen Art und Weise vorgenommen werden, so wären Software-Entwicklungssysteme daraufhin zu überprüfen, inwieweit die ihnen zugrundeliegenden Metastrukturen im Einklang mit der geforderten Metastruktur stehen. Pragmatisch bietet sich zur Überprüfung der Vollständigkeit ein Vorgehen an, das aus den folgenden Schritten besteht:

1) Formulierung der eigenen fachlichen Anforderungen,

2) Unterscheidung zwischen unabdingbaren und eher nebensächlichen Anforderungen,

3) Übertragung der Anforderungen in eine Metastruktur und

4) Abgleich der erarbeiteten Metastruktur mit der des Software-Entwicklungssystems.

Weist die Metastruktur des Entwicklungssystems Defizite in einem Bereich auf, der als wesentlich erachtet wird, so ist das untersuchte System in bezug auf das Kriterium der Vollständigkeit nicht in vollem Umfang zur Abdeckung der Anforderungen geeignet.

Selbstverständlich sollte nicht anhand eines einzelnen Kriteriums die Ablehnung oder Befürwortung eines Software-Entwicklungssystems vorgenommen werden.

Alle Kritierien müssen gemeinsam in bezug auf das betrachtete Entwicklungssystem untersucht werden.

Eine standardmäßige Gewichtung der Faktoren ist dabei nicht zwingend. Von Unternehmen zu Unternehmen können die Bewertungen unterschiedlich sein.

So wird in einem Fall der vollständigen Abbildung aller Ergebnisanforderungen hohe Bedeutung zugesprochen, während in einem anderen Unternehmen aufgrund der dort bestehenden dezentralen Entwicklungsumgebung dem Kriterium der Teamfähigkeit die höchste Priorität zukommt. +