Die Entwicklung und Nutzung unternehmensweiter Datenschemata ist problematisch. Elmar Sinz* analysiert methodische Ursachen und zeigt einen Weg auf, wie das Unternehmensdatenmodell in seiner Rolle als Rueckgrat der unternehmensweiten Informationssystem- und Anwendungs-architektur durch ein Geschaeftsprozessmodell abgeloest werden kann.

Viele Unternehmen investieren seit Mitte der 80er Jahre grosse Anstrengungen und finanzielle Mittel in die Entwicklung unternehmensweiter Datenschemata (UDS) - haeufig auch als unternehmensweite Datenmodelle oder Unternehmensdatenmodelle bezeichnet. Damit wollen sie ein zentrales fachliches Modell der Unternehmung und ein stabiles Rueckgrat fuer die Spezifikation und Integration der Informationssystem- beziehungsweise Anwendungssystemarchitektur schaffen.

Viele dieser Projekte sind auf halbem Weg steckengeblieben oder haben zumindest nicht den erwarteten Erfolg gebracht. Generell wird der Nutzen von UDS derzeit sehr zwiespaeltig beurteilt; das Spektrum reicht von Euphorie bis zu aeusserster Skepsis.

Wo liegen die Probleme? Zunaechst ist das UDS ein Modell, das nur einen begrenzten Ausschnitt der betrieblichen Realitaet in einem Schema aus Datenobjekttypen und deren Beziehungen untereinander abbildet. Neben den reinen Modellierungsproblemen - Beispiele dafuer sind die begriffliche Klaerung von Homonymen und Synonymen sowie das Auffinden geeigneter Generalisierungs- und Aggregationsstrukturen - stellt insbesondere die Beherrschung der Komplexitaet ein gravierendes Problem dar.

Die Komplexitaetsfalle schnappt zu

Ein haeufig gewaehlter Ausweg aus der "Komplexitaetsfalle" besteht darin, das UDS sukzessive und unter Nutzung unterschiedlicher Detaillierungsgrade zu entwickeln. Ausgehend von einem Top-level- Datenschema werden Bereichsdatenschemata fuer einzelne Unternehmensbereiche erstellt und integriert. Anschliessend lassen sich, zum Beispiel im Rahmen von Anwendungsentwicklungs-Projekten, detaillierte Teildatenschemata entwickeln und mit den Bereichsdatenschemata abstimmen. Die einzelnen Teildatenschemata werden dann sukzessive zu einem UDS integriert.

Mit diesem Loesungsansatz bleiben allerdings folgende Probleme ungeloest oder verstaerken sich sogar:

- Konfigurations-Management: Die Entwicklung eines detaillierten Teildatenschemas macht in der Regel Anpassungen des zugehoerigen Bereichsdatenschemas notwendig. Diese fuehren wiederum zu Anpassungen anderer detaillierter Teildatenschemata etc. Da die Bereichsdatenschemata und das Top-level-Datenschema im allgemeinen nicht aus den detaillierten Teildatenschemata automatisch ableitbar sind, muessen die Datenschemata der unterschiedlichen Detaillierungsebenen separat gepflegt werden.

- Modellvalidierung: Die betriebswirtschaftlichen Fachabteilungen empfinden das Denken in Datenobjekttypen und Beziehungen haeufig als "aufgezwungene Informatikersicht". Sie sehen ihre fachliche Sicht auf die betriebliche Realitaet hinsichtlich Beschreibungsform und -umfang im UDS nur unzureichend repraesentiert. Dies erschwert dessen Validierung.

- Schritthaltende Anpassung: Die Entwicklung eines UDS wird vielfach von der Vorstellung geleitet, eine zweckneutrale und weitgehend konstante Datensicht der betrieblichen Realitaet zu schaffen. Seine Nutzung zeigt aber, dass Aenderungen der Ziele und Strategien, der betrieblichen Leistungsarten und -beziehungen, der Koordination der Leistungserstellung und -uebergabe sowie Rekonfigurationen und Reorganisationen der Unternehmung laufende Anpassungen des UDS notwendig machen. Das UDS erweist sich dann haeufig als inflexibel. Es entsteht ein gravierendes Wartungsproblem.

Das UDS modelliert einen Ausschnitt der betrieblichen Realitaet in Form von Datenobjekttypen und Beziehungen zwischen diesen; es beschreibt also die Datensicht auf eine Unternehmung. Diese stellt ein zustands- und strukturorientiertes Modell dar, das seinen Zustandsraum spezifiziert. Datenobjekttypen lassen sich als Typspezifikationen fuer Teilzustands-Speicher bezeichnen, die untereinander durch Strukturbeziehungen verknuepft sind.

In einem umfassenden fachlichen Unternehmensmodell muss die Datensicht um weitere Sichten ergaenzt werden, die vor allem das Verhalten der Unternehmung beschreiben. Sie sind vom gewaehlten Modellierungsansatz abhaengig.

Einige Beispiele sollen dies verdeutlichen:

- Bei der fachlichen Modellierung, wie sie von den meisten klassischen CASE-Tools unterstuetzt wird, ergaenzt eine Funktionssicht, auch als Funktionsmodell bezeichnet, die Datensicht.

- Im Aris-Ansatz von Professor Scheer ergeben Daten-, Steuerungs-, Funktions- und Organisationssicht zusammen das fachliche Modell der Unternehmung.

- Grundlage des objektorientierten Modellierungsansatzes OMT ist das Objektmodell, welches als eine um das Verhalten der Datenobjekttypen erweiterte Datensicht verstanden werden kann. Dieses Objektmodell wird um ein dynamisches und ein Funktionsmodell ergaenzt.

Im Kontext des jeweiligen Modellierungsansatzes ergeben diese Sichten zusammen im Idealfall ein konsistentes und vollstaendiges, struktur- und verhaltenstreues Unternehmensmodell. Das UDS allein stellt aber die betriebswirtschaftlichen Zusammenhaenge der Unternehmung nur unvollstaendig dar. Zudem ist es staerker am Informationssystem beziehungsweise an der Anwendung als an betriebswirtschaftlichen Zusammenhaengen orientiert.

So koennen zum Beispiel die betrieblichen Leistungen und die Leistungsbeziehungen zwischen Teilsystemen des Unternehmens und der Umwelt kaum explizit erfasst werden.

Das UDS - wie auch die anderen Sichten eines Unternehmensmodells - sind in Abhaengigkeit vom jeweiligen Modellierungsansatz in einen zugehoerigen Architekturrahmen eingebettet, im folgenden als Unternehmensarchitektur bezeichnet. Eine Unternehmensarchitektur wird im wesentlichen spezifiziert durch die verwendeten Modell- beziehungsweise Beschreibungsebenen und ihren Beziehungen untereinander.

Eine Modellebene ist dadurch gekennzeichnet, dass sie eine vollstaendige Spezifikation des zugrundeliegenden betrieblichen Systems unter einem bestimmten Blickwinkel umfasst. So gehoeren zum Beispiel das fachliche Modell und die Entwurfsspezifikation eines Anwendungssystems unterschiedlichen Modellebenen an, waehrend Daten- und Funktionssicht zu einer Modellebene gehoeren.

Eine notwendige Voraussetzung fuer einen methodisch fundierten Modellierungsansatz ist ein integriertes Metamodell, das fuer jede Modellebene den Beschreibungsrahmen fuer das Unternehmensmodell vorgibt und anhand dessen die einzelnen Sichten auf das Unternehmensmodell durch Projektion abgeleitet werden. Zum Beispiel stellt das UDS, das heisst die Datensicht, eine Projektion auf die Datenobjekttypen und Beziehungen eines umfassenden Unternehmensmodells dar. In bezug auf dieses Metamodell wird auch die Konsistenz und Vollstaendigkeit des Unternehmensmodells und seiner verschiedenen Sichten ueberprueft.

Da das UDS bei der herkoemmlichen Vorgehensweise separat und zeitlich vor den anderen Sichten des Unternehmensmodells entwickelt wird, sind Aussagen ueber seine Konsistenz und Vollstaendigkeit in bezug auf diese anderen Sichten nicht moeglich. Es kann also zum Beispiel vorkommen, dass bei der Ergaenzung der Daten um eine Funktionssicht Inkonsistenzen und Unvollstaendigkeiten des UDS sichtbar werden. Die separate Entwicklung des UDS gefaehrdet die globale Konsistenz und Vollstaendigkeit in bezug auf das gesamte Unternehmensmodell. Ausserdem laesst sich eine Strukturierung des UDS nach betrieblichen Funktionsbereichen ohne Kenntnis der Funktionssicht nicht durchfuehren.

Grundsaetzlich kann sich jede Funktion auf beliebige Datenobjekttypen und Beziehungen des UDS beziehen. Ohne die Einbeziehung weiterer Sichten stellt daher das UDS einen schwer handhabbaren "monolithischen Block" dar.

Die Begriffe Geschaeftsprozess, Geschaeftsprozessmodellierung und - optimierung sowie die entsprechenden englischen Begriffe Business Process, Business Process Modeling und Business Process Redesign beherrschen derzeit die fachliche Diskussion im Bereich der Analyse und Gestaltung betrieblicher Systeme. Handelt es sich hier lediglich um Schlagwoerter und Modeerscheinungen?

Aus methodischem Blickwinkel kann die zunehmende Fokussierung auf Geschaeftsprozesse und Geschaeftsprozessmodelle als Versuch interpretiert werden, die Analyse und Gestaltung betrieblicher Systeme staerker als bisher auf dynamische, verhaltensorientierte Modelle zu stuetzen. Der Grund dafuer liegt in den zunehmenden Anforderungen an die Anpassungsfaehigkeit von Unternehmen. Statische, zustandsorientierte Modelle erweisen sich zunehmend als ungeeignet.

Im folgenden werden Geschaeftsprozesse und Geschaeftsprozessmodelle unter dem Blickwinkel des Unternehmensmodells und der Unternehmensarchitektur analysiert.

Als Beispiel dient zunaechst die Aris-Architektur. Aris stellt Geschaeftsprozesse und Geschaeftsprozessmodelle in den Mittelpunkt eines Unternehmensmodells und dokumentiert dadurch die angesprochene Umorientierung von einer daten- zu einer geschaeftsprozesszentrierten Modellierung. In Aris werden Geschaeftsprozesse in Form einer Datensicht, einer Funktionssicht und einer Organisationssicht modelliert.

Die Beziehungen zwischen diesen drei Sichten werden durch eine vierte, die Steuerungssicht, geschaeftsprozessorientiert hergestellt. Die Steuerungssicht fokussiert dabei auf den Ablauf des Geschaeftsprozesses. Als Repraesentationsform fuer die Steuerungssicht werden zum Beispiel ereignisgesteuerte Prozessketten verwendet, die aus Funktionen (Elemente der Funktionssicht) und Ereignissen (Elemente der Datensicht) bestehen.

Den Funktionen sind Datenelemente und Informationsobjekte (Elemente der Datensicht) sowie Elemente der Organisationssicht zugeordnet. In Aris gehoeren diese vier genannten Sichten genau einer Modell- beziehungsweise Beschreibungsebene an. Sie bilden zusammen ein umfassendes Unternehmensmodell. Aus der Sicht der Unternehmensarchitektur erfolgt die fachliche Modellierung eines betrieblichen Systems somit in einer Ein-Ebenen- Fachkonzeptarchitektur. (Weitere Beschreibungsebenen, die hier nicht betrachtet werden sollen, sind fuer das DV-Konzept und die Implementierung vorgesehen.)

Als Alternative moechte ich einen Ansatz zur Modellierung von Geschaeftsprozessen vorstellen, den von Ferstl und Sinz entwickelten Modellierungsansatz des Semantischen Objektmodells (SOM-Ansatz). Die Unternehmensarchitektur des SOM-Ansatzes sieht drei fachliche Modellebenen eines betrieblichen Systems vor:

- Der "Unternehmensplan" ist ein Modell der Aussensicht eines betrieblichen Systems und enthaelt unter anderem die Abgrenzung der betrieblichen Realitaet, die Wertschoepfungsketten der Unternehmung sowie die Ziele, Strategien und Erfolgsfaktoren.

- "Geschaeftsprozessmodelle" modellieren die Innensicht eines betrieblichen Systems. Sie werden im SOM-Ansatz als Loesungsverfahren fuer die Umsetzung des Unternehmensplans verstanden. Geschaeftsprozessmodelle bestehen aus betrieblichen Objekten (fachliche betriebliche Einheiten), die in betrieblichen Transaktionen Leistungspakete und Lenkungsnachrichten austauschen. Jedem betrieblichen Objekt sind Aufgaben zugeordnet, die auf dem Zustandsraum (objektinterner Speicher) des Objekts operieren und die Transaktionen, an denen das Objekt beteiligt ist, durchfuehren. Ereignisse steuern die Aufgabendurchfuehrung.

- "Anwendungssystem-Spezifikationen": Anwendungssysteme stellen Ressourcen zur Automatisierung von Geschaeftsprozessen dar. Auf der dritten Modellebene werden Anwendungssysteme aus fachlicher Sicht spezifiziert. Neben der im SOM-Ansatz vorgesehenen, objektorientierten Spezifikation ist hier auch eine klassische Spezifikation, bestehend aus Daten- und Funktionssichten fuer die einzelnen Teil-Anwendungssysteme, moeglich.

Der SOM-Ansatz beruecksichtigt Prozesse

Dem SOM-Ansatz liegt ein erweitertes Verstaendnis von Geschaeftsprozessen zugrunde. Jeder Geschaeftsprozess spezifiziert

- die Erstellung und Uebergabe einer oder mehrerer Leistungen an die Kunden dieses Prozesses (Leistungssicht des Geschaeftsprozesses). Die Beziehungen zwischen Geschaeftsprozessen folgen dem Client-Server-Prinzip;

- die Koordination der betrieblichen Objekte bei der Erstellung und Uebergabe von Leistungen (Lenkungssicht des Geschaeftsprozesses). Hierzu werden zwei ausgewaehlte Koordinationsprinzipien, das Verhandlungs- und das Regelungsprinzip, verwendet;

- den Ablauf betrieblicher Aufgaben in Form von Vorgaengen (Ablaufsicht des Geschaeftsprozesses). Dies ist die auch bei anderen Modellierungsansaetzen verwendete Sicht.

Geschaeftsprozessmodelle bilden im SOM-Ansatz somit eine eigene Modellebene in einer Unternehmensarchitektur. Innerhalb dieser Modellebene wird jeder einzelne Geschaeftsprozess in Form eines betrieblichen Objekts, welches Struktur und Verhalten kapselt, sowie einer oder mehrerer Transaktionen, modelliert. Mit Hilfe dieser Transaktionen sind die Objekte untereinander schwach gekoppelt. Die einzelnen Geschaeftsprozesse lassen sich innerhalb des Geschaeftsprozessmodells durch Zerlegung von Objekten und Transaktionen hierarchisch verfeinern.

Das Geschaeftsprozessmodell kann nach meiner Einschaetzung in der Mehrebenen-Fachkonzeptarchitektur des SOM-Ansatzes das unternehmensweite Datenschema als zentrales fachliches Modell und als Spezifikations- und Integrationsplattform fuer betriebliche Informations- und Anwendungssysteme abloesen.

Die Zusammenhaenge lassen sich anhand der beiden Modellebenen in der Abbildung auf Seite 66 nachvollziehen (die Ebene des Unternehmensplans wird im folgenden nicht betrachtet). Die dort gezeigte Ebene des Geschaeftsprozessmodells umfasst Teilmodelle fuer die einzelnen Geschaeftsprozesse, die ihrerseits weiter hierarchisch verfeinert werden koennen.

Leistungstransaktionen zwischen betrieblichen Objekten modellieren Client-Server-Beziehungen zwischen Geschaeftsprozessen. Lenkungstransaktionen modellieren die Koordination betrieblicher Objekte bei der Erstellung und Uebergabe von Leistungen. In der Abbildung liefert das betriebliche Objekt "Vertrieb" Leistungen an das Umweltobjekt "Kunde", das betriebliche Objekt "Produktion" liefert Leistungen an Vertrieb.

Auf der dargestellten Zerlegungsebene begruenden die Objekte "Produktion" und "Vertrieb" zusammen mit ihren zugehoerigen Transaktionen jeweils einen Geschaeftsprozess.

- Auf der Ebene der Anwendungssystem-Spezifikationen werden die einzelnen Anwendungen zur Unterstuetzung der Geschaeftsprozesse innerhalb des Geschaeftsprozessmodells abgegrenzt. Dabei wird in Abhaengigkeit vom Zerlegungsgrad des Geschaeftsprozesses fuer ein oder mehrere betriebliche Objekte ein konzeptuelles Datenschema (im SOM-Ansatz ein konzeptuelles Objektschema) entwickelt. Seine Grobstruktur laesst sich unmittelbar aus dem Geschaeftsprozessmodell ableiten.

Das Datenschema spezifiziert die objektinternen Speicher der zugehoerigen betrieblichen Objekte sowie die Datenschnittstellen der beteiligten Transaktionen. Die einzelnen Datenschemata sind indirekt ueber die Transaktionen des Geschaeftsprozessmodells gekoppelt. Dabei spezifizieren die Transaktionen zwischen zwei betrieblichen Objekten ein fachliches Protokoll, durch das die Konsistenz der Daten gewaehrleistet wird.

Die Integrationsbeziehungen zwischen betrieblichen Teilsystemen werden somit auf der Ebene des Geschaeftsprozessmodells und nicht auf der des Datenschemas beschrieben. Das UDS wird als Integrationsplattform durch das Geschaeftsprozessmodell ersetzt. Aus methodischer Sicht erfolgt dabei ein Uebergang von der Datenintegration zur Objektintegration.

Welche Auswirkung hat diese Konzeption auf die eingangs beschriebenen Probleme der Entwicklung und Nutzung von unternehmensweiten Datenschemata?

- Die zweistufige Modellierung von Geschaeftsprozessmodellen und von Datenschemata fuer einzelne betriebliche Objekte fuehrt zu einer wirksamen Unterstuetzung bei der Beherrschung der Komplexitaet betrieblicher Systeme. Die einzelnen Datenschemata sind aus Aussensicht gekapselt. Sie lassen sich isoliert entwickeln. Gegebenenfalls koennen fuer die Beschreibung der einzelnen Datenschemata sogar unterschiedliche Meta-Modelle verwendet werden.

- Durch das Hierarchiemodell fuer Geschaeftsprozesse im SOM-Ansatz und die Ableitung der Grobstruktur des konzeptuellen Datenschemas aus dem Geschaeftsprozessmodell vereinfacht sich das Konfigurations- Management.

- Die Kooperation mit den betriebswirtschaftlichen Fachabteilungen konzentriert sich auf die Erstellung des Geschaeftsprozessmodells. Dessen Elemente, wie Leistungstransaktionen, Lenkungstransaktionen und Aufgaben, sind der unmittelbaren Erfahrungswelt der Fachabteilung entnommen und erlauben eine umfassende Modellierung der fachlichen Zusammenhaenge aus betriebswirtschaftlicher Sicht. Hierdurch wird unter anderem die Modellvalidierung unterstuetzt.

- Die Client-Server-Beziehungen zwischen den Prozessen des Geschaeftsprozessmodells unterstuetzen dessen Rekonfiguration. In den zugehoerigen Datenschemata schlagen sich diese Rekonfigurationen allenfalls in bezug auf Schnittstellenspezifikationen nieder. Dies erhoeht die Flexibilitaet des Unternehmensmodells.

Im Bereich der Anwendungssysteme haben Client-Server-Architekturen laengst Eingang in die Unternehmen gefunden. Im Vergleich dazu muten UDS mit ihren monolithischen Strukturen wie Relikte aus der Mainframe-Welt an. Wann beginnen wir, die unbestrittenen Vorteile von Client-Server-Architekturen auch fuer die fachliche Unternehmensmodellierung zu nutzen?

Literatur:

Ferstl O.K., Sinz E.J.: Grundlagen der Wirtschaftsinformatik. Band 1, 2. Auflage, Oldenbourg, Muenchen1994;

Ferstl O.K., Sinz E.J.: Multi-Layered Development of Business Process Models and Distributed Business Application Systems. An Object-Oriented Approach. 2nd Edition. Bamberger Beitraege zur Wirtschaftsinformatik Nr. 20, November 1994 http://www.seda.sowi.uni-bamberg.de/lehrstuhl/publikationen/ ;

Ferstl O.K., Sinz E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschaeftsprozessen. Erscheint in: Wirtschaftsinformatik 37 (1995), 3;

Gerard P.: Unternehmensdaten-Modelle haben Erwartungen nicht erfuellt. In: Computerwoche 42, 15. Oktober 1993;

Rumbaugh J., Blaha M., Premerlani W.,

Edddy F., Lorensen W.: Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, New Jersey 1991;

Scheer A.-W.: Wirtschaftsinformatik. Referenzmodelle fuer industrielle Geschaeftsprozesse. 4. Auflage, Springer, Berlin 1994.

* Prof. Dr. Elmar j. Sinz, Ott-Friedrich-Universitaet Bamberg, Lehrstuhl fuer Wirtschaftsinformatik (insbesondere Systementwicklung und Datenbankanwendung).