Die Harmonisierung der Europäischen Gemeinschaft verlangt nach Harmonisierung auch der Geschäftspraktiken. Offene Grenzen, gemeinsame Produktspezifikationen und eine einheitliche Steuerpolitik, so Klaus Röber*, bieten die Chance der organisatorischen Straffung von europaweiten Unternehmen.

Nachdem das Team den Strategieplan erstellt und das Go-Ahead des Managements für die zweite Phase des Information Engineering - Geschäftsbereichsanalyse und -modellierung erhalten hat, ergeben sich neue, veränderte Probleme für die Arbeit. Die alten Probleme bleiben aber erhalten, sie werden sogar teilweise noch schwieriger zu lösen. Beispielsweise werden die Sprachprobleme in der Regel größer, wenn die Abstimmungsgespräche bei größerer Detaillierung aus der Managementebene auf die Ebene der Fachbereichsmitarbeiter verlegt werden müssen.

Zu analysieren ist die Informationsarchitektur

In der zweiten Phase des Information Engineering geht es darum, die in der ersten Phase definierten Geschäftsgebiete und natürlichen Geschäftssysteme näher zu analysieren sowie die Komponenten der technischen Architektur auszuwählen und die Information-Management-Organisation zu konkretisieren.

Interessant, weil schwierig, ist hier insbesondere die Analyse der Informationsarchitektur. Konkret geht es darum, das in der ersten Phase erstellte unternehmensweite Datenmodell - genauer das Entity-Relationship-Modell und die Funktionenhierarchie - zu verfeinern. Das geschieht beim Datenmodell durch Hinzufügen von Attributen zur näheren Beschreibung der Informationsobjekte und Normalisierung. Darüber hinaus wird der Funktionenbaum weiter zerlegt, bis man auf der Stufe der Elementarprozesse angelangt ist, wo eine weitere Zerlegung aus Geschäftssicht nicht mehr sinnvoll erscheint.

Ein oder zwei Bereiche werden herausgegriffen

Auf der untersten Stufe muß man dann Prozesse und Daten miteinander in Verbindung setzen, um die Prozeßaktivitäten auf die Daten (Create, Read, Update, Delete) sowie die Reihenfolge der Ausführung der Prozesse abzubilden.

Am Ende der Business-Area-Analysis steht die Definition von logischen Geschäftssystemen. "Logisch" heißen sie, weil sie zwar die Geschäftslogik präzise beschreiben, bisher aber noch keine Kompromisse hinsichtlich der zu ihrer Umsetzung in physische Systeme einzusetzenden Technik gemacht werden mußten. Dies ist den folgenden Phasen des Information Engineering vorbehalten.

Nun wird man in der Regel nicht ein ganzes Unternehmen auf einmal durchanalysieren. Vielmehr wird man einen oder zwei Bereiche herausgreifen, wo der Bedarf des Unternehmens für bessere EDV-Unterstützung am größten scheint und diese so weit analysieren, wie dies wirtschaftlich gerechtfertigt werden kann. Wenn für ein Teilgebiet keine neuen Systeme erstellt werden sollen oder wenn die vorhandenen ausreichen, wird die Analyse an dieser Stelle abgebrochen.

Ziel des hier vorgestellten Projekts ist, neue einheitliche Systeme zu schaffen - und in einer möglichst kurzen Zeit. Dies läßt sich nur erreichen, wenn parallel mehrere Geschäftsgebiete in Angriff genommen werden. Der besseren Akzeptanz wegen wird man diese Untersuchungen nicht mehr alle in der Zentrale durchführen, sondern die Verantwortung in die Hände der leistungsfähigsten Tochterunternehmen legen. Beispielsweise könnten wir vier internationale Teams einsetzen, um die wichtigsten Geschäftsgebiete zu analysieren, etwa ein Logistikteam in Frankreich, ein Marketingteam in Dänemark, ein Personalteam in England und ein Produktionsteam in Deutschland.

Das zentrale Projektteam, das die strategische Planung durchgeführt hat, wird jetzt aber nicht überflüssig. Seine Aufgaben verändern sich jedoch. Wesentlichste Aufgabe der zentralen Koordination ist nun die Pflege der globalen Informationsarchitektur. Das zentrale Team hat also dafür zu sorgen, daß die von den Geschäftsgebietsteams erstellten Analyseergebnisse an den Schnittstellen zusammenpassen, um dem Ziel der integrierten "common systems" näher zu kommen.

Es gilt, eine große Zahl von Analyse-Ergebnissen miteinander zu integrieren. Sinnvollerweise geschieht das in nicht zu großen zeitlichen Abständen, da sonst die Integration sehr arbeitsaufwendig werden kann. Daneben stellt sich für das Team die Aufgabe der Autorisierung.

Bisher lag alles in einer Hand. Jetzt arbeiten verschiedene Teams zum Teil an den gleichen Objekten (das gilt insbesondere für die Datenseite, aber auch für die Prozesse, denn wir wollen weiterhin die Chance haben, mehrfach verwendbare Elementarprozesse zu identifizieren). Es muß also für jedes Objekt beziehungsweise für eine Gruppe von Objekten festgelegt werden, wer dafür verantwortlich ist, und wer deshalb Definitionen erstellen/verändern darf und wer nicht.

Konkret heißt das, wir müssen unsere Objekte klassifizieren in Unternehmensobjekte, die nur mit Zustimmung der Zentrale geändert werden dürfen, Fachbereichsobjekte, die der Zustimmung des Fachbereichs bedürfen und lokale Objekte, die aus Gesamtunternehmenssicht untergeordnete Bedeutung haben. Wir werden also einige internationale Gremien einrichten müssen, die diese Autorisierungen vergeben und Veränderungen von Objektdefinitionen genehmigen.

Aufgabe des zentralen Teams ist dann, darüber zu wachen, daß die Regeln der Autorisierung auch eingehalten werden. Hier kann uns die CASE-Technologie helfen. Allerdings wird die Auswahl der möglichen Tools, die mit diesen Problemen fertig werden können, jetzt schon sehr eng.

Analysedaten reizen Rechnerkapazität aus

Was wir benötigen, ist ein leistungsfähiges zentrales Dictionary (auch Enzyklopädie genannt). Dieses Dictionary muß es uns ermöglichen, Teilmodelle zu definieren, die einzelnen Objekte mit ihrer Autorisierung zu versehen und die periodische Konsolidierung der Teilmodelle in dem Globalmodell durchzufahren. Aber Achtung: Alles, was das Tool nicht kann, müssen wir auf andere Weise organisatorisch sicherstellen. Da dies sehr arbeitsaufwendig ist, muß der Auswahl eines geeigneten Tools besondere Aufmerksamkeit gewidmet werden.

An diesem Punkt des Projektes wird die Menge der Analysedaten sehr schnell wachsen und es dauert nicht lange, bis jedes der Teilmodelle auf eine Größe von mehreren MB angeschwollen ist. PC-basierte Tools geraten hier ans Ende ihrer Leistungsfähigkeit. Aber auch der Einsatz eines Mainframe garantiert noch keineswegs, daß etwa Konsolidierungen schnell genug durchgeführt werden können ( länger als ein bis zwei Stunden sollte es nicht dauern). Praktisch wird jede Konsolidierung mindestens zweimal durchgeführt werden müssen. Das erste Mal, um Inkonsistenzen aufzudecken, und das zweite Mal, um die veränderten Modelle endgültig miteinander abzugleichen.

Je nach Größe der definierten Geschäftsgebiete wird die Analyse der zweiten Phase etwa sechs bis zwölf Monate dauern und zwischen zwei und sechs Mitarbeiter pro Team beschäftigen. Am Ende haben wir eine Reihe von logischen Systemdefinitionen vorliegen, aus der wir die Kandidaten für Pilotprojekte zur Implementierung der einheitlichen Systeme auswählen können.

Während wir es auf der strategischen Ebene im wesentlichen noch mit einem Modell zu tun hatten, müssen wir auf der detaillierten Ebene damit fertig werden, daß wir verschiedene Versionen eines Modells für das gleiche Gebiet vorhalten müssen, denn auch bei Angleichung der Geschäftspraktiken werden Unterschiede bleiben. Man tut allerdings gut daran, zu versuchen, die Definition der Objekte so einheitlich wie möglich zu halten, sonst gerät man schnell in Schwierigkeiten, da auch die besten CASE-Tools hier nur beschränkte Hilfestellung leisten.

In der nächsten Phase des Information Engineerings geht es darum, die logischen Systemdefinitionen in lauffähige EDV-Systeme umzusetzen. Wir betrachten hier die Schritte Fachlicher Systementwurf, Technischer Systementwurf und Konstruktion gemeinsam.

Bevor wir uns die technische Realisierung überlegen können, betrachten wir die geschäftlichen Anforderungen, die wir an die Implementierung und damit an die zu nutzenden Werkzeuge stellen müssen.

Minimale Anforderungen an europaweite Systeme sind eine nationalsprachliche Anwenderschnittstelle, Rücksichtnahme auf nationale Eigenheiten, auf unterschiedliche Größenverhältnisse und Mengengerüste der Tochterunternehmen, auf lokal implementierte unterschiedliche technische Umgebungen, deren Änderung kostspielig sein kann sowie die Einbindung der neuen Systeme in unterschiedliche lokale Ist-Anwendungssystemlandschaften. Um es salopp zu sagen: Wir brauchen Systeme, die so gleich wie möglich und so verschieden wie notwendig sind.

Wie bleiben einheitliche Systeme einheitlich? Die Aufgabe, eine einheitliche Systemlandschaft zu schaffen, ist mit der Implementierung der Systeme nicht abgeschlossen. Überläßt man die einzelnen Töchter sich selbst, werden die Systeme sich schnell auseinander entwickeln. Außerdem dürfte dann nur eine relativ geringe Reduktion der Maintenance-Kosten eintreten, da jedes System unabhängig gewartet werden muß.

Ein zentrales Entwicklungs- und Maintenance-Zentrum hat andererseits den erheblichen Nachteil der Anwenderferne und dürfte auf Akzeptanzprobleme in der Organisation stoßen. Auch die mögliche Alternative, mehrere lokale Entwicklungszentren jeweils mit der Pflege einer bestimmten Systemgruppe zu betreuen, ist nicht attraktiv, da Probleme an den Schnittstellen auftreten werden. Außerdem setzt eine wie auch immer zentralisierte oder teilzentralisierte Systembetreuung das Vorhandensein möglichst einheitlicher Hardware und Systemsoftware in den Tochterunternehmen voraus. Ansonsten kann der Aufwand, mehrere Versionen desselben Systems zu pflegen und unterschiedliche Entwicklungsumgebungen vorhalten zu müssen, schnell auf erhebliche Größenordnungen anwachsen.

Einige Probleme werden auf Kosten anderer gelöst

Unser Projekt muß zudem sicherstellen, daß das Arbeiten in den lokalen Zentren für gutes DV-Personal weiterhin attraktiv bleibt. Einen optimalen Nutzen aus der DV wird der Endanwender nur dann ziehen können, wenn er qualifizierte Beratung und Betreuung vor Ort hat.

Und last but not least, müssen wir auch an die Produktivität denken. Es wäre doch schade, wenn wir jetzt, nachdem wir so viele detaillierte Analyseergebnisse in einem CASE-Tool dokumentiert haben, wieder mit dem Programmieren anfangen müßten.

Für alle diese Probleme gibt es Lösungen oder zumindest Teillösungen. Alle Teillösungen sind aber unbefriedigend, da sie immer nur einige der Probleme auf Kosten anderer lösen.

Betrachten wir beispielsweise den Einsatz von Standardsoftware. Um Kompatibilitätsprobleme zu vermeiden, sollten wir möglichst nur Programme von einem oder wenigen Herstellern einsetzen. Außerdem sollte diese Software auf verschiedenen Rechnersystemen einsatzfähig ein und in den wichtigsten europäischen Nationalsprachen vorliegen. Damit engt sich der Kreis der möglichen Anbieter erheblich ein.

Ein weiterer Faktor, den es zu beachten gilt, sind die Kosten. Lizenzgebühren für Software gelten in der Regel pro Rechnerinstallation. Das kann - auch bei entsprechenden Rabatten - schnell sehr teuer werden, wenn wir aus Gründen der Anwendernähe nicht auf lokale DV-Zentren verzichten wollen.

Auch senkt der Einsatz von Standardsoftware unsere Entwicklungskosten nur marginal. Da wir nicht alle erforderlichen Anwendungssysteme von Softwareherstellern bekommen können, müssen wir Entwicklungs-Know-how und Entwicklungskapazität weiterhin vorhalten.

Ich möchte nicht alle möglichen Lösungsvarianten im Detail diskutieren, sondern mich darauf beschränken, eine ideale Lösung vorzustellen, die alle Probleme in optimaler Weise löst. Ihr einziger Nachteil ist, daß sie heute noch nicht vollständig technisch realisierbar ist.

In der Abbildung auf Seite 14 ist der Kern dieser Lösung dargestellt. Voraussetzung ist der Einsatz eines integrierten CASE-Tools, das in der Lage ist, aus Spezifikationen lauffähige Anwendungssysteme herzustellen. Diese Anwendungssysteme müssen für verschiedene Zielumgebungen erzeugbar sein (Groß- und Kleinrechnerumgebungen).

Außerdem muß es möglich sein, in der zentralen Enzyklopädie verschiedene Varianten einzelner Objekte vorzuhalten, etwa lokal entwickelte Bildschirmmasken in verschiedenen Sprachen, die bei der Generierung jeweils landestypisch zusammengesetzt werden, um Systeme zu erzeugen, die möglichst kompakt sind und nicht unter dem Overhead von Parametrisierungen leiden.

In einer solchen Entwicklungsumgebung lassen sich alle Anforderungen erfüllen:

- die zentrale Entwicklung, die über die unternehmensweit einheitlichen Teile der Architekturmodelle wacht;

- die lokalen Entwicklungsgruppen, die die landestypischen Systemteile definieren;

- generierte statt programmierter Systeme, die immer in gleicher Qualität erzeugt werden können;

- Systeme, die für einen IBM-Großrechner, für einen DEC-Rechner oder für einen PC erzeugt werden können und die die oft schmerzlichen Folgen des Systemsoftwarewechsels dem Hersteller des Generators aufbürden;

- Maintenance, die nicht an Programmen, sondern an logischen Definitionen in der Enzyklopädie durchgeführt wird und damit zu einem großen Teil vom Anwender selbst durchgeführt werden kann;

- Entwicklungszentren, die, obwohl sie relativ klein sein werden, auch für ambitionierte DVler attraktiv sind, da sie modernste Technologie einsetzen;

- signifikant reduzierte Kosten (trotz der nicht unwesentlichen Kosten für Soft- und Hardware des CASE-Tools).

Derzeit verfügbare Tools sind noch nicht soweit

Leider kann auch das beste derzeit am Markt verfügbare CASE-Tool diese Anforderungen noch nicht vollständig erfüllen. Es fehlt zum Beispiel die Möglichkeit, unterschiedliche Versionen des gleichen Objekts zu führen.

Die Auswahl der Zielumgebungen ist noch zu beschränkt und die Verwaltung von mehrfach gestaffelten Teilmodellen in der Enzyklopädie wird noch nicht ausreichend unterstützt. Außerdem können Batch-Systeme noch nicht vollständig generiert werden. Entwicklungspläne von CASE-Herstellern zeigen aber, daß an der Lösung dieser Probleme gearbeitet wird. In spätestens zwei Jahren dürfte die Situation ganz anders sein.

Mit dem besten der verfügbaren CASE-Tools jedoch lassen sich aber auch heute schon große Teile des oben beschriebenen Konzepts realisieren. Da für Planung und Analyse sowieso ein Vorlauf von knapp zwei Jahren benötigt wird, besteht für Unternehmen, die eine europäische Vision haben, kein Grund, noch länger zu warten.