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.

30.10.1992

Anwenderbericht: Leica Heerbrugg AG, HeerbruggSchweiz\Standardsoftware läßt sich sinnvoll in UDM integrieren

30.10.1992

Ein unternehmensweites Datenmodell (UDM) ist heute unbestritten ein Baustein der Informationsstruktur. Ebenso wird in immer stärkerem Maße Standardsoftware zur Abdeckung der betrieblichen Funktionsbereiche eingesetzt. UDM und Standardsoftware scheinen sich aber in vielen Belangen auszuschließen. Unser Bericht zeigt am Beispiel der Leica Heerbrugg AG auf, wie Standardsoftware ins UDM integriert und welcher Nutzen daraus gezogen werden kann.

Der Einsatz betriebswirtschaftlicher Standardsoftware bringt häufig größere organisatorische Veränderungen mit sich. Die Änderung von Daten-, Ablauf- und Aufbauorganisation erfordert die Bereitschaft zur Absage an bisher Gewohntes und vielfach auch an selbst Geschaffenes und Erprobtes. Die Zeit des Überganges von alter auf neue Software ergibt sowohl für die Anwender in den Fachabteilungen als auch für die Informatik-Mitarbeiter eine erhöhte zeitliche Belastung und neue qualitative ----Herausforderungen.

Psychologische Hemmschwellen überwinden

Die Einführung von Standardsoftware ab einer bestimmten Größenordnung bedingt meistens die Durchführung und Koordination mehrerer Großprojekte, welche zeitgleich oder direkt aufeinanderfolgend ablaufen. Hinzu kommt, daß neben der Bewältigung fachlich anspruchsvoller Aufgaben auch psychologische Hemmschwellen zu überwinden sind.

Auch für das Daten-Management entstehen neue Herausforderungen. Die in einem Unternehmen existierende Begriffsvielfalt und die daraus resultierenden Fehlinformationen und -interpretationen werden zusätzlich durch die Terminologie der Standardsoftware bereichert.

Langfristig wird der Begriffswirrwarr durch die Ubernahme der Standardsoftware-Terminologie vermindert, kurzfristig, das heißt in der Umstellungsphase von alten Systemen auf Standardsoftware, muß das gesamte Unternehmen jedoch mit zusätzlichen unterschiedlichen Begriffen leben. Hier muß das Daten-Management durch Definition der in der Standardsoftware verwendeten Begriffe und deren Abgleich mit den im Unternehmen gängigen Entsprechungen den Überblick behalten. Voraussetzung dazu ist neben der eigentlichen Begriffsdefinition die Dokumentation von Synonymen, Homonymen, Begriffsüberschneidungen und - abweichungen.

Ebenso wird das Datenvolumen kurzfristig stark zunehmen. Um in der Übergangszeit von alten Systemen auf Standardsoftware beide Systemwelten befriedigen zu können, müssen in der Regel mehr Daten redundant gehalten werden. Beispielsweise wird bei der Leica Heerbrugg AG durch die Ein führung der SAP-Module RM (Materialwirtschaft), RV (Vertrieb) und RF (Finanzbuchhaltung) das Datenvolumen allein im ersten Jahr vorübergehend um über 40 Prozent anwachsen. Die Zunahme entsteht hauptsächlich durch das Kopieren vorhandener Daten in eine andere Software-Umgebung. Die Konsistenz der Daten ist durch ein möglichst automatisiertes Copy- Management zu gewährleisten. Voraussetzung dazu ist auch hier der Überblick über die im Unternehmen benötigten Daten, deren Bedeutung und Beziehungen zueinander sowie deren physikalische Speicherorte.

Auch heute noch verfügt Standardsoftware -meist nur über mangelhafte Transparenz in der Informationsstruktur. So besitzt beispielsweise SAP zwar ein integriertes Data Dictionary das eine Beschreibung der Datenfelder auch Óus betriebswirtschaftlicher Sicht enthält, aber auch hier sind - zumindest in der SAP-R2-Generation - weder die für SAP betriebswirtschaftlich relevanten Informationseinheiten (Entitätstypen) definiert noch deren Zusammenhänge transparent dokumentiert. Einblick und Einstieg in Philosophie und Anwendung der Software werden dadurch wesentlich erschwert.

Mit dem Einsatz von Standardsoftware lassen` sich nicht alle Geschäftsfunktionen abdekken. Die Schnittstellen zu den Umsystemen der Standardsoftware müssen daher aus datenorientierter Sicht abgegrenzt werden.

Es steht die Frage im Vordergrund, welche Informationseinheiten in welcher Form sowohl von der Standardsoftware als auch von einem oder auch mehreren Umsystemen benutzt werden.

Schon aus dieser nicht vollständigen Aufzählung neuer Herausforderungen an das Daten-Management ist ersichtlich, daß der Einsatz von Standardsoftware dieses nicht - wie häufig angenommen - entlastet oder gar überflüssig macht.

Durch ein unternehmensweites Datenmodell, also die fachliche Beschreibung aller im Unternehmen verwendeten Informationseinheiten und ihrer Beziehungen untereinander, kann man die geschilderten Mängel in den Griff bekommen. Durch das UDM können folgende Ziele erreicht werden:

- Vergleich und Bewertung von Standardsoftware in der Evaluationsphase;

- eine klare, eindeutig definierte und unternehmensweit gültige Begriffswelt;

- eine Grundlage für präzise Datendefinitionen aus fachlicher und DV-technischer Sicht;

- eine klare Darstellung der Zusammenhänge zwischen betriebswirtschaftlich relevanten Informationseinheiten und damit Transparenz von gültigen Geschäftsregeln;

- eine gezielte Abgrenzung von Projekten aus datenorientierter Sicht; - stark verminderte Schnittstellen-Probleme zwischen Projekten und betrieblichen Funktionsbereichen;

- eine Basis für die Umsetzung der fachlichen Informationseinheiten und ihrer Beziehungen zueinander in DV-technische Datenstrukturen so daß DV-gestützte Lösungen in kürzerer Zeit und besserer Qualität erstellt werden können;

- eine Grundlage zur Erkennung von Unterschieden und Gemeinsamkeiten zu anderen Unternehmensteilen.

Der Weg zu dem UDM ist bei Palffy und Patzke [2] erläutert und im folgenden Kapitel kurz umrissen. Im Augenblick interessiert vor allem die Frage, wie die Informationsstruktur der Standardsoftware in ein UDM integriert werden kann. Dafür gibt es zwei Möglichkeiten:

1. Die ausschließliche Klärung der Bedeutung der in der Standardsoftware definierten Informationseinheiten und Abgleich mit den Unternehmensbegriffen: Nicht berücksichtigt werden dabei wesentliche Geschäftsregeln der Standardsoftware, implementiert durch die Beziehungen zwischen den Informationseinheiten. Die Transparenz der Software ist stark vermindert. Die Anpassung der Unternehmensorganisation an das der Standardsoftware zugrunde liegende Unternehmensmodell-oder umgekehrt

- wird dadurch wesentlich erschwert. Dieses Vorgehen erfordert gegenüber der zweiten Möglichkeit den geringeren Aufwand.

2. Erstellen eines unternehmensspezifischen Datenmodells der Standardsoftware und Abgleich mit dem bestehenden UDM: Neben der Klärung der Bedeutung von in der Standardsoftware verwendeten Informationseinheiten werden auch deren Beziehungen untereinander transparent Dieses Vorgehen hat einen hohen Aufgabenerfüllungsgrad, ist aber sehr aufwendig und erfordert gute Kenntnisse der betriebswirtschaftlichen Zusammenhänge.

Die Entscheidung bei der Leica Heerbrugg AG für den zweiten Weg wurde maßgeblich durch die Tatsache bestimmt daß in den nächsten drei Jahren 70 bis 80 Prozent der betriebswirtschaftlichen Funktionen mit der Standardsoftware SAP abgedeckt werden sollen. Damit wird das UDM stark durch die SAP-lnformationsstruktur geprägt. Um unter diesen Umständen die eingangs erwähnten Ziele zu erreichen, muß das unternehmensspezifische Datenmodell der Standardsoftware erstellt werden Unternehmensspezifisch deshalb, weil sich die Informationsstruktur der Standardsoftware durch Parametrisierung - also durch Anpassung der Software an die Erfordernisse des Unternehmens - teilweise stark verändert Die Modellierung der sehr allgemeinen Standard-Informationsstruktur würde an den Bedürfnissen vorbeigehen.

Dieser Sachverhalt impliziert daß selbst bei Existenz eines Datenmodells zu einer Standardsoftware deren unternehmensspezifische Datenmodellierung nicht ersetzt werden kann. Der Datenmodellierungsprozeß wird durch ein Standarddatenmodell zwar wesentlich erleichtert, aber nicht überflüssig.

Am Beispiel der Leica Heerbrugg AG wird der Weg zu einem UDM erläutert. Anschließend wird diese Vorgehensidee durch das Konzept der Datenmodellierung bei Standardsoftware und dessen Integration in das bestehende UDM ergänzt.

Verfeinerung der Entitätstypen der Architektur

Als erster Schritt zum UDM wurde die Leica Datenarchitektur erarbeitet. In dieser sind die relevanten Informationseinheiten (Entitätstypen) der gesamten Wertschöpfungskette und der administrativen Bereiche dokumentiert. Die Datenarchitektur ist ein stark aggregiertes Datenmodell. Mit etwa 70 Entitätstypen und 130 Beziehungen gibt sie einen Überblick über alle relevanten Informationen und deren wechselseitige Beziehungen. Daneben sind die wichtigsten Attribute je Entitätstyp und, soweit auf dieser hohen Abstraktionsebene möglich und sinnvoll, Verantwortlichkeiten fur diese definiert.

Im zweiten Schritt wird die Datenarchitektur durch projektbezogene Detaillierung so weit konkretisiert, bis alle für das Unternehmen relevanten Informationseinheiten und deren Beziehungen erfaßt sind (vgl. die Abbildungen 1 und 2) .

Jedes Projekt, das die Neukonzeption eines Anwendungssystems beinhaltet, nutzt die Datenarchitektur und bestehende Teile des UDMs und ergänzt diese durch das erstellte projektbezogene Datenmodell. In der Datenarchitektur wird zunächst der für ein Projekt relevante Ausschnitt abgegrenzt. Dieser definiert die Projektgrenzen und Schnittstellen zu den Umsystemen aus datenorientierter Sicht (vgl. Abbildung 3).

Der abgegrenzte Ausschnitt wird im Verlauf des Projektes verifiziert, korrigiert und konkretisiert, das heißt, es entsteht ein Datenmodell, das eine Verfeinerung der entsprechenden Entitätstypen der Datenarchitektur darstellt.

Die neu gefundenen Informationseinheiten und deren Beziehungen untereinander werden mit der Datenarchitektur abgestimmt: Homonyme, unterschiedliche Definitionen und widersprüchliche Beziehungen werden eliminiert, Synonyme mit ihrer jeweiligen Verwendung in den betrieblichen Funktionsbereichen wenn möglich eliminiert, zumindest aber dokumentiert. Außerdem werden neue Attribute den entsprechenden Entitätstypen zugeordnet.

Auf diese Weise entsteht, ausgehend von der Datenarchitektur, in einem iterativen Prozeß das unternehmensweite Datenmodell, gebildet aus den konsolidierten Projektdatenmodellen Die Projektdatenmodelle werden zu verschiedenen Sichten auf das unternehmensweite Datenmodell, das seinerseits eine Konkretisierung beziehungsweise Verfeinerung der Datenarchitektur darstellt (vgl. Abbildung 5).

Auch bei der Ermittlung des unternehmensspezifischen Datenmodells der Standardsoftware dient die Datenarchitektur der Abgrenzung des Untersuchungsbereiches .

Der abgegrenzte Ausschnitt in der Datenarchitektur und dazu korrespondierend in dem UDM stellt den Ist-Zustand des durch die Standardsoftware zu ersetzenden Systems in bezug auf die Daten dar. Außerdem werden die Beziehungen zu anderen, nicht innerhalb des betrachteten Systems liegenden Entitätstypen aufgezeigt. Mit der Konzeption des Sollsystems beginnt die Erhebung des unternehmensspezifischen Datenmodells der Standardsoftware .Hierzu wird unter anderem auf Hilfsmittel wie Handbücher, Dateibeschreibungen und Data Dictionary der Standardsoftware zurückgegriffen.

Im Unterschied zur im vorhergehenden Abschnitt erläuterten prinzipiellen Vorgehensweise entsteht das Datenmodell der Standardsoftware nicht durch Verfeinerung der Datenarchitektur, sondern durch Reengineering der physischen Datenstrukturen der Standardsoftware. Dieses Bottom-up-Vorgehen hat zwei Konsequenzen:

1. Das UDM und das ermittelte unternehmensspezifische Datenmodell der Standardsoftware liegen

auf dem gleichen Abstraktionsniveau. Da letzteres die neue Informationsstruktur darstellt, muß der anfanglich abgegrenzte Ausschnitt im UDM durch das Datenmodell der Standardsoftware ersetzt werden.

2. Ebenso muß der entsprechende Ausschnitt in der Datenarchitektur ersetzt werden. Dazu wird das unternehmensspezifische Datenmodell der Standardsoftware durch Aggregation der Entitätstypen und ihrer Beziehungen auf das Wesentliche reduziert. Dies entspricht der Umkehrung des in den Abbildungen I und 2 gezeigten Vorgehens.

Implementierungen der Schnittstellen-Beziehungen

Während der Integration des unternehmensspezifischen Datenmodells in das UDM gilt den Randentitätstypen besonderes Augenmerk, das heißt denjenigen Entitätstypen, die nicht nur von der Standardsoftware, sondern auch von anderen Anwendungen benötigt werden. Hier müssen Maßnahmen für die Implementierung dieser Schnittstellen-Beziehungen abgeleitet werden.

Häufig, so auch bei Leica, ist der Fall anzutreffen, daß Standardsoftware in mehreren, teilweise parallel laufenden Projekten eingeführt wird. Es entstehen viele unternehmensspezifische Teildatenmodelle der Standardsoftware, die zunächst untereinander konsolidiert werden müssen, bevor sie Eingang in das UDM beziehungsweise die Datenarchitektur finden. Damit werden Problemfelder innerhalb der Standardsoftware

-und solche sind nicht selten

-sichtbar und können gegebenen- falls eliminiert werden.

Das konsolidierte unternehmensspezifische Datenmodell der Standardsoftware wird dann wie erläutert in das UDM beziehungsweise in die Datenarchitektur integriert (vgl. Abbildung 6).

Damit erhält man neue Sichten auf das UDM beziehungsweise auf die Datenarchitektur (vgl.Abbildung 7).

Die Frage nach dem essentiellen, das heißt fachlich korrekten und vollständigen Datenmodell der Standardsoftware ist häufig schwierig zu beantworten. Bei der Vielzahl der vorhandenen Steuertabellen mit Stammdatencharakter sowie der entitätstypverdächtigen Dateien und Felder ist es nicht immer leicht zu sagen, welche davon auch betriebswirtschaftlich relevant sind. Dieses Problem ist nur in enger Zusammenarbeit mit den Fachabteilungen und den Projektteams zu lösen.

Anders als bei der Datenmodellierung für Eigenentwicklungen ist die Datenmodellierung für Standardsoftware ein Reengineering von physikalischen Datenstrukturen. Der Weg von diesen zu dem fachlichen Datenmodell muß transparent und nachvollziehbar sein. Denn von einer normalisierten Datenstruktur, die den Weg von der physikalischen Datenstruktur zum fachlich-logischen Datenmgdell relativ einfach macht, kann man bei Standardsoftware immer noch nicht sprechen. Die explizite Dokumentatlon der Speicherorte der Entitätstypen und ihrer Beziehungen ist daher unerläßlich für spätere Entwicklungsarbeiten innerhalb der Standard-Software-Umgebung.

Spezielle Rechner verwalten das UDM

Die Vielzahl der anfallenden Datenmodelle erwies sich auf Dauer als nicht mehr ohne geeignete Werkzeuge handhabbar. Zu viele Entitätsdefinitionen, Beziehungen, Attribute und Verantwortlichkeiten für Daten müssen verwaltet werden. Die komplexe Aufgabe der Konsolidierung von Datenmodellen ist ohne Rechnerunterstützung kaum noch zu bewältigen. Daher wird ein Werkzeug eingesetzt, das im wesentlichen folgende Anforderungen erfüllt:

- grafische Bearbeitung von Datenmodellen in Form eines Entity Relationship Diagrams;

- Data Dictionary für Ablage der fachlichen Definitionen der Entitätstypen, Beziehungen und Attribute;

- Unterstützung bei der Konsolidierung von Datenmodellen;

- Sicherung der vertikalen Konsistenz bei der Verfeinerung eines Datenmodells .Damit soll der Bezug sichergestellt werden ,welcher Entitätstyp im UDM aus welchem Entitätstyp der Datenarchitektur entstanden ist (vgl.Abbildung 2) ;

-Integration in die gesamte CASE- Strategie ; Möglichkeit der Weiterverwendung der Datenmodelle, insbesondere der Projektdatenmodelle,in unserer Progammierumgebung (Delta, DB2,SAP/Abap),beispielsweise durch die werkzeugunterstützte Normaliesierung und Generierung von Datenbankstrukturen aus dem erstellten Datenmodell .

Die Datenbank des verwendeten Werkzeuges ,die sogenannte Enzyklopädie [3],dient als Master,in dem zum jetzigen Zeitpunkt für die Datenarchitektur und die verschidenen Prejektdatenmodelle ,für das unternehmensspezifische Datenmodell der Standardsoftware und das UDM folgende Informationen gepflegt und konsistent gehalten werden :

-die fachliche Definition der Entitätstypen und der verwendeten Synonime ;

- die Bedeutung der Beziehungen zwischen Entitätstypen und der jeweilige Beziehungstyp;

- die fachliche Definition relevanter Attribute;

- Dateien und Tabellen, in denen Entitätstypen und deren Beziehungen zueinander realisiert sind Implementierung der Entitätstypen und Beziehungen);

- der Bezug eines Entitätstyps zum Superentitätstyp, also zum Entitätstyp in der Datenarchitektur, aus dem ein bestimmter Entitätstyp des UDMs entstanden ist (vgl. Abbildung 2 auf Seite 48). Insgesamt soll zukünftig in Abbildung 8 illustrierte Metamodell in der Masterenzyklopädie abgebildet werden. Zum aktuellen Zeitpunkt sind in der Masterenzyklopädie die Informationen erst rudimentär enthalten, welcher Geschäftsprozeß welche Entitätstypen verwendet und welche Organisationseinheit für welche Entitätstypen verantwortlich ist.

Die Masterenzyklopädie versorgt die nachgeordneten Data Dictionaries,insbesondere das der Standardsoftware ,mit den notwendigen Informationen . Änderungen sind nur im Master erlaubt.Ein geeignetes Organisationskoncept sorgt für die Aktualität der nachgeordneten Data Dictionaries.

*Rainer Endl und Bernhard Fritz sind Datenmanager bei der Leica Heerbrugg AG:

Das-Datenchaos bewältigen

Viele Unternehmen haben heute mit einem Datenchaos als Folge isoliert gewachsener Anwendungssysteme und einer technikzentrierten Denkweise gewaltige Probleme. Als erfolgversprechendes Mittel, dieses Chaos in den Griff zu bekommen und zu eindeutigen, strukturierten Informationen zu gelangen, hat sich das unternehmensweite Datenmodell (UDM) erwiesen [ 1]. Viele Unternehmen besitzen heute bereits ein solches Modell oder sind im Begriff, es zu erstellen.

Andererseits wird in immer stärkerem Umfang versucht durch den Einsatz von Standardsoftware möglichst große Teile der betriebswirtschaftlichen und technischen Anwendungen abzudecken. Nicht selten ist damit die Hoffnung verknüpft, durch Verwendung der von der Standardsoftware vorgegebenen lnformationsstruktur auch das Datenchaos zu bewältigen und die unternehmensweite Datenmodellierung überflüssig zu machen. Dabei wird übersehen, daß die Informationsstruktur der Standardsoftware nur einen Rahmen vorgibt, der jedoch verstanden, den Erfordernissen des Unternehmens angepaßt und mit den richtigen Unternehmensdaten gefüllt werden muß.

Man kann daher der Ansicht sein, daß trotz oder gerade wegen der Verwendung von Standardsoftware der unternehmensweiten Datenmodellierung eine sehr wichtige Rolle auf dem Weg zu einem effizienten Informations-Management zukommt. Es stellt sich die Frage, wie die Informationsstruktur der Standardsoftware in ein unternehmensweites Datenmodell integriert werden kann. Die Antwort ist naheliegend: Darstellung der Informationsstruktur der Standardsoftware in einem Datenmodell und Abgleich mit dem bestehenden UDM.

Nebenstehend wird am Beispiel der Leica Heerbrugg AG gezeigt, wie diese Idee sich in die Praxis umsetzen ließ. Das Konzept kann auch als Teil eines allgemeinen Vorgehensmodells für die Einführung einer großen Standardsoftware verstanden werden.