Identifikation und Anwendung semantischer ... - CEUS

ceus.bayern.de

Identifikation und Anwendung semantischer ... - CEUS

Identifikation und Anwendung semantischer

Modellbausteine für Managementsichten

Michael Böhnlein 1 , Dr. Roland Holten 2 , Ralf Knackstedt 2 ,

Achim Ulbrich-vom Ende 1

1

2

Otto-Friedrich-Universität Bamberg, Lehrstuhl für Wirtschaftsinformatik,

insb. Systementwicklung und Datenbankanwendung,

Feldkirchenstr. 21, 96045 Bamberg,

Tel.: +49 (0)951/863-2512, Fax: +49 (0)951/9370163,

E-Mail: {michael.boehnlein | achim.ulbrich}@sowi.uni-bamberg.de

Westfälische Wilhelms-Universität Münster, Institut für Wirtschaftsinformatik,

Lehrstuhl für Wirtschaftsinformatik und Informationsmanagement,

Steinfurter Straße 109, 48149 Münster,

Tel.: +49 (0)251/83-38100, Fax: +49 (0)251/83-38109,

E-Mail: {roland.holten | ralf.knackstedt}@wi.uni-muenster.de


Identifikation und Anwendung semantischer

Modellbausteine für Managementsichten

Zusammenfassung: Data-Warehouse-Systeme stellen eine etablierte Basistechnologie

für dispositive Informationssysteme dar. Die Umweltdynamik bedingt eine

stetige Veränderung der Informationsbedarfe des Managements und resultiert in

der Notwendigkeit einer Evolution der Data-Warehouse-Systeme. Den Entwicklern

und Betreibern von Data-Warehouses mangelt es an methodischer Unterstützung

zur Bewältigung dieser Herausforderung. Der Beitrag konzipiert auf der

Basis einer komprimierten Problemanalyse einen Lösungsvorschlag zur Unterstützung

des evolutionären Data-Warehousings. Die vorgestellte Methodik integriert

einen Ansatz zur Informationsbedarfsanalyse auf der Grundlage von Prozessmodellen,

eine Modellierungstechnik zur fachkonzeptionellen Spezifikation

von Data-Warehouses und Konzepte zur umfassenden Werkzeugunterstützung des

Design- und Implementierungsprozesses. Die Anwendung der Methodik wird

anhand eines durchgängigen Beispiels illustriert.

Schlüsselworte: Data-Warehousing, Entwicklungsumgebung, Evolution, Informationsbedarfsanalyse,

Informationsobjektmodelle, SOM-Methodik

1 Herausforderungen des Data-Warehousings

Data-Warehouse-Systeme haben sich als Basis dispositiver, Managemententscheidungen

unterstützender Applikationen etabliert [Wint00]. Die Entwicklung und

der Betrieb von Data-Warehouse-Systemen (das Data-Warehousing) stellt allerdings

noch immer eine Herausforderung dar. Insbesondere für die folgenden

Hauptschwierigkeiten sind bisher keine befriedigenden, aufeinander abgestimmten

Antworten gefunden worden.

Mit der technologischen Möglichkeit grundsätzlich sehr große Datenmengen zur

Verfügung zu stellen, ist die Gefahr der Überflutung mit irrelevanten Informationen

verbunden. Der Navigationsraum durch den Datenbestand, der einem Manager

zur Verfügung gestellt wird, sollte auf die von ihm wahrgenommenen Steuerungs-

und Regelungsaufgaben zugeschnitten werden [BeHo98]. Die Gestaltung

dispositiver Informationssysteme bedingt eine Soll-Konzeption der Informationslogistik

und stellt daher notwendiger Weise einen kreativen Akt dar, der nicht

vollständig automatisiert werden kann. Ein Großteil der vorgeschlagenen Methoden

orientiert sich an Ist-Informationsflüssen bzw. beruht auf der Befragung von

Managern [Holt99, S. 119-125]. Da Manager häufig ihren Informationsbedarf nur

unzureichend spezifizieren können, ist eine auf Befragungen von Managern basie-


ende Informationsbedarfsanalyse allein ungenügend. Bezüglich der Verfügbarkeit

von Methoden zur Unterstützung des kreativen Aktes der Begründung von Informationsbedarfen

ist daher ein Methodendefizit zu konstatieren.

Die zahlreichen Vorschläge zur fachlichen Modellierung von Data-Warehouses

belegen, dass sich bisher keine Modellierungstechnik als allgemein anerkannt

durchsetzen konnte [Holt00a, S. 10]. Die Wahl oder Konstruktion einer geeigneten

Modellierungstechnik zur Dokumentation des Fachkonzepts stellt daher eine

weitere Schwierigkeit des Data-Warehousings dar.

In dynamischen Umwelten gestaltet sich der Betrieb des Data-Warehouse-Systems

notwendiger Weise evolutionär. Die Anpassungen haben unterschiedliche Reichweite.

Vom Austausch von Speichertechnologien bleiben die fachkonzeptionellen

Spezifikationen unberührt. Die Einführung neuer operativer Applikationen bedingt

die Anpassung der Komponenten der ETL-Schicht (Extraktion, Transformation,

Laden) des Data-Warehouses. Ist die Anpassung des operativen Informationssystems

mit Veränderungen der operativen Prozesse verbunden, hat dies Rückwirkungen

auf die Steuerungs- und Regelungsaufgaben der Manager und bedingt

damit Veränderungen ihres Informationsbedarfs. Die Weiterentwicklung des Data-

Warehouse-Systems muss dann sämtliche Projektphasen von der Fachkonzepterstellung

über die DV-Konzeption bis hin zur Implementierung wieder durchlaufen.

Um die Evolution des Data-Warehouse-Systems wirtschaftlich zu gestalten,

muss vermieden werden, dass mit den Anpassungen des Systems jeweils ein umfangreicher

Neuaufwurf verbunden ist. Deshalb bedarf es einer konsistenten, projektphasenübergreifenden

Verwaltung aller generierten Lösungskomponenten, die

deren Wiederverwendung fördert. Zur Bewältigung dieser Aufgabe werden domänenspezifische

CASE-Werkzeuge benötigt. Kommerziell verfügbare Lösungen

sind ausschließlich auf Teilprobleme der Data-Warehouse-Entwicklung fokussiert.

Ein umfassender, integrierter Lösungsansatz fehlt.

Die Veränderungsprozesse können für einzelne Steuerungs- und Regelungsaufgaben

nicht isoliert durchlaufen werden. Statt dessen muss die abteilungsübergreifende

Konsistenz der zur Verfügung gestellten Daten sichergestellt werden, um

Kommunikationsdefekte zwischen Entscheidungsträgern zu vermeiden. Bestimmte

betriebswirtschaftliche Konzepte [HoKB01], wie z. B. Efficient Consumer

Response (ECR), erfordern sogar eine unternehmensübergreifende Konsistenzsicherung.

In den Prozess des Data-Warehousings muss daher eine geeignete

Instanz integriert werden, welche die gemeinsame Verwendung von Lösungskomponenten

sicherstellt.

Angesichts der hier hervorgehobenen vier Herausforderungen des Data-

Warehousings ist es unwahrscheinlich, dass Data-Warehouse-Projekten bei einem

intuitiven, von praktischen Ad-hoc-Entscheidungen geleiteten Vorgehen langfristiger

Erfolg beschieden ist. Deshalb wird im Folgenden ein systematisches Vorgehen

vorgeschlagen, das zur Bewältigung der Anforderungen beiträgt.


2 Methodik zur Identifikation und Anwendung

semantischer Modellbausteine

2.1 Semantische Modellbausteine für die fachkonzeptionelle

Spezifikation von Data-Warehouses

Die Aufgabe der fachkonzeptionellen Spezifikation der Daten, die einem Manager

durch ein Data-Warehouse zur Verfügung gestellt werden sollen, wird hier interpretiert

als die Aufgabe der Konstruktion eines Navigationsraums durch Daten.

Zur Beschreibung dieses Navigationsraums wird im Folgenden eine Sprache verwendet,

deren Konstruktion ausführlich in [Holt00a] dokumentiert ist. Die Konstruktion

erfolgte unter Verwendung der Objekttypenmethode von WEDEKIND

[Wede81]. Die eigentliche Navigation kann zum Beispiel in Form der Operationen

Rotation, Ranging, Dicing, Drill-down und Roll-up eines OLAP-Systems [Holt99,

S. 49-52] ermöglicht werden. Der Navigationsraum wird durch Bezugsobjekte und

Kennzahlen aufgespannt [Holt99, S. 71-107].

Bezugsobjekte stellen die für die Managemententscheidung relevanten Untersuchungsgegenstände

dar [Rieb79, S. 869]. Bezugsobjekte, die – abhängig vom

Modellierungszweck – untereinander eine besonders starke Bindung aufweisen,

werden zu Dimensionen zusammengefasst (vgl. den konzeptionellen Sprachaspekt

in Abbildung 1). Die Bezugsobjekte werden innerhalb einer Dimension häufig

hierarchisch gegliedert, wodurch sich die Bezugsobjekte nach Hierarchiestufen

ordnen lassen. Dimensionen selbst können zudem in Dimensionsgruppen geordnet

werden, wenn eine Art von Bezugsobjekten nach verschiedenen Kriterien zu analysieren

ist. Kombinierte Bezugsobjekte können sich aus einem Bezugsobjekt oder

mehreren Bezugsobjekten verschiedener Dimensionen zusammensetzen. Den

Navigationsraum durch die Bezugsobjekte festzulegen ist gleichbedeutend mit der

Spezifikation einer bestimmten Menge kombinierter Bezugsobjekte. Die Menge

der kombinierten Bezugsobjekte lässt sich über die Angabe der analysierbaren

Dimensionen einschränken. Diese Spezifikation kann weiter verfeinert werden,

indem zu den Dimensionen Dimensionsausschnitte definiert werden.

Kennzahlen erfassen quantitativ darstellbare Sachverhalte in konzentrierter Form.

[Reic97, S. 19]. Sie spezifizieren die für die Managementaufgaben relevanten

Aspekte der kombinierten Bezugsobjekte. Kennzahlensysteme ordnen Kennzahlen

nach rechentechnischen oder rein sachlogischen Zusammenhängen [Grof92, S.

76]. Der Navigationsraum durch die Kennzahlen lässt sich durch die Angabe eines

Kennzahlensystems spezifizieren.

Durch das Verknüpfen einer über Dimensionen spezifizierten Menge von kombinierten

Bezugsobjekten mit einem Kennzahlensystem erhält man eine Menge von

Fakten. Fakten stellen Paare von Kennzahlen und kombinierten Bezugsobjekten

dar. Die Spezifikation einer Menge von Fakten ist geeignet den Navigationsraum


zu beschreiben, der einem Manager für seine Steuerungs- und Regelungsaufgaben

zur Verfügung gestellt werden soll. Die Menge an Fakten, die auf eine spezielle

Steuerungs- und Regelungsaufgabe zugeschnitten ist, wird kurz Informationsobjekt

genannt.

Konzeptioneller Sprachaspekt

Repräsentationeller Sprachaspekt

N,T

D-HS-Zuordnung

(1,1)

D-DG-Zuordnung

(1,1)

Dimension (1,n)

(1,n)

(1,n)

Kennzahl (1,n)

Kombiniertes

Bezugs-

(1,n)

objekt

K-BO-

Koordinaten

Dimensions-

(1,n)

(1,n)

bezugs-

objekt

(0,1)

(0,n)

DBO-Hierarchie

(1,1)

Dimensionsgruppe

(1,n)

Bezugsobjekt

Hierarchiestufe

DBO-

DHS-Zuordnung

Fakt

(1,n)

Kennzahlensystem

(1,n)

(0,1)

(0,n)

K-KS-Zuordnung

K-KS-

Hierarchie

(1,n)

Informationsobjekt

(1,n)

IO-S/RA-

Zuordnung

Steuerungs-/ (1,1)

Regelungsaufgabe

IO-F-Zuordnung

Navigationsraum Bezugsobjekte

Dimensionsgruppe

1

Dimensionsgruppe

2

...

Nicht obligatorische

Dimensionsgruppen

(z. B. Artikel, Geschäftsstellen,

Kunden, etc.)

Dimensionsgruppe

n

Obligatorische

Dimensionsgruppen

(Zeit, Wertansatz)

N,T

N,T

N,T

Dimension (0,m

)

1.1

...

Dimension (0,m

)

1.M

Dimension (0,m

)

N.1

...

Dimension (0,m

)

N.O

Navigationsraum Kennzahlen

Kennzahlensystem

)

(0,m

p

(z. B. das Du Pont-System

oder das RL-Kennzahlensystem)

Dimension

2.1

...

Dimension

2.N

Kombiniertes

(0,m

)

Bezugsobjekt

q

Informationsobjekt

t

Informationsobjektmodell

zur Steuerungs-/

Regelungsaufgabe s

Abbildung 1: Sprache zur fachkonzeptionellen Spezifikation von Data-Warehouses

Zur grafischen Repräsentation der Spezifikation des aufgabenspezifischen Navigationsraums

werden Informationsobjektmodelle verwendet, die sich an die Notation

der Entity-Relationship-Modelle [Chen76; BeSc96, S. 31-37] anlehnen (vgl.

den repräsentationellen Sprachaspekt in Abbildung 1) [HoKn99]. Im oberen Bereich

des Modells erfolgt über die Nennung der Dimensionen, die Dimensionsgruppen

zugeordnet sind, die Spezifikation der Navigationsmöglichkeiten durch

die Bezugsobjekte. Im unteren Bereich wird über die Nennung eines Kennzahlensystems

die relevante Menge an Kennzahlen festgelegt. Für die detaillierte Beschreibung

der Dimensionen sind gesonderte Modelle vorgesehen.

Informationsmodelle lassen sich aus den Modellelementen Dimensionen, Dimensionsgruppen,

Kennzahlen und Kennzahlensystemen zusammensetzen. Diese

Elemente werden hier semantische Modellbausteine genannt. Mit der beschriebenen

Sprache wird die Basis für eine domänenspezifische Modellierungstechnik

gelegt. Die übrigen Herausforderungen des Data-Warehousings werfen drei offene

Fragestellungen im Zusammenhang mit den semantischen Modellbausteinen auf:


1. Wie können die relevanten semantischen Modellbausteine identifiziert werden

2. Wie ist eine unternehmensweite Konsistenz in der Definition und Verwendung

semantischer Modellbausteine sicherzustellen

3. Wie kann die Anwendung semantischer Modellbausteine in einem dynamischen

Umfeld unterstützt werden

Die im Folgenden vorgestellte Methodik stellt ein geschlossenes Lösungskonzept

zur Bewältigung dieser Probleme vor.

2.2 Überblick über die Methodik

Wesentliche Komponenten einer Methodik stellen Methoden dar. Eine Methode

ist allgemein ein nach Mittel und Zweck planmäßiges Verfahren, das zu technischer

Fertigkeit bei der Lösung theoretischer und praktischer Aufgaben führt [Lore95].

Kennzeichnend für eine Methode ist somit ein Aufgabentyp, welcher der

Methode ihren Zweckbezug verleiht, und ein Satz von Vorschriften (Regeln,

Techniken und Heuristiken), die der Problemlösung dienen. Im Rahmen der Softwareentwicklung

eingesetzte Methoden sind durch die Arbeit mit Modellen geprägt.

Softwareentwicklung im Allgemeinen und Data-Warehousing im Speziellen

kann als ein kreativer Prozess der Transformation von Modellen aufgefasst werden

[Teub99, S. 94-95]. Die eingesetzten Methoden schaffen Modelle als Artefakte

und verwenden Modelle - soweit sinnvoll - auch als Input. Eine Untermenge der

Vorschriften einer Methode wird daher durch eine Modellierungstechnik festgelegt.

Eine Modellierungstechnik besteht aus einer Sprache und einer Handlungsanleitung

zur allgemeinen Verwendung dieser Sprache. Die Sprache selbst beinhaltet

einen konzeptionellen und einen repräsentationellen Aspekt. Darüber hinaus bedarf

es für eine Methode Vorschriften, die festlegen, wie Input-Artefakte auszuwerten

sind, und die die Konstruktion des Output-Artefakts durch Hinweise zur

Problemlösung unterstützen. Diese Vorschriften müssen eng mit der Modellierungstechnik

abgestimmt sein [HoKn01].

Eine Methodik ist gekennzeichnet durch einen Aufgabentyp, der auch der Methodik

einen bestimmten Zweck zuweist, ein Vorgehensmodell und eine Dokumentenstruktur

[Teub99, S. 100-104]. Das Vorgehensmodell definiert eine logische

und damit mittelbar auch zeitliche Verknüpfung von Aufgabentypen, innerhalb

derer bestimmte Methoden einzusetzen sind. Die Dokumentenstruktur legt Vorschriften

zur Integration der im Rahmen der Anwendung der Methoden geschaffenen

Artefakte fest. Methoden, die innerhalb von Methodiken angewendet werden,

weisen zweierlei Besonderheiten auf. Erstens erhält der Aufgabentyp der Methode

entsprechend ihrer Verwendung innerhalb der Methodik eine genauere Festlegung.

Zweitens müssen die Vorschriften der Methode so erweitert bzw. modifiziert

werden, dass die Integration der geschaffenen Artefakte aller Methoden der


Methodik sichergestellt wird. Die Artefakte, die im Rahmen einer Methodik geschaffen

werden, werden Dokumente genannt, um ihren gemeinsamen Bezug auf

die Vorschriften der Dokumentenstruktur zu verdeutlichen [HoKn01].

Zur Konstruktion einer Methodik ist zunächst ihr Zweck festzulegen. Anschließend

ist das Vorgehensmodell und die Dokumentenstruktur zu definieren. Regelmäßig

kann auf vorhandene Methoden und Methodiken zurückgegriffen werden.

Allerdings muss hierbei die beschriebene Anpassung der Methoden hinsichtlich

der Aufgabentypspezifikation und der Dokumententypdefinition stattfinden. Unter

Umständen sind zur Unterstützung von bestimmten Aufgabentypen neue Methoden

zu entwickeln.

Prozessmodell

Umfeld der Methodik

Umweltmonitoring

Prozessgestaltung

Zielsetzung

Prozessmonitoring

Dokumentenstruktur

Implementierte

Managementsicht

Prozessmodell

Modellbausteinvorschlagsliste

Evolutionäre

Anpassung

Bibliothek

semantischer

Zielsetzung

Modellbausteine

Informationsobjektmodell

Konstruktion

der Bibliothek

Bibliothek

semantischer

Modellbausteine

Unterstützung

des

kreativen

Aktes

Unternehmensweite

Konsistenz

Modellierung

-technik

Ableitung von

Modellbausteinen

Fachkonzeptionelle

Spezifikation

Vorgehensmodell

Implementierte

Managementsicht

DV-

Konzeption

und Implementierung

Modellbausteinvorschlagsliste

Informationsobjektmodell

Legende:

Problem

des Data

Warehousings

Dokumententyp

Aufgabentyp

Sachlogische Abfolge

Vorschriften zur

inhaltlichen Integration

Abbildung 2: Methodik zur Identifikation und Anwendung semantischer Modellbausteine

Die Rahmenbedingungen des Einsatzes der hier vorgeschlagenen Methodik wurden

in Abschnitt 1 erläutert. KIMBALL fordert eine an Geschäftsprozessen orientierte

Entwicklungsstrategie für Data-Warehouses [Kimb96, S. 25-27]. Die Methodik

wertet daher zur Unterstützung des kreativen Akts der Informationsbedarfsanalyse

Prozessmodelle aus und unterstützt die Implementierung geeigneter

Managementsichten (vgl. Abbildung 2). Durch Auswertung der spezifizierten

Datenmengen können Probleme erkannt werden, die eine Veränderung der verfolgten

Zielsetzung bedingen, was eine Umgestaltung der Prozesse motivieren

kann. Für die neu gestalteten Prozesse ist - den Zyklus schließend - wiederum eine

Anpassung der Managementsichten notwendig. Die hiermit verbundene Data-

Warehouse-Evolution wird von der Methodik unterstützt.


Der erste Aufgabentyp des Vorgehensmodells der Methodik beinhaltet eine methodische

Analyse von Zielsetzungen und Prozessmodellen zur Identifikation

relevanter semantischer Modellbausteine. Die auf Prozessmodellen ausgerichtete

Informationsbedarfsanalyse fokussiert die innerhalb der Prozesse erbrachten Leistungen.

Die Methodik dient daher zur Gestaltung der informationellen Unterstützung

von Entscheidungen, die primär das Management von Leistungen in Prozessen

zum Gegenstand haben. Data-Warehousing für Aufgaben des strategischen

und normativen Managements liegen außerhalb des Fokus der vorliegenden Arbeit,

da für diese zusätzlich der intensive Einbezug weiterer unternehmensexterner

Daten notwendig ist. Das Ergebnis der Prozessmodellanalyse bildet die Grundlage

für den Aufbau einer Bibliothek semantischer Modellbausteine. Die Bibliothek

fungiert als zentralisierte Koordinationsinstanz und stellt die unternehmensweite

Konsistenz der Verwendung der Modellbausteine sicher. Die fachkonzeptionelle

Spezifikation der Managementsichten gestaltet sich als konstruktive Zusammensetzung

von Informationsobjektmodellen aus semantischen Modellbausteinen, die

der Bibliothek entnommen werden. Die Ergebnisse der Prozessanalyse werden

nochmals referenziert, um die für die speziellen Steuerungs- und Regelungsaufgaben

relevanten Bausteine der Bibliothek zu identifizieren. Beim Aufbau der Bibliothek

und der fachkonzeptuellen Spezifikation wird auf die in Abschnitt 2.1

erläuterte Modellierungssprache zurückgegriffen. Die Umsetzung des Fachkonzepts

stellt den letzten Aufgabentyp der Methodik dar.

Die Dokumentenstruktur beschreibt Vorschriften zur inhaltlichen Integration der

Input- und Output-Dokumenttypen der Methoden. Zu integrieren sind die Definitionen

der vom Management verfolgten Zielsetzungen, die Prozessmodelle, die

abgeleiteten Hinweise auf relevante semantische Modellbausteine, die Inhalte der

Bibliothek, die Informationsobjektmodelle und die Ergebnisse der DV-Konzeption

und Implementierung. Geänderte Zielsetzungen und Prozessmodelle erfordern

eine Anpassung der fachkonzeptuellen Spezifikation der Informationsobjektmodelle,

was mit einer Erweiterung oder Anpassung der Bibliotheksinhalte einhergehen

kann. Die geänderten Anforderungen können eine Anpassung der physikalischen

Struktur des Data-Warehouses notwendig machen. Die Zusammenhänge

zwischen den Dokumenten lassen sich nur werkzeugunterstützt handhaben. Die

Dokumentenstruktur liefert eine Anforderungskonzeption für das Repository einer

CASE-Umgebung für das Data-Warehousing. Ein solches Werkzeug stellt ein

bedeutendes Hilfsmittel zur Bewältigung der Data-Warehouse-Evolution dar.

Die grundsätzliche Vorgehensweise bei Anwendung der Methodik soll im Folgenden

anhand eines Ausschnitts aus dem idealisierten Geschäftsprozessgefüge

eines Industriebetriebs aufgezeigt werden.


3 Anwendung der Methodik

3.1 Einführung in den Anwendungsbereich

Industriebetrieb

betriebliches Rechnungswesen

(extern u. intern)

Servicebereich

Finanzbuchhaltung

K & L - Rechnung

betrieblicher Geschäftsbereich

betriebliche Leistungserstellung

Beschaffungsmarkt

(Lieferanten, Arbeitsmarkt)

Beschaffung

Verbrauchsgüter

Dienstleistungen

Gebrauchsgüter

Arbeitsleistungen

Beschaffungsleistungen

Servicebereich

Produktionsleistungen

Verbrauchsgüter

Dienstleistungen

Gebrauchsgüter

Produktion

Sachgüter

Arbeitsleistungen

Bereitstellungsleistungen

Absatz

Hauptbereich

Produkt

(Sachgüterund

Dienstleistungen)

Absatzmarkt

(Kunde)

Finanzierung

Finanzmarkt

Transferzahlungen

Transferzahlungen

betriebliches Finanzwesen

Servicebereich

Staat/

Sozialversicherungen

Abbildung 3: Idealisiertes Geschäftsprozessgefüge eines Industriebetriebs [vgl. Raue94]

Ein Industriebetrieb ist gemäß Systemtheorie als ein offenes, zielgerichtetes und

soziotechnisches System zu verstehen (Abbildung 3), das sowohl materielle als

auch immaterielle Leistungen mit seiner Umwelt austauscht [FeSi01, S. 59 f.].

Von seinen Beschaffungsmärkten bezieht er in Form von Dienst- und

Arbeitsleistungen bzw. Ge- und Verbrauchsgütern einzelne

Beschaffungsleistungen, die er im Rahmen seiner innerbetrieblichen

Wertschöpfung (betriebliche Leistungserstellung) zur Produktion von Sachgütern

und begleitenden Dienstleistungen einsetzt und an seine Absatzmärkte abgibt. Die

von der Beschaffung über die Produktion zum Absatz reichende

Wertschöpfungskette wird von zwei Servicebereichen flankiert. Zum einen

erbringt das Rechnungswesen durch die Finanzbuchhaltung und K&L-Rechnung

Serviceleistungen an den betrieblichen Geschäftsbereich, während das

Finanzwesen durch Beziehung zu Staat und Finanzmärkten eine ausreichende

Finanzierung sicherstellt. Für die weiteren Betrachtungen erfolgt eine Projektion

und Detaillierung des Absatzbereichs des Industriebetriebs einschließlich seiner

Umweltkontaktstellen. Zur Vereinfachung der weiteren Ausführungen wurde die

Darstellung einzelner Managementebenen in den vorgestellten Modellen explizit

ausgeklammert.


3.2 Ableitung semantischer Modellbausteine aus

Prozessmodellen

1 2 3 4

Auswählen der Ziele

der betrachteten

Unternehmung

Analyse der

Geschäftsprozesse

Ableitung des

konzeptuellen

Objektschemas

Identifikation

initialer

Modellbausteine

Sachziele

Formalziele

Abgrenzung des

relevanten

(Teil-) Prozesses

Zuordnung

analyserelevanter

Attribute

a) Kennzahlen

b) Dimensionen

c) Integritätsbedingungen

Rückkopplung

Abbildung 4: Ableitung semantischer Modellbausteine aus Prozessmodellen

Die Methode zur Identifikation initialer semantischer Modellbausteine sieht vier

logisch aufeinander folgende Teilschritte vor, wobei jederzeit eine Rückkopplung

zu früheren Phasen zugelassen ist (Abbildung 4). Sie lehnt sich in ihren ersten drei

Schritten weitgehend an die umfassende geschäftsprozess- und objektorientierte

Modellierungsmethodik Semantisches Objektmodell (SOM) nach FERSTL und SINZ

an (vgl. u.a. [FeSi90; FeSi98]). Während diese Schritte lediglich an die spezifischen

Belange des Data-Warehousings angepasst wurden, ermöglicht der vierte

zusätzliche Schritt die methodisch fundierte Identifikation von Modellbausteinen

[BoUl00, S. 3 ff.].

• Im ersten Schritt werden die Ziele für Steuerungs- und Regelungsaufgaben des

Managements ausgewählt, die im weiteren untersucht werden sollen. Während

Sachziele Art und Zweck der betrieblichen Leistungserstellung beschreiben,

bestimmen Formalziele Art und Umfang der Sachzielerreichung [FeSi01,

S.59].

• Im Rahmen des zweiten Schritts werden bei einer Analyse der Prozesse die für

die Ziele relevanten (Teil-) Prozesse abgegrenzt. Sowohl das Zielsystem als

auch die Prozesse sollten bereits im Umfeld der Methodik (Abbildung 2) definiert

worden sein.

• Als nächstes wird auf der Grundlage des ausgewählten Prozesses das konzeptuelle

Objektschema (KOS) durch einfache Transformationsregel gebildet. Das

KOS beschreibt, vergleichbar mit einem konzeptuellen Datenschema, die für

die Abwicklung eines Prozesses benötigte Datenstruktur.

• Nach der Zuordnung analyserelevanter Attribute werden innerhalb des KOS

im letzten Schritt initiale Modellbausteine für Managementsichten identifiziert.


Die Vorgehensweise orientiert sich dabei an folgender Argumentationskette: Ziel

– Prozess – Leistung – Kennzahl – Dimension. Sie soll anhand eines Beispiels für

den Teilprozess Absatz im Folgenden weiter präzisiert werden.

3.2.1 Auswahl von Zielen der betrachteten Unternehmung

Der erste Schritt fordert eine Auswahl von Zielen für die Verfolgung von Steuerungs-

und Regelungsaufgaben des Managements. Die Zieldefinition ist ein äußerst

kreativer Prozess, bei dem vielfältige Interessensgruppen und Rahmenbedingen

zu berücksichtigen sind. Zu fordern ist eine weitgehende Zielkonkretisierung,

bei der die Einzelziele zumindest die Eigenschaften der Quantifizierbarkeit und

Operationalität aufweisen sollten [Stae91, S. 405 ff.]. Exemplarisch werden die

folgenden Sachziele für unseren idealtypischen Industriebetrieb unterstellt:

• Produktion und Vertrieb von Sachgütern und begleitende Dienstleistungen

• Reparatur und Wartung von eigengefertigten Sachgütern

• Neuproduktentwicklung

Diese Sachziele sollen unter dem Formalziel einer Gewinn-/Umsatzmaximierung

bestehen. Für die weiteren Betrachtungen erfolgt eine Fokussierung auf das Sachziel

Produktion und Vertrieb von Sachgütern und begleitende Dienstleistungen.

Die damit verbundenen konkreten Leistungen des Industriebetriebs sind die erstellten

Sachgüter bzw. die jeweiligen Dienstleistungen.

3.2.2 Analyse der Geschäftsprozesse

Das Prozessmodell beschreibt die Innensicht eines betrieblichen Systems, indem

es Lösungsverfahren zur Umsetzung der in Schritt 1 spezifizierten Ziele aufzeigt.

Modelliert wird es in Form eines strukturorientierten Interaktionsschemas (IAS),

das das Zusammenspiel von betrieblichen Objekten und Transaktionen beim Leistungsaustausch

widerspiegelt, und einer korrespondierenden verhaltensorientierten

Sicht, dem Vorgangs-Ereignis Schema (VES), das eine explizite Reihenfolgebeziehung

bei der Aufgabendurchführung betrieblicher Objekte visualisiert. Eine

ausführliche Beschreibung der SOM-Methodik und der bei der Detaillierung des

IAS angewandten Zerlegungsregeln, wie z.B. Regelungs- und Verhandlungsprinzip,

findet sich u.a. in [FeSi98; FeSi01]. Im Folgenden sollen anhand einer Detaillierung

eines IAS (Abbildung 5) die wesentlichen Zusammenhänge im Prozess

„Absatz“ veranschaulicht werden, der aus einer Kombination von nichthierarchischen

Verhandlungsstrukturen (Anbahnungs- (A), Vereinbarungs- (V) und Durchführungstransaktionen

(D)) sowie hierarchischen Regelungsstrukturen (Steuer- (S)

und Kontrolltransaktionen (K)) hervorgegangen ist (das korrespondierende VES

ist in Abbildung 9 im Anhang zu finden).


Produktion

2

V: Absatzplan

5

V: Absatzbedarf

6

D: Produktbereitstellung

S: Absatzplan

2

Absatzplanung

Vertrieb

K: Absatzmeldung

8

S: Versandauftrameldung

K: Versand-

9

5

7 S:

Abrechnung

Versand

13

K:

Abrechnungsmeldung

1

A: Absatzmarktforschung

3

A: Produktkatalog

V: Auftrag

4

7

D: Produktlieferung

Absatzmarkt

(Kunde)

Absatzlogistik

10

Versand

12

10

V: Rechnung

Absatz

S: Zahlungs-

K: Zahlungseinganeingangsavisierung

betriebliches Finanzwesen

11

D: Zahlung

Legende:

Betriebliches

Objekt

A: / V: / D:

S: / K:

Betriebliche

Transaktion

Anbahnungs-,

Vereinbarungs-,

Durchführungs-,

Steuer-,

Kontrolltransaktion

Abbildung 5: Interaktionsschema des Absatzprozesses eines Industriebetriebs

Auf der Grundlage einer Absatzmarktforschung (1) erstellt die Absatzplanung

einen entsprechenden Absatzplan. Dieser Plan wird zum einen an die Produktion

und zum anderen an den Vertrieb weitergegeben (2). Der auf Basis des Absatzplans

entwickelte Produktkatalog wird anschließend vom Vertrieb an Kunden im

jeweiligen Absatzmarkt verschickt (3). Entscheidet sich der Kunde für ein Produkt

kommt ein Auftrag zustande (4), der vom Vertrieb wiederum als Absatzbedarf an

die Produktion übermittelt und dem Versand als zukünftiger Versandauftrag mitgeteilt

wird (5). Erfolgt daraufhin eine Bereitstellung des Produkts durch die Produktion

(6), kann der Versand die Produktlieferung an den Kunden anstoßen (7)

und eine Mitteilung über eine erfolgreiche Versendung im Rahmen der Versandmeldung

an den Vertrieb weitergeben (7). Der Vertrieb gibt seinerseits die erfolgreiche

Versendung als Absatzmeldung an die Absatzplanung weiter (8) und initiiert

bei der Fakturierung eine Abrechnung der erbrachten Leistung (9). Daraufhin

verschickt die Fakturierung eine Rechnung an den Kunden (10), der diese durch

eine Zahlung beim betrieblichen Finanzwesen begleichen muss (11). Gleichzeitig

teilt sie dem betrieblichen Finanzwesen einen Termin für die Zahlungseingangsavisierung

mit (10). Nach Zahlungseingang meldet das Finanzwesen diesen dem


Versand (12), der ihn wiederum in Form einer Abrechnungsmeldung an den Vertrieb

weitergibt (13).

3.2.3 Ableitung des konzeptuellen Objektschemas

Absatzmarkt

Absatzplanung

Vertrieb

1 3

Absatzmeldung

2

Absatzplan

an

Vertrieb

Absatzmarktforschung

2

Absatzplan

an

Produktion

4

Auftrag

5

Zuordnung von

Kennzahlen

Produktkatalog

Absatzbedarf

Produktbereitstellung

Versandauftrag

Produktlieferung

6 7 8

Versand

Produktion

Hülle der

Existenzvoraussetzungen

für Produktlieferung

5

Versandrückmeldung

7

9

10

Abrechnung

Rechnung

10

11

Zahlung

12

13

Fakturierung

Zahlungseingangsavisierung

betriebl.

Finanzen

Legende

Existenzunabhängiger

Objekttyp

Existenzabhängiger

Objekttyp

Interaktionskante

Abbildung 6: Das konzeptuelle Objektschema (KOS) für den Absatzprozess

Im dritten Schritt wird aus dem weiter detaillierten Prozessmodell Absatz ein

konzeptuelles Objektschema (KOS) abgeleitet. Das KOS beschreibt die einem

Prozess zugrundeliegenden Datenstrukturen und ist vergleichbar mit einem um

objektorientierte Konzepte angereicherten, klassischen konzeptuellen Datenschema,

da die konzeptuellen Objekttypen neben dem Zustand der einzelnen Aufgaben

von betrieblichen Objekten auch Zustandsinformationen von Transaktionen

und Leistungen festhalten. Die Notation lehnt sich an das Strukturierte Entity-

Relationship Modell (SERM) nach SINZ an [Sinz88] und besitzt damit die Fähigkeit,

Existenzabhängigkeiten zwischen den beteiligten Objekttypen explizit zu

visualisieren. Deshalb werden im KOS die Objekttypen nach ihrer Existenzabhängigkeit

angeordnet. Während existenzunabhängige Objekttypen ganz links im

Diagramm dargestellt werden, nimmt der Grad der Existenzabhängigkeit von links

nach rechts sukzessive zu. Eine initiale Struktur eines KOS ist aus dem Interaktionsschema

aus Abbildung 6 in Verbindung mit der Reihenfolgebeziehung des

VES in Abbildung 9 ableitbar. Dabei werden folgende einfache Transformationsregeln

angewendet, um Abbildung 6 zu erhalten:

• Betriebliche Objekte sind immer existenzunabhängig und werden daher als

konzeptuelle Objekttypen auf der linken Seite des Diagramms untereinander


visualisiert. Dazu gehören die Objekttypen Absatzmarkt, Absatzplanung, Vertrieb,

Versand, Produktion, Fakturierung und Finanzwesen.

• Transaktionen zwischen zwei betrieblichen Objekten hängen jeweils von diesen

beiden Objekten ab und werden daher rechts von den mit ihnen korrespondierenden

Objekttypen im Diagramm dargestellt. Weiterhin sind sie mit Interaktionskanten

zu verbinden. Beispielsweise ist die Absatzmarktforschung vom

Absatzmarkt und von der Absatzplanung existenzabhängig.

• Die übrigen Existenzabhängigkeiten können anhand der weiteren Reihenfolgebeziehungen

ermittelt werden. Indirekte Beziehungen zu den konzeptuellen

Objekttypen betrieblicher Objekte über eine oder mehrere vorgelagerte Transaktionen

sind dabei auszunutzen. Beispielsweise ist der Absatzplan an den

Vertrieb mit der Absatzmarktforschung und nicht direkt mit dem Absatzmarkt

und der Absatzplanung zu verbinden. Die übrigen Transaktionen können analog

ermittelt werden.

Das vorliegende initiale KOS kann bei Bedarf weiter verfeinert bzw. durch die

Angabe von Beziehungskardinalitäten weiter präzisiert werden [FeSi98; FeSi01].

Um den vierten Schritt vorzubereiten, ist das KOS um analyserelevante Attribute

zu ergänzen. Diese können durch klassische Techniken der Informationsbedarfsanalyse,

wie z.B. Interviews und Fragebögen verfeinert werden.

Im Folgenden werden exemplarisch nachstehende Attribute unterstellt. Der Absatzmarkt

kann durch Kundenmerkmale, wie z.B. Kundentyp (A-, B-, C-Kunde,

Geschlecht oder geographische Herkunft nach Stadt, Region und Land) näher

charakterisiert werden. Dem Produkt lässt sich beispielsweise die Art der Fertigung

und die geographische Lage der Fertigungsstätten zuweisen. Während der

Auftrag über das Auftragsdatum beschreibbar ist, lässt sich der Versandauftrag

neben einem entsprechenden Versanddatum durch Lieferform und Versandweg

präzisieren. Schließlich legt der Vertrieb die Erfassung einer spezifischen Vertriebsstruktur

und der Produktkatalog die Bestimmung von Sonderaktionen nahe.

3.2.4 Identifikation initialer Modellbausteine

Als nächstes erfolgt die Identifikation initialer Modellbausteine anhand des abgeleiteten

KOS in drei Teilschritten.

Identifikation von Kennzahlen

Bei der Identifikation von Kennzahlen wird der Argumentationskette Ziel – Prozess

– Leistung – Kennzahl gefolgt. Eine Kennzahl dient somit dazu, Leistungen

eines Prozesses im Hinblick auf seine Zielerreichung zu messen. Ausgehend von

dem in Abschnitt 3.2.2 ausgewählten Sachziel wird der Objekttyp im KOS identifiziert,

der mit der entsprechenden Leistung Produktion von Gütern und Dienstleistungen

korrespondiert. Für die Zuordnung von Leistungen eignen sich vor

allem Durchführungstransaktionen (D), da sich diese mit der Erstellung und Über-


gabe von Leistungen beschäftigen. Die vorliegende Leistung wird daher dem

Objekttyp Produktlieferung zugeordnet, der an der Übergabe von Produkten und

Dienstleistungen zwischen Versand und Absatzmarkt beteiligt ist. Nun ist zu klären,

wie die bereitgestellte Leistung im Hinblick auf das Sachziel adäquat gemessen

werden kann. Als mögliche Kennzahlen eignen sich dabei vor allem Absatzzahlen.

Beispielhaft soll daher im Folgenden die Kennzahl Menge der veräußerten

Güter weiter betrachtet werden.

Identifikation von Dimensionen und Dimensionshierarchien

Die Eigenschaft des KOS, Existenzabhängigkeiten zwischen Objekttypen zu visualisieren,

hilft bei der Identifikation von Dimensionen bzw. Dimensionshierarchien,

die mit der Kennzahl korrespondieren. Alle Objekttypen, die Existenzvoraussetzungen

für den der Kennzahl zugeordneten Objekttyp sind, enthalten Informationen

über potentielle Dimensionskandidaten. Daher werden diese zur näheren

Betrachtung in eine Hülle der Existenzvoraussetzungen aufgenommen (vgl. Abbildung

6). Für die Bildung von Dimensionen und Dimensionshierarchien können

neben den vorher zugeordneten analyserelevanten Attribute, vor allem die Beziehungen

zwischen den einzelnen Objekttypen herangezogen werden. Eine ausführliche

Darstellung der dabei verwendeten Regeln findet sich in [BoUl99]. Somit

ergeben sich beispielsweise folgende Modellbausteine: Eine Dimension Kunde mit

einer Kategorisierung nach ihrer geographischen Herkunft (Stadt, Bundesland,

Land) oder eine Dimension, die die spezifische Vertriebsstruktur des Industriebetriebs

widerspiegelt.

Spezifikation von zugehörigen Integritätsbedingungen

Diese aus der Kombination von Kennzahl und zugehörigen Dimensionen resultierende

Modellstruktur unterliegt i.d.R. weiteren spezifischen Integritätsbedingungen.

Beispielsweise ist nicht jede Kennzahl hinsichtlich jeder ihrer Dimension

additiv [LeSh97]. Bevor Modellbausteine weiter konsolidiert werden, ist zudem

immer auch in Abgleich mit den Datenschemata der operativen Systeme zu prüfen,

ob diese Bausteine auch bereitgestellt werden können [BoUl99].

Die identifizierten Dimensionen und Kennzahlen sind Kandidaten für die in die

Bibliothek zu übernehmenden semantischen Modellbausteine (vgl. Abschnitt 3.3).

Analog zu den vorgestellten Modellbausteinen auf Basis der Kennzahl Anzahl der

veräußerten Güter lassen sich weitere mögliche Bausteine identifizieren. Beispielsweise

lassen sich Umsatz- und Gewinnkennzahlen am Objekttyp Zahlung

festmachen oder die Anzahl der gewonnenen Aufträge am Objekttyp Auftrag. Die

zugehörigen Hüllen von Existenzvoraussetzungen ermöglichen die Gewinnung

weiterer Dimensionskandidaten. Eine Überschneidung der Hüllen hilft bei einer

Ermittlung von Dimensionen, die mehreren Analysezwecken gemeinsam sind.


3.3 Bibliothek-gestützte Fachkonzeption

Die Ergebnisse der Prozessmodellanalyse werden genutzt, um in den nächsten

Schritten der Methodik das Fachkonzept gestützt auf eine Bibliothek der semantischen

Modellbausteine zu konstruieren [HoKn99, S. 59-61]. Abbildung 7 zeigt die

Abfolge der Aufgabentypen unter Einbezug des Konzepts ihrer Werkzeugunterstützung.

Die Bibliothek gliedert sich in zwei Teile. Der erste Teil verwaltet die

auf Bezugsobjekten basierenden Modellbausteine. Die von der Prozessanalyse

vorgeschlagenen Dimensionen werden gegebenenfalls, z. B. durch Definition von

Hierarchiestufen, verfeinert. Die einzelnen Bezugsobjektdefinitionen können aus

bestehenden Datenquellen importiert werden. Bei der Anlage der Modellbausteine

muss eine Abstimmung mit den vorhandenen Inhalten der Bibliothek vorgenommen

werden. Es ist zu prüfen, ob ähnliche Dimensionen bereits definiert sind und

wiederverwendet werden können. Erst wenn die Suche nach adäquaten Modellbausteinen

erfolglos ist, sind Ergänzungen vorzunehmen. Eventuell können bestehende

Modellbausteine auch so modifiziert werden, dass sie für einen breiteren

Anwendungsbereich verwendbar sind. Desgleichen gilt für die Definition der

Kennzahlen und Kennzahlensysteme, die den zweiten Teil der Bibliothek bilden.

Insbesondere die rechentechnischen Definitionen der Kennzahlen sind bei dem

Abgleich der neuen Vorschläge mit den bestehenden Inhalten zu beachten. Für

den betrachteten Absatzbereich eines Industriebetriebs sind die Überprüfungen

und Verfeinerungen z. B. für die Kennzahlen Menge der veräußerten Güter und

wertmäßiger Umsatz sowie für die Kundendimension und die Vertriebsstrukturdimension

vorzunehmen. Im Resultat wird mit der Bibliothek eine unternehmensweite

Wissensbasis über relevante Bestandteile von Managementsichten definiert.

Prozessgestaltung

Ableitung von

Modellbausteinen

Konstruktion der

Bibliothek

Fachkonzeptionelle

Spezifikation

Designer für SOM-

Prozessmodelle

Prozessmodellanalysierer

Administrator der

Bibliothek

Designer für

Informationsobjektmodelle

Repository

Prozessmodelle

und Zielsetzungen

Analyseergebnisse

Modellbaustein-

Bibliothek

Bezugsobjekte

Repository

Fachkonzept

Legende:

Aufgabentyp des Vorgehensmodells der

Methodik

Softwarekomponente zur

Werkzeugunterstützung der Methodik

Teil des Repositorys als Implementierung der

Dokumentenstruktur

Logischer Ablauf

Verwendung der Repositoryinhalte

Modellbaustein-

Bibliothek

Kennzahlen

Abbildung 7: Konzept der Bibliothek-gestützten Fachkonzeption

Die kreative Konstruktion der Navigationsräume wird durch die in der Prozessmodellanalyse

identifizierten Zugehörigkeiten von Kennzahlen zu Dimensionen


und deren Relevanz für in die Verantwortungsbereiche von Managern fallende

Prozesse und Zielsetzungen wesentlich unterstützt. Für die Steuerungs- und Regelungsaufgabe

des Absatzbereichs wurde zum Beispiel ermittelt, dass die Menge

der veräußerten Produkte aufgeschlüsselt nach der Vertriebsstruktur eine relevante

Information zur Beurteilung der Leistung Produktlieferung des Absatzbereichs

darstellt. Zudem liefern die konsolidierten Modellbausteine der Bibliothek auch

isoliert wertvolle Anregungsinformationen für die Auswahl von Kennzahlen und

Dimensionen. In die Konstruktion des geeigneten Navigationsraums können über

die Prozessanalyseergebnisse hinaus weitere theoretische Überlegungen oder

Ergebnisse aus Befragungen einfließen.

Zur grafischen Repräsentation der Konstruktionsergebnisse werden Informationsobjektmodelle

verwendet. Die Informationsobjektmodelle können quasi nach dem

Baukastenprinzip zusammengesetzt werden, indem die entsprechenden semantischen

Modellbausteine der Bibliothek entnommen werden. In [Holt00b] wird ein

dieses Konzept umsetzender Editor gezeigt. Die Verwendung eines solchen Editors

fördert die Qualität der Modellierungsergebnisse. Zu den im Folgenden zu

Grunde gelegten Kriterien vergleiche die Grundsätze ordnungsmäßiger Modellierung

(GoM) [BeSc96, S. 65-92]. Die Verwendung der konsolidierten Bausteine

fördert durch Begriffsvereinheitlichung die semantische Richtigkeit der Modelle.

Nach der Auswahl eines Bausteines kann die Anordnung der Modellelemente

automatisiert erfolgen und die Klarheit des Modells sicherstellen. Über die Dimensionen

und Kennzahlensysteme sollte innerhalb der Bibliothek eine Reihenfolge

definiert werden. Bei der Übernahme der Modellelemente in die Informationsobjektmodelle

wird diese Reihenfolge übernommen, so dass die Anordnung

der Elemente in den einzelnen Modellen vereinheitlicht wird. Diese Regelung

erhöht die Vergleichbarkeit der Modelle. Insgesamt ist zu erwarten, dass die Wirtschaftlichkeit

der Fachkonzeption erhöht wird.

3.4 Werkzeugunterstützte DV-Konzeption und Implementierung

Die inhaltliche Integration der Dokumente der fachkonzeptionellen Spezifikation

wird auf die Komponenten der DV-Konzeption und der Implementierung ausgeweitet,

indem Methoden und Werkzeuge zur (teil-)automatisierten Transformation

der Spezifikation in Konfigurationseinstellungen des Data-Warehouses in die

Methodik einbezogen werden. Eine diesem Prinzip gerecht werdende Data-

Warehouse-Entwicklungsumgebung wird am Institut für Wirtschaftsinformatik

der Westfälischen Wilhelms-Universität Münster unter dem Namen MetaMIS

Toolset entwickelt. Abbildung 8 zeigt die Werkzeugarchitektur anhand einer beispielhaften

Data-Warehouse-Implementierung, die als ETL-Werkzeug (Extraktion,

Transformation, Laden) Informatica verwendet, als Datenbankmanagementsystem

Oracle nutzt und deren Auswertungsebene durch das ROLAP-System von

MicroStrategy gebildet wird [Holt00b]. Im Folgenden werden die drei wichtigsten

Komponenten beschrieben:


Der Data-Warehouse-Generator entwickelt aus dem Fachkonzept einen Vorschlag

für das Datenbankschema des Data-Warehouses. Hierbei geht die Wahl des

Grundmusters (Starschema vs. Snowflakeschema) und die Festlegung von Denormalisierungsvarianten

(Denormalisierung von Schlüsseln bzw. Bezeichnungen)

als Parameter in den Algorithmus ein. Der Vorschlag ist anschließend mit Hilfe

eines Editors vom Datenbankadministrator anzupassen. Zu dem konstruierten

Schema wird ein passendes SQL-Skript (Create Table) generiert, das von dem

Datenbankmanagementsystem ausgeführt wird.

Der ETL-Konfigurator gibt die Definition der Zieltabellen an das ETL-Werkzeug

weiter. Im ETL-Werkzeug selbst werden diese Halbmappings erweitert, indem die

Quelltabellen angegeben werden und Regeln zur Befüllung der Zieltabellen mit

den Daten der Quelltabellen festgelegt werden. Im Informatica-Werkzeug werden

diese Schritte durch grafische Notationen unterstützt.

Der OLAP-Konfigurator verwendet Informationen über das Fachkonzept und das

Datenbankschema des Data-Warehouses. Automatisiert wird die Metadatenbank

des MicroStrategy-Systems gefüllt, das die Beziehung zwischen den Basiselementen

der Oberfläche des ROLAP-Systems (Attribute, Hierarchien, Metriken) und

den Data-Warehouse-Tabellen herstellt. Zudem werden dem Fachkonzept entsprechende

ROLAP-Berichte angelegt, deren Definitionen ebenfalls in der MicroStrategy-Metadatenbank

gespeichert werden.

Fachkonzeptionelle

Spezifikation

DV-Konzeption und Implementierung

Prozessmonitoring

Designer für

Informationsobjektmodelle

ETL-Konfigurator

MetaMIS-Toolset-Module

Data-Warehouse-

Generator

OLAP-

Konfigurator

MicroStrategy

ROLAP-Funktionalität

Repository

Fachkonzept

Informatica

Metadaten

Repository

Datenbankschema

MicroStrategy

Metadaten

Oracle

Datenbankmanagementsystem

Data-

Warehouse-

Datenbank

Legende:

Aufgabentyp des Vorgehensmodells der

Methodik

Softwarekomponente zur

Werkzeugunterstützung der Methodik

Teil des Repositorys als Implementierung der

Dokumentenstruktur

Logischer Ablauf

Verwendung der Repositoryinhalte

Informatica

ETL-Funktionalität

Data-

Warehouse-

Datenbank

Data-

Warehouse-

Datenbank

Abbildung 8: Konzept der werkzeugunterstützten DV-Konzeption und Implementierung

Änderungen an den Komponenten des Data-Warehouse-Systems dürfen ausschließlich

über die als führendes System fungierende Entwicklungsumgebung

vorgenommen werden. Mittels der von der Entwicklungsumgebung verwalteten

Dokumentenstruktur wird die ständige Konsistenz aller Arbeitsergebnisse des

Data-Warehousings sichergestellt und damit die Komplexität der Data-

Warehouse-Evolution beherrschbar.


4 Zusammenfassung und Ausblick

Es wurde eine Methodik vorgestellt, die vier Hauptschwierigkeiten des Data-

Warehousings begegnet:

1. Unterstützung des kreativen Akts der Informationsbedarfsanalyse durch eine

systematische Analyse von Prozessmodellen,

2. Vorgabe einer Modellierungstechnik für die fachkonzeptionelle Spezifikation

des Data-Warehouses in Form von Informationsobjektmodellen,

3. Bewältigung der Komplexität der Data-Warehouse-Evolution durch Definition

einer Dokumentenstruktur und Konzeption ihrer werkzeugunterstützten Verwaltung

sowie

4. Sicherstellung unternehmensübergreifender Konsistenz der Modelle durch

Verwendung von Bibliotheken semantischer Modellbausteine.

In weiteren Arbeitsschritten soll die Implementierung der Werkzeugunterstützung

der Methodik weiterentwickelt werden. Während der Designer der Informationsobjektmodelle

und einige Module der DV-Konzept- und Implementierungsphase

bereits ein fortgeschrittenes Realisierungsstadium erreicht haben, steht die Kopplung

einer Umgebung zur Modellierung von SOM-Prozessmodellen und deren

Analyse mit dem MetaMIS Toolset erst am Anfang. Der Aufbau von Bibliotheken

semantischer Modellbausteine kann zudem durch die Verwendung von Referenzmodellen

unterstützt werden [Knac01].

Literaturverzeichnis

[BeHo98] Becker, J.; Holten, R.: Fachkonzeptuelle Spezifikation von Führungsinformationssystemen.

Wirtschaftsinformatik 40 (1998) 6, S. 483-492.

[BeSc96] Becker, J.; Schütte, R.: Handelsinformationssysteme. Moderne Industrie,

Landsberg am Lech 1996.

[BoUl00] Böhnlein, M.; Ulbrich-vom Ende, A.: Business Process Oriented Development

of Data Warehouse Structures. In: Jung, R.; Winter, R. (Hrsg.): Data

Warehousing 2000. Physica, Heidelberg, S. 3-21.

[BoUl99] Böhnlein, M.; Ulbrich-vom Ende, A.: Deriving Initial Data Warehouse

Structures from the Conceptual Data Models of the Underlying Operational

Information Systems. In: Proceedings of the ACM Second International

Workshop on Data Warehousing and OLAP (DOLAP 1999, Kansas City, 6.

November), 1999, S. 15-21.

[Chen76] Chen, P. P.: The Entity-Relationship-Model. Toward a Unified View of

Data. ACM Transactions on Database-Systems, 1 (1976) 1, S. 9-36.

[FeSi01] Ferstl, O.K.; Sinz, E.J.: Grundlagen der Wirtschaftsinformatik Band 1. 4.

Aufl., Oldenbourg, München 2001.

[FeSi98] Ferstl, O. K.; Sinz, E. J.: SOM Modeling of Business Systems. In: Bernus,

P.; Mertins, K.; Schmidt, G. (Hrsg.): Handbook on Architectures of Information

Systems. Springer, Berlin 1998, S. 339-458.


[FeSi90]

[Grof92]

[Holt00a]

[Holt00b]

[Holt99]

[HoKn01]

[HoKn99]

[HoKB01]

[Kimb96]

[Knac01]

[LeSh97]

[Lore95]

[Reic97]

[Rieb79]

[Sinz88]

[Stae91]

[Teub99]

[Wede81]

[Wint00]

Ferstl, O. K.; Sinz, E. J.: Objektmodellierung betrieblicher Informationssysteme

im Semantischen Objektmodell (SOM). In: Wirtschaftsinformatik, 32

(1990) 6, S. 566-581.

Groffmann, H.-D.: Kooperatives Führungsinformationssystem. Grundlagen,

Konzept, Prototyp. Gabler, Wiesbaden 1992.

Holten, R.: Entwicklung einer Modellierungstechnik für Data Warehouse-

Fachkonzepte. In: Schmidt, H. (Hrsg.): Modellierung betrieblicher Informationssysteme.

Proceedings der MobIS-Fachtagung 2000, S. 3-21.

Holten, R.: Framework and Method for Information Warehouse Development

Processes. In: Jung, R.; Winter, R. (Hrsg.): Data Warehousing 2000.

Physica, Heidelberg 2000, S. 135-163.

Holten, R.: Entwicklung von Führungsinformationssystemen. Ein methodenorientierter

Ansatz. Gabler, Wiesbaden 1999.

Holten, R.; Knackstedt, R.: Entwicklung von Methodiken. Vorschläge für

eine begriffliche Grundlegung. Arbeitsbericht des Instituts für Wirtschaftsinformatik

Nr. 74. Münster 2001.

Holten, R.; Knackstedt, R.: Fachkonzeptuelle Modellierung von Führungsinformationssystemen

am Beispiel eines filialisierenden Einzelhandelsunternehmens.

In: Sinz, E. J. (Hrsg.): Modellierung betrieblicher Informationssysteme.

Proceedings der MobIS-Fachtagung 1999. S. 48-64.

Holten, R.; Knackstedt, R.; Becker, J.: Betriebswirtschaftliche Herausforderungen

durch Data-Warehouse-Technologien. In: Schütte, R.; Rotthowe, T.;

Holten, R. (Hrsg.), Data Warehouse Managementhandbuch. Konzepte,

Software, Erfahrungen. Springer, Berlin u. a. 2001, S. 41-64.

Kimball, R.: The Data Warehouse Toolkit. Practical Techniques for Building

Dimensional Data Warehouses. Wiley, New York u. a. 1996.

Knackstedt, R.: Konfigurative Referenzmodelle als Instrumente des Wissensmanagements

bei der Data-Warehouse-Entwicklung. Erscheint in: Tagungsband

zur WM 2001 in Baden-Baden, März 2001.

Lenzerini, H. J.; Shoshani, A.: Summarizability in OLAP and Statistical

Data Bases. In: Proceedings of the 9th International Conference on Statistical

and Scientific Database Management (SSDBM 1997, Olympia, USA,

11.-13. August), 1997, S. 132-143.

Lorenz, K.: Methode. In: Mittelstraß, J. (Hrsg.), Enzyklopädie Philosophie

und Wissenschaftstheorie. Band 2, Metzler, Stuttgart 1995, S. 876-879.

Reichmann, T.: Controlling mit Kennzahlen und Managementberichten.

Grundlagen einer systemgestützten Controlling-Konzeption. 5. Aufl., Vahlen,

München 1997.

Riebel, P.: Gestaltungsprobleme einer zweckneutralen Grundrechnung. In

ZfbF 31 (1979), S. 863-893.

Sinz, E. J.: Das Strukturierte Entity-Relationship-Modell (SER-Modell). In:

Angewandte Informatik, 30 (1988) 5, S. 191-202.

Staehle, W. H.: Management – Eine verhaltenswissenschaftliche Perspektive.

6. Aufl., Vahlen, München 1991.

Teubner, R. A.: Organisations- und Informationssystemgestaltung. Theoretische

Grundlagen und integrative Methoden. Gabler, Wiesbaden 1999.

Wedekind, H.: Datenbanksysteme I. Eine konstruktive Einführung in die

Datenverarbeitung in Wirtschaft und Verwaltung. 2. Aufl., Bibliographisches

Institut, Mannheim et al. 1981.

Winter, R.: Zur Positionierung und Weiterentwicklung des Data Warehousing

in der betrieblichen Applikationsarchitektur. In: Schmidt, H. (Hrsg.):

Proceedings der MobIS-Fachtagung 2000. S. 23-38.


Abbildung 9: Vorgangs-Ereignis Schema für den Absatzprozess eines Industriebetrieb

Planung

Vertrieb

Versand

Produktion

Absatz-

Fakturierung

betriebl.

Finanzwesen

Absatzmarkt

Absatzmarktforschung

>

Absatzmarkt

A: Absatzmarktforschung

1

Absatzplan an

> Absatzmarkt-

Vertrieb >

A: Absatzplan

an Produktion

> Absatzplan

an Produktion

Produktion

Absatzplan an

Produktion >

Absatzplanung

forschung

Absatzplanung

2

katalog

Absatzplanung

A: Absatzplan

an Vertrieb

2

> Absatzplan

Produktkatalog

>

an Vertrieb

Vertrieb

Vertrieb

Legende

Vorgangstyp und

> Vorgangstyp

korrespondierendes

Objekt betriebliches Objekt

Transaktionsgebundenes

Ereignis

Objektinternes Ereignis

> Produktkatalog

Absatzmarkt

3

A: Produkt-

Auftrag >

Absatzmarkt

4

V: Auftrag

> Auftrag

Absatzbedarf

>

Vertrieb

Vertrieb

5

V: Absatzbedarf

> Absatzbedarf

Produktion

> Produktlieferung

Absatzmarkt

7

K: Produktlieferung

Versandauftrag

>

Vertrieb

S: Versandauftrag

5

Produktlieferung

>

> Versandauftrabereitstellung

>

Produkt-

Versand

Versand

Versand

D: Produktbereitstellung

6

Produktbereitstellung

>

Produktion

> Absatzmeldung

Abrechnung >

Absatzplanung Absatzplanung

K: Absatzmeldung

8

> Versandmeldunmeldung

>

Absatz-

Vertrieb

Vertrieb

K: Versandmeldung

7

Versandmeldung

>

9

S: Abrechnung

Versand

> Abrechnung

Fakturierung

> Rechnung

Zahlung >

Absatzmarkt

Absatzmarkt

10

V: Rechnung

11

D: Zahlung

Rechnung >

Zahlungseingangsav.

>

Fakturierung

Fakturierung

V: Zahlungsein

10

gangsav.

> Zahlungseingangsav.

> Zahlung

Finanzwesen Finanzwesen

> Abrechungsmeldung

Vertrieb

13

D: Abrechnungsmeldung

> Zahlungseinganmeldung

>

Abrechnungs-

Fakturierung Fakturierung

D: Zahlungseingang

12

Zahlungseingang

>

Finanzwesen

Anhang

Ähnliche Magazine