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.

31.03.1989 - 

Immer mehr europaweite Projekte (Teil 1):

1992 - Die Vision für europaweite Unternehmen

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.

Am Anfang der meisten großen Leistungen steht eine Vision. Heute heißt sie 1992 - das Jahr der europäischen Harmonisierung. Noch halten sich manche abseits, wie etwa Margaret Thatcher, die in insularer Engstirnigkeit auf die unabhängigen Rechte eines britischen Nationalstaates pocht.

Die Mehrheit der Unternehmen - soweit sie sich mit diesem Thema bereits intensiv befaßt hat - begreift l992 dagegen als eine große Chance.

Offene Grenzen, einheitliche Produktspezifikationen und eine einheitliche Steuerpolitik müßten in der EG eine Stimulanz für einen Wachstumsschuh nach 1992 sein. Economies of Scale und Economies of Scope, die Reduzierung der Bürokratie und die Möglichkeit, sich dem Wettbewerb innerhalb und außerhalb Europas von einer breiteren Basis aus stellen zu können, bieten ein ideales Betätigungsfeld für die Entrepreneure, die systematischen Innovatoren. Doch dafür braucht man innovative Unternehmen und mutige Manager.

Einen solchen couragierten Vorsitzenden hat das Unternehmen, das mir die Idee zu diesem Artikel gab. Publicity wünscht es jedoch im jetzigen frühen Stadium des Projekts noch nicht. Nennen wir es deshalb United Products Ltd.

United Products Ltd. ist schon ein echt altes Unternehmen. Es treibt Handel in allen Ländern der EG und produziert für verschiedene Branchen. In der Vergangenheit wurde das Unternehmen von London aus geführt - zunächst eher im Laissez-faire-Stil. Inzwischen konnte jedoch ein steigender Einfluß der Zentrale Auf die Tochterunternehmen beobachtet werden.

Als das Management sich mit der angestrebten Harmonisierung der EG zu beschäftigen begann, begriff es bald die Chance, die sich hier auftat - aus einer Gruppe von mehr oder weniger unabhängigen Gesellschaften mit lokalem Management ein europäisches Unternehmen zu formen. Von dieser vergrößerten Basis aus glaubt das Unternehmen, seine Rolle am Weltmarkt und in der Steuerung der außereuropäischen Tochtergesellschaften mit größerem Nachdruck und mit größeren Erfolgschancen wahrnehmen zu können. Erster sichtbarer Ausdruck dieser Neuorientierung war eine Reorganisation, de mehr Kompetenzen auf die europäische Ebene verlagerte und die die Keimzelle eines europäischen Managements werden sollte.

Nun bietet die europäische Harmonisierung nicht nur erweiterte Möglichkeiten am Markt. Ein europäisches Unternehmen kann auch rationeller geführt werden als eine Gruppe von weitgehend unabhängigen Gesellschaften.

Traditionell wurde in der Vergangenheit von United Products Ltd. eher die Verschiedenheit betont. ..Wir verkaufen zwar dieselben Produkte, aber der deutsche Markt (der französische, der holländische und so weiter) ist ganz anders. Deshalb müssen wir auch unsere Aufgaben anders erfüllen." Die gedankliche Hinwendung zu Europa jedoch ließ bei einigen leitenden Managern die Frage aufkommen: Ist das erstens wirklich wahr, und zweitens, wenn es denn heute wahr ist, muß das eigentlich so sein?

Zur Beantwortung dieser Fragen wurde eine Studie durchgeführt, in der die europäischen Geschäftspraktiken des Unternehmens analysiert wurden.

Das - für viele vielleicht überraschende Ergebnis - war, daß die Gemeinsamkeiten die Verschiedenheiten bei weitem überwogen. Es dauerte nicht lange, bis das Ergebnis dieser Studie in eine Vision umgesetzt wurde.

Wenn die Verschiedenheiten schon heute geringer als die Gemeinsamkeiten sind, dann laßt uns die Gemeinsamkeiten betonen und die Geschäftspraktiken harmonisieren. Damit ergibt sich für das Unternehmen einerseits die Basis, ihre Mitarbeiter europäischer und damit austauschbarer zu machen, andererseits lassen sich nun die EDV-Systeme, die die Durchführung der Geschäftsaufgaben unterstützen, vereinheitlichen und damit wird eine ganze Menge Geld für Entwicklung und Systempflege gespart.

Die Vision von United Products Ltd. war also die Schaffung einer Anwendungs-Systemlandschaft von europäischen, das heißt weitestgehend einheitlichen EDV-Systemen zur Unterstützung von europäischen Geschäftspraktiken in einem europäischen Unternehmen.

Nun ist die Idee, einheitliche Systeme zur Lösung von Aufgaben in verschiedenen Branchen und Ländern einzusetzen, weder neu, noch unproblematisch. Allzu große Vereinheitlichung kann insbesondere bei marktnahen Systemen zu einigen Problemen führen.

Ziemlich neu ist jedoch der Gedanke, die Schaffung dieser einheitlichen europäischen Systemlandschaft mit Hilfe der Information-Engineering-Methode durchzuführen. Neu sind auch die technischen Möglichkeiten, die uns die moderne CASE-Technologie bietet, um die Durchführung einer solchen Aufgabe zu erleichtern beziehungsweise sie überhaupt erst möglich zu machen.

Wir haben es hier aber nicht mit einer einfachen Aufgabe zu tun! Auch der Einsatz der modernsten und leistungsfähigsten technischen Hilfsmittel darf nicht darüber hinwegtäuschen, daß einer der wesentlichsten Critical Success Factors des Projekts die Fähigkeit des Managements ist, die Größe der Aufgabe wirklich zu begreifen und die Umsetzung in die Realität konsequent gegen alle Schwierigkeiten durchzuführen. Das Europa-Projekt der United Products Ltd. gibt den Anlaß, zu beschreiben, wie ich mir die technische Realisierung einer solchen Aufgabe vorstelle.

Die Vorgehensweise der Information-Engineering-Methode zur Konzeption einer Anwendungssystemlandschaft besteht darin, daß zunächst einmal in einem ersten Schritt, bei der Informations-Strategie-Planung (ISP), verschiedene Architekturen für das Unternehmen entwickelt werden. Eine Architektur ist ein Bauplan, ein Strukturkonzept, das als Leitfaden für folgende Implementierungsaktivitäten dient.

Gegenstand der ISP-Studie ist die Erstellung von konzeptionellen Architekturen, also die Erarbeitung der wesentlichen strukturbestimmenden Elemente, der "strategischen Eckpfeiler" für die Informationsverarbeitung des Unternehmens. Die Ausformung der für die Implementierung notwendigen Details wird in späteren Phasen der Methode durchgeführt.

Die wichtigsten Architekturen sind die Informationsarchitektur und die daraus abgeleitete Geschäftssystemarchitektur. Unter Informationsarchitektur verstehe ich ein Modell der Aktivitäten, die im Unternehmen ausgeführt werden, und der Daten, die dazu nötig sind.

Die Geschäftssystemarchitektur entsteht aus der Informationsarchitektur durch Gruppierung der Aktivitäten und Daten in sinnvolle Untermengen, den Geschäftsgebieten (Business Areas) und innerhalb derer die natürlichen Geschäftssysteme (siehe Abbildung I). "Natürlich" heißen diese Systeme, weil sie im ersten Stadium der Untersuchung noch "ideale" Systemideen sind, die einen Teil des geschäftlichen Geschehens modellieren und damit die optimale denkbare Unterstützung für diesen Bereich darstellen. Im Laufe der weiteren Analysen erfahren diese Systemideen bis zu ihrer Realisierung noch eine Reihe von Wandlungen, da Kompromisse mit der finanziellen und technischen Realität geschlossen werden müssen, die zu Änderungen des ursprünglichen Systemkonzepts führen.

Weitere Architekturen, die definiert werden, betreffen Technik und Organisation. Die erstere Architektur legt die technischen Komponenten fest, die zur Implementierung der Geschäftssystemarchitektur bereitgestellt werden müssen. Das sind Hardware, Software, Kommunikation, Methoden und Verfahren. Obwohl es hier eigentlich zunächst nur auf den "Typ" einer Komponente ankommt, etwa ein "relationales Datenbanksystem' anstelle von "DB2", werden die Aussagen häufig schon sehr viel konkreter sein, da die technische Vergangenheit der Informationsverarbeitung des Unternehmens nur gewisse sinnvolle Wachstumspfade zuläßt.

Die Organisationsarchitektur definiert die zur Umsetzung des Information-Engineering-Konzepts notwendige Aufbauorganisation und Aufgabellverteilung der Informationsverarbeitungsfunktion des Unternehmens.

Abschluß einer ISP-Studie sind dann in der Regel Kosten/Nutzen-Überlegungen für das vorgeschlagene Konzept und ein Implementierungsplan, der die ersten Schritte der Implementierung fixiert.

Eine derartige ISP-Studie dauert für e in Unternehmen etwa zwischen sechs und neun Monaten und beschäftigt ein Kernteam von mindestens fünf Mitarbeitern fulltime.

Betrachten wir diese Aufgabe unter dem Aspekt der Internationalität des Konzernansatzes, dann treten eine ganze Reihe von Problemen auf mit denen wir es in der Regel bei der Strategieplanung für ein Unternehmen nicht oder nicht in diesem Um fang zu tun haben. Probleme tendieren dazu, die Zeitdauer für die! Durchführung der Studie und den Aufwand zu vergrößern. Ein höherer Aufwand wird schnell als gerechtfertigt erkannt und deshalb akzeptiert Wesentlich problematischer ist die Zeitdauer.

Dauert eine Studie zu lange, er lischt entweder das Interesse, wichtige Sponsoren werden versetzt, oder das Management beginnt, Abstriche! an der Qualität der Ergebnisse zu machen, weil die Ungeduld, endlich etwas Vorzeigbares zu haben, zu groß wird. Alles dies kann tödlich für das Projekt sein. Eine sorgfältige Planung, professionelles Projekt- und Zeitmanagement, Einsatz von arbeitssparenden abkürzenden Techniken und Hilfsmitteln, realistische Ziele, eine optimale Teamzusammensetzung sowie intensive Managementunterstützung sind deshalb notwendige Voraussetzungen für den Erfolg des Projekts.

Ein nicht zu unterschätzendes praktisches Problem stellt die Verständigung dar. Eine einheitliche Sprache für die Dokumentation der Ergebnisse wird unumgänglich sein. In einem international besetzten Team wird das in der Regel Englisch sein. Ich habe in mehreren derartigen Teams gearbeitet und weiß aus Erfahrung, daß es - auch bei sehr guten Englischkenntnissen - in der täglichen Arbeit ständig zu Mißverständnissen sowohl innerhalb des Teams wie auch insbesondere bei der Kommunikation mit der Anwenderorganisation kommt.

Praktische Ansätze zur Lösung dieses Problems bestehen in der Verwendung von grafischen Dokumentationstechniken und eines einfachen Wortschatzes. In meinem letzten derartigen Projekt überließen die Engländer häufig mir die Erstellung von Definitionen und Dokumenten da der geringere Sprachumfang, der mir als Ausländer zur Verfügung stand, von anderen Ausländern einfacher verstanden wurde.

Weitere Schwierigkeiten entstehen durch die große Zahl der beteiligten Personen, mit denen das Team kommunizieren muß. Wirkliche Akzeptanz für die Ergebnisse, die über das Beugen vor der Macht der Zentrale hinausgeht, kann nur erreicht werden, wenn während der Projektarbeit intensive Kommunikation mit den Anwendern der einzelnen Tochterunternehmen gepflegt wird. Sie müssen außerdem die Chance haben, rechtzeitig ihr Wissen und ihre Probleme in die Projektergebnisse einzubringen. Derartige Abstimmungsanforderungen stellen das Team vor nicht unerhebliche Reiseprobleme. Telefonkonferenzen sind derzeit immer noch eher exotisch als hilfreich.

Abstimmung soll in der Zentrale stattfinden

Praktische Ansätze zur Reduzierung dieses Problems bestehen zum Beispiel darin, daß Abstimmungen und Gespräche nicht mit allen betroffenen Anwendern, sondern nur mit einer Gruppe von ausgewählten Repräsentanten (beziehungsweise mit mehreren Gruppen, um die unterschiedlichen Aspekte der Modelle abzudecken) durchgeführt werden. Zeit läßt sich sparen, wenn die Abstimmungsmeetings in der Projektzentrale durchgeführt werden und nicht - wie üblich - die Teammitglieder die Anwender zu Abstimmungsgesprächen aufsuchen.

Zudem muß erst einmal ein repräsentatives Team für die Untersuchung gefunden werden. In ihm sollen einmal die Tochterunternehmen ausreichend repräsentiert sein, andererseits sollten im Team möglichst Kenntnisse aus verschiedenen Bereichen des Geschäfts vorhanden sein. Die sich daraus ergebende Mischung mit dem Logistikexperten aus Frankreich, dem Marketingleiter aus Dänemark, dem Personalchef aus England und dem Produktionsexperten aus Deutschland stellt eine erhebliche Herausforderung für einen Projektleiter dar, der aus diesen Mitarbeitern mit sehr unterschiedlichem geschäftlichen und kulturellen Hintergrund ein effizientes Team formen muß.

Neben diesen organisatorischen Problemen eines internationalen Strategieprojekts treten die technischen Schwierigkeiten fast in den Hintergrund.

Der wesentliche Unterschied zwischen einer nationalen und einer internationalen Architektur besteht darin, daß es sehr viel aufwendiger ist, sie international zu entwickeln. Die Ergebnisse der Arbeit, die Modelle des Geschäfts, werden nicht wesentlich verschieden aussehen.

Eine konzeptionelle Informationsarchitektur läßt sich normalerweise mit etwa 70 bis 100 Informationsobjekten (Entity Types) und etwa 100 bis 150 Aktivitäten ausreichend präzise darstellen, egal ob sie für ein Unternehmen oder für eine Gruppe von Unternehmen gilt. Voraussetzung ist allerdings, daß alle diese Unternehmen das gleiche Geschäft betreiben.

Daraus können etwa 40 bis 60 logische Systeme gebildet werden, die alle Aspekte des Geschäfts unterstützen. Allerdings werden die Definitionen der Informationsobjekte und Aktivitäten häufig etwas ausführlicher sein müssen, um lokale Varianten zu berücksichtigen oder um lokale Begriffe zu dokumentieren, die das Verständnis der Anwender erleichtern.

Zusätzliche Arbeiten entstehen für das Team bei der Distributionsanalyse, das heißt bei der Dokumentation des unterschiedlichen Vorkommens von Informationsobjekten und Aktivitäten in den einzelnen Tochterunternehmen und insbesondere bei der Analyse der Ist-Situation in den einzelnen Ländern.

Als unerläßliches Hilfsmittel für die Erarbeitung und Dokumentation der Ergebnisse benötigt das Team in dieser Phase ein gutes CASE-Tool in Verbindung mit Textverarbeitung und Programmen zur Tabellenkalkulation

Bei der CASE-Anwendung muß man auf einige Überraschungen gefaßt sein. Obwohl die Modelle der strategischen Planung noch nicht sehr groß sind (1 bis 2 MB Speicherplatz auf der Platte, Matrizen der Größenordnung 100x 150, EntityRelationship-Modelle mit 100 Entity Types und 200 bis 250 Beziehungen), gehen rein PC-orientierte CASE-Tools dabei schnell in die Knie.

Insbesondere für das Handling von Matrizen (Navigation, Affinitätsanalysen, Druck) gilt, daß eine Software, die für kleine Matrizen sehr hübsch sein kann, für größere Matrizen völlig versagt. So lassen sich etwa größere Matrizen nicht mehr sinnvoll ausdrucken, da sie aufgrund des unglücklichen Formats der Spaltenbeschriftung und der Größe der Felder schnell wandfüllend leeres Papier produzieren. Auch muß man bei wachsender Modellgröße mit einer erheblichen Verlängerung der Zugriffszeiten rechnen.

Beispiele, bei denen allein der Aufbau einer Funktions-/Entity-Matrix der Größe 100x200 aus dem Speicher 45 Minuten dauert und wo eine Affinitätsanalyse nach sieben Studen ergebnislos abgebrochen werden muß, ermutigen nicht unbedingt.

Trotz dieser kritischen Anmerkungen möchte ich betonen, daß eine strategische Informationsplanung, die mit Hilfe eines brauchbaren CASE-Tools durchgeführt wird, zwar einige Probleme beinhalten kann, daß aber andererseits eine derartige Planung ohne die Unterstützung eines solchen CASE-Tools kaum durchführbar ist - jedenfalls nicht dem Qualitätsstandard des Informations-Engineering-Ansatzes entsprechend. (wird fortgesetzt)