Active Enterprise Intelligence: Unternehmensweite Informationslogistik als Basis einer...

Active Enterprise IntelligenceTM

Jochen Töpfer · Robert WinterHerausgeber

Active EnterpriseIntelligenceTM

Unternehmensweite Informationslogistikals Basis einer wertorientiertenUnternehmenssteuerung

123

Dr. Jochen TöpferTeradata (Schweiz) GmbHPostfach8301 [email protected]

Prof. Dr. Robert WinterUniversität St. GallenInstitut für WirtschaftsinformatikMüller-Friedberg-Str. 89000 St. [email protected]

Teradata and Active Enterprise Intelligence are trademarks of Teradata Corporation.

ISBN 978-3-540-78496-8 e-ISBN 978-3-540-78498-2

DOI 10.1007/978-3-540-78498-2

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

c© 2008 Springer-Verlag Berlin Heidelberg

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die derÜbersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funk-sendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherungin Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. EineVervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in denGrenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschlandvom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungs-pflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werkberechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne derWarenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermannbenutzt werden dürften.

Herstellung: le-tex publishing services oHG, LeipzigEinbandgestaltung: WMX Design GmbH, HeidelbergTitelbild: John Knill/Digital Vision/Getty Images

Gedruckt auf säurefreiem Papier

9 8 7 6 5 4 3 2 1

springer.de

Vorwort

Heutige globale Geschäftsmodelle sind alle betriebswirtschaftlichen Funk-tionsbereiche übergreifend stark arbeitsteilig aufgebaut. Diese innovative Vernetzung der Wertschöpfungsprozesse über Landesgrenzen und Konti-nente hinweg erfordert ebensolche Innovationen in der Informationstech-nologie. IT-Innovationen sollen Enabler für Geschäftsinnovationen sein – sie erlauben neuartige fachliche Lösungen umzusetzen oder zumindest fachliche Lösungen durch Kostensenkung, Beschleunigung, Qualitätsver-besserung o. ä. weiterzuentwickeln. Wo Leistungsprozesse betroffen sind, werden solche Innovationen deutlicher sichtbar als für Unterstützungs- und Führungsprozesse. Gleichwohl haben IT-Innovationen in den vergangenen zwanzig Jahren auch fundamentale Innovationen in diesen Bereichen er-möglicht. Durch die unter den Sammelbegriff Data Warehousing / Busi-ness Intelligence zusammengefassten Innovationen wurde es beispielswei-se möglich, entscheidungsrelevante Informationen systematisch in der nachgefragten Qualität und der notwendigen Geschwindigkeit bereitzustel-len, ohne an die Einschränkungen operativer Systeme gebunden zu sein. Operative Systeme zeichnen sich im Hinblick auf ihre Eignung zur Ent-scheidungsunterstützung bekanntermaßen durch mangelnde Integration und daraus resultierende Inkonsistenzen, durch für explorative Arbeit nicht ausreichende Performanz, durch begrenzten Zeithorizont der verfügbaren Daten usw. aus – Sie wirken eher als Disabler denn als Enabler.

Die systematische, einzelne Abteilungen bzw. Unternehmensbereiche übergreifende und durch dedizierte, integrierte Systeme unterstützte In-formationsversorgung ist zum unverzichtbaren Bestandteil der betriebli-chen Informationssystem-Architektur geworden. Mehr denn je erkennen Unternehmen, dass die integrierte, systematische Befriedigung von Infor-mationsbedarfen ein Schlüssel zu Produktivität von Knowledge Workern und damit zur Wettbewerbsfähigkeit ist.

Seit ihren Anfängen hat sich die Literatur zu analytischen Informations-systemen und insbesondere zum Data Warehousing als wichtiger Basis-technologie sehr stark auf technische Aspekte konzentriert. Dieser Ansatz greift zu kurz – insbesondere in der Phase der technologischen Reife hängt der Erfolg der Informationslogistik davon ab, dass die Betrachtungen über die rein technologischen Aspekte hinausgehen. Erst eine ganzheitliche Be-

VI Vorwort

trachtung von Strategie, Organisation, Prozess, Architektur und Nutzen ermöglicht nachhaltige Wertschöpfung durch den IT-Einsatz.

Dieses Buch löst einen solchen Anspruch ein. Auf Grundlage des St. Galler Business Engineering-Frameworks wird Teradatas Active Enterpri-se Intelligence-Ansatz mit aktuellen Problemfeldern und ganzheitlichen Lösungsansätzen der Informationslogistik verbunden und es werden Hin-weise zur Gestaltung der Informationslogistik in fachlicher, organisatori-scher und technischer Hinsicht gegeben.

Eine Fallstudie der Swisscom Mobile zeigt am praktischen Beispiel, wie Active Enterprise Intelligence im Unternehmen erfolgreich gestaltet und umgesetzt werden kann.

Dieses Buch ist in drei Teile gegliedert. Im ersten Teil wird Teradatas Active Enterprise Intelligence-Ansatz in Verbindung mit der St. Galler in-tegrierten Informationslogistik vorgestellt. Der zweite Teil stellt aktuelle Schwerpunktthemen aus dem Bereich der Informationslogistik vor und im dritten Teil werden anhand eines Vorgehensmodells und einer Fallstudie die Kernaspekte des ersten Teils auf die Praxis übertragen.

Im ersten Kapitel stellt Töpfer Terdadatas Active Enterprise Intelligence als unternehmensweiten, integrierten Ansatz für strategische und operatio-nale Informationsversorgung im Unternehmen vor. Im darauf folgenden Beitrag stellt Winter den St. Galler Business Engineering-Ansatz zur Konstruktion und Evolution von Informationssystemen vor.

In den folgenden vier Beiträgen wird das Konzept der integrierten In-formationslogistik auf den verschiedenen Ebenen des Business Enginee-ring-Frameworks detailliert. Dinter / Winter behandeln die Strategie der Informationslogistik, Klesse / Schmaltz erläutern die Aufbauorganisation, Bucher zeigt die Zusammenführung analytischer Informationen mit der Ausführung operativer Prozesse und Stroh / Lahrmann geben einen Über-blick über Systemarchitekturen für die Informationslogistik. Der Beitrag von Schmaltz und Töpfer zu Nutzenpotenzialen der Informationslogistik schließt den ersten Teil ab.

Die Beiträge des zweiten Teils adressieren Querschnittaspekte der In-formationslogistik. Wegener erläutert in seinem Beitrag die Konzepte der Metadaten, Referenzdaten und Stammdaten und ihre Rolle zur Verwirkli-chung eines integrierten Gesamtsystems Informationslogistik. Otto et al. greifen in ihrem Kapitel mit dem Datenqualitätsmanagement einen „Dauerbrenner“ in der Informationsversorgung auf und zeigen, wie schon in operativen Systemen die Grundlage für eine erfolgreiche Informati-onslogistik gelegt werden kann. Klesse stellt seinen Ansatz für eine Leis-tungsverrechnung für die Informationslogistik vor.

Vorwort VII

Der dritte Teil beginnt mit dem Kapitel von Konzelmann über Teradatas Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse. Die Fallstudie schlägt die Brücke zwischen Theorie und Praxis. Dabei folgt der Beitrag der Gliederung des ersten Teils. Ahrens, Huber und Kühni be-schreiben die Einführung eines Enterprise Data Warehouse bei der Swiss-com Mobile.

Unser besonderer Dank gilt der NCR Stiftung zur Förderung wissen-schaftlicher Arbeiten auf dem Gebiet der Informatik, die durch eine groß-zügige finanzielle Unterstützung die Erarbeitung dieses Buches möglich machte.

Danken wollen wir Markus Huber und Peter Kühni für die umfassende Darstellung der Fallstudie bei Swisscom Mobile und Robert Konzelmann für die Bearbeitung des Vorgehensmodells zur Erstellung eines Enterprise Data Warehouse. Weiterhin danken wir allen Autoren am Institut für Wirt-schaftsinformatik der Universität St. Gallen, die zum Inhalt dieses Buches mit großem Engagement beigetragen haben. Schließlich gebührt unser Dank auch Moritz Schmaltz, Alfred Geers, Remo Stieger, Stefan Wagner und Philipp Gubler, die bei der Redaktion des Buches mitgewirkt haben. Moritz Schmaltz leistete durch seine engagierte Gesamtkoordination einen wesentlichen Beitrag zum Gelingen dieses Buches. Wir danken Jürg Büh-ler von Teradata (Schweiz) auch stellvertretend für alle weiteren involvier-ten Kollegen von Teradata für die stets motivierende Unterstützung und den so wichtigen Freiraum für dieses Vorhaben.

Jochen Töpfer, Robert Winter Zürich, im März 2008

Inhaltsverzeichnis

1 Active Enterprise Intelligence ............................................................ 1 Jochen Töpfer

2 Business Engineering – Betriebswirtschaftliche Konstruktions- lehre und ihre Anwendung in der Informationslogistik .................... 29 Robert Winter

3 Das St. Galler Konzept der Informationslogistik ............................ 43 Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

4 Strategie der Informationslogistik .................................................... 59 Barbara Dinter, Robert Winter

5 Organisationsformen für die Informationslogistik .......................... 77 Mario Klesse, Moritz Schmaltz

6 Interaktionseffekte zwischen prozessorientierter Organisation und Informationslogistik................................................................. 101 Tobias Bucher

7 Informationslogistik-Systemarchitekturen ..................................... 129 Gerrit Lahrmann, Florian Stroh

8 Nutzenpotenziale unternehmensweiter Informationslogistik ......... 157 Moritz Schmaltz, Jochen Töpfer

9 Metadaten, Referenzdaten, Stammdaten ........................................ 179 Hans Wegener

X Inhaltsverzeichnis

10 Unternehmensweites Datenqualitätsmanagement: Ordnungsrahmen und Anwendungsbeispiele ................................. 201 Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

11 Einsatzmöglichkeiten serviceorientierter Architekturen in der Informationslogistik ....................................................................... 221 Barbara Dinter

12 Methode zur Gestaltung einer Leistungsverrechnung für DWH Competence Center .............................................................. 243 Mario Klesse

13 Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse .............................................................................. 273 Robert Konzelmann

14 Die Informationslogistik bei der Swisscom Mobile ....................... 313 Maximilian Ahrens, Markus Huber, Peter Kühni

Autorenverzeichnis ......................................................................... 331

Sachverzeichnis .............................................................................. 335

1 Active Enterprise Intelligence

Jochen Töpfer

Teradata

1 Pervasive Business Intelligence – eine Vision ................................... 1 2 Active Enterprise Intelligence – eine Strategie .................................. 4 3 Active Data Warehouse – eine Technologie ...................................... 9 4 Data Integration Services .................................................................. 15 5 Decision Services ............................................................................. 21 6 Zitate von Anwendern ...................................................................... 25

Literatur ............................................................................................ 27

1 Pervasive Business Intelligence – eine Vision

Viele Firmen unternahmen in den letzten 20 Jahren sehr große Anstren-gungen, um Führungskräften entscheidungsrelevante Informationen zur Verfügung zu stellen. Dazu beschritten sie mutig unterschiedliche Wege. Die methodische und systemische Unterstützung ist – verglichen mit den frühen 90er Jahren – sehr weit vorangeschritten.

Aus Sicht einer Unternehmung, die mit weltweit ständig wechselnden Rahmenbedingungen umgehen muss und in einem harten globalen Wett-bewerb steht, sind diese Fortschritte nur einzelne Schritte auf einer langen Lernkurve, deren Ende auch in naher Zukunft nicht erreicht sein wird.

Was kann getan werden, um die Leistungsfähigkeit der Informations-systeme zur Entscheidungsunterstützung weiter zu steigern? Grundsätzlich ist eine Unternehmung nur dann langfristig erfolgreich, wenn sie im Rah-men eines profitablen Geschäftsmodells Produkte und Leistungen anbietet, die für ihre Kunden einen größeren Mehrwert erzeugen als die Angebote des Wettbewerbs. Das Geschäftsmodell ist immer wieder Ausgangspunkt für Strategie, Budget und Maßnahmen. Im Rahmen der Steuerung von

2 Jochen Töpfer

Maßnahmen wiederum müssen eine Vielzahl von Mitarbeitern jeden Tag teilweise unzählige Entscheidungen treffen.

Zentral wichtig für den langfristigen Geschäftserfolg ist somit, dass die-se Entscheidungen

im Rahmen des Geschäftsmodells relevant sind, mit den Strategien konform gehen, für die Zielerreichung der Budgets wirken, für die Maßnahmen terminlich passend sind.

Heutige Geschäftsmodelle sind arbeitsteilig aufgebaut. Diese Vernetzung der Wertschöpfungsprozesse erfordert eine ebensolche Integration der Un-ternehmensdaten. Die Ansprüche der Entscheidungsträger steigen noch immer kontinuierlich an und erfordern die beste Qualität, Verfügbarkeit, Detaillierung, Zielorientierung und Präsentation der Unternehmensinfor-mationen. Nur dann können Entscheidungsprozesse zeitnah und nachvoll-ziehbar unterstützt werden.

In der Vergangenheit wurden Daten in erster Linie Funktionen zugeord-net. Dadurch wird die Datenintegration verfehlt. Werden jedoch alle Un-ternehmensdaten in einem zentralen Enterprise Data Warehouse integriert, so können sie „near real time“ und serviceorientiert von den operativen Geschäftsprozessen angefordert werden. Dies alles erscheint oft kompli-ziert, ist aber maßgeblich für den wirtschaftlichen Erfolg. Denn oft herrscht im Rahmen der allgemeinen Euphorie für das Thema integrierte Informationslogistik die Annahme vor, dass diese Disziplin ein Problem ist, das durch ein Projekt und einige gute Software-Applikationen gelöst werden kann. Dieser Optimismus ist allerdings nicht gerechtfertigt, denn Business Intelligence ist eine permanente Aufgabe. Die Herausforderung besteht darin, durch methodische und technologische Unterstützung bei der Entscheidungsfindung den langfristigen Geschäftserfolg zu ermöglichen und zu sichern. Da sich Geschäftsmodelle weiterentwickeln, die Wettbe-werber und auch Führungskräfte sich verändern, gilt es aus Unternehmens-sicht, auf dieser Lernkurve stetig voranzukommen und sich an geänderte Rahmenbedingungen anzupassen.

Eine konsequente Serviceorientierung ist auch für eine Business Intelli-gence-Referenzarchitektur zur Unterstützung flexibler Entscheidungspro-zesse unabdingbar. Abbildung 1 stellt einen zentralen Enterprise Service Bus dar, der Transaction Services, Data Integration Services und Decision Services bedient (Brobst et al. 2007). Transaction Services sind operative Applikationen, die die Geschäftsprozesse steuern und ihre Daten in Trans-action Repositories ablegen. Data Integration Services extrahieren, trans-formieren und laden Transaktionsdaten aus unterschiedlichsten internen

Active Enterprise Intelligence 3

und externen Transaction Repositories und speichern diese als integrierte Unternehmensdaten unter Verwendung eines applikationsneutralen Da-tenmodells in den Decision Repositories, dem Data Warehouse ab.

Von dort können die Unternehmensdaten zielorientiert weiterverwendet, d. h. in Decision Services eingebunden werden. Unter Decision Services werden Applikationen für die Entscheidungsvorbereitung, -unterstützung oder -durchführung verstanden. Die Prozessintegration durch Business Process Automation ermöglicht eine ereignisgesteuerte Reaktion mit zeit-naher (near real time) Analytik zur Informationsanreicherung der Ge-schäftsprozesse.

Abb. 1. Business Intelligence Referenzarchitektur (Brobst et al. 2007)

Damit bestehende oder neue Analyseplattformen neue Geschäftsanfor-derungen und ihre Prozesse aktiv unterstützen können, benötigt es wohl orchestrierte, integrierte und „aktive“ Systemkomponenten.

Ein Data Warehouse muss in der Lage sein, mit unterschiedlichen App-likationen und Systemen Daten auszutauschen, und gemeinsam an einem übergreifenden Geschäftsprozess zu arbeiten. Dies geschieht mittels offe-nen Standards innerhalb einer serviceorientierten Architektur (SOA) (vgl. Kap. 11). Die resultierenden Datensätze müssen wiederum in offenen und standardisierten Formaten den unterschiedlichen Applikationen und Be-nutzern zur Verfügung gestellt werden. Die Verwendung von offenen und akzeptierten Standards unterstützt die Wiederverwendbarkeit einzelner Komponenten und verkürzt die Entwicklungszeit neuer Applikationen, dies ganz im Sinne einer modernen Unternehmung, die flexibel und rasch auf neue Ereignisse und Prozesse reagieren muss.

4 Jochen Töpfer

2 Active Enterprise Intelligence – eine Strategie

Active Enterprise Intelligence (AEI) ist eine Strategie, die zwischen Stra-tegic und Operational Intelligence unterscheidet, diese aber in einer ganz-heitlichen Betrachtungsweise wieder zusammenführt. In den letzten Jahren hat sich die klassische Business Intelligence, die eher strategische und tak-tische Fragestellungen zu beantworten suchte, weiterentwickelt und zu-nehmend operationale Themenstellungen aufgegriffen (Imhoff 2006).

Strategic Intelligence hat einen Fokus auf lang- und mittelfristige Ziel-stellungen und basiert auf historisierten und zumeist aggregierten Monats-, teilweise auch Tagesdaten. Es werden Entscheidungsprozesse der Unter-nehmensleitung unterstützt.

Operational Intelligence ist direkt in den operationalen Geschäftsprozes-sen integriert und unterstützt somit jeden Mitarbeiter mit aktueller (intra-day) Information. Besonders hervorzuheben sind Informationen, die so-wohl die aktuelle Datenlage als auch Analytik aus integrierten, historisier-ten Detaildaten in Sekundenbruchteilen erfordern.

Strategische und operationale Informationssysteme so auf einander ab-zustimmen (Alignment), dass einmal definierte Geschäftsziele gleicherma-ßen gefördert werden, bildet hier die Herausforderung. Ein Active Data Warehouse (ADW) macht dieses Alignment möglich und umsetzbar.

Business event

Data ready

Action taken

Intelligence delivered

Time

BusinessValue

Valuelost

Action time / Action distance

Datalatency

Analysislatency

Decisionlatency

Abb. 2. Wertverlust bei Verzögerung zwischen einem Geschäftsereignis und fol-gender Handlung (Imhoff 2006, S. 6)

Abbildung 2 veranschaulicht das Verhältnis des Geschäftsnutzens zu der Verzögerung zwischen dem Eintreten eines Ereignisses und der darauf fol-genden Handlung. Hier ist die Erkenntnis wichtig, dass sowohl für Daten-


aufbereitung, Analyse bzw. Entscheidungsvorbereitung und Entschei-dungsfindung sehr unterschiedliche Teilprozesse zu durchlaufen sind, be-vor eine Handlung ausgelöst werden kann (Imhoff 2006).

Derzeit werden beispielsweise im Bankenmarkt verstärkt Geschäftspro-zesse im Rahmen der Kundeninteraktion etabliert, deren analytische Fä-higkeiten sowohl eine Aktualisierung der Unternehmensdaten im Minuten- bzw. Sekundenbereich, als auch eine Zugriffsgeschwindigkeit von 0,1 bis 3 Sekunden erfordern. Mit einer auf Tagesverarbeitung basierenden Data Warehouse-Infrastruktur lassen sich künftige Anforderungen im globalen Wettbewerb nicht vollständig erfüllen (Müller-Scholz 2007).

Aus einem Geschäftsmodell werden ein oder mehrere Unternehmens-modelle abgeleitet, welche das Zusammenspiel von Input- und Steue-rungsgrößen beschreiben. Zur Steuerung des Unternehmens müssen Ent-scheidungen an wohl definierten Steuergrößen getroffen werden. Den Ent-scheidungen ist ein Prozessablauf mit entsprechendem Informationsbedarf und beteiligten Personen zugeordnet. Entscheidungsprozesse haben ihren Ursprung im Geschäftsmodell und werden mit allen genutzten Informatio-nen nachvollziehbar dokumentiert. Informationen werden zielorientiert im Rahmen von Entscheidungsprozessen eingesetzt und in der Struktur und Präsentation gemäß der Sichtweise von Businessanwendern aufbereitet. In-formationen sind demnach für Entscheidungsprozesse zielgerichtet einge-setzte Unternehmensdaten. Die Unternehmensdaten sind das Abbild der operativen Geschäftsprozesse und aus einer Vielzahl von Basissystemen integriert und granular gespeichert, sodass eine zeitnahe Nutzung flexibel und performant möglich ist (Töpfer 2006).

Für die Unternehmenspraxis ist die Verwendung eines Modells hilf-reich, das die Reife von Business Intelligence (BI) und Data Warehousing (DW) innerhalb einer Unternehmung in Stufen beschreibt. In der folgen-den Darstellung wird die Intelligenz in der Anwendung (Data Sophistica-tion) mit den Anforderungen an das Datenmanagement (Workload Com-plexity) in Beziehung gesetzt (vgl. Abb. 3).

Mit Hilfe der im Reifegradmodell identifizierten Phasen ist es möglich, eine Standortbestimmung durchzuführen, die dann als Basis für weitere Business Intelligence-Initiativen verwendet werden kann (Zaima u. Schra-der 2007).

In der Phase Reporting wird auf die Jahre zurückgeblickt, in denen tat-sächlich gedrucktes Papier in Batchläufen erzeugt wurde. Die Berichtsin-halte sind stets vergangenheitsorientiert („What happened?“). Heute sind weiterhin statische Informationen in Berichten zu finden, in denen keine weitergehende Analyse möglich ist.

6 Jochen Töpfer

OPERATIONALIZINGWHAT IS

happening now?

ACTIVATINGMAKE it happen!

Link to Operational

Systems

Automated Linkages

REPORTINGWHAT

happened?

PREDICTINGWHAT WILL

happen?

ANALYZINGWHY

did it happen?

Batch Reports

Ad Hoc, BI Tools

Predictive Models

Batch

Ad Hoc

Analytics

Continuous Update/Short Queries

Data Sophistication

Wo

rklo

ad

Co

mp

lex

ity

Event-Based Triggering

Abb. 3. BI/DW Maturity Model

Jeder Bericht wirft Folgefragen nach dem „Why did it happen?“ auf, die vom Empfänger analysiert werden wollen. Für die Zuordnung in die Phase Analyzing müssen die Unternehmensdaten in einer Analysedatenbank ge-speichert sein und entsprechende Funktionalität zur tabellarischen oder grafischen Anzeige verfügbar sein.

In der Phase Predicting wird die Frage nach dem „What will happen?“ beantwortet. Hierfür sind weitergehende analytische Fähigkeiten zur Clus-teranalyse, Mustererkennung, Segmentierung oder Vorhersage erfor-derlich.

Um jederzeit Auskunft geben zu können, welchen Status die Geschäfts-prozesse im Moment haben, benötigt man die Fähigkeit der Phase Opera-tionalizing. Um die Frage „What is happening now?“ beantworten zu kön-nen, müssen untertags in kurzen Intervallen die Daten der Geschäftspro-zesse für die weiterführende Analyse bereitgestellt werden.

Sobald diese aktuellen und integrierten Daten wiederum in der Steue-rung der Geschäftsprozesse zum Einsatz kommen, wird diese Anwendung der Phase Activating zugeordnet.


Today

REPORTINGWHAT

happened?

Batch Reports

ANALYZINGWHY

did it happen?

Ad Hoc, BI Tools

PREDICTINGWHAT WILL

happen?

Predictive Models

OPERATIONALIZINGWHAT IS

happening now?

Link to Operational

Systems

ACTIVATINGMAKE it happen!

Automated Linkages

STRATEGIC INTELLIGENCE

OPERATIONAL INTELLIGENCE

Operational Intelligence is the application of Strategic Intelligenceto operational systems and processes, when it can make a business impact

Align

Accelerate

Abb. 4. Strategic and Operational Intelligence (Zaima u. Schrader 2007)

In Abb. 4 wird deutlich, dass in Zukunft die operative Nutzung von Un-ternehmensdaten unmittelbar in den Geschäftsprozessen einen neuen Wettbewerbsvorteil ermöglicht, wenn sich diese mit der strategischen Aus-richtung im Einklang befindet.

Die ersten drei Phasen Reporting, Analyzing und Predicting werden als Strategic Intelligence bezeichnet, während Operationalizing und Activa-ting der Operational Intelligence zugeordnet werden. Active Enterprise In-telligence impliziert somit, dass das Handeln der Benutzer von der Ge-schäftsstrategie getrieben wird und die unterstützenden Systeme schnell und flexibel genug sind, um den Geschäftsgang positiv zu beeinflussen (White 2007).

Die nachfolgende Tabelle 1 zeigt die unterschiedlichen Anforderungen an ein System in Abhängigkeit der Verwendung. Trotz der in der Tabelle aufgezeigten Unterschiede dürfen Strategic Intelligence und Operational Intelligence nicht als zwei eigenständige Systeme betrachtet werden, son-dern als Applikationen und Workflows basierend auf derselben konsisten-ten Datenbasis – einem ADW.

Eine zielführende und effektive Behandlung von Geschäftspotenzialen, Geschäftsmodellen, Entscheidungs- und Planungsprozessen auf Basis ei-nes ADW können das Wachstumstempo eines Unternehmens be-schleunigen. Die schrittweise Umsetzung einer Active Enterprise Intelli-gence-Strategie erfolgt nach einer in Kap. 13 beschriebenen Methodologie.

8 Jochen Töpfer

Tabelle 1. Vergleich Strategic Intelligence / Operational Intelligence

Strategic Intelligence Operational Intelligence Benutzer Planer, Analysten, Manager,

Finanz, Marketing Konsumenten, Call Center, Verkäufer, Lieferanten, Systeme / Applikationen

Zu ladende Daten

10–100 pro Sekunde 100–10'000 pro Sekunde

Antwortzeit Sekunden bis Stunden 1–5 Sekunden, in Ausnahmefällen einige Minuten

Update-Frequenz

Tägliche Batch Loads Innerhalb von Minuten und / oder Stunden

Zugriff BI Werkzeuge, Excel Dashboards, Portale, Applikationen, Alerts

Verfügbarkeit Business Critical – kurze Nichtverfügbarkeit ist tolerierbar

Mission Critical – garantierte Hochverfügbarkeit

Abb. 5. Architektur Strategic and Operational Intelligence (Graham 2006)


3 Active Data Warehouse – eine Technologie

Das traditionelle Data Warehouse wurde stets auf die Unterstützung von strategischen Entscheidungsprozessen ausgerichtet. Der Nutzen einer zentralen Informationsquelle für die Analyse von Unternehmenskennzahlen ist unbestritten. Ein Unternehmen in stark umkämpften Märkten zu führen ist aufgrund äußerer Markteinflüsse komplex genug. Eine interne Diskussion über die „richtigen“ oder die „besseren“ Informationen ist hier wenig hilf-reich bzw. lösungsorientiert. Das traditionelle Data Warehouse wird typischerweise von Entschei-dungsträgern im Marketing, Finanzen und Strategischer Planung eingesetzt (Brobst et al. 2007). Gegenüber der strategischen Entscheidungsunterstüt-zung, wo eine eher kleine Gruppe von hochrangigen Entscheidungsträgern bedient wird, erreicht eine taktische Entscheidungsunterstützung alle direkt am Wertschöpfungsprozess beteiligten Mitarbeiter an der Basis. Diese tref-fen „kleine“ Entscheidungen, deren Tragweite und Bedeutung jede für sich betrachtet äußerst gering sind. Bezieht man jedoch die Häufigkeit dieser Entscheidungen mit ein, so ergibt sich für das Unternehmen ein strategi-scher Effekt. Der Wertschöpfungsprozess selbst wird mit relevanten In-formationen bedient, dadurch gesteuert und ständig optimiert. Eine Ver-einheitlichung der Geschäftsprozesse wird ebenfalls unterstützt.

Die Anforderungen, die sich durch eine Unterstützung von taktischen Entscheidungsprozessen an das Data Warehouse ergeben, unterscheiden sich deutlich von denen an ein traditionelles Data Warehouse. Taktische Entscheidungen werden innerhalb einer Woche, eines Tages, einer Stunde, einer Minute oder gar binnen weniger Sekunden getroffen. Die Informati-onsbasis muss diesem Entscheidungsrhythmus angepasst sein. Die Aktua-lität und Verarbeitungsgeschwindigkeit der Daten von den operativen Ba-sissystemen der Geschäftsprozesse bis hin zu entscheidungsrelevanten In-formationen beim Zugriff auf das Data Warehouse muss in der Regel der Geschwindigkeit entsprechen, in der eine Entscheidung getroffen und um-gesetzt wird. Diese Anforderungen an ein Data Warehouse werden von ei-nem Active Data Warehouse (ADW) erfüllt. Hier sind explizite Eigen-schaften eines Active Data Warehouse zu beleuchten, die den Unterschied auch in der einzusetzenden Technologie deutlich machen.

Nachfolgend werden die Merkmale eines Active Data Warehouse wie End-to-End-Performance, Workload Management, Verfügbarkeit und Ver-lässlichkeit, Skalierbarkeit, Betrieb und Wartung sowie der Investiti-onsschutz ausführlich erläutert.

10 Jochen Töpfer

3.1 End-to-End-Performance

Das Ermöglichen von zeitnahen Zugriffsszenarien ist für einen zielkon-formen Einsatz und die Akzeptanz einer ADW-Systemumgebung existen-tiell. Grundsätzlich unterscheiden sich zwei Architekturvarianten, die Sha-red Resource- und Shared Nothing-Architektur. Werden im Rahmen einer Parallelisierung von Einzelrechnern Komponenten wie CPU, Arbeitsspei-cher, Plattenspeicher und Netzwerkbandbreite untereinander genutzt, oder nicht?

Eine Shared Resource-Architektur hat eine möglichst gleichmäßige und hohe Nutzung aller Komponenten zum Ziel, um hierdurch Kosten zu spa-ren. Diese Zielsetzung ist nur auf Kosten der Performance erreichbar.

Eine Shared Nothing-Architektur dagegen ist auf höchstmögliche Re-chenleistung und Input/Output-Bandbreite ausgelegt. Diese Zielsetzung kann zu leicht höherem Speicherplatzbedarf führen. Dennoch ist das Ver-hältnis von Performance zu Kosten wesentlich günstiger als bei einer Sha-red Resource-Architektur (Burns et al. 2004).

Bis zu 1024 Knotenrechner werden über eine vollskalierbare Intercon-nect-Verbindung (BYNET) zu einer Massively Parallel Processing (MPP)- Systemumgebung zusammen geschaltet. Jeder Knotenrechner verfügt über dedizierte Plattenspeicher. Das Server Management erfolgt zentral für die ganze Systemumgebung (vgl. Abb. 6).

Eine gute Performance zu erreichen, ist sicherlich eine generelle Anfor-derung an ein jedes Data Warehouse. Generell kann man die Performance unterteilen in die Zeit, die benötigt wird, ein Data Warehouse zu laden, und in die Zeit, die es benötigt, Anfragen zu beantworten. Doch ob die Leistung eines schnell zu beladenden Data Warehouse, welches aber wäh-rend des Laden keine Abfragen bearbeiten kann höher ist, als die Leistung eines Data Warehouse, welches immer verfügbar ist, dafür aber längere Ladezyklen hat, ist nicht immer klar. Auch ist das Data Warehouse oft nicht das endgültige Ziel der Daten, sondern verteilt diese an Drittsysteme weiter. Ein Data Warehouse muss daher zwingend in der Lage sein, die Performance des eigentlichen Geschäftsprozesses aufrecht zu erhalten und zu beschleunigen. Dies hat zu Folge, dass die Lade- und Abfrage-Zeiten sowie die Verteilung der Leistung auf einzelne Prozesse, Applikationen und Personen flexibel anpassbar werden müssen.


SMP Node1 SMP Node2 SMP Node3 SMP Node4

Server Management

Dual BYNET Interconnects

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

CPU1 CPU2

Memory

Operating Sys

Abb. 6. Teradata Shared Nothing-Architektur

3.2 Workload Management

Einer der Vorteile eines Active Data Warehouse ist, dass es den Front Li-ne- (taktischen Entscheidungsträgern) sowie den Backoffice-Benutzern (strategischen Entscheidungsträgern) zu jeder Zeit eine dem Informations-bedarf angemessene integrierte Sicht auf die Unternehmensdaten ermög-licht. Bis anhin scheiterte dieser Ansatz aber meistens an den technischen Limitationen, unterschiedliche Abfragen gleichzeitig auf einem gemein-samen System zeitgerecht zu verarbeiten. Die Lösung schien lange Zeit im Aufbau und Unterhalt von unterschiedlichen Plattformen für einzelne Ver-arbeitungsschritte und Zielstellungen zu liegen. So wurden beispielsweise operative Abfragen durch ein Operational Data Store (ODS) bedient, der zwar sehr zeitnah mit Daten aus den Geschäftsprozessen befüllt wurde, je-doch weder eine Datenhistorie vorhielt noch eine Integration von Daten

12 Jochen Töpfer

außerhalb des Kernprozesses erlaubte, während analytische Abfragen vom Data Warehouse bedient wurden. Dieser Ansatz jedoch behindert eine zeitgleiche und konsistente Unternehmenssicht für alle Mitarbeiter und Prozesse, führt zu redundanter Datenhaltung, erhöhter Komplexität und den damit verbundenen zusätzlichen Kosten.

Ein erfolgreiches Active Data Warehouse muss deshalb in der Lage sein, operative (taktische) sowie strategische (analytische) Abfragen auf einer Plattform auszuführen, unter Einhaltung definierter und garantierter Antwortzeiten. Hierfür muss das System in der Lage sein, die unterschied-lichen Lastprofile („Workloads“) wiederkehrend zu analysieren, entspre-chende Verhaltensmuster zu entdecken und darauf basierend Benutzer- und / oder Abfragegruppen vorzuschlagen respektive zu definieren. Im Ge-gensatz zu den heute vorherrschenden statischen Ressourcenzuteilungen im Data Warehouse-Umfeld, werden die Ressourcen in einem Active Data Warehouse basierend auf den analysierten Verhaltensmustern sowie der momentanen Systemauslastung, der Ausführungszeit der Abfrage und den mit den Benutzern vereinbarten Service Level Agreements (SLA) dyna-misch zugeordnet. Nur so kann eine optimale Auslastung des Systems und die Verarbeitung jeglicher Abfragen unter Einhaltung der vereinbarten Antwortzeiten garantiert werden (Burns et al. 2004).

3.3 Verfügbarkeit und Verlässlichkeit

Im Gegensatz zu herkömmlichen Analyseumgebungen wird ein ADW zeitgleich von unterschiedlichen Benutzern und / oder Benutzergruppen sowie als integrierter Teil einer übergreifenden Systemlandschaft verwen-det. Dies hat zur Folge, dass vom System dieselbe Verfügbarkeit wie von einem Transaktionssystem verlangt wird. Diese betrifft nicht nur die 100% Systemverfügbarkeit untertags, sondern auch eine Erweiterung des 5x8 Betriebes auf 7x24. Diese Erweiterung der allgemeinen Verfügbarkeit von Business Critical zu Mission Critical hat zwingend zur Folge, dass alle Hardware- und Software-Komponenten hochverfügbar, sprich redundant, und im höchsten Masse fehlertolerant ausgelegt sind.

Beim Aufbau eines Active Data Warehouse und seiner Datenverarbei-tungsprozesse sollte stets darauf geachtet werden, dass Komplexität, Ab-hängigkeiten und manuelle Manipulationen und Interventionen auf ein Minimum reduziert werden.


SMP Node1 SMP Node2 SMP Node3 SMP Node4

Dual BYNET Interconnects

Ausfall eines Knotensführt zu 25% Verlust an Systemleistung

AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP AMP

…migrieren die AMPs auf die verbleibenden Knoten…

AMP AMP AMP

AMP AMP AMP

Falls dieserKnotenaus-fällt,…

X…und die migrierten AMPs könnenw eiterhinüber alternative Pfade auf ihreVDISKs zugreifen.

Abb. 7. AMP Migration nach Ausfall eines Nodes (Burns et al. 2004, S. 23)

Eine hochverfügbare ADW-Systemumgebung zeichnet sich dadurch aus, dass kein Single Point of Failure existiert und automatische Mecha-nismen für den Betrieb bei Ausfall von einzelnen Systemkomponenten in-tegriert sind (vgl. Abb. 7). Dies betrifft Hardwarekomponenten im glei-chen Masse wie die Software und die Daten selbst. Hochverfügbarkeit darf aber nicht nur auf einzelne Systemkomponenten reduziert werden, sondern beinhaltet auch aufbau- und ablauforganisatorische Aspekte, um einen rei-bungslosen Betrieb jederzeit sicherstellen zu können. Da nicht alle Daten und Funktionen in einem Active Data Warehouse gleich kritisch für ein Unternehmen sind, und Anforderungen an die Verfügbarkeit sich mit der Zeit ändern, muss auch die Hochverfügbarkeit skalierbar sein.

3.4 Skalierbarkeit

Die Skalierbarkeit einer ADW-Umgebung ist grundsätzlich in zwei Fällen relevant. Ein konstanter Workload muss trotz eines steigenden Datenvo-lumens in einer durch ein SLA vorgegebenen Zeit erledigt werden. Ein Datenwachstum erfordert eine Size up-Skalierbarkeit. Ebenso denkbar sind steigende Anforderungen an das ADW und somit ein wachsender Work-load bei gleich bleibendem Datenvolumen. Hier ist ebenso eine in SLAs vereinbarte End to End-Performance der Benutzergruppen maßgeblich. Ein steigender Workload erfordert eine Scale up-Skalierbarkeit (Burns et al. 2004).

Natürlich treten diese beiden Anforderungen an die Skalierbarkeit in Kombination auf – mehr Daten, mehr Anwender, mehr Datenbereiche, hö-

14 Jochen Töpfer

here Komplexität und variabler Workload - alles in einem Datenbanksys-tem. Diese Faktoren multiplizieren die einzelnen Effekte. Eine Verdopp-lung sowohl der Daten als auch der Anwender kann leicht zu einer Ver-vierfachung des geforderten Systemdurchsatzes führen.

Die Fähigkeit zur Skalierung einer ADW-Umgebung ist technisch mit der Fähigkeit zur massiven Parallelisierung einer Shared Nothing-Archi-tektur verknüpft. Damit die Anforderungen der Benutzer an ein Active Da-ta Warehouse in Form von Service Level Agreements verfasst werden können, darf die Parallelisierung der Systemumgebung aus technologi-schen Gründen nicht mit Bedingungen bzw. Restriktionen verknüpft wer-den. Um auch große Systemumgebungen und deren Erweiterungen mit hoher Komplexität stets kalkulierbar und damit entscheidungsfähig zu hal-ten, wird eine lineare Skalierbarkeit mit einer Steigung von 1 benötigt. Dies bedeutet, dass das Hinzufügen einer Systemkomponente immer den-selben Mehrwert bezüglich Datenvolumen und Rechenleistung generiert.

Die meisten Data Warehouse-Implementierungen beginnen als relativ kleine, funktions- oder geschäftsbereichsspezifische Installationen. Mit steigender Anzahl Benutzer und zu integrierender Funktions- und Ge-schäftsbereiche steigen auch die Anforderungen an das System bezüglich Speichervolumen und Rechenleistung. Skaliert die Implementierung, so kann diese durch zusätzliche Komponenten erweitert werden, ohne die schon bestehenden ersetzen zu müssen. Dadurch werden früher getätigte Investitionen geschützt. Für eine mehrjährige Gesamtplanung eines Active Data Warehouse und den zukünftig daraus resultierenden Business Cases ist es zusätzlich notwendig, dass die Skalierung linear mit einer Steigung von 1 verläuft. Nur wenn dies der Fall ist, ist man auch in der Lage, die in der Zukunft anfallenden Kosten zu prognostizieren und zu garantieren.

3.5 Betrieb und Wartung

Active Data Warehouses sind anspruchsvolle und komplexe Systeme, aber ihr Betrieb und ihre Verwaltung muss deshalb nicht zwingend kompliziert sein. ADW-Umgebungen zeichnen sich heute durch eine einheitliche Ar-beitsoberfläche für Konfiguration, Monitoring, Administration, Pflege und Wartung aus. Durch den Wegfall von komplizierten, wiederkehrenden und fehleranfälligen Arbeiten reduzieren sich einerseits Infrastruktur- und Pro-zesskosten und das Betriebsrisiko, andererseits wird die Zeit zur Umset-zung neuer Anforderungen stark verkürzt.


3.6 Investitionsschutz

Ein langfristiger Investitionsschutz für eine ADW-Umgebung ist von meh-reren Faktoren abhängig. Die Anforderungen an die beschriebene Skalier-barkeit werden über mehrere Jahre von den in SLAs zugesicherten Ant-wortzeiten definiert. Technologisch betrachtet erfordert dies die Koexis-tenz verschiedener Hardware-Generationen in einer Systemumgebung. Die Kompatibilität von Hardware-Generationen sollte sich an der Langfristig-keit der Strategie einer zentralisierten Informationslogistik orientieren. Ebenso wichtig ist die Flexibilität und Erweiterungsfähigkeit des zugrunde liegenden Datenmodells.

4 Data Integration Services

Folgt man der Vision von Pervasive Business Intelligence unter Anwen-dung einer Active Enterprise Intelligence-Strategie, so wird der Einsatz ei-ner Active Data Warehouse-Technologie unabdingbar. Eine sehr weitge-hende Vision rückt mittels einem mehrjährigem strategischen Um-setzungsprogramm in den Mittelpunkt. Ein Active Data Warehouse be-deutet keinerlei technologische Restriktionen bezüglich Datenvolumen oder Komplexität der Workloads. Das bedeutet jedoch auch stark gestie-gene Anforderungen an die Integration der Daten aus den diversen Vor-systemen in die zentrale Analysedatenbank. Bewerten wir die Qualität der integrierten Unternehmensdaten, so müssen Kriterien wie Aktualität, Ge-nauigkeit, Vollständigkeit und Verständlichkeit im Rahmen eines ADWs auf einem deutlich höheren Niveau implementiert sein (Brobst et al. 2007).

Heutige Data Warehouse-Umgebungen werden vorwiegend täglich über Nacht befüllt. Dies führt meistens zur eingeschränkten Verfügbarkeit des Data Warehouses und / oder der Daten einzelner Quellsysteme. Ein aktives System benötigt aktuelle Daten, und muss so zwingend auch untertags ge-laden und gleichzeitig abgefragt werden können. Hierzu sind intelligente Lade- und Workload-Werkzeuge notwendig, die die unterschiedlichen vorgegebenen Service Level Agreements (SLA) auf Daten- und Benutzer-ebene jederzeit garantieren und flexibel auf wechselnde Ereignisse reagie-ren können.

16 Jochen Töpfer

Abb. 8. Schematische Darstellung der Data Integration Services (Brobst et al. 2007)

Neue unternehmensübergreifende Prozesse benötigen konsistente Daten und Informationen aus unterschiedlichen internen wie auch externen Sys-temen. Diese können entweder für jede neue Anwendung neu zusammen-gestellt werden, was einen wiederkehrenden Aufwand mit den dazugehöri-gen Kosten mit sich bringt, oder aber einmalig zentral integriert und dann den entsprechenden Anwendungen und / oder Prozessen zeitnah zur Ver-fügung gestellt werden. Daten werden unternehmensweit in verschiedenen Systemen benötigt und basieren auf komplexen Transformationen oder sind ein Produkt unterschiedlicher Datensätze. Die zentrale Haltung und Pflege solcher Daten ist unabdingbar.

Doch Zeit und Geld sind nicht die einzigen Treiber, die für eine Inte- gration sprechen. Aufsichtsbehörden und das Risikomanagement fordern heute schon eine verstärkte Nachweispflicht über die jeweilige Herkunft und Qualität der Datensätze. Eine dezentrale Architektur kann einen sol-chen Nachweis nur schwer erbringen, da die einzelnen Datenflüsse stark variieren und kein einheitliches Verständnis bezüglich der Definition ein-zelner Werte existiert. Um solchen Anforderungen gerecht zu werden, wird heute schon, und in der Zukunft verstärkt, ein zentrales Metadaten-management mit dokumentierten Definitionen bezüglich einzelner Werte, ihrer Distributionswege und Besitzer verwendet (Loftis 2007).


4.1 Datenmodellierung

Um eine unternehmensweite, konsistente Entscheidungsfindung zu er-möglichen, müssen die Daten zentral und in einer einheitlichen Struktur gehalten werden. Diese Struktur wird durch ein übergreifendes Datenmo-dell sichergestellt, das mit Hilfe der einzelnen Geschäftseinheiten erstellt und durch die Data Warehouse-Organisation verwaltet und implementiert wird. Ein konsistentes logisches Datenmodell über alle heutigen und zu-künftigen Funktionsbereiche eines Unternehmens ist eine wichtige Vor-aussetzung für Investitionsschutz und flexibles unternehmerisches Handeln gleichermaßen. Investitionsschutz wird dadurch gewährleistet, dass auch zukünftige Geschäftsfelder logisch bereits im Datenmodell vorhanden und somit jederzeit physisch implementierbar sind. Die nachfolgende Tabelle beschreibt dies exemplarisch am Beispiel eines Financial Services Logical Data Model (FS-LDM).

Tabelle 2. Geschäftsfelder des Financial Services Logical Data Model

Parties Kunde, Interessent, Verkäufer, Gegenpartei, Angestell-ter, Schuldner, Demographie

Internal Organizations Niederlassungen, Regionen, Abteilungen, Teams

Events Ein- und Auszahlung, verspätete Gebühr, Konto-standsabfrage, Adresswechsel, Web-Interaktion, Wert-schriftenhandel

Agreements Bankkonto, Geschäftskonto, Kreditbrief, Kreditkarte, Hypothek, Versicherungspolice

Customer Assets Kundenvermögen in Form von Immobilien, Finanz-instrumenten, Autos, Schmuck

Products Produktangebot, Zinsen, Verzugszinsen, Frist und Limit, Kondition, Deckung

Campaigns Kommunikationsplan und Zielgruppe

Channels E-Mail, Telefon, Web, Bankomat

Location Adresse, E-Mail, Stadt, Postleitzahl, Region, Land

Finance Hauptbuch, Journal, Nebenbuch

Das flexible unternehmerische Handeln wird durch eine konsequente Verwendung der Dritten Normalform (3NF) erreicht. Jede Art von Frage-stellung, ob detailliert oder aggregiert, kann beantwortet werden, indem die Beziehungen von Daten hergestellt bzw. genutzt werden.

18 Jochen Töpfer

In vier Schritten wird das Datenmodell ausgehend von einem Refe-renzmodell entwickelt. Ausschlaggebend ist hier die Verwendung eines Referenzmodells, auch wenn die heutige Nutzung nur Teilbereiche ver-wendet. Zukünftige Erweiterungen sind um ein Vielfaches schneller und risikoärmer als ständige Individualergänzungen, da diese stets auf einem auf Integrität geprüften Referenzmodell basieren.

Abb. 9. Entwicklungsschritte eines Datenmodells

Die jeweils benötigte Datenbasis und die dazugehörige Granularität hängen stark von der jeweiligen Fragestellung und der geforderten Ge-nauigkeit des Resultates ab. Um sich einen Überblick über die momentane Geschäftssituation zu verschaffen, genügt oft ein approximativer Wert, wogegen z. B. ein Monatsabschluss alle Transaktionen und Buchungen berücksichtigen muss. Um die tägliche Last und die Speicherkapazität ein-zelner Systeme möglichst tief zu halten, haben einige Unternehmen des-halb in der Vergangenheit damit begonnen, Daten nur noch in aggregierter Form den Benutzern zur Verfügung zu stellen.

Aggregierte Daten haben den Vorteil, dass sie einerseits weniger Platz benötigen als einzelne Werte und anderseits die Antwortzeiten und die Re-chenlast der einzelnen Systeme optimieren. Dagegen spricht aber klar der Geschäftsnutzen granularer Daten. Systeme mit vorwiegend aggregierten Daten sind meistens zweckgebundene Systeme und verfügen nicht über die in der Zukunft benötigte Flexibilität. Neue Anforderungen enthalten neue Fragestellungen, die ihrerseits auf einer bestimmten Granularität aufsetzen. Dies führt unweigerlich zu einer Ansammlung von (Sub-) Systemen mit jeweils derselben Datenbasis auf unterschiedlicher Aggregationsstufe. Daraus resultieren der Verlust von Flexibilität, erhöhter Entwicklungs- und


Unterhaltsaufwand sowie erschwerte Nachweisbarkeit bezüglich der Ent-stehung einzelner Werte.

Zukünftige Systeme müssen daher in der Lage sein, granulare Daten ef-fizient zu bewirtschaften und diese den einzelnen Benutzern in jeweils ge-eigneter Form zur Verfügung zu stellen.

4.2 Metadaten

Den Kern eines proaktiven Ansatzes für das Management von Unterneh-mensdaten bildet das Data Dictionary. Das Data Dictionary stellt einen zentralen Punkt dar, an dem unterschiedliche Abteilungen sowie Fachbe-nutzer und technische Teams ein gemeinsames Verständnis von Daten festlegen. Damit wird für den Gebrauch und die Anwendung von Datenbe-ständen Konsistenz geschaffen. Insbesondere die Beschreibung von Da-tenquellen und die Definition von unternehmensweit gültigen Kennzahlen sind erforderlich, um eine hohe Akzeptanz von jedweden Anwendungen zu erreichen. Es muss nicht betont werden, dass es in einem Unternehmen nur ein Data Dictionary für Daten und Informationen eines Unternehmens und deren Verwendung geben kann. Sehr zeitaufwändige und vergangen-heitsorientierte Diskussionen über im Unternehmen präsentierte Informati-onen können hierdurch vermieden werden.

4.3 Aktualität

Unternehmen jeder Größe brauchen Lösungen, die Wissen aufbauen, die Produktivität erhöhen und ein Unternehmen in die Lage versetzen, vor ih-rem Wettbewerb auf Veränderungen im Markt zu reagieren. Der rechtzei-tige Zugriff auf relevante aktionsfähige Daten, um eine schnelle, präzise und unternehmensweite Entscheidungsfindung zu ermöglichen, ist ein Al-leinstellungsmerkmal im verschärften Wettbewerb. Um den Wertbeitrag der Datenaktualität zu beurteilen, ist es erforderlich zu verstehen, in wel-cher Weise Daten Entscheidungsprozesse unterstützen bzw. diese über-haupt ermöglichen.

Strategische Entscheidungsprozesse, die über die langfristige Zukunft eines Unternehmens entscheiden, werden in einem Zeitraum von 3–18 Monaten getroffen. Hierfür ist eine monatliche bzw. quartalsweise Daten-aktualität ausreichend. Viel wichtiger als die Aktualität ist hier der Grad der Datenintegration (über Funktionsbereiche) bei gleichzeitiger Aggrega-tion in managementfähige Geschäftseinheiten (Management Reporting vs. Legal Reporting, Business Divisions vs. Legal Entities).

20 Jochen Töpfer

Kurzfristige Entscheidungsprozesse lassen sich anhand der Datenaktua-lität wie folgt gliedern:

Kurzfristige Entscheidungsprozesse mit

monatlicher Aktualität, täglicher Aktualität, 4-stündlicher Aktualität oder ¼-stündlicher Aktualität der zugrunde liegenden Daten.

Welche Aktualität der Daten erforderlich ist, lässt sich daran ablesen, wann eine Entscheidung auf der Basis aktueller Daten vor der nächsten Aktualisierung der Daten getroffen und umgesetzt wird.

Tagesaktuelle Daten sollten nur dann gefordert werden, wenn eine Ent-scheidung am folgenden Tag erfolgt.

4-stündlich aktuelle Daten ermöglichen eine Entscheidung noch am sel-ben Tag.

¼-stündliche Aktualität ist dann sinnvoll, wenn der Entscheidungspro-zess unmittelbar eingeleitet wird und in den nächsten Minuten beendet ist.

Um den Wertbeitrag einer ADW-Infrastruktur zu berechnen, die vier- bzw. ¼-stündliche Datenaktualität ermöglicht, müssen Wertbeiträge von Geschäftsmodellen ermittelt werden, die eine Vielzahl von kurzfristigen Entscheidungsprozessen beinhalten. Ein Beispiel hierfür ist die Freigabe von Privatkrediten innerhalb 24 Stunden. Auch eine Real Time-Überprü-fung wie z. B. das Scoring von Kreditkarten-Transaktionen, erfordert eine minütliche Datenaktualität.

Führende Finanzinstitute verfügen über tagesaktuelle Unternehmensda-ten und arbeiten an der untertägigen Aktualität. Besondere Schwierigkeit bestehen im Bereich der Datenintegrationsprozesse, die in der Regel über Nacht ablaufen und 8–10 Stunden benötigen. Erste Herausforderung ist es somit, eine Infrastruktur aufzubauen, die alle Datenintegrationsprozesse in unter 4 Stunden abwickeln kann. Hat man dies erreicht, so ist es anschlie-ßend noch eine Frage des Intervalls, kleinere Datenmengen entsprechend noch schneller zu verarbeiten. Das nächtliche so genannte Batch-Window der Datenintegrationsprozesse ist jedoch durchbrochen und die Infrastruk-tur sollte generell für die Intervalle eines ADW geeignet sein.

Gleichzeitig muss betrachtet werden, dass die in operativen Basissyste-men anfallenden Prozessdaten den Datenintegrationsprozessen untertags bereitgestellt und damit weiterverarbeitet werden können. Hier gilt es ebenso eine untertägige Verarbeitung zu ermöglichen.


4.4 Qualität

Zunehmend sehen Unternehmen integrierte Daten als einen Wettbewerbs-vorteil an, der die Zusammenarbeit mit den Kunden und Veränderungspro-zesse allgemein verbessern lässt. Soll die Qualität integrierter Unterneh-mensdaten verbessert werden, so wird ein Business Case benötigt, der Kosten aufgrund schlechter Datenqualität reduzieren lässt, oder aber die Erfolge verbesserter Datenqualität in Geschäftsnutzen verwandelt. Wie kann der Geschäftsnutzen verbesserter Datenqualität ermittelt werden? Ge-lingt es, die Datenqualität zu verbessern, so bleibt ungewiss, ob die Ver-besserung schnell und effektiv genug erfolgt. Die Nachfrage nach In-formationsmanagement steigt besonders mit der Zunahme der Benutzer-zahl und des Datenvolumens sprunghaft an. Veränderungsprozesse müssen Jahr für Jahr schneller durchgeführt werden. Der erhöhte Veränderungs-druck führt zwangsläufig zu einer höheren Umsetzungsgeschwindigkeit, die bezüglich der Qualität ein erhöhtes Risiko mit sich bringt. Es entsteht insbesondere bei der Datenqualität ein Mengen- und Komplexitätspro-blem. Das gesamte System ist durch die großen Datenmengen und die Vielzahl an Verarbeitungsprozessen sehr träge. Jeder Fehler in einem Teil-prozess (Datenbelieferung, Datenverarbeitung und Datenselektion) erzeugt weitere Folgefehler, so dass selbst kleine Korrekturen sehr zeitaufwändig sind.

Ein Active Data Warehouse leistet durch den zentralisierten Ansatz ei-ner integrierten Datenmodellierung implizit einen großen Beitrag zur Ver-besserung der Datenqualität. Die Aufteilung der Unternehmensdaten in ein ODS und eine Vielzahl von Data Marts meist über unterschiedliche In-frastrukturen hinweg birgt das größte Qualitätsrisiko. Weiterhin eliminiert ein unternehmensweites, einheitliches logisches Datenmodell über alle Un-ternehmens- und Funktionsbereiche eine Vielzahl von weiteren Fehler-quellen durch die Verringerung der Schnittstellenzahl.

5 Decision Services

Die Vision von Pervasive Business Intelligence umfasst sämtliche Formen der Entscheidungsunterstützung für alle Mitarbeiter im Unternehmen. Zentral aufbereitete und integrierte Unternehmensdaten in einem ADW enthalten nicht nur einfache Sichtweisen auf die Transaktionsdaten der Vorsysteme, sondern durch eine integrierte Business Intelligence-Plattform sind die analytischen Bedürfnisse, die Kenntnisse, die Zustellmethoden und Arbeitsmittel der unterschiedlichen Anwendergruppen bzw. auch ein-zelner Anwender angewendet (Brobst et al. 2007).

22 Jochen Töpfer

Abb. 10. Eine Business Intelligence Plattform als Basis der Decision Services (Brobst et al. 2007, S. 13)

Um alle Facetten von Planung, Simulation, Budgetierung, Forecasting, Konsolidierung, Ad-hoc-Analyse und Reporting in eine Vision Pervasive Business Intelligence einzuordnen, ist es hilfreich, einige grundlegende Konzepte von einander abzugrenzen.

Ein betriebswirtschaftliches Unternehmensmodell beschreibt vereinfacht die Funktionsweise eines Unternehmens im Markt und somit dessen ex-terne und interne Zusammenhänge und Abhängigkeiten. Es besteht aus Basis-Daten (exogene Größen) und berechneten Kennzahlen (endogenen Größen). Unternehmensmodelle können für Plan- oder Ist-Daten entwic-kelt werden, unterscheiden sich dann in den Datenstrukturen und Rechen-algorithmen. Dieser Umstand wird sehr häufig ignoriert.

Planung bezeichnet den organisatorischen Prozess, um über die Erstel-lung von Szenarien bzw. Simulationen zu Plan-Daten zu gelangen. Es werden Datenstrukturen und Rechenvorschriften verwendet, die nur für die Planung, nicht jedoch für die Ist-Berichterstattung verwendet werden kön-nen. Zum Abschluss eines Planungsprozesses werden die Planwerte auf einer vorgegebenen Aggregationsstufe in die Ist-Struktur überführt. Nur dann können die unterjährigen Controllingprozesse wirksam erfolgen. Auch hier gilt als oberstes Gebot die Nachvollziehbarkeit der Erkenntnisse des Planungsprozesses während der täglichen Controllingarbeit und Unter-nehmenssteuerung.

In den Unternehmen findet neben einer strategischen Planung eine jähr-liche Budgetierung statt. Was unterscheidet eine Budgetierung von einer Planung, nur die Bezeichnung oder die Periodizität? Eine Budgetierung ist eine deutlich vereinfachte Form der monetären Planung in Ist-Strukturen. Für eine Auswahl von in der Regel aggregierten Größen des Ist-Berichts-wesens werden Jahreswerte festgelegt – „budgetiert“. Der gedankliche Ausgangspunkt in einer Planung ist das Geschäftsmodell, dargestellt durch das betriebswirtschaftliche Modell, in dem das Unternehmen im Markt ak-tiv ist. Bei einer Budgetierung werden hingegen die Strukturvorgaben der


operstiven Systeme, die erfolgte Transaktionen des Geschäftsbetriebs do-kumentieren, genutzt.

Es wird deutlich, dass hier ganz unterschiedliche Herangehensweisen gewählt werden, die erheblichen Einfluss auf die Architektur der unterstüt-zenden Systeme haben. Pervasive Business Intelligence erfordert die Integ-ration beider genannter Herangehensweisen in einem ganzheitlichen Mo-dell. Erst dann werden alle Mitarbeiter eines Unternehmens von der strate-gischen Unternehmensplanung über das Jahresbudget einer Geschäftsein-heit und die täglichen Controllingprozesse an der Unternehmenssteuerung beteiligt. Für die unmittelbare Verzahnung, Einbezug und Unterstützung auch der vielen kleinen Entscheidungen der Front Line Worker ist eine solche ganzheitliche Active Enterprise Intelligence-Strategie auf Basis ei-nes Active Data Warehouse unabdingbar.

5.1 Zugriff

Der Zugriff auf Daten eines ADW geschieht wann immer ein Benutzer oder eine operative Applikation über verschiedene Lieferungsmechanis-men Daten beziehen. Meistens sind dies schnelle, taktische Abfragen ba-sierend auf historischen und / oder aktuellen Daten. Die daraus resultieren-den Antworten müssen typischerweise innerhalb von wenigen Sekunden dem jeweils zu unterstützenden Geschäftsprozess, dem Benutzer oder Sys-tem zur Verfügung gestellt werden (Brobst et al. 2007).

Abb. 11. Zugriffskanäle für die BI-Plattform (Brobst et al. 2007, S. 15)

24 Jochen Töpfer

Um solche Abfragen innerhalb der geforderten Zeit verarbeiten zu kön-nen, ohne gleichzeitig die zugesagte Verfügbarkeit für strategische Abfra-gen zu gefährden, wird ein Active Data Warehouse benötigt. Während die Integration zu den umliegenden Systemen mittels standardisierter Kon-nektoren in einer nachricht- oder in der Zukunft vermehrt serviceorien-tierten Umgebung realisiert wird, muss das Active Data Warehouse über technische Möglichkeiten verfügen, die Antwortzeiten zu optimieren, ohne die parallel laufenden Aktivitäten zu behindern.

5.2 Ereignisse

Moderne Unternehmen verhalten sich im Rahmen des Geschäftsmodells ereignisgesteuert und reagieren auf Gelegenheiten und Probleme situati-onsbezogen bei deren Eintritt. Ein solches Ereignis kann eine einfache Bu-chung oder eine risikobehaftete Hypothekanfrage und deren Ausstellung sein. Ereignisse dieser Art können entweder direkt in der entsprechenden operativen Applikation oder aber zentral im Active Data Warehouse ent-deckt, und basierend auf ihrer Dringlichkeit bearbeitet werden. Insbeson-dere komplexe Ereignisse können selten direkt von der operativen Appli-kation entdeckt und abschließend bearbeitet werden, sondern benötigen weitere aktuelle und / oder historische Informationen, die typischerweise durch das Active Data Warehouse verwaltet werden. Dieses muss daher jederzeit in der Lage sein, solche Ereignisse zu erkennen, zu priorisieren und gemäß definierten Regeln zu verarbeiten bzw. adäquate Aktivitäten über geeignete Kommunikationskanäle zu initiieren. Dieses Verfahren wird als Enterprise Event Management (EEM) bezeichnet und wird bei vielen Unternehmen für eine Vielzahl von Anwendungsfällen eingesetzt.

EEM findet organisationsübergreifend Anwendung, wo immer Infor-mationen für Entscheidungen herangezogen werden, die signifikanten Ein-fluss auf Umsatz und Profitabilität haben. Beispiele hierfür sind Eventba-siertes Marketing (z. B. bedarfsgerechte Beratung bei ungewöhnlich hohen Zahlungseingängen), Kreditrisikomanagement (z. B. Abfolge verspäteter Ratenzahlungen), Management operationaler Risiken (z. B. übermäßig vie-le Korrekturen bei direkten Eingaben), Betrugserkennung (z. B. überhöhte Cash Handling-Fehler), Geldwäscheerkennung (z. B. Konten-Inhaber-„Ketten”) oder Audit / Compliance (z. B. abnorme Trading-Mengen und / oder Werte).

Aktuelle ereignisbasierte Anwendungen sind derzeit - sofern überhaupt automatisiert - meist bereichsspezifisch ausgelegt und isoliert umgesetzt. Der strategische Fokus auf den „ganzheitlichen Kunden“ wird in der Zu-kunft zu einer unternehmensweiten Synchronisation bzw. Zusammenfüh-


rung der EEM-Aktivitäten führen. Zunehmend werden Synergien zwi-schen verschiedenen fachlichen Bereichen gesucht und berücksichtigt so-wie die Prozesse für die Definition von Ereignissen und die Operationali-sierung der Ereignisse synchronisiert. Der Werttreiber der Zukunft wird vernetztes, bereichsübergreifend genutztes Wissen sein. Beispielsweise werden Kundenereignisse mit Marketing-Hintergrund zukünftig verfeinert durch Informationen aus dem Credit Management-Bereich zum Risiko-Profil der Kunden und die Bewertung des Ereignisses und die Auswahl der Folgeschritte anhand dieser Fremdinformationen abgestimmt.

Essentiell für erfolgreiches EEM sind historische und aktuelle Daten feinster Granularität, die konsistent aus den verschiedenen fachlichen Be-reichen zusammengeführt und strukturiert in einem ADW abgelegt sind.

Das Nutzenpotenzial von EEM auf Basis eines ADW sind:

gemeinsam nutzbare, nicht-redundante Daten, gemeinsam nutzbare Prozesse, gemeinsam nutzbare Mittel und Fähigkeiten, verkürzte „Time to Market”-Dauer, größere Flexibilität, niedrigere „Total Cost of Ownership”.

Beispiele von Geschäftsnutzen durch EEM:

Kostentransparenz und -controlling durch automatisiertes operatives Credit und Financial Risks Management (z. B. proaktives Erkennung und Initiierung von Folgeaktivitäten),

Optimierung der Kundenbeziehungen durch ein integriertes Com-munications Framework (z. B. ereignisbasierte, zeitnahe und personali-sierte Kundendialoge),

Institutionalisierung der (dynamischen) Koordination und Verwaltung tausender, komplexer Ereignisse und zugehöriger Aktivitäten gemäß der Geschäftsprozesse.

6 Zitate von Anwendern

“We recalculated customer profitability using the account level metric produced by Teradata Value Analyzer, which showed that 75 percent of our customers moved two or more deciles.” Kevin Purkiss, Manager Customer Analytics, RBC Financial Group

26 Jochen Töpfer

“DnB NOR is running event-based marketing through all distribution channels. The Teradata EBM solution gives us the ability to track infor-mation on each individual customer, react to the information, and find op-portunities for growth.” Kari Opdal, Head of CRM, DnB NOR

“National Australia Bank today runs 140 individual campaigns every night and over 400 on weekends. We have witnessed an increased share of wallet in key customer segments, and we have certainly been able to re-duce our marketing costs.” Charles Lawoko, Head of CRM, National Australia Bank

“We have been able to use our application design in combination with the Teradata Warehouse solution to create an active data warehousing en-vironment that conventional database platforms would not support very well. Teradata has given us the ability to utilize actual transactional data in powerful queries without requiring data extraction into a separate data warehouse, allowing us to bypass issues of data versioning and conver-sion. Combining Teradata services, active data warehousing, and scalable software and hardware gives us the tools we need to keep PING on top of the leader board.” Kent Crossland, Information Services Director, PING, Inc.

“Eighty percent of our workload is real time or near real time. We load data from the operational system into the data warehouse in near real time; it’s never more than a minute or two behind. Marketing wants real time information, and we give it to them. The business side wants informa-tion every hour or every other hour; finance pulls some data on a daily ba-sis. We’re providing data for lots of different parts of the company. The important thing is that wherever a number is used, whoever is looking at it, whatever the view, it’s the same number.” Jack Garzella, Vice President of Data Warehouse Reporting and Analysis, Over-stock.com


Literatur

Brobst, S.; Markarian, J.; Bedell, J.: Critical Success Factors Deploying Pervasive BI, Teradata White Paper, 2007.

Burns, R.; Drake, D.; Winter, R.: Scaling the Enterprise Data Warehouse, Winter Corporation White Paper, 2004.

Graham, D.: Enabling the Agile Enterprise with Active Data Warehousing, Tera-data White Paper, 2006.

Imhoff, C.: Enterprise Business Intelligence, Intelligent Solutions White Paper, 2006.

Loftis, L.: A perfect combination, in: Teradata Magazine 7 (2007) 2. Müller-Scholz, W.: Messlatte für Schweizer Banken, in: Business Intelligence

Magazin (2007) 3. Töpfer, J.: Wie entsteht Enterprise Intelligence, in: Business Intelligence Magazin

(2006) 3, S. 36-37. White, C.: Who needs real-time business intelligence?, in: Teradata Magazine 7

(2007) 3. Zaima, A.; Schrader, D.: Business Analytics in an Active World, in: Teradata Ma-

gazine 7 (2007) 3.

2 Business Engineering – Betriebswirtschaftliche Konstruktionslehre und ihre Anwendung in der Informationslogistik

Robert Winter

Universität St. Gallen

1 Change the Business vs. Run the Business ....................................... 292 Aufgabenstrukturierung der Veränderung ........................................ 313 Ziele und Ergebnisse der Veränderung ............................................ 344 Gegenstand der Veränderung ........................................................... 365 Grundlegende Veränderungsprozess-Szenarien ............................... 386 Business Engineering für Betriebsprozesse ...................................... 41

Literatur ............................................................................................ 41

1 Change the Business vs. Run the Business

Das Unternehmensmodell des neuen St. Galler Managementmodells ver-steht Organisationen als komplexe soziale Systeme, die unter den verschie-densten Blickwinkeln verstanden und gestaltet werden müssen. Einige die-ser Blickwinkel sind einfach verständlich. So ist z. B. naheliegend, dass Anspruchsgruppen wie Kapitalgeber, Kunden, Mitarbeitende, Öffentlich-keit, Staat, Lieferanten und Mitbewerber sich jeweils für spezifische As-pekte von „Unternehmen“ interessieren (z. B. Ertrag, Risiko, gesellschaft-licher Nutzen, ökologische Nachhaltigkeit). Auch die Sicht auf die „Unternehmung“ als System vernetzter Management-, Geschäfts- und Un-terstützungsprozesse ist naheliegend. Hinsichtlich anderer Blickwinkel wie z. B. der Interaktionsthemen „Ressourcen“, „Normen / Werte“ und „An-liegen / Interessen“ oder der Ordnungsmomente „Strategie“, „Strukturen“

30 Robert Winter

und „Kultur“ sei auf die entsprechende Literatur verwiesen (Dubs et al. 2004). Für das Business Engineering ist ein weiterer Blickwinkel interes-sant, nämlich der so genannte Entwicklungsmodus. Als grundlegende Ent-wicklungsmodi werden im St. Galler Managementmodell „Optimierung“ und „Erneuerung“ unterschieden (in Anlehnung an Rüegg-Stürm 2002). Das heißt, dass sich die Analyse und Gestaltung von Unternehmen grund-sätzlich anders gestalten, je nachdem, ob bestehende Strukturen und Pro-zesse optimiert werden oder ob die grundlegende Erneuerung von Struktu-ren und Prozessen im Mittelpunkt der Betrachtung steht. Die Unterscheidung von Optimierung und Erneuerung findet sich in der Wirt-schaftspraxis auch im Begriffspaar „Run the Business“ vs. „Change the Business“.

Während die meisten Methoden der betriebswirtschaftlichen Funktio-nallehren (wie z. B. Marketing, Finanzmanagement, HR-Management etc.) nicht dediziert auf Veränderungsvorhaben zugeschnitten sind und damit dem Entwicklungsmodus „Optimierung“ zugeordnet werden können („Run the Business“), versteht sich Business Engineering als „betriebswirt-schaftliche Konstruktionslehre“, d. h. stellt Modelle und Methoden für den Entwicklungsmodus „Veränderung“ („Change the Business“) bereit.

Die Auslöser vieler Veränderungen sind Technologieinnovationen, und zwar in erster Linie aus dem Bereich der Informations- und Kommunika-tionstechnologie: Kapazität und Leistungsfähigkeit in der Chip- und Spei-chertechnologie wachsen immer noch entsprechend Moores Gesetz. Die Standardisierung von Applikationen und Diensten, die Verbilligung und Steigerung von Netzwerkbandbreiten, neue Formen der Verknüpfung und Nutzung von Informationen usw. führen zu neuen Potenzialen für Auto-matisierung, Standardisierung und Arbeitsteilung. Neben technologischen Treibern werden Veränderungen aber auch durch andere Treiber ausgelöst. Zu nennen sind etwa veränderte Organisationsformen (z. B. virtuelle Or-ganisation oder dezentralisierte Netzwerkorganisation), umfassendere Orientierung an Kundenprozessen, Verhaltensänderungen von Kunden und Mitarbeitenden oder Veränderungen ökonomischer Rahmenbedingungen (Globalisierung, Deregulierung von Branchen und enger gefasste Com-pliance-Regeln).

Ein gutes Beispiel für die Vielschichtigkeit von Veränderungsvorhaben ist die Vernetzungsfähigkeit. Die Fähigkeit, Kooperationen innerhalb von Organisationen und vor allem zwischen Organisationen einzugehen und dynamisch weiterzuentwickeln, erscheint immer wichtiger. Das Informa-tionszeitalter ist kundenseitig durch Wertschöpfungsnetzwerke geprägt, die Kundenprozesse ganzheitlich unterstützen (Kagermann u. Österle 2006). Andererseits ist es produktionsseitig auf industrielle Strukturen angewie-sen, die Effizienz durch Arbeitsteilung und Standardisierung erreichen.

Business Engineering 31

Vernetzungsfähigkeit ist aber nicht allein durch Daten-Schnittstellen, in-terorganisationale Prozesse, eine Netzwerkstrategie und Kooperationsbe-reitschaft der Mitarbeitenden realisierbar. Erst ein ganzheitliches Vernet-zungskonzept ist erfolgversprechend, in dem Strategie, Prozesse und In-formationssysteme aufeinander abgestimmt („konsistent“) gestaltet sind (Fleisch 2000).

Die vielen Beteiligten, die Unterschiedlichkeit der Perspektiven und Ansprüche, die hohe Komplexität und die finanzielle Bedeutung vieler Veränderungsvorhaben verbieten ein intuitives oder einseitiges (z. B. al-lein Technologie-orientiertes) Vorgehen. Um komplexe Zusammenhänge systematisch abzubilden, die verschiedensten Perspektiven miteinander zu verknüpfen, mit den unterschiedlichen Anspruchsgruppen zu kommunizie-ren, arbeitsteilig vorzugehen und genügend Planungs- / Steuerungssicher-heit zu erreichen, bedarf es eines systematischen und gleichwohl ganzheit-lichen Ansatzes. Systematisch bedeutet dabei, dass der Ansatz modell- und methodenbasiert ist („ingenieurmäßiges Vorgehen“ (Österle u. Winter 2003b). Als Nebeneffekte der Modell- und Methodenbasierung wird das Vorgehen transparent, werden Ergebnisse dokumentiert und werden Grundlagen für Implementierung und Optimierung geschaffen.

Business Engineering versteht sich als betriebswirtschaftliche Kons-truktionslehre für Veränderungsvorhaben. Dazu werden Modell- und Me-thodenkomponenten aus Betriebswirtschaftslehre, Change Management, Systems Engineering und Technologiebeobachtung integriert (Österle u. Winter 2003a). Business Engineering setzt damit die Tradition fort, die mit Software Engineering als Konstruktionslehre für Software (Balzert 2000) oder Information Engineering als Konstruktionslehre für Informations-flüsse und -nutzung (Martin 1989) begonnen hat. Allerdings ist der Gegen-stand des Business Engineering nicht auf Software oder Informationsflüsse beschränkt, sondern umfasst Organisationen wie Unternehmen, öffentliche Verwaltung und nichtstaatliche Institutionen – in Teilen, als Ganzes oder als Netzwerke.

2 Aufgabenstrukturierung der Veränderung

Die Vielzahl der in Abschn. 1 skizzierten Sichten des St. Galler Unter-nehmensmodells macht deutlich, dass die Gestaltung aller wichtigen As-pekte einer Unternehmung oder selbst einer einzelnen Geschäftseinheit nicht simultan erfolgen kann. Deshalb ist es wichtig, eine sinnvolle Struk-turierung der Aufgaben in der Veränderung zu finden, wobei jedoch die

32 Robert Winter

notwendige Ganzheitlichkeit der Veränderungsgestaltung durch geeignete Mechanismen gewährleistet werden muss.

Die Aufgabenstrukturierung muss ausreichend generisch sein, um der Vielgestaltigkeit von Veränderungsvorhaben gerecht zu werden. Beispiele für Veränderungsvorhaben sind

die Umgestaltung oder der radikale Neuentwurf von Kern-, Unterstüt-zungs- und / oder Führungsprozessen,

die Überführung monolithischer Geschäftsmodelle in vernetzte Ge-schäftsmodelle,

die Umstellung von hierarchischer auf marktliche Koordination (Ver-selbständigung von Funktionalbereichen),

die Aus- oder Einlagerung von Teilprozessen oder Aufgaben zwischen Unternehmen oder Verwaltungen (Out- / Insourcing),

die Integration oder Aufspaltung von Organisationen, der systematische Aufbau und die systematische Nutzung von Informa-

tionen (z. B. integriertes Kundenwissen), die Herstellung von Orts-, Zeit- und Kanalunabhängigkeit von Produk-

ten / Leistungen, die Nutzung elektronischer Vertriebs- und Zugangskanäle für Produkte /

Leistungen, die Nutzung elektronischer Marktplätze für Beschaffung, Handel und

Vertrieb, die Digitalisierung und Integration von Medien oder die Standardisierung / Konsolidierung von IT-Infrastrukturen oder Soft-

warekomponenten.

Die hohe Zahl gescheiterter Veränderungsprojekte hat zu vielen Unter-suchungen geführt, die immer wieder mangelnde Veränderungswilligkeit und / oder mangelnde Veränderungsfähigkeit bei Betroffenen und Betei-ligten als wichtigen Einflussfaktor identifizieren (Beuck 2005). Neben den verschiedenen in der obigen Aufzählung enthaltenen fachlichen Fragen müssen deshalb auch Aspekte betrachtet werden, welche mit der Unter-nehmenskultur, der Unternehmensführung, den Machtverhältnissen und Ansprüchen, der Motivation und dem Verhalten der Betroffenen bzw. Be-teiligten zusammenhängen.

In Anlehnung an die Ordnungsmomente des St. Galler Managementmo-dells lassen sich in erster Näherung die verschiedenen Aufgaben in der Veränderung den folgenden Betrachtungsebenen zuordnen:

Strategieebene: Hier werden für die betrachtete Einheit (Unternehmen oder Geschäftseinheit) die Positionierung im Wettbewerb und hinsicht-


lich Kompetenzen, die daraus folgende Positionierung in Wertschöp-fungsnetzwerken, das Produkt- / Leistungsprogramm und das Zielsys-tem betrachtet. Diese Gestaltungsfragen lassen sich auch als WAS-Fra-gen bezeichnen.

Organisationsebene: Hier werden für die betrachtete Einheit Aktivitäten, Abläufe, Verantwortlichkeiten und Berichtswege, operative Führung, organisatorische Einheiten sowie Informationsbedarfe und -flüsse be-trachtet. Diese Gestaltungsfragen lassen sich auch als WIE-Fragen be-zeichnen, da sie die Umsetzung der strategischen Festlegungen behan-deln.

Systemebene: Hier werden für die betrachtete Einheit Applikationen, Softwarekomponenten, Datenstrukturen sowie Hardware- und Vernet-zungskomponenten betrachtet. Diese Gestaltungsfragen lassen sich auch als WOMIT-Fragen bezeichnen, da sie die Unterstützung der Organisa-tion durch Anwendungssysteme behandeln. Zur weiteren Differenzie-rung von Modellen und Methoden kann die Systemebene in Unterebe-nen zerlegt werden, z. B. für IT-Infrastruktur, Software / Daten und In-tegration.

Politisch-kulturelle Ebene: Hier werden für die betrachtete Einheit Or-ganisationskultur, Führung, Macht, Motivation und Verhalten be-trachtet. Diese Gestaltungsfragen lassen sich auch als WARUM-Fragen bezeichnen, weil es hier um die Ursachen und Hintergründe für die Un-terstützung oder Verhinderung von Veränderungen geht.

„Change the Business“ wird im Business Engineering als Prozess ver-standen, durch den, ausgelöst und ermöglicht durch bestimmte „Enabler“, Veränderungen auf allen genannten Ebenen konsistent geplant und umge-setzt werden. Die sog. Business Engineering-Landkarte umfasst deshalb neben den vier Betrachtungsebenen für Aufgaben in der Veränderung zwei Prozessteile:

1. Enabler erkennen und bewerten sowie 2. Veränderungen konsistent planen und umsetzen.

Abbildung 1 stellt die Business Engineering-Landkarte dar. Da sehr häufig IT-Innovationen der Enabler für Veränderungen sind (siehe dazu auch die Aufzählung von Veränderungsvorhaben weiter oben), wird in Abb. 1 der Erkennungs- und Bewertungs-Prozessteil als „IT als Enabler“ bezeichnet.

Um die Notwendigkeit einer ganzheitlichen Planung und Umsetzung von Veränderungen über alle Betrachtungsebenen hinweg zu verdeutli-chen, umfasst in Abb. 1 der als „Transformation“ bezeichnete Planungs- und Umsetzungs-Prozessteil alle Betrachtungsebenen.

34 Robert Winter

Strategie(Vernetzung, Ziele, Positionierung)

Organisation(Prozesse, Strukturen, Information)

System(Integration, Software, IT-Infrastruktur)

FührungVerhalten

Macht

Transformation

IT als Enabler(und andere Auslöservon Veränderungen)

Abb. 1. Business Engineering-Landkarte (in Anlehnung an Österle u. Winter 2003b)

3 Ziele und Ergebnisse der Veränderung

Um die Effektivität und Effizienz der Planung und Umsetzung von Verän-derungen sicherstellen zu können, müssen die Ergebnisse der Veränderung und die im Veränderungsprozess zu beachtenden Zielsetzungen spezifiziert sein. Effektivität heißt, dass spezifizierte Ergebnisse erzielt werden („das Richtige tun“). Effizienz heißt, bei der Erzeugung der Ergebnisse die spe-zifizierten Ziele zu beachten („es richtig tun“).

Auch hinsichtlich Zielen und Ergebnissen der Veränderung lassen sich – wie bei der Systematisierung der Aufgaben in der Veränderung – trotz der Vielgestaltigkeit von Veränderungsvorhaben bestimmte Strukturierungen feststellen. Da sich das Ergebnis an den zu erreichenden Zielen orientiert, werden zunächst die Ziele der Veränderung betrachtet.

Da Organisationen wie Unternehmen, öffentliche Verwaltung und nichtstaatliche Institutionen im Mittelpunkt der Betrachtung stehen, sind zunächst die Ziele der verschiedenen Anspruchsgruppen zu beachten. Eine besondere Rolle spielen dabei Wirtschaftlichkeitsziele. Veränderungsvor-haben dienen dazu, die Wirtschaftlichkeit zu erhöhen oder andere Ziele be-stimmter Anspruchsgruppen besser zu erfüllen.


Um Sachziele wie geringere Kosten, höhere Erträge, höhere Geschwin-digkeit, bessere Qualität und / oder höhere Flexibilität zu erreichen, ver-folgen Veränderungsvorhaben verschiedene Formalziele:

Werden Strategien, Organisationen und / oder Systeme flexibler gestal-tet, lassen sie sich schneller, besser oder mit geringeren Kosten an be-kannte, antizipierbare Veränderungen anpassen. Werden Strategien, Or-ganisationen und / oder Systeme agiler gestaltet, darf erwartet werden, dass sie sich schneller, besser oder mit geringeren Kosten an unbe-kannte, zukünftige Veränderungen anpassen lassen.

Durch Vereinfachung lassen sich bestimmte Ergebnisse mit geringerem Aufwand erzielen. Durch Optimierung lassen sich mit bestimmten Auf-wänden bessere Ergebnisse erzielen.

Sind Strategien, Organisationen, Systeme und / oder Führung, Verhal-ten, Macht konsistent gestaltet, lässt sich die Zielerreichung besser steuern, werden weniger Ressourcen verschwendet und lassen sich Strukturen einfacher, schneller bzw. mit geringeren Kosten ändern.

Grundlage für die systematische Veränderung von Strategien, Organisa-tionen, Systemen und / oder politisch-kultureller Faktoren ist Transpa-renz. Nur Strukturen und Prozesse, die transparent sind, können analy-siert, kommuniziert und systematisch verändert werden.

Die vier Formalziel-Dimensionen sind nicht unabhängig voneinander: Transparente Strukturen und Prozesse sind eine wichtige Grundlage für die systematische Herstellung bzw. Aufrechterhaltung von Konsistenz. Kon-sistente Strukturen und Prozesse sind eine wichtige Grundlage für syste-matische Vereinfachung bzw. Optimierung. Einfache bzw. optimierte Strukturen und Prozesse sind eine wichtige Grundlage für die systemati-sche Herstellung bzw. Aufrechterhaltung von Flexibilität bzw. Agilität.

Daneben gibt es verschiedene Unter-Formalziele, welche die Erreichung der Ober-Formalziele Transparenz, Konsistenz, Vereinfachung / Optimie-rung und Flexibilität / Agilität unterstützen. In diese Kategorie fallen z. B. Vernetzungsfähigkeit, Komponentisierung / Wiederverwendung, lose Kopplung oder Offenheit. Durch Ersetzen von 1:1-Kopplungen durch M:N-Kopplungen werden z. B. nicht nur Strukturen vereinfacht, sondern auch flexibilisiert. Durch lose Kopplung werden z. B. Strukturen nicht nur flexibilisiert, sondern auch vereinfacht.

Die Diskussion der (generischen) Ziele von Veränderungsvorhaben lie-fert auch Hinweise für deren (generische) Ergebnisse: Die Vision des Bu-siness Engineering sind generell offene, lose gekoppelte, aus wiederver-wendbaren Komponenten bestehende Strukturen und Prozesse. Die „Ge-schäftsarchitektur des Informationszeitalters“ (Kagermann u. Österle 2006)

36 Robert Winter

entspricht dieser Vision auf Strategieebene. Auf Systemebene entspricht eine konsequent serviceorientierte Anwendungssystemlandschaft dieser Vision.

4 Gegenstand der Veränderung

Neben den Aufgaben, Zielen und Ergebnissen der Veränderung sind die Gestaltungsobjekte der Veränderung zu betrachten. Da die Aufgaben-strukturierung von rein betriebswirtschaftlich orientierten Aufgaben (Stra-tegiebildung, Organisationsgestaltung) bis zu stark IT-bezogenen Aufga-ben (Software- und IT-Infrastrukturgestaltung) reicht, müssen die Gestal-tungsobjekte des Business Engineering „Business-to-IT“-Charakter haben, d. h. die ganze Bandbreite von rein fachlichen Gestaltungsobjekten bis zu IT-spezifischen Gestaltungsobjekten umfassen.

Entsprechend der Strukturierung der Aufgaben (Strategieebene, Organi-sationsebene, Systemebene, politisch-kulturelle Ebene, siehe Abschn. 2) werden Gestaltungsobjekte auf Strategie-, Organisations- und System-ebene unterschieden. Auf Systemebene wird zudem zwischen „Software“- und „Hardware“-Gestaltungsobjekten unterschieden. Auf dieser Grundlage lässt sich der Gegenstand des Business Engineering (also das betrachtete Geschäftsnetzwerk, die betrachtete Unternehmung oder die betrachtete Geschäftseinheit) in verschiedene Beschreibungsebenen zerlegen, die je-weils bestimmte Gestaltungsobjekte umfassen.

Gestaltungs- bzw. Veränderungsmethoden unterstützen die Festlegung der verschiedenen Gestaltungsobjekte und ihrer Zusammenhänge in einer bestimmten Reihenfolge, die dem jeweiligen Projekttyp und dem jeweili-gen Kontext entsprechen. Auf diese Szenarien wird in Abschn. 5 näher eingegangen.

Im Normalfall unterscheidet sich der Lebenszyklus der Gestaltungsob-jekte auf Strategie- und Organisationsebene vom Lebenszyklus der Gestal-tungsobjekte auf Software- und Infrastrukturebene: Während fachliche Strukturen und Abläufe aufgrund der Dynamik des Geschäfts relativ schnell und oft auch umfassend geändert werden müssen, haben die grund-sätzliche Architektur der Systemebene und bestimmte Software- und In-frastrukturkomponenten durchaus lange Lebensdauer. Typischen Zyklen von einigen Jahren und weniger (auf Strategie- und Organisationsebene) stehen Zyklen von mehreren Jahren oder gar einigen Jahrzehnten auf der Systemebene gegenüber. Das dadurch entstehende Problem unterschiedli-cher Frequenzen wird durch Abb. 2 illustriert.


1-2 Jahre

3-6Monate

6-10Jahre

Infrastruktur-ebene

Strategie-ebene

Organisations-ebene

Software-ebene

Abb. 2. Unterschiedliche Lebenszyklen auf Strategie-, Organisations- und Sys-temebene

Da es aufgrund der unterschiedlichen Lebenszyklen der Gestaltungsob-jekte auf den fachlichen Ebenen einerseits und der Systemebene anderer-seits nicht möglich ist, die Konsistenz des Gesamtsystems durch vollstän-dige Propagation aller Änderungen aufrecht zu erhalten, ist ein Entkopp-lungsmechanismus notwendig. In Analogie zur Dreiebenenarchitektur von Datenbanken wird dazu eine spezielle Architekturebene, die „Integrations-ebene“ vorgeschlagen. Ähnlich der konzeptionellen Ebene in der Daten-bankarchitektur, die die („interne“) Ebene der Datenspeicherung von der („externen“) Ebene der Datennutzung entkoppelt, entkoppelt die Integ-rationsebene die sich schnell ändernden fachlichen Ebenen von den deut-lich stabileren Systemebenen.

Als Konsequenz sind die Gestaltungsobjekte der Integrationsebene we-der allein fachlicher Natur noch allein IT-bezogen. Sie repräsentieren logi-sche Strukturen und Abhängigkeiten, die zur Entkopplung fachlicher und IT-Artefakte dienen. Beispiele für solche logischen Strukturen „zwischen“ Fachlichkeit und IT sind Domänen (Aier u. Schönherr 2007), andere Arten von Integrationsbereichen (Winter 2006) und fachliche Services (Woods u. Mattern 2006).

Die wichtigsten Modelle des Business Engineering auf den verschiede-nen Architekturebenen werden in Abb. 3 aufgezählt. Ein Modell repräsen-tiert dabei einen Zusammenhang zwischen verschiedenen Gestaltungsob-jekten. So werden z. B. Zusammenhänge zwischen Geschäftseinheiten,

38 Robert Winter

Strategie-ebene

Software-ebene

Organisations-ebene

Integrations-ebene

Gestaltung der Organisation• Prozesslandkarte• Prozessmodelle• Aufbauorganisation• Informationslandkarte

Gestaltung der Strategie• Geschäftsnetzwerkmodelle• Kundenprozessmodelle• Leistungsmodelle• Zielsystem

Gestaltung der Integration• Applikationslandschaft• Fachliche Services• Geschäftsfunktions-/

Informationsobjektemodelle

Infrastruktur-ebene

Gestaltung von Software• Softwarekomponenten / Software

Services• Datenmodelle

Gestaltung der IT-Infrastruktur• Plattforminfrastruktur• Netzwerkinfrastruktur

Abb. 3. Architekturebenen und Modelle des Business Engineering

Kunden und Lieferanten in Geschäftsnetzwerkmodellen, Zusammenhänge zwischen Prozessen und Leistungen in der Prozesslandkarte, Zusammen-hänge zwischen Organisationseinheiten, Rollen und Stellen im Aufbauor-ganisations-Modell oder Zusammenhänge zwischen Datenstrukturen im Datenmodell abgebildet. „Gestaltung“ in Abb. 3 umfasst nicht nur den Erstentwurf, sondern auch die Weiterentwicklung der entsprechenden Mo-delle.

5 Grundlegende Veränderungsprozess-Szenarien

Business Engineering versteht sich als methoden- und modellbasierte Konstruktionslehre (Österle u. Winter 2003b). Die durch Methoden und (Referenz-)Modelle zu unterstützenden Veränderungen sind dabei sehr vielfältig. Um eine ausreichend zielgerichtete und konkrete Unterstützung zu liefern, sollten deshalb verschiedene Veränderungsprozess-Szenarien unterschieden werden.

Auf Grundlage der Business Engineering-Architekturebenen können die folgenden generellen Veränderungsprozess-Typen unterschieden werden:


1. Fachlich getriebene Veränderungen durchlaufen die Gestaltungsebe-nen Strategie, Organisation usw. „top-down“. So setzt z. B. die (Neu-)Formulierung der Geschäftsstrategie die Rahmenbedingungen für die (Um-)Gestaltung der Organisation (sowohl in Bezug auf die Aufbau- wie die Ablauforganisation) und führt schließlich zu ent-sprechenden Anpassungen der Applikationen und möglicherweise sogar der Infrastruktur. Begleitet werden solche Veränderungsvorha-ben auf allen Ebenen durch geeignete Maßnahmen im Bereich „Füh-rung, Verhalten, Macht“.

2. Innovationen der Informations- und Kommunikationstechnik ermög-lichen neue fachliche Lösungen oder sogar eine vollkommen neue strategische Positionierung. So werden z. B. individualisierte Tarife im Versicherungsbereich erst durch Innovationen von Datenerhebung / -übertragung, Realtime-Informationslogistik und entsprechende Ab-rechnungsapplikationen möglich. Elektronische Marktplätze bzw. Einkaufs- / Verkaufsplattformen sind Beispiele für Geschäfts-innovationen auf Strategieebene. In diesen Fällen werden wie auch bei der Einführung innovativer Softwarelösungen oder innovativer IT-Infrastrukturen die Gestaltungsebenen „bottom-up“ durchlaufen.

3a. Die unterschiedlichen Lebenszyklen von fachlichen Lösungen und von IT-Lösungen führen zum sukzessiven Auseinanderklaffen der jeweils realisierten Strukturen (Winter 2004), so dass immer wieder „Alignment-Programme“ notwendig werden. Das heißt, dass die Inte-grationsebene so umgestaltet werden muss, dass veränderte Prozesse (oder Organisationsstrukturen) mit bestehenden (oder nur leicht an-gepassten) IT-Lösungen arbeiten können oder dass Veränderungen auf IT-Ebene (z. B. Ersatz von Standardsoftware) durch Umgestal-tung der Integrationsebene nur begrenzte Anpassungen der Organisa-tion erfordern.

3b. Eine Variante des Alignment-Szenarios ergibt sich aus der Notwen-digkeit, Strukturen auf allen Beschreibungsebenen nicht nur „verti-kal“, sondern auch „horizontal“ abzugleichen. Dies ist z. B. der Fall, wenn zwei Partner eines Wertschöpfungsnetzwerks ihre strategische Positionierung, ihre Prozesse / Organisation und ihre IT-Lösungen koordinieren müssen. Horizontale Abgleiche sind auch innerhalb von Unternehmungen (z. B. verschiedene Konzerngesellschaften, Fachbe-reiche und IT-Bereiche) sowie zwischen auslagernden Unternehmen und Dienstleistern (z. B. bei Outsourcing) notwendig.

4. Neben Transparenz und Alignment verfolgen Veränderungsprojekte auch häufig das Ziel, Betriebskosten durch Vereinfachung und / oder zukünftige Projektkosten durch Flexibilisierung zu senken (siehe Abschn. 3). In diesem Fall werden auf einer oder mehreren Gestal-

40 Robert Winter

tungsebenen durch Restrukturierung Potenziale geschaffen, die auf der jeweils darüber liegenden Ebene genutzt werden können. So wird es z. B. durch serviceorientierte (Re-)Strukturierung fachlicher Servi-ces (auf Integrationsebene) möglich, Prozesse (auf Organisations-ebene) leichter zu verändern.

Die vier Veränderungsprozess-Szenarien „fachlich getriebene Projekte“, „technisch getriebene Projekte“, „Alignment-Projekte“ (in zwei Varianten) und „Vereinfachungs- / Flexibilisierungsprojekte“ werden in Abb. 4 illust-riert.

Strategie-ebene

Software-ebene

Organisations-ebene

Integrations-ebene

Infrastruktur-ebene

FachlichgetriebeneProjekte (Top-down)

TechnischgetriebeneProjekte(Bottom-up)

Alignment-Projekte

Vereinfa-chungs-/Flexi-bilisierungs-Projekte(SOA)

Abb. 4. Veränderungsprozess-Szenarien

Je feiner die Differenzierung von Veränderungsprojekt-Szenarien er-folgt, desto gezielter können Methoden und (Referenz-)Modelle bei der Gestaltung unterstützen. So hat z. B. eine umfangreiche Fallanalyse in (Baumöl 2005) ergeben, dass bei fachlich getriebenen Veränderungen zwi-schen (1) klassischen Strategieprojekten, (2) Vernetzungsprojekten mit Kunden oder Netzwerkpartnern, (3) Wachstums- und Kulturprojekten mit Technologiehintergrund, (4) Prozess-Design / Prozess-Redesign und (5) Projekten zur Agilitätssteigerung unterschieden werden kann, da teilweise unterschiedliche Instrumente erfolgreich eingesetzt wurden.


6 Business Engineering für Betriebsprozesse

Veränderung ist traditionell eng mit dem Projektgedanken assoziiert: Selbst wenn es sich um komplexe Veränderungsprozesse handelt, so herrscht die Vorstellung einer gewissen Einmaligkeit, eines bestimmten (Projekt-)Anfangs und eines bestimmten (Projekt-)Abschlusses vor.

Informationslogistik ist eng mit IT-Innovationen verbunden und deren Einführung kann durchaus projektartig verstanden werden. Allerdings ist es zur nachhaltigen Etablierung von Innovationen wichtig, von einer pro-jektartigen Gestaltung / Steuerung der Initialprojekte auf eine prozessartige Gestaltung / Steuerung der Daueraufgaben umzustellen. Diese Umstellung hat nicht nur Konsequenzen für Gestaltung und Steuerung, sondern auch für Wirtschaftlichkeitsanalysen, Finanzierungs- und Verrechnungsmodelle, Aufbau- und Ablauforganisation sowie natürlich Führungsfragen.

Business Engineering-Methoden dürfen sich deshalb nicht nur auf die Unterstützung von Projekten zur Gestaltung von Veränderungen beschrän-ken, sondern sollten auch die Gestaltung des Dauerbetriebs unterstützen. Die Mehrzahl der bisher publizierten Business Engineering-Methoden fo-kussiert allerdings auf die Gestaltung von Veränderungen. Mit dem Ver-ständnis der Informationslogistik als langfristig angelegte, auf die Realisie-rung von Synergien zielende Infrastruktur und in Form der Betrachtung entsprechender Wirtschaftlichkeits-, Finanzierungs- / Verrechnungs- sowie Organisations- und Führungsfragen adressieren die Beiträge dieses Buches den Betriebsaspekt erstmals umfassend.

Literatur

Aier, S.; Schönherr, M.: Model Driven Service Domain Analysis, in: Georgako-poulos D. et al. (Hrsg.): Service-Oriented Computing ICSOC 2006, Workshop Proceedings, Springer, Berlin, Heidelberg 2007, S. 190-200.

Balzert, H.: Lehrbuch der Software-Technik - Software-Entwicklung, 2. Aufl., Spektrum Akademischer Verlag, Heidelberg 2000.

Baumöl, U.: Strategic Agility through Situational Method Construction, in: Reichwald R. et al. (Hrsg.): The European Academy of Management Annual Conference (EURAM2005), München 2005.

Beuck, K. A.: Widerstand von Mitarbeitern bei organisatorischen Veränderungen in Kreditinstituten, Dissertation, Universität Flensburg, Flensburg 2005.

Dubs, R.; Euler, D.; Rüegg-Stürm, J.; Wyss, C. E. H.: Einführung in die Manage-mentlehre, Haupt, Bern 2004.

Fleisch, E.: Das Netzwerkunternehmen, Springer, Berlin et al. 2000.

42 Robert Winter

Kagermann, H.; Österle, H.: Geschäftsmodelle 2010 - Wie CEOs Unternehmen transformieren, F.A.Z.-Institut für Management-, Markt- und Medieninforma-tionen, Frankfurt am Main 2006.

Martin, J.: Information Engineering. Vol. 1: Introduction, Prentice-Hall, Engle-wood Cliffs 1989.

Österle, H.; Winter, R.: Business Engineering, 2. Aufl., Springer, Berlin et al. 2003a.

Österle, H.; Winter, R.: Business Engineering, in: Österle H. et al. (Hrsg.): Busi-ness Engineering - Auf dem Weg zum Unternehmen des Informationszeital-ters, 2. Aufl., Springer, Berlin et al. 2003b, S. 3-19.

Rüegg-Stürm, J.: Das neue St. Galler Management-Modell, in: Dubs R. et al. (Hrsg.): Einführung in die Managementlehre, Haupt, Bern et al. 2002, S. 33-106.

Winter, R.: Architektur braucht Management, in: Wirtschaftsinformatik 46 (2004) 4, S. 317-319.

Winter, R.: Ein Modell zur Visualisierung der Anwendungslandschaft als Grund-lage der Informationssystem-Architekturplanung, in: Schelp J. et al. (Hrsg.): Integrationsmanagement, Springer, Berlin et al. 2006, S. 1-29.

Woods, D.; Mattern, T.: Enterprise SOA - Designing IT for Business Innovation, O'Reilly, Beijing et al. 2006.

3 Das St. Galler Konzept der Informationslogistik

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher


1 Einleitung ......................................................................................... 43 2 Das St. Galler Konzept der Informationslogistik ............................. 44 3 Spezifika und Herausforderungen der Informationslogistik ............. 51 4 Zusammenfassung und Ausblick ...................................................... 56

Literatur ............................................................................................ 56

1 Einleitung

Viele Untersuchungen belegen den unverändert hohen Stellenwert von Bu-siness Intelligence und Data Warehousing im Unternehmen (z. B. Sommer 2007). Mittlerweile sind analytische Informationssysteme zum unverzich-tbaren Bestandteil der Applikationslandschaft eines Unternehmens gewor-den und nehmen einen erheblichen Teil des IT-Budgets in Anspruch. Al-lerdings stellt sich heutzutage den Unternehmen nicht mehr primär das Problem des initialen Aufbaus analytischer Systeme; Vielmehr stehen Fra-gestellungen des Betriebs und der kontinuierlichen Weiterentwicklung analytischer Systeme angesichts sich ändernder Rahmenbedingungen und Anforderungen im Vordergrund. Dabei werden aber nach wie vor zwei entscheidende Aspekte vernachlässigt: Zum einen fehlt die Betonung einer umfassenden Gesamtsicht auf alle Initiativen und Projekte in diesem Um-feld anstelle einer fokussierten Partikular- oder Projektsicht, zum anderen werden solche Vorhaben oft nicht mit dem dafür eigentlich notwendigen, langen Planungs- und Investitionshorizont betrachtet.

Durch IT-Enabler wie Data Warehousing und Business Intelligence wird es möglich, nachhaltig Mehrwert durch systematische, bereichsüber-

44 Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

greifende Zusammenführung und Nutzung von Informationen zu schaffen. Um diesem Aspekt Rechnung zu tragen und um die fachliche Schwer-punktsetzung zu verdeutlichen (Business Intelligence und Data Warehou-sing sind historisch IT-Konzepte), wird im Folgenden der Begriff der In-formationslogistik eingeführt. Er wird in Abschn. 2 definiert und gegenü-ber verwandten Begriffen abgegrenzt. In Abschn. 3 werden die Charakte-ristika des Informationslogistik-Konzepts erläutert.

2 Das St. Galler Konzept der Informationslogistik

Um dem skizzierten Charakter einer bereichsübergreifenden, an fachlichen Zielen orientierten Informationsversorgung zu entsprechen, definieren wir Informationslogistik wie folgt:

Als Informationslogistik (IL) wird die Planung, Steuerung, Durch-führung und Kontrolle der Gesamtheit der Datenflüsse verstanden, die über eine Betrachtungseinheit hinausgehen, sowie die Speiche-rung und Aufbereitung dieser Daten.

Dabei werden nur solche Datenflüsse zur Informationslogistik ge-zählt, die der Unterstützung von Entscheidungen dienen.

2.1 Betrachtungseinheiten der Informationslogistik

Als Betrachtungseinheiten kommen Organisationseinheiten beliebiger Größe in Frage. Die kleinste Betrachtungseinheit ist die Stelle als feinste Granularität der Aufbauorganisation, d. h. die kleinste selbständig han-delnde Einheit der Gesamtorganisation, die bestimmte Teilaufgaben erfüllt (Bleicher 1991, S. 45; Hill et al. 1994, S. 130). Die Wahl der Stelle als kleinste Betrachtungseinheit macht die Definition der Informationslogistik unabhängig von der Größe der Unternehmung. Theoretisch kann also In-formationslogistik im Ein-Personen-Unternehmen genauso stattfinden wie im multinationalen Großkonzern.

Eine typische Betrachtungseinheit ist der Geschäftsbereich, d. h. ein Teil eines Unternehmens oder Konzerns. Informationslogistik ist in diesem Fall die Planung, Durchführung, Steuerung und Kontrolle der Gesamtheit der Datenflüsse zwischen Geschäftsbereichen sowie die Speicherung und Auf-bereitung dieser bereichsübergreifenden Daten, soweit sie zur Unterstüt-zung von Entscheidungen dienen und nicht etwa für die automatisierte Abwicklung der operativen Geschäftsprozesse benutzt werden. Die größte

Das St. Galler Konzept der Informationslogistik 45

Betrachtungseinheit ist das Gesamtunternehmen. Die Informationslogistik befasst sich auch mit unternehmensübergreifenden Datenflüssen, wie sie etwa bei unternehmensübergreifenden Kooperationen oder beim Outsour-cing von Geschäftsprozessen oder Teilprozessen erforderlich werden (Pi-cot et al. 2003, S. 287ff.; Kagermann u. Österle 2006, S. 167ff.).

2.2 Übergreifende Datenflüsse und analytische Nutzung

Durch Informationslogistik werden Daten, die in einer Betrachtungseinheit anfallen, für die analytische Nutzung in einer anderen Betrachtungseinheit verfügbar gemacht. Datenflüsse, die nur innerhalb der selben Betrach-tungseinheit ihre Quelle und ihren Endpunkt haben, sind daher auf dieser Betrachtungsebene nicht Teil der Informationslogistik. Bei Wahl einer an-deren Betrachtungsebene können solche Datenflüsse aber durchaus Teil der Informationslogistik sein: So sind bei Betrachtung von Unternehmens-bereichen die Datenflüsse innerhalb eines Unternehmensbereichs nicht Teil der Informationslogistik – bei Betrachtung der Abteilungen innerhalb dieses Unternehmensbereiches sind abteilungsübergreifende, jedoch be-reichsinterne Datenflüsse jedoch durchaus Teil der Informationslogistik. Ob Datenflüsse zur Informationslogistik zählen, hängt damit auch von der Wahl des Betrachtungseinheit ab. Abbildung 1 illustriert den Betrach-tungseinheit-Bezug des Informationslogistik-Begriffs: Für die schwarz dargestellten Einheiten bilden die schwarz dargestellten Datenflüsse den IL-Gegenstand, für die dunkelgrau dargestellten Einheiten die dunkelgrau dargestellten Datenflüsse, für die hellgrau eingefärbten Einheiten die hell-grau eingefärbten Datenflüsse usw.

Analytische Nutzung heißt, dass Informationen zur Unterstützung von Entscheidungen genutzt werden. Eine Entscheidung ist dabei die (im Kon-text der Informationslogistik immer bewusste) Auswahl einer von zwei oder mehreren Handlungsalternativen (Wöhe 1993, S. 156). Grundlage für Entscheidungen sind Informationen (Picot et al. 2001, S. 69). Diese wiede-rum ergeben sich aus Daten, wenn sie von „einer Person in einem be-stimmten Kontext empfangen und interpretiert werden“ (Jung 2006, S. 44). Die Datenflüsse an sich sind daher keine Informationsflüsse, da die Daten per se verwendungsneutral sind und der Kontext erst bei einer tat-sächlichen Nutzung feststeht (Klesse 2007, S. 20).

Die Informationslogistik hat dabei das Ziel, Informationen zur Unter-stützung sämtlicher Arten von Entscheidungen im Unternehmen zur Ver-fügung zu stellen. Einerseits werden Entscheidungen auf den verschiede-nen Hierarchieebenen des Unternehmens (strategische Entscheidungs-findung, Managementkontrolle und operative Kontrolle), andererseits auch


Informationslogistik-relevante Datenflüsse

Unternehmen A Unternehmen B

Unternehmensbereich A Unternehmens-bereich B

Abteilung A Abteilung B

Stelle A

Stelle B

Abb. 1. Informationslogistik auf verschiedenen Ebenen der Organisation

Entscheidungen von unterschiedlichem Strukturiertheitsgrad (unstruktu-riert, semistrukturiert und strukturiert) unterstützt (Gorry u. Scott Morton 1971, S. 62; Laudon et al. 2006, S. 141).

Die Informationslogistik ist nicht auf die Unterstützung bestimmter Pro-zesstypen beschränkt. Vielmehr kann die Informationslogistik dispositive und operative Prozesse beliefern. Eine dispositive Nutzung der Infor-mationslogistik ist beispielsweise die Versorgung von Planungsprozessen mit aggregierten Daten - eines der klassischen Einsatzfelder von Business Intelligence-Werkzeugen. Ebenso denkbar ist aber eine Versorgung von operativen Prozessen, wie etwa eine zeitnahe Lieferung von Absatzinfor-mationen zur Unterstützung der Preisfindung in Absatzprozessen.

Informationslogistik befasst sich also mit allen Arten der Informations-bereitstellung mit Entscheidungsbezug. Rein operativen Zwecken dienende Datenflüsse zur Prozessabwicklung ohne Entscheidungskonsequenz, wie z. B. der Fluss von Bestelldaten aus der Auftragserfassung an die Kommis-sionierung, gehören nicht zur Informationslogistik, auch wenn sie Organi-sationseinheiten übergreifen. Ebenso wenig zählen die Systeme zur Reali-sierung solcher Datenflüsse, wie z. B. Integrationsinfrastruktur mit rein operativem Zweck, zur Informationslogistik.


2.3 Aufgaben und Ziel der Informationslogistik

Die Hauptfunktionen der Informationslogistik ergeben sich aus der Defi-nition des Logistikbegriffs. Analog zur Definition der Logistik als Pla-nung, Steuerung, Durchführung und Kontrolle von Material- und Daten-flüssen innerhalb und außerhalb der Unternehmung (Heiserich 2002, S. 8; Bichler u. Schröter 2004, S. 17; Schulte 2005, S. 1) ist die Aufgabe der In-formationslogistik die Planung, Steuerung, Durchführung und Kontrolle von Datenflüssen. Hierzu werden Ziele und Leistungen sowie Organisati-onsstrukturen und Prozesse definiert (Vgl. Kap. 2). Für die Implementie-rung der Datenflüsse sind die Speicherung und Aufbereitung von Daten er-forderlich. Diese werden mit Hilfe von entsprechenden Informationssys-temen (z. B. Data Warehouses) realisiert.

Ziel der Informationslogistik ist damit, dass relevante Informationen in geeigneter Qualität zur Befriedigung der Informationsbedarfe in einer Be-trachtungseinheit bereitgestellt werden, auch wenn die dafür benötigten Daten in einer anderen Betrachtungseinheit entstehen. Damit trägt die In-formationslogistik wesentlich zur Realisierung von Synergien bei.

2.4 Abgrenzung

2.4.1 Data Warehousing

Ausgehend von William Inmons ursprünglicher Definition des Data Ware-house (DWH) als „a subject-oriented, integrated, non-volatile, and time-variant collection of data in support of management’s decisions“ (Inmon 2002, S. 31) hat sich das Begriffsverständnis von Data Warehousing in den letzten Jahren erweitert und damit unserem Verständnis von Informati-onslogistik angenähert. Unter Data Warehousing wird die Gesamtheit von Prozessen und Systemen zum Betrieb und Nutzung eines DWH-Informati-onssystems verstanden (Jung u. Winter 2000, S. 5; Klesse 2007, S. 27). Das Data Warehouse (genauer das Data Warehouse-Informationssystem) dient als zentrale, unternehmensweite, von den operativen Datenbeständen entkoppelte Plattform zur Datenintegration aus operativen Systemen für die Nutzung in analytischen Applikationen (von Maur et al. 2003, S. 9; Kemper et al. 2006, S. 17). Zunehmend wird die Nutzung des Data Ware-house erweitert von einer reinen Managementunterstützung (wie bei In-mon) hin zu operativen Nutzungsformen, etwa im Marketing (Kemper et al. 2006, S. 21ff.; Klesse 2007, S. 26). Selten jedoch werden über die auch in jüngerer Literatur vorherrschende Fokussierung auf das DWH-Informa-tionssystem, (wie z. B. bei Chamoni u. Gluchowski 2006; Kemper et al. 2006) hinaus weitere relevante Dimensionen des Data Warehousing, wie


z. B. Organisation oder Strategie, betrachtet, wie dies im Sinne des Busi-ness Engineering erforderlich wäre (vgl. Kap. 2).

Weiterhin steht beim Data Warehousing meist die integrierte Speiche-rung in einer zentralen Datenbank im Vordergrund, wie sie sich in zahlrei-chen Referenzarchitekturen widerspiegelt (Inmon 2002, S. 36; Bauer u. Günzel 2004, S. 34ff.; Kemper et al. 2006, S. 31; Mucksch 2006, S. 131), während die Informationslogistik darüber hinaus auf die Planung, Steue-rung und Kontrolle von Datenflüssen abzielt.

Damit lassen sich drei zentrale Unterschiede zwischen Data Warehou-sing und Informationslogistik erkennen:

Einerseits hat die Informationslogistik im Gegensatz zum Data Ware-housing einen umfassenderen Fokus, der nicht nur das Informati-onssystem in den Vordergrund stellt, sondern die Gesamtheit von Stra-tegie, Organisation und Informationssystem betrachtet.

Zweitens fokussiert das Data Warehousing auf die Schaffung einer inte-grierten Datenbasis, während die Informationslogistik auf die Realisie-rung von Informationsflüssen zur Befriedigung von Informationsbedar-fen abzielt.

Zum dritten ist der Fokus des Data Warehousing in der Regel unterneh-mensintern, während die Informationslogistik auch unternehmensüber-greifende Datenflüsse betrachtet.

2.4.2 Business Intelligence

Der Begriff Business Intelligence (BI) ist deutlich weniger klar definiert als der des Data Warehousing, was eine Abgrenzung erschwert. In seiner ursprünglichen Bedeutung wurde der Begriff 1996 von der Gartner Group geprägt: „Data analysis, reporting, and query tools can help business users wade through a sea of data to synthesize valuable information from it - to-day these tools collectively fall into a category called ‘Business Intelli-gence.‘“(Anandarajan et al. 2003, S. 18f.). Damit wurde BI ursprünglich als Sammelbegriff für die verschiedenen analytischen Applikationen, die auf das Data Warehouse zugreifen, und die zugehörigen Technologien zur Datenauswertung gebraucht (Jung u. Winter 2000, S. 11; Strauch u. Winter 2002, S. 493; Laudon u. Laudon 2006, S. 240). Daneben existieren eine Vielzahl von weiteren Auffassungen des Begriffs (Mertens 2002, S. 67; Kemper et al. 2006, S. 3f.). Einerseits finden sich systemzentrierte, erwei-terte Auffassungen, die unter BI die Gesamtheit der analytischen Systeme und der speisenden Datenbanken bzw. Data Warehouses verstehen (Glu-chowski 2001, S. 6; Negash 2004, S. 178). Andererseits finden sich auch ganzheitliche Ansätze, die BI als Gesamtheit von Systemen und Prozessen


zur Analyse des Unternehmens und seiner Umwelt definieren (Grothe u. Gentsch 2000, S. 11; Strauch u. Winter 2002, S. 442; Gartner Group 2004, S. 48; Bucher u. Dinter 2008).

Das engere Verständnis von Business Intelligence als Gesamtheit der analytischen Informationssysteme (Kemper et al. 2006, S. 4) lässt sich so-mit leicht von der Informationslogistik abgrenzen – die Informationslogis-tik hat einen wesentlich umfassenderen und ganzheitlicheren Fokus. Je weiter das Verständnis von BI jedoch gefasst wird, desto mehr ver-schwimmt die Grenze zur Informationslogistik. Hauptsächliches Abgren-zungskriterium der Informationslogistik ist wieder der Schwerpunkt auf Datenflüssen. Zudem umfasst keine der Definitionen von BI auch unter-nehmensübergreifende Datenflüsse – BI ist nicht unternehmensübergrei-fend, wenngleich auch unternehmensexterne Datenquellen genutzt werden können.

2.4.3 Management Support Systems

Der Begriff Management Support Systems (deutsch Führungsunterstüt-zungssysteme bzw. Führungsinformationssysteme) ist ein Sammelbegriff für verschiedenen Arten von analytischen Systemen (Holten 1999, S. 29). Unter den Begriffen Management Information Systems (MIS), Decision Support Systems (DSS) und Executive Information Systems (EIS) werden verschiedene Systemklassen zur Entscheidungsunterstützung verstanden, deren Entwicklung bis in die 1970er Jahre zurückreicht. Im Lichte moder-ner Informationslogistik- bzw. BI-Konzepte (Gluchowski u. Kemper 2006, S. 12) beschreiben diese Begriffe Spezialkonzepte, die sich kaum noch in dedizierter Form finden.

Unter MIS werden Systeme zur Versorgung des mittleren Managements mit Berichten zur Unterstützung alltäglicher, strukturierter Entscheidungen verstanden, die auf Unternehmensdaten aus den operativen Systemen ba-sieren, welche teilweise historisiert sein können und die in der Regel engen Subjektbezug aufweisen (Davis u. Olson 1985, S. 6; O'Brien 1996, S. 370f.; Laudon et al. 2006, S. 86f.). Daneben wird der Begriff MIS auch teils synonym für die Gesamtheit der Management Support Systems ver-wendet. DSS sind Systeme, die basierend auf Datenanalysemodellen und Datenbanken das mittlere Management interaktiv beim Treffen von se-mistrukturierten, nicht standardisierten Entscheidungen unterstützen sollen (Davis u. Olson 1985, S. 11f.; O'Brien 1996, S. 373ff.; Holten 1999, S. 36f.; Laudon et al. 2006, S. 88). Hierzu werden teils auch OLAP- und Data Mining Tools gezählt (Laudon u. Laudon 2006, S. 481). Verwandt sind die Expertensysteme, die basierend auf einer Wissensbasis mit Methoden der Künstlichen Intelligenz Entscheidungen in eng abgegrenzten Bereichen au-


tomatisiert treffen können (Holten 1999, S. 38; Laudon u. Laudon 2006, S. 452). EIS schließlich sind Systeme zur Unterstützung unstrukturierter, strategischer Entscheidungen, die in erster Linie für das Top-Management gedacht sind. Funktionen von EIS sind u. a. Aggregation und Integration von Daten aus bestehenden MIS, DSS und externen Quellen, Recherche in verschiedenen Datenquellen, Visualisierungs- und Kommunikationsfunk-tionen (O'Brien 1996, S. 382ff.; Holten 1999, S. 32ff.; Gluchowski u. Kemper 2006, S. 12; Laudon et al. 2006, S. 89).

Management Support Systems bilden damit eine Untermenge der Infor-mationslogistik. Sie umfassen verschiedene Klassen analytischer Informa-tionssysteme, die Teil der Informationslogistik sind. In der Literatur zu MSS zeigt sich deutlich der historische Kontext – einerseits ist die Inte-gration von Daten aus verschiedenen Quellen, wie sie im DWH angestrebt wird, kaum Ziel von MSS, andererseits haben MSS einen begrenzten Fo-kus auf die Leitungsebenen im Unternehmen. Zudem konzentriert sich die Literatur weitestgehend auf die IT-Systeme, ohne dass Organisation und Strategie ausreichend einbezogen werden.

2.5 Synergiepotenziale der Informationslogistik

Von Synergien wird dann gesprochen, wenn einerseits die Gruppenleis-tung besser ist als die des besten Gruppenmitglieds und andererseits besser als jede Kombination der allein erbrachten Leistungen (Stumpf 1999, S. 193). Im Kontext des Unternehmens entstehen Synergien dann, wenn die Leistungen einer Organisationseinheit als Vorleistung für eine andere Organisationseinheit genutzt werden kann oder wenn diese Organisations-einheiten Märkte und Kompetenzen bündeln und wenn diese Beziehungen zwischen Organisationseinheiten Kosten senken oder den Gewinn steigern (Laudon u. Laudon 2006, S. 109). Insbesondere zur Bündelung von Märk-ten und Kompetenzen ist der Transfer von Informationen zwischen den Organisationseinheiten unerlässlich – dies ist der „Business Case“ (d. h. die wirtschaftliche Begründung) für Informationslogistik.

Die Spezialisierung und Arbeitsteilung im Unternehmen und die Schaf-fung von funktionsspezifischen Informationssystemen in der Frühzeit der elektronischen Datenverarbeitung führten dazu, dass Informationen im Un-ternehmen vielfach verteilt und fragmentiert gespeichert werden (Holten 1999, S. 29ff.). Das Ziel der Informationslogistik, die effektive und effi-ziente Befriedigung von Informationsbedarfen, ist daher oftmals nicht be-trachtungseinheitsintern möglich, sondern nur unter Nutzung extern bezo-gener Informationen (Klesse u. von Maur 2003, S. 32f.). Die Quelle der In-


formationen kann dabei innerhalb oder außerhalb der Unternehmung gen.

Wird die Existenz von Synergien unterstellt, ist zwar die Gesamtwert-schöpfung höher als die Summe der Wertschöpfungen der einzelnen Be-trachtungseinheiten. Dies heißt aber nicht, dass es aus Sicht jeder einzel-nen Betrachtungseinheit „lokal“ sinnvoll ist, „ihre“ Daten in die Informati-onslogistik einzubringen. Synergievorteile und Beteiligungskosten sind unter den Betrachtungseinheiten möglicherweise ungleichmäßig verteilt. So kann es z. B. vorkommen, dass bestimmte Einheiten mit hohem Auf-wand hohe (Stamm-)Datenqualität erzeugen, von denen andere Einheiten ohne eigenen Aufwand profitieren. Ein ganzheitliches Konzept zur Ge-staltung der Informationslogistik muss diese Effekte berücksichtigen und geeignete Steuerungs- und Incentivierungsmechanismen vorsehen.

3 Spezifika und Herausforderungen der Informationslogistik

Drei Eigenschaften sind charakteristisch für die Informationslogistik: Zum einen hat sie Infrastrukturcharakter, zum zweiten strategischen Charakter und zum dritten Prozesscharakter. Diese drei Eigenschaften werden im fol-genden Abschnitt erläutert. In Abschn. 3.2 werden daraus resultierende Herausforderungen und Lösungsansätze vorgestellt.

3.1 Charakteristika der Informationslogistik

3.1.1 Infrastrukturcharakter

Der Betrieb der Informationslogistik erfordert neben den Prozessen, die die Bereitstellung und Nutzung der Daten betreffen, eine Vielzahl weiterer Prozesse. Da Informationslogistik als auf Synergien abzielendes und Or-ganisationseinheiten übergreifendes Konzept auch nahe legt, solche un-terstützenden Prozesse nicht isoliert und singulär zu betrachten, bietet sich an, diese Prozesse im Rahmen einer Infrastruktur einzubetten. Die zugehö-rigen Infrastrukturthemen sind Querschnittsthemen, die analog zum über-greifenden Charakter der Informationslogistik die verschiedensten Be-reiche des Data Warehousing und verwandter Systeme betreffen und in der Regel nicht auf einzelne Domänen oder Projekte beschränkt sind. Die In-frastruktur ist unerlässlich für eine erfolgreiche Informationslogistik, in vielen Fällen ermöglicht sie erst eine sinnvolle Nutzung der in den analyti-schen Systemen gespeicherten Daten.


Infrastruktur stellt die notwendigen organisatorischen und technischen Voraussetzungen für Informationssysteme bereit. Sie ist nutzungsoffen, wiederverwendbar und wird in Form standardisierter, zuverlässiger Diens-te bereitgestellt, die aufeinander aufbauen und von mehreren Infrast-rukturanwendungen genutzt werden können (Klesse 2007). Der Nutzen von Infrastruktur ist häufig schwer quantifizierbar, so dass entsprechende Investitionen oft strategische Managemententscheidungen erfordern, da die Nutzenpotenziale zwar nicht rechenbar, so doch entscheidbar sind (vgl. Kap. 8, Nagel 1990; Klesse 2007).

Gemäß dieser Definition geht Infrastruktur über den reinen Systembe-trieb hinaus und umfasst vielmehr all diejenigen Grundeinrichtungen, die für die Realisierung und den Betrieb der fachlichen Anwendungen in der Informationslogistik erforderlich sind. Dabei ist zu beachten, dass Infra-struktur nicht nur aus Hardware und Software besteht, sondern zusätzlich aus Prozessen und Prozesswissen, die für Planung, Steuerung, Kontrolle, Unterhalt und Pflege der Infrastruktur erforderlich sind. Ebenso werden für die Infrastruktur Standards und Prinzipien benötigt, die einen effizienten Betrieb mit reibungslosem Zusammenspiel der Komponenten ermöglichen. Über klar definierte Schnittstellen muss dabei nicht nur das Zusammen-spiel der Infrastrukturkomponenten, sondern auch der Zugriff der fachli-chen Applikationen auf die Infrastruktur geregelt werden.

Die folgenden Ausführungen beziehen sich auf die Strategie- und Orga-nisationsaspekte von Infrastruktur, nicht auf Infrastruktur im Sinne von Hardware und Software.

In der Informationslogistik können folgende Themenbereiche identifi-ziert werden, die einen Infrastrukturcharakter gemäß obiger Definition aufweisen:

Architekturmanagement Metadatenmanagement (Daten-)Qualitätsmanagement Stammdatenmanagement Management von Datenschutz und Datensicherheit Aufbau- und Ablauforganisation (inkl. Servicemanagement und Leis-

tungsverrechnung) Projekt- und Anforderungsmanagement

Alle genannten Themenbereiche sind nicht nur für die Informationslo-gistik relevant, sondern müssen auch im unternehmensweiten Informati-onsmanagement, und damit insbesondere auch in den operativen Syste-men, adressiert werden. Folglich gilt es im Kontext der Informationslogis-tik zu entscheiden, ob unternehmensweite Standards und Lösungen aufge-


baut bzw. etwaige in den operativen Systemen bereits angewandte Kon-zepte genutzt werden sollen. Eine isolierte Betrachtungsweise und der se-parate Aufbau einer eigenen Infrastruktur für die Informationslogistik empfiehlt sich nur in Ausnahmefällen, weil die Informationslogistik sich zum einen in der unternehmensweiten IT-Landschaft einfügen muss und zum anderen direkt oder indirekt auf bereits vorhandene Infrastrukturen (etwa beim Bezug möglichst qualitativer Daten aus den operativen Syste-men oder bei Nutzung von Stamm- und Metadaten) zurückgreift. Zudem gilt es, mögliche Skaleneffekte der Infrastrukturnutzung zu realisieren.

Mit Ausnahmen der Themenbereiche „Management von Datenschutz und Datensicherheit“ werden alle genannten Infrastrukturthemen im vor-liegenden Buch in eigenen Kapiteln adressiert.

3.1.2 Strategischer Charakter

Als „strategisch“ werden solche Entscheidungen bezeichnet, die ge-samthafte Zusammenhänge betreffen und langfristigen Charakter haben (Anthony 1965). Entsprechend ihrer Definition ist Informationslogistik be-trachtungseinheit-übergreifend, und die Nutzeffekte von Informationslo-gistik treten typischerweise eher langfristig ein. Deshalb hat Informati-onslogistik grundsätzlich strategischen Charakter und muss entsprechend geplant, bewirtschaftet und gesteuert werden. Konkret heißt das, dass für die Informationslogistik nur solche Einheiten zuständig sein sollten, die übergreifende Verantwortung haben. Außerdem müssen Wirtschaftlich-keitsentscheidungen in Betracht ziehen, dass Informationslogistik-Investi-tionen im Normalfall nicht innerhalb der üblichen Fristen (zwei bis drei Jahre) rentabel sind.

3.1.3 Prozesscharakter

Die in Abschn. 2 eingeführte Definition von Informationslogistik be-schränkt sich bewusst nicht auf die ehemals datenzentrierte Sichtweise im Data Warehousing. Vielmehr adressiert dieses Verständnis auch Anwen-dungen, bei denen Techniken und Verfahren der Datenanalyse und der In-formationsbereitstellung in den Kontext der Prozessausführung eingebettet werden. Zunehmend wird die Nutzung analytischer Daten in operative Prozesse integriert, um auch operative Entscheidungen von der durch die Informationslogistik bereitgestellten Datenbasis profitieren zu lassen. Ziel ist die Erhöhung der Effektivität und Effizienz der wertschöpfenden Pro-zesse. Das Konzept der sogenannten prozessorientierten Business Intelli-gence wird in Kap. 6 näher vorgestellt.


3.2 Herausforderungen und Lösungsansätze

Die Besonderheiten der Informationslogistik führen zu speziellen Heraus-forderungen bei der Umsetzung im Unternehmen. Dabei ist eine Diskre-panz zu beobachten: Auf der einen Seite genießen die Themen hohe Auf-merksamkeit und werden als sehr relevant eingestuft. Auf der anderen Seite ist die Praxis geprägt von isolierten, lokalen Lösungen und kurzfris-tig angelegten Initiativen. Folglich hat die Umsetzung von Infrastruktur-maßnahmen wie die meisten bereichs- oder themenübergreifenden Initiati-ven einige Herausforderungen zu meistern.

3.2.1 Risikofaktoren

Zu den Risikofaktoren gehören die Projektgröße und die Komplexität sol-cher Vorhaben. Je weiter das mögliche Einsatzgebiet von Infrastruktur-themen definiert wird, desto mehr Abhängigkeiten und (teils unvereinbare) Anforderungen müssen berücksichtigt werden und desto höher wird auch der Abstimmungsaufwand mit den beteiligten Organisationseinheiten. Die-se Hürden bilden einen Tradeoff zum Bestreben, zur Schaffung von Syn-ergien eine möglichst breite Positionierung von Infrastrukturthemen im Unternehmen zu erreichen. Lösungsansätze für dieses Problem können den Best Practices für Data Warehouse-Projekte entnommen werden - wie et-wa die Zerlegung des Vorhabens in Teilprojekte und Module, die se-quentiell umgesetzt werden können. Dabei sollte insbesondere auf mögli-che Quick Wins fokussiert werden, um den Nutzern in der initialen Phase den Wertbeitrag der Infrastrukturmaßnahme zu demonstrieren. In diesem Zusammenhang ist auch darauf zu achten, dass überzogenen Erwartungen der Anwender rechtzeitig gegengesteuert wird, die durch mangelnden Ein-blick und Verständnis für die Komplexität hervorgerufen werden oder an-gesichts von Budget- oder Ressourcenrestriktionen nicht realisierbar sind. Trotz anzustrebender Komplexitätsreduzierung sollte nicht außer Acht ge-lassen werden, dass die einzelnen Infrastrukturthemen nicht völlig unab-hängig voneinander anzusehen sind. So weisen zum Beispiel Metadaten-, Stammdaten- und Datenqualitätsmanagement zahlreiche Berührungs-punkte und Schnittstellen auf, weshalb die jeweiligen Aktivitäten aufei-nander abgestimmt werden sollten.

3.2.2 Gemeinschaftliche Nutzung

Infrastruktur wird von mehreren Anwendungen gemeinsam genutzt. Dies ermöglicht einerseits Skaleneffekte bei den Nutzungskosten, andererseits erschwert es aber auch die Zurechnung der Infrastrukturkosten zu den ein-


zelnen Nutzergruppen. Auch ist der Nutzen der Infrastruktur nicht einfach zu quantifizieren – es ist offensichtlich, dass die Infrastruktur für die An-wendungen in der Informationslogistik Nutzen bringt, nicht jedoch, in-wieweit sie zum geschaffenen Wert beiträgt. Oft fehlt das Bewusstsein im Unternehmen, dass die oben genannten Infrastrukturthemen wie andere In-frastrukturmaßnahmen im Unternehmen auch (etwa bei Investitionen in Hardware) behandelt werden sollten, wo trotz fehlenden oder unvollstän-digen Nachweises der Wirtschaftlichkeit entsprechende Investitionen ge-tätigt werden. Dennoch sollten nach Möglichkeit den Nutzen unter-mauernde (wenn auch nicht notwendigerweise quantifizierbare) Anwen-dungsfälle herangezogen werden. An dieser Stelle sei auch auf Abschn. 3 verwiesen, in dem anhand ökonomischer Theorien die Sinnhaftigkeit von Massnahmen mit synergetischen Zielsetzungen hergeleitet und nachgewie-sen wird. Eng mit dieser Problematik verbunden ist die Herausforderung, Infrastrukturprojekte mit Unterstützung des (oberen) Managements durch-zuführen. Angesichts der vergleichsweise hohen Aufwände in der Umset-zung und dem Anspruch der Langfristigkeit braucht es Sponsoring von entsprechenden Stellen. Diese Unterstützung kann rein monetär sein, aber durchaus auch im Sinne eines „Fürsprechers“ oder Paten.

3.2.3 Gesamtsicht vs. Partikularsicht

Vielfach wurden und werden in den Unternehmen Teilprojekte zur Infra-struktur durchgeführt, die jedoch als halbfertige oder insuläre Lösungen nicht ihr volles Nutzenpotenzial realisieren können. Ein großer Risikofak-tor für Infrastrukturprojekte liegt daher in der Partikularsicht der beteilig-ten Organisationseinheiten. Diese sind bestrebt, in erster Linie lokale Op-tima zu erreichen, d. h. ihre eigenen Ziele mit minimalem Aufwand umzu-setzen. Dies führt beispielsweise zu Präferenzen für bestimmte Werkzeuge oder Anbieter sowie zur Nichtbeachtung existierender Infrastrukturlösun-gen in benachbarten Bereichen. Solchen Entwicklungen muss mit über-greifendem Ressourcenmanagement und mit klarer Kommunikation der Vorteile von übergreifender Informationslogistik-Infrastruktur entgegen-gewirkt werden.

3.2.4 Architektur-Alignment

Bereits erwähnt wurde, dass die Informationslogistik und zugehörige In-frastrukturmaßnahmen in die unternehmensweite IT-Architektur eingebet-tet werden müssen. Eine Harmonisierung von Organisationsstrukturen zielt dabei auf die nahtlose Einbettung der Informationslogistik und ihrer In-frastruktur in die IT-Organisation. Sinnvollerweise werden bei der Gestal-


tung der Informationslogistik dieselben Maßstäbe angelegt wie in der ope-rativen IT-Architektur. Stakeholder, Ownerships, Verantwortlichkeiten und Prozesse müssen in derselben Art und Weise definiert werden, wie dies für die Gesamt-IT üblich sein sollte (vgl. Kap. 5). Ein weiteres Ziel ist ein integriertes Architekturmanagement, das aus zentraler Perspektive Architektur-Governance umsetzt. Hier wird nicht nur der Bereich der In-formationslogistik, sondern auch die Gesamtarchitektur des Unternehmens in die Betrachtungen einbezogen. Die Architektur-Einheit überwacht die Entwicklung von Plattformen und neuen Applikationen. Hierbei stellt sie sicher, dass die übergreifende Sicht bei der Ausgestaltung gegenüber den Partikularsichten der einzelnen Abteilungen nicht ins Hintertreffen gerät – sie ist quasi der Anwalt der Gesamtsicht. Die Perspektive der Gesamt-architektur umfasst nicht nur einzelne Projektschwerpunkte, sondern komplette Wertschöpfungsketten mit ihren Prozessen. Diese Betrachtung ermöglicht es, Redundanzen zu vermeiden und Synergiepotenziale zu er-kennen.

4 Zusammenfassung und Ausblick

Die Informationslogistik ermöglicht als übergreifende Enablerfunktion die Versorgung des Unternehmens mit Daten zur Entscheidungsunterstützung. In den komplexen Zusammenhängen heutiger Großunternehmen ist dabei nicht eine techologiegetriebene Betrachtung nicht zielführend, vielmehr ist muss der Fokus auf strategische und organisatorische Aspekte erweitert werden.

In den folgenden Kapiteln werden die Aspekte Strategie, Organisation und Systemarchitekturen der Informationslogistik detailliert erörtert und mit einer zusammenfassenden Fallstudie aus der Praxis illustriert.

Literatur

Anandarajan, M.; Anandarajan, A.; Srinivasan, C.: Business Intelligence Techni-ques - A Perspective from Accounting and Finance, Springer, Berlin et al. 2003.

Anthony, R.: Planning and Control Systems: A Framework for Analysis, Harvard University Press, Boston 1965.

Bauer, A.; Günzel, H.: Data Warehouse Systeme - Architektur, Entwicklung, An-wendung, 2. Aufl., dpunkt, Heidelberg 2004.

Bichler, K.; Schröter, N.: Praxisorientierte Logistik, 3. Aufl., Kohlhammer, Stutt-gart 2004.


Bleicher, K.: Organisation: Strategien, Strukturen, Kulturen, 2. Aufl., Gabler, Wiesbaden 1991.

Bucher, T.; Dinter, B.: Process Orientation of Information Logistics - An Empiri-cal Analysis to Assess Benefits, Design Factors, and Realization Approaches, in: IEEE Computer Society (Hrsg.): 41th Hawaii International Conference on System Sciences (HICSS-41), Waikoloa, Big Island, Hawaii 2008.

Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technologien und -Anwendungen, 3. Aufl., Berlin et al. 2006.

Davis, G.; Olson, M.: Management Information Systems - Conceptual Foundati-ons, Structure and Development, 2. Aufl., McGraw-Hill, New York 1985.

Gartner Group: The Gartner Glossary of Information Technology Acronyms and Terms, http://www.gartner.com/6_help/glossary/Gartner_IT_Glossary.pdf, 27.02.2007.

Gluchowski, P.: Business Intelligence - Konzepte, Technologien und Einsatzbe-reiche, in: HMD - Praxis der Wirtschaftsinformatik 222 (2001), S. 5-15.

Gluchowski, P.; Kemper, H.-G.: Quo Vadis Business Intelligence?, in: BI-Spektrum 1 (2006) 1, S. 12-19.

Gorry, A.; Scott Morton, M.: A Framework for Management Information Sys-tems, in: Sloan Management Review 13 (1971) 1, S. 55-70.

Grothe, M.; Gentsch, P.: Business Intelligence, Addison-Wesley, München 2000. Heiserich, O.-E.: Logistik: Eine praxisorientierte Einführung, 3. Aufl., Gabler,

Wiesbaden 2002. Hill, W.; Fehlbaum, R.; Ulrich, P.: Organisationslehre 1: Ziele, Instrumente und

Bedingungen der Organisation sozialer Systeme, 5. Aufl., Haupt, Bern et al. 1994.

Holten, R.: Entwicklung von Führungsinformationssystemen, Deutscher Universi-täts Verlag, Wiesbaden 1999.

Inmon, W.: Building the Data Warehouse, 3. Aufl., Wiley, New York 2002. Jung, R.: Architekturen zur Datenintegration : Gestaltungsempfehlungen auf der

Basis fachkonzeptueller Anforderungen, Deutscher Universitätsverlag, Wies-baden 2006.

Jung, R.; Winter, R.: Data Warehousing: Nutzungsaspekte, Referenzarchitektur und Vorgehensmodell, in: Jung R. et al. (Hrsg.): Data Warehousing Strategie, Springer, Berlin et al. 2000, S. 3-20.

Kagermann, H.; Österle, H.: Geschäftsmodelle 2010 - Wie CEOs Unternehmen transformieren, 1. Aufl., F.A.Z.-Institut für Management- Markt- und Medien-informationen, Frankfurt 2006.

Kemper, H.-G.; Mehanna, W.; Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Eine Einführung in die IT-basierte Managementun-terstützung, 2. Aufl., Vieweg, 2006.

Klesse, M.: Leistungsverrechnung im Data Warehousing – Entwicklung einer Me-thode, Dissertation, Universität St. Gallen, St. Gallen 2007.

Klesse, M.; von Maur, E.: Informationsintegration für Entscheidungsprozesse im Corporate Knowledge Center, in: von Maur E. et al. (Hrsg.): Data Warehouse Management, Springer, Berlin et al. 2003, S. 25-46.


Laudon, J.; Laudon, K.: Management Information Systems: Managing the Digital Firm, 10. Aufl., Prentice Hall, 2006.

Laudon, K.; Laudon, J.; Schoder, D.: Wirtschaftsinformatik: Eine Einführung, Pearson Studium, München et al. 2006.

Mertens, P.: Business Intelligence - Ein Überblick, in: Information Management & Consulting 17 (2002) Sonderausgabe, S. 65-73.

Mucksch, H.: Das Data Warehouse als Datenbasis analytischer Informationssys-teme, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Busi-ness Intelligence Techlologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 129-142.

Nagel, K.: Nutzen der Informationsverarbeitung, 2. Aufl., Oldenbourg, München 1990.

Negash, S.: Business Intelligence, in: Communications Of The Association For In-formation Systems 13 (2004), S. 177-195.

O'Brien, J.: Management Information Systems - Managing Information Technolo-gy in the Networked Enterprise, 3. Aufl., Irwin, Chicago 1996.

Picot, A.; Reichwald, R.; Wigand, R.: Die grenzenlose Unternehmung: Informati-on, Organisation und Management, 5. Aufl., Gabler, Wiesbaden 2003.

Picot, A.; Reichwald, R.; Wigand, R. T.: Die grenzenlose Unternehmung, 4. Aufl., Gabler, Wiesbaden 2001.

Schulte, C.: Logistik: Wege zur Optimierung der Supply Chain, 4. Aufl., Vahlen, München 2005.

Sommer, D.: Spending Preferences for Business Intelligence and Information In-frastructure, 2007, Gartner, Stamford 2007.

Strauch, B.; Winter, R.: Stichwort "Business Intelligence", in: Bellmann M. et al. (Hrsg.): Praxishandbuch Wissensmanagement - Strategien, Methoden, Fall-beispiele, Symposion, Düsseldorf 2002, S. 439-448.

Stumpf, S.: Wann man von Synergie in Gruppen sprechen kann: Eine Begriffsana-lyse, in: Gruppendynamik 30 (1999) 2, S. 191-206.

von Maur, E.; Schelp, J.; Winter, R.: Integrierte Informationslogistik - Stand und Entwicklungstendenzen, in: von Maur E. et al. (Hrsg.): Data Warehouse Ma-nagement, Springer, Berlin etc. 2003, S. 3-23.

Wöhe, G.: Einführung in die Allgemeine Betriebswirtschaftslehre, 18. Aufl., Vah-len, München 1993.

4 Strategie der Informationslogistik

Barbara Dinter, Robert Winter


1 Strategiebegriff in der Informationslogistik ..................................... 592 Produktsicht auf die IL-Strategie: die IL-Teilstrategien ................... 653 Prozesssicht auf die IL-Strategie: der IL-Strategie-

entwicklungsprozess ......................................................................... 714 Zusammenfassung ............................................................................ 74

Literatur ............................................................................................ 75

1 Strategiebegriff in der Informationslogistik

1.1 Motivation und Grundlagen

Der Informationslogistik (IL) wird als wesentliches Unterstützungsinstru-mentarium und als Enabler für fachliche Innovationen ein hoher Stellen-wert zugeordnet. Folglich kommt der Ausgestaltung der IL-Strategie große Bedeutung zu. Entsprechend der Definition der Informationslogistik (vgl. Kap. 3) steht die IL-Strategie vor der Herausforderung, Partikularsichten und -interessen unterschiedlicher Organisationseinheiten (oder Funktional-bereiche) im Unternehmen und daraus historisch gewachsene, intranspa-rente und inhomogene Insellösungen zu einer Gesamtsicht in Form einer allgemein getragenen und genutzten Plattform für analytische Zwecke zu entwickeln. Eine solche Plattform muss zudem nicht nur aktuellen Anfor-derungen genügen, sondern sollte auch für künftige Anforderungen tragfä-hig sein. Die IL-Strategie hat sich zudem verschiedenen internen und ex-ternen Veränderungen anzupassen. Diese können strategischer Natur sein wie z. B. zunehmender Kostendruck oder zusätzliche Compliance Anfor-derungen, können aber auch aus neuen fachlichen Anforderungen erstehen

60 Barbara Dinter, Robert Winter

(z. B. BI-Nutzung in den Geschäftsprozessen), aus organisatorischen Ver-änderungen resultieren (etwa in Folge von Mergers & Acquisitions) oder durch technische Innovationen ausgelöst werden.

Zum Verständnis des (allgemeinen) Strategiebegriffs finden sich zahl-reiche Ansätze und Definitionen. Am häufigsten ist auch in der Praxis das Verständnis anzutreffen, das auf Ansoff zurückgeht und Strategien als Maßnahmen zur Sicherung des langfristigen Erfolgs eines Unternehmens beschreibt (Ansoff 1965, S. 486ff.). Demzufolge ist die strategische Pla-nung „ein informationsverarbeitender Prozess zur Abstimmung von An-forderungen der Umwelt mit den Potenzialen des Unternehmens in der Absicht, mit Hilfe von Strategien den langfristigen Erfolg zu sichern“ (Bea u. Haas 2001, S. 49).

Eine ähnliche Sichtweise repräsentiert die Ausprägung „Plan“ als Weg-Ziel-Beschreibung bzw. Handlungsabsicht bei Mintzberg’s „fünf P’s“, die die unterschiedlichen Verwendungsarten einer Strategie beschreiben (Mintzberg 1987).1 Bei Bea und Haas finden sich sogar sieben Strategiear-ten (Bea u. Haas 2001, S. 164). Dort wird auch die häufig zitierte Differen-zierung der Strategiearten anhand der Ebenen des Planungssystems in Un-ternehmensebene, Geschäftsbereichsebene und Ebene der Funktionen eingeführt (Bea u. Haas 2001, S. 164).

Auch zur wechselseitigen Positionierung zwischen IT- und Unterneh-mensstrategie gibt es zahlreiche Ansätze, so u. a. bei Earl und Heinrich (Earl 1989; Heinrich 2002). Gemäß Heinrich ist die IT-Strategie immer Teil der Unternehmensstrategie und bildet ihrerseits die Grundlage für das Ableiten von IT-Teilstrategien. „Dabei wird mit IT-Strategie das Konzept, die Perspektive oder die Art und Weise bezeichnet, in der die strategischen IT-Ziele verfolgt, d. h. in strategische Maßnahmen umgesetzt werden sol-len“ (Heinrich 2002, S. 106).

Noch gibt es vergleichsweise wenige Arbeiten, die BI-Strategie oder gar die Strategie der Informationslogistik adressieren. Der Beitrag versucht, diese Lücke zu schließen und stellt einen Rahmen zur IL-Strategieent-wicklung vor. Das Kapitel ist wie folgt aufgebaut: Im verbleibenden Abschn. 1 wird schrittweise zum Begriffsverständnis der IL-Strategie hin-geführt. Abschnitt 2 zeigt auf, wie Teilstrategien der Informationslogistik abgeleitet werden können. Diese so genannte Produktsicht auf die IL-Strategie wird ergänzt in Abschn. 3 durch einen Strategieentwicklungspro-

1 Neben der oben erwähnten Ausprägung „Plan“ gibt es „Ploy“ (Spielzug gegen-

über Wettbewerbern und Konkurrenten), „Pattern“ (Muster in der Handlungs-weise eines Unternehmens), „Position“ (Verortung des Unternehmens in seiner Umwelt) und „Perspective“ (Form der Weltanschauung) (Mintzberg 1987).

Strategie der Informationslogistik 61

zess, der die Prozesssicht repräsentiert. Der Beitrag endet mit einer Zu-sammenfassung (Abschn. 4).

1.2 Alignment von Unternehmens- und IT-Strategie

Die bisherigen Ausführungen machen deutlich, dass sowohl der allge-meine Strategiebegriff wie auch der Strategiebegriff im Kontext IT / IS auf

langfristig wirksame, grundlegende (d. h. Grundlagen für andere Gestaltungsprozesse schaf-

fende) und ganzheitliche (d. h. die gesamte Betrachtungseinheit umfassende und

damit automatisch aggregierte) Festlegungen abstellen.

Als typische Festlegungen auf Strategieebene werden im Business En-gineering (siehe Kap. 2) die Positionierung im Wettbewerb und hinsich-tlich Kompetenzen die daraus folgende Positionierung in Wertschöpfungs-netzwerken, das Produkt- / Leistungsprogramm sowie das Zielsystem betrachtet. Derartige Gestaltungsfragen lassen sich auch als „Was-Fragen“ bezeichnen, während sich nicht-strategische Gestaltungsprozesse auf die „Wie-Fragen“ konzentrieren.

Wenn man „Was-Fragen“ und „Wie-Fragen“ als Abschnitte auf der ver-tikalen Achse eines Koordinatensystems interpretiert, dessen horizontale Achse die Abschnitte „Fachseite“ und „IT“ bilden, entsteht das Grundge-rüst des von Henderson und Venkatraman 1993 vorgeschlagenen „Strate-gic Alignment Model“ (vgl. Abb. 1) (Henderson u. Venkatraman 1993). Im linken oberen Quadranten findet sich dort die fachliche Strategie, im rechten oberen Quadranten die IT-Strategie, im linken unteren Quadranten die fachlichen Prozesse und Infrastrukturen und im rechten unteren Quad-ranten die IT-Prozesse und -Infrastrukturen.


Fachliche Strategie IT-Strategie

Administra-tive Infra-struktur

Fachliche Prozesse und Infrastrukturen IT-Prozesse und Infrastrukturen

Prozesse Fertigkeiten

Architek-turen

Prozesse Fertigkeiten

Betäti-gungs-felder

Steuerung/Kontrolle

Technolo-giebereich

IT-Steuerung

System-Kompeten-

zen

SpezifischeKompeten-

zen

FACHSEITE INFORMATIONSTECHNOLOGIE Abb. 1. Strategic Alignment Model (in Anlehnung an Henderson u. Venkatraman 1993)

Auf dieser Grundlage beschreiben Henderson und Venkatraman die aus ihrer Sicht wesentlichen Abstimmungsprozesse („IT / Business Align-ment“) (Henderson u. Venkatraman 1993):

1. Strategy Execution Alignment bezeichnet die Ausrichtung der IT-Pro-zesse und -Infrastruktur auf die fachlichen Prozesse (und Infrastruk-tur), wobei diese an der fachlichen Strategie ausgerichtet sind. Ent-sprechende Abstimmungsprozesse lassen sich unter dem Stichwort „IT follows Business“ zusammenfassen.

2. Technology Transformation Alignment bezeichnet die Ausrichtung der IT-Prozesse und -Infrastruktur auf die IT-Strategie, wobei diese an der fachlichen Strategie ausgerichtet ist. Entsprechende Abstim-mungsprozesse lassen sich unter dem Stichwort „IT Structure follows IT Strategy“ zusammenfassen.

3. Competitive Potential Alignment bezeichnet die Ausrichtung der fachlichen Prozesse und Infrastruktur an der fachlichen Strategie, wobei diese von der IT-Strategie beeinflusst werden soll. Entspre-chende Abstimmungsprozesse lassen sich unter dem Stichwort „IT als Enabler“ zusammenfassen.


4. Service Level Alignment bezeichnet die Ausrichtung der fachlichen Prozesse und Infrastruktur an den IT-Prozessen (bzw. der IT-Infra-struktur), wobei diese an der fachlichen Strategie ausgerichtet ist. Entsprechende Abstimmungsprozesse lassen sich unter dem Stich-wort „IT als Automatisierungsinstrument“ zusammenfassen.

Die folgende Abb. 2 illustriert zusammenfassend die genannten Ab-stimmungsprozesse:

IT-StrategieFachliche Strategie

IT-Prozesse und Inf rastrukturen

Fachliche Prozesse und Inf rastrukturen

1

1

2

23

3

4

4

1. Strategy Execution Alignment

2. Technology Transformation Alignment

3. Competitive Potential Alignment

4. Service Level Alignment

Abb. 2. Abstimmungsprozesse im Strategic Alignment Model (in Anlehnung an Henderson u. Venkatraman 1993)

Die Vielschichtigkeit der Zusammenhänge zwischen strategischen Ge-staltungen auf der einen Seite und prozess- bzw. infrastrukturbezogenen Gestaltungen auf der anderen Seite macht deutlich, dass ein methodenge-stütztes, systematisches Vorgehen große Vorteile bietet. Allerdings sollte beachtet werden, dass Anschlussfähigkeit ein wichtiges Kriterium zur Auswahl eines geeigneten Ansatzes darstellt, weil die IT-Strategiegestal-tung komplexe Wechselwirkungen nicht nur mit fachlicher Strategiege-staltung und IT-Prozess- bzw. IT-Infrastrukturgestaltung aufweist, sondern auch mit anderen Informationsmanagement-Aufgabenkomplexen wie z. B. Architekturmanagement, Projektportfolio-Management oder IT-Gover-nance.

1.3 IL-Strategie

Eine Strategie zur Gestaltung der Informationslogistik kann als Teildiszi-plin der IT-Strategie angesehen werden. Sie muss sich daher den gleichen


Anforderungen stellen und eine – wie oben erwähnt – langfristig wirk-same, grundlegende und ganzheitliche Perspektive einnehmen. Das Verständnis der IL-Strategie lässt sich anhand unterschiedlicher Sichtweisen schärfen. Zunächst kann man die IL-Strategie aus Positionie-rungssicht als Spezifikation aggregierter, umfassender und langfristiger Ziele verstehen. Eingangs wurde im Zuge der allgemeinen Strategiedefini-tion bereits die Umsetzungssicht auf die Strategie vorgestellt (Strategie als die Maßnahmen zur langfristigen Sicherung des Erfolgs eines Unterneh-mens). Übertragen auf die IL-Strategie ist das dann die Summe aller Maß-nahmen zum Aufbau und zur langfristigen Sicherstellung der Versorgung mit analytischen Informationen im Unternehmen durch und für alle Unter-nehmensbereiche. Dies schließt auch die unternehmensübergreifende Nut-zung und Bereitstellung analytischer Informationen ein. Schließlich lässt sich die IL-Strategie auch als eine Menge von Teilstrategien interpretieren (Komponentensicht).

Diese Perspektiven des Strategieverständnisses kann man auch als Pro-duktsicht bezeichnen. Auf der anderen Seite sollte auch die Strategieent-wicklung, also die Prozesssicht berücksichtigt werden. Im Beitrag werden diese beiden Dimensionen (Produktsicht und Prozesssicht) adressiert. Zum einen wird das Strategieverständnis aus Komponentensicht näher beschrie-ben. Als Ausgangsbasis hierfür dient das Modell des integrierten Informa-tionsmanagements (vgl. Abschn. 2). Ebenso findet sich im Abschn. 3 eine Präzisierung der Prozesssicht, indem der IL-Strategieentwicklungsprozess dargestellt wird.

Die bereits erwähnten Wechselwirkungen zwischen IT- und Unterneh-mensstrategie gelten gleichermaßen für die Beziehung zwischen IL- und Unternehmensstrategie. Die IL-Strategie unterstützt die Umsetzung der Unternehmensstrategie, indem sie beispielsweise eine adäquate Plattform zur Explizierung, Messung und Kontrolle der strategischen Unterneh-mensziele in Form von Kennzahlen bereitstellt bzw. per definitionem alle entscheidungsrelevanten und -unterstützenden Informationen zur Steue-rung des Unternehmens auf den verschiedenen Ebenen (Unternehmens-ebene, Geschäftsbereichsebene und Ebene der Funktionen) liefert. Gleich-zeitig fungiert sie aber auch als Enabler für die Unternehmensstrategie, wenn sie in ihrer ganzen Bandbreite umgesetzt wird (vgl. Kap. 8). So las-sen sich beispielsweise neue Geschäfts- und Produktfelder erschließen, wenn analytische Informationen in Geschäftsprozessen genutzt werden (vgl. Kap. 6) oder zwischen Unternehmen ausgetauscht werden.

Die IL- Strategie muss sich neben der Unternehmensstrategie auch an der IT-Strategie orientieren. Bei den Ausführungen zum Infrastrukturcha-rakter der IL (vgl. Kap. 3, Abschn. 3) wurde bereits herausgearbeitet, dass


die Informationslogistik nicht isoliert, sondern in enger Abstimmung mit den Aktivitäten der unternehmensweiten IT betrieben werden sollte.

1.4 Limitationen von BI-Strategien

Trotz der hohen Relevanz der IL-Strategie finden sich vergleichsweise wenig Erkenntnisse zur Gestaltung und Umsetzung der IL-Strategie in der Literatur. Wenn überhaupt, wird das Themenfeld unter dem Begriff „BI-Strategie“ adressiert. Wie bereits in Kap. 3, Abschn. 2.4.2 ausgeführt wur-de, verschwimmen die Grenzen zwischen den Begriffen „Informati-onslogistik“ und „Business Intelligence“ je nachdem, wie weit der letztere Terminus gefasst wird. Jedoch lässt sich beobachten, dass zwei wesentli-che Eigenschaften der Informationslogistik, nämlich die übergreifende Be-reitstellung und Nutzung von analytischen Informationen sowie die Be-rücksichtigung auch unternehmensübergreifender Datenflüsse, in BI-Strategien nicht oder kaum berücksichtigt wird. Im Gegenteil, häufig wer-den unter dem Label „BI-Strategie“ lediglich einzelne Aspekte oder Schnittstellenthemen einer solchen Strategie adressiert, wenn etwa nur auf organisatorische Fragestellungen, wie dem Aufbau von BI Competence Centern, eingegangen wird (z. B. Zeid 2006).

Die unternehmerische Praxis und Software-Hersteller bzw. Beratungs-häuser erschließen die Aufgabenstellung häufig über eine (mehr oder we-niger) systematische Herleitung von Teilstrategien, dann meist in Anleh-nung an etablierte Teilstrategien der IT-Strategie, und deren anschließende Adaption. Einige Arbeiten (wie z. B. Totok 2006; Trost u. Zirkel 2006) stellen ein Vorgehensmodell für die Entwicklung einer BI-Strategie vor. Dabei orientieren sie sich in der Regel am generischen Strategieentwick-lungsprozess und reichern die einzelnen Phasen mit Vorschlägen zur prak-tischen Umsetzung an. Den meisten Ansätzen ist gemein, dass sie betonen, die Unternehmens- bzw. Geschäftsstrategie müsse den Ausgangspunkt für die Herleitung einer BI-Strategie bilden und Ziele müssten dem Top-down-Ansatz folgend abgeleitet werden (Hoffmann 2002; Totok 2006).

2 Produktsicht auf die IL-Strategie: die IL-Teilstrategien

2.1 Das Modell des integrierten Informationsmanagements

Angesichts der Komplexität der IL-Strategie bietet es sich an, die Kompo-nentensicht des IL-Strategieverständnisses (vgl. Abschnitt 1.3) einzuneh-men und die strategischen Fragestellungen in Teilstrategien zu adressieren.


Eine solche Zerlegung dient nicht nur der Komplexitätsreduzierung, auch die Abstimmung mit der (unternehmensweiten) IT-Strategie (bzw. deren Teilstrategien) fällt leichter und. kann transparenter erfolgen. Es gibt be-reits zahlreiche Arbeiten zur Herleitung und Ausgestaltung solcher IT-Teilstrategien (Earl 1989; Heinrich 2002). Speziell für BI-Strategien (vgl. vorheriger Abschnitt) konnte sich bisher noch kein gemeinsames Ver-ständnis etablieren, welche Teilstrategien ihr zuzurechnen seien. In der un-ternehmerischen Praxis orientiert sich die Definition zugehöriger Teil-strategien häufig an den Teilstrategien der IT-Strategie oder an Teilaspek-ten des Datenmanagements (wie Metadatenmanagement, Datenqualitäts-management, Datenarchitektur etc.).

Im Folgenden werden die Teilstrategien aus dem Modell des integrier-ten Informationsmanagements (Zarnekow et al. 2005) auf die Spezifika der Informationslogistik übertragen.

Das Modell beschreibt die zentralen Managementprozesse eines IT-Leistungserbringers, die zur Herstellung und Nutzung von IT-Produkten erforderlich sind (Zarnekow et al. 2005, S. 66). Es basiert auf einer Adap-tion des SCOR (Supply Chain Operations Reference)-Modells (Supply Chain Council 2006). Übertragen auf den Kontext des Informationsmana-gements werden dann IT-Leistungserbringer und Leistungsabnehmer in ei-ner Supply Chain zur Erstellung von IT-Leistungen (Zarnekow et al. 2005) unterschieden. Leistungsabnehmer sind typischerweise Geschäftsbereiche des Unternehmens, die Leistungserbringung erfolgt durch einen IT-Dienstleister – der wiederum die Rolle des Leistungsabnehmers eines internen oder externen Lieferanten einnehmen kann. Der Source-Prozess des Leistungsabnehmers umfasst alle zum Management der Lieferantenbe-ziehungen erforderlichen Aufgaben, der Deliver-Prozess des Leistungserb-ringers die zum Management der Kundenbeziehungen. Im dazwischen lie-genden Make-Prozess des Leistungserbringers sind alle Aufgaben zum Management der IT-Leistungserstellung zusammengefasst. Der übergeord-nete Govern-Prozess wird im Folgenden nicht weiter betrachtet.

Diese Kernidee einer Liefer- und Leistungskette für IT-Leistungen lässt sich sehr gut auf den Kontext der Informationslogistik übertragen, denn aktuell sind die für die Informationslogistik verantwortlichen Organisati-onseinheiten häufig im Spannungsfeld zwischen zu beziehenden IT-Dienstleistungen, der eigenen „Produktion“ von IT-Leistungen bzw. der Schnittstelle hin zu Leistungsabnehmern (i. d. R. die Fachbereiche) posi-tioniert. In Kap. 5 wird auf die unterschiedlichen Typen von Leistungserb-ringern in der Informationslogistik näher eingegangen. Die dort vorgestell-ten Studienergebnisse bestätigen eine Abnahme der Fertigungstiefe, indem standardisierbare Leistungen extern oder unternehmensintern an andere IT-Bereiche vergeben werden.


Im Modell des integrierten Informationsmanagements werden Teilstra-tegien unterschieden, sie decken alle relevanten Phasen der IT-Leistungs-erstellung ab (vgl. Abb. 3).

Portfoliostrategie

• Identifikation von Leistungssegmenten• Bewertung und Positionierung von

Leistungssegmenten

Entwicklungsstrategie

Organisation der Entwicklung

• Vorgehensmodelle• Entwicklungs-

prinzipien• Methoden,

Werkzeuge

Produktionsstrategie

Organisation des Betriebs

• Plattformstrategie• Standortstrategie• Designprinzipien

• Definition der strategischen Rahmenbedingungen für Entwicklung und Produktion

• Gestaltung der Anwendungs- u. Systemarchitektur• Rahmenbedingungen für Werkzeuge

Sourcing-Strategie

• Alignment mit Unterneh-mens- und IT-Strategie

• Lieferantenmanagement• Auswahl Sourcing-

Strategie; Dimensionen:

Delivery-Strategie

• Strategische Positio-nierung in Markt und Wettbewerb

• Strategische Ausrichtung des Angebotsportfolios

• Preisstrategie• Kommunikations-

strategie• Distributionsstrategie

Entwicklungs-management

Produktions-management

Programm-management

KundenmanagementLieferantenmanagement

• Intern / Extern• Total / Selektiv• Single / Multiple• Offshore /Nearshore• Komponenten• Utility (RZ)• Software (SSW)• Lösungen (ASP)• Prozesse (BPO)

Abb. 3. Teilstrategien im Modell des integrierten Informationsmanagements (Zar-nekow et al. 2004; Klesse u. Wilhelmi 2005)

Im Folgenden werden die Teilstrategien hinsichtlich ihrer Ausgestaltung für die Informationslogistik diskutiert (vgl. Klesse u. Wilhelmi 2005).

2.2 Sourcing-Strategie (Source)

Den Kern der Sourcing-Strategie bildet die Frage, welche IL-Leistungen in welchem Umfang von wem erbracht werden sollen. Dabei ist nicht nur an Outsourcing (oder gar Offshoring) im Sinne einer externen Vergabe zu denken, sondern auch an die Möglichkeit, für einzelne Aufgaben und Pro-zesse auf die interne IT des Unternehmens zurückzugreifen. Auch ist hier zu klären, ob eine Make or Buy-Strategie (d.h. Eigenentwicklung versus Bezug von Standardprodukten) verfolgt werden soll. Die Festlegungen in der Sourcing-Strategie werden stark beeinflusst von den organisatorischen Rahmenbedingungen (inkl. interner Kapazitäten) und Gestaltungsmöglich-keiten. Hierzu sei nochmals auf Kap. 5 verwiesen, wo anhand der Ferti-gungstiefe und Geschäftsnähe des Leistungserbringers unterschiedliche Typen ableitet werden. Die Sourcing-Strategie hängt in besonderem Maße ab von strategischen Vorgaben auf der Geschäftsebene zur Fertigungstiefe in der IT und speziell zum Thema Outsourcing bzw. zur IT-Strategie hin-sichtlich der Make or Buy-Strategie. Abbildung 3 zeigt die Dimensionen zur Kategorisierung von Sourcing-Strategien.


2.3 Delivery-Strategie (Deliver)

Die Delivery-Strategie adressiert die Schnittstelle des Leistungserbringers zum Leistungsabnehmer, d. h. alle Aufgaben, die zur Gestaltung der Be-ziehung des Leistungserbringers zum Absatzmarkt seiner IT-Produkte, al-so zu den Leistungsabnehmern, erforderlich sind. Hauptaufgabe des De-liver-Prozesses ist es, die Bedürfnisse der Leistungsabnehmer in interne Anforderungen an die IT-Leistungserstellung zu transformieren. Im Kon-text der Informationslogistik betrifft dies insbesondere die Art und Weise, wie die IL-Produkte an Kunden (in den Fachbereichen) geliefert und wie sie dabei ggf. vermarktet werden. Zu klären sind dabei folgende Fragestel-lungen:

Strategische Positionierung im Markt und Wettbewerb: Es gilt, zum ei-nen festzulegen, ob die IL-Produkte am externen Markt angeboten wer-den sollen (beispielsweise in Form von Reports), aber auch Fragestel-lungen wie die der Delegationsform des IL-Leistungserbringers (Cost / Profit / Investment Center, vgl. Klesse 2007) müssen geklärt werden.

Strategische Ausrichtung des Angebotsportfolios: Das Portfolio an IL-Leistungen sollte möglichst optimal an der Kundennachfrage ausgerich-tet sein, was die Kenntnis von Kundenbedürfnissen und Kundennutzen voraussetzt. Für den IL-Leistungserbringer bedeutet dies, dass eine gute Kommunikation mit den Fachbereichen (den Leistungsabnehmern) vor-herrschen muss bzw. dass der IL-Leistungserbringer selbst fachliches Know How im Team hat.

Preisstrategie: Die Bepreisung der IL-Leistungen hängt insbesondere ab von Budgets und vom gewählten Finanzierungs- und Verrechnungsmo-dell, das es ebenfalls festzulegen gilt. Zur Problematik und möglichen Lösungsansätzen sei auf Kap. 12 verwiesen.

Kommunikationsstrategie: Hier werden die Kommunikationsziele und Zielgruppen des IL-Leistungserbringers festgelegt. Der Anspruch der Informationslogistik, bereichsübergreifendes Denken und Datenaus-tausch zu fördern, zielt in eine ähnliche Richtung, dass nämlich mit ge-eigneter Kommunikation oder „Marketing“ die Leistungen der IL weit-flächig im Unternehmen bekannt gemacht werden.

Distributionsstrategie: Damit werden die Rahmenbedingungen festge-legt, wie und über welche Wege die IL-Leistungen für die Kunden ver-fügbar gemacht werden. Dies betrifft auch die Grundsatzentscheidung, ob die Produkte im Push- oder Pull-Modus zum Kunden gelangen. Letz-teres Prinzip wird zunehmend von den Fachbereichen nachgefragt, wenn sie nämlich autonom, zeitnah und selbstbestimmt analytische In-


formationen beziehen möchten („Selbstbedienung“ anstelle von Abhän-gigkeiten von der IT).

2.4 Portfolio-Strategie (Make)

Die Portfolio-Strategie definiert die Strategie für das IL-Leistungspro-gramm (die Summe aller IL-Leistungen des Leistungserbringers). Fol-gende Fragestellungen gilt es zu beantworten:

Identifikation von Leistungssegmenten: Die Portfolio-Strategie muss auf Dauer ertragskräftige Leistungssegmente identifizieren. Hierzu soll-ten insbesondere auch die Anforderungen aus der fachlichen Strategie berücksichtigt werden, um Angebot und Nachfrage an IL-Leistungen bestmöglich zur Deckung zu bringen.

Bewertung und Positionierung von Leistungssegmenten: Hier bieten sich Portfolio-Ansätze an, die zusammen mit etwaigen Normstrategien auf die Informationslogistik übertragen werden. Es besteht einerseits die Option, sich als Spezialanbieter für einzelne Lösungstypen zu positio-nieren oder anderseits sich als Service Integrator für das gesamte Spek-trum an relevanten IL-Anwendungen aufzustellen („All in One“) und somit als primäre Anlaufstelle für das Business für alle IL-Themen zu fungieren.

Für den IL-Leistungserbringer mag das eine neue, ungewohnte Sicht-weise darstellen, wenn er nun selbst und proaktiv die zu erbringenden Leistungen definiert und nicht mehr wie einst reaktiv die Anforderungen der Kunden umsetzt.

2.5 Entwicklungsstrategie (Make)

Die Leistungsgestaltung steht im Mittelpunkt der Entwicklungsstrategie. Viele BI-Strategien (vgl. Abschn. 1.4) in der unternehmerischen Praxis ad-ressieren v.a. diese Teilstrategie und entlehnen sie der IT-Strategie. Die Funktionalität der IT-Leistungen wird maßgeblich durch die Anwendungs-systeme, d.h. durch die Entwicklung, bestimmt. Die Entwicklungsstrategie betrifft zum einen systemarchitektonische Aspekte, zum anderen Entwick-lungsprinzipien und Vorgaben für die Werkzeugunterstützung. Dazu wer-den folgende Fragestellungen adressiert:

Organisation der Entwicklung: Die Ansprüche der Informationslogistik müssen auch in der Organisationsgestaltung reflektiert werden. Kapi-


tel 5 geht näher auf mögliche Aufbauorganisationen ein. Auch die Ab-lauforganisation für die Entwicklung gilt es hier festzulegen.

Festlegung der Entwicklungsprinzipien und Standards: Bereichsüber-greifende verbindliche Standards und Vorgehensweisen ermöglichen die (schrittweise) Umstellung von Insellösungen im Unternehmen hin zu ei-ner umfassenden homogenen Informationslogistik und fördern den Da-tenaustausch zwischen Organisationseinheiten. Ebenso erfordert der In-frastrukturcharakter der Informationslogistik (vgl. Kapitel 3) solche Richtlinien und macht die Abstimmung mit der unternehmensweiten IT sinnvoll.

Rahmenbedingungen für Entwicklungswerkzeuge und -sprachen: In ei-ne ähnliche Richtung zielt diese Aufgabe. Als Beispiel könnte die Frage genannt werden, ob die Datenbewirtschaftung (ETL-Prozesse) für das Data Warehouse in Form von Eigenprogrammierung oder mit Kauf-software realisiert wird.

Strategische Ausrichtung des Anwendungs-Portfolios: Hiermit soll si-chergestellt werden, dass die Gestaltung und Anordnung der Anwen-dungssyteme auch bestimmten Prinzipien folgen sollte.

2.6 Produktionsstrategie (Make)

Die Produktionsstrategie ist verantwortlich für die effiziente Produktion der IL-Leistungen (Leistungsherstellung), was insbesondere Betrieb und Wartung adressiert. Im Einzelnen gilt es folgende Aspekte zu beachten, wobei in der Ausgestaltung der Produktionsstrategie kaum Unterschiede zwischen der IT- und der IL-Strategie zu finden sind:

Organisation der Produktion: Die bei der Entwicklungsstrategie bereits angesprochene Aufbau- und Ablauforganisation muss auch die Anforde-rungen des Betriebs der Informationslogistik beachten.

Designprinzipien und Standards: Hier gelten ähnliche Aussagen wie zur Entwicklungsstrategie; es gilt, u. a. Vorgaben für Produktionsinfrastruk-tur festzulegen (Skalierbarkeit, Fehlertoleranz, etc.).

Strategische Ausrichtung der Systemarchitektur: Damit wird die Pro-duktionsinfrastruktur und deren Architektur langfristig gestaltet.

Rahmenbedingungen für Werkzeuge: Dies betrifft im Wesentlichen Werkzeuge für die Steuerung und Überwachung der Produktion.

Hinsichtlich der Auslagerung von Betriebsaufgaben macht die Produk-tionsstrategie auch Vorgaben für die Sourcing-Strategie, nämlich, ob diese prinzipiell sinnvoll ist.


2.7 Zusammenfassung und Bewertung der einzelnen Teilstrategien

Die Teilbereiche im Make-Prozess weisen starke Abhängigkeiten auf. Folglich ist hier eine integrierte Betrachtung der Teilstrategien zwingend notwendig, nur so können markt- und kundengerechte IL-Leistungen erb-racht werden (Zarnekow et al. 2005, S. 65). Auch zu den restlichen Teil-strategien gibt es Interdependenzen, die oben zum Teil schon angespro-chen wurden. Zudem sind ggf. bereits bestehende für die gesamte IT formulierte Strategien zu berücksichtigen.

In der unternehmerischen Praxis werden v.a. Teilstrategien adressiert, die sich in obiger Klassifikation am ehesten unter der Entwicklungs- und der Produktionsstrategie einordnen lässt. Dies bedeutet aber auch im Um-kehrschluss, dass die restlichen Teilstrategien (Source- / Deliver- / Portfo-lio-Strategie) häufig vernachlässig werden. Eine solche unzureichende Reflexion über die Positionierung des IL-Leistungserbringers im eigenen Unternehmen steht nicht in Einklang mit den Ansprüchen der Informati-onslogistik.

3 Prozesssicht auf die IL-Strategie: der IL-Strategieentwicklungsprozess

Wie in Abschn. 1.3 erläutert wurde, kann man neben der Produktsicht auf die IL-Strategie auch eine Prozesssicht einnehmen. Diese spiegelt sich in einem Strategieentwicklungsprozess wider. Sowohl für Strategie im All-gemeinen (bzw. für Unternehmensstrategien) gibt es zahlreiche Vorge-hensmodelle zur Strategieentwicklung (wie Ansoff 1965; Mintzberg 1987; Müller-Stewens u. Lechner 2003; Dubs et al. 2004), als auch für die Erar-beitung von IT-Strategien (wie Earl 1989; Heinrich 2002). Vereinzelt sind Arbeiten für BI-Strategien (vgl. Abschn. 1.4) verfügbar, sie entstammen häufig der Beraterpraxis (wie Totok 2006; Trost u. Zirkel 2006). Auf ho-hem Aggregationsniveau ähneln sich die verschiedenen Vorgehensmodelle stark und enthalten in der Regel die Hauptphasen Analyse, Design bzw. Planung, Umsetzung und Controlling, wenngleich Reihenfolge oder Zu-sammenfassung von Teilschritten variieren können. Zu jeder Phase lassen sich jeweils Aufgaben (Teilschritte) und unterstützende Techniken definie-ren (z. B. bei Bea u. Haas 2001, S. 65ff.).

Basierend auf der Konsolidierung der oben zitierten Ansätze zum Stra-tegieentwicklungsprozess und unter Berücksichtigung der Charakteristika


der Informationslogistik wird im Folgenden ein Vorgehensmodell für den IL-Strategieentwicklungsprozess vorgestellt.

3.1 Situationsanalyse

Die erste Phase des IL-Strategieentwicklungsprozesses legt mit einer um-fassenden Ist-Analyse den Grundstein: Heinrich zieht den treffenden Ver-gleich, dass ein Kompass nur dann sinnvoll verwendbar ist, wenn der Standort des Benutzers bekannt ist (Heinrich 2002, S. 82). Im Kontext der Informationslogistik bietet sich eine Strukturierung anhand der drei Di-mensionen Fachlichkeit, Technik und Organisation an. Als unterstützende Technik könnte z.B. ein (idealerweise BI-spezifisches) Reifegradmodell für eine möglichst objektive Selbsteinschätzung und als Vergleichsmaß-stab zum Wettbewerb zum Einsatz kommen (vgl. z. B. Chamoni u. Glu-chowski 2004; Steria Mummert Consulting AG 2006); alternativ oder er-gänzend verhilft eine Stärken-Schwächen-Analyse (z. B. SWOT-Analyse) zu weiteren Einblicken. Auch andere Analysetechniken sind denkbar (Bea u. Haas 2001, S. 58). Insbesondere bei einer Vielzahl historisch gewachse-ner, heterogener analytischer Informationssysteme (häufig ein Auslöser zur Etablierung einer IL-Strategie) hilft eine systematische Erfassung, um etwaige Überschneidungen und Lücken in den drei genannten Dimensio-nen aufzudecken.

3.2 Strategische Zielplanung

Strategische Ziele werden in der Regel in einem mehrstufigen Verfahren entlang einer Zielhierarchie abgeleitet. Das im strategischen Management erprobte Verfahren, aus einer Vision zu einem Leitbild zu gelangen, das dann wiederum den Input für eine Top Down-Ableitung in einer Zielhie-rarchie darstellt, lässt sich gut auf die Informationslogistik übertragen. Ausgangspunkt ist die Vision mit der Formulierung einer Grundposition, die eine weit in die Zukunft gerichtete Orientierung markiert (Bea u. Haas 2001, S. 67); sie soll den Anspruch erfüllen, sinnstiftend, motivierend und handlungsleitend zu wirken (Müller-Stewens u. Lechner 2003, S. 235). Während die Vision häufig noch unternehmensweite Gültigkeit hat2, so wird diese in einer ersten Konkretisierung auf ein spezielles Leitbild (in 2 Heinrich und Bea sehen im Leitbild bereits eine Spezialisierung hinsichtlich des

Zielpublikums und / oder Einsatzzwecks (Bea u. Haas 2001; Heinrich 2002), wohingegen Müller-Stewens den unternehmensweiten Scope des Leitbilds be-tont (Müller-Stewens u. Lechner 2003).


diesem Fall für die Informationslogistk) bereits verfeinert. Das IL-Leitbild sollte demzufolge bereits Orientierungshilfe für die Ausgestaltung der In-formationslogistik bieten bzw. das Selbstverständnis der Informationslo-gistik im Unternehmen reflektieren. Laut Heinrich soll das Leitbild (präg-nante) Aussagen zu Ziel- und Zweckorientierung, Kunden- und Mitarbei-terorientierung, Datenschutz und -sicherheit sowie zu den angebotenen Leistungen beinhalten (Heinrich 2002, S. 101f.). Bezogen auf das im St. Galler Konzept der Informationslogistik verankerte Verständnis (vgl. Kap. 3) sollte ein IL-Leitbild die Grundidee der Schaffung von Synergien durch übergreifende Bereitstellung und Nutzung analytischer Informatio-nen einerseits und den umfassenden Ansatz andererseits zum Ausdruck bringen.

Leitbilder lassen sich bei weitem noch nicht operationalisieren, so dass eine weitere Konkretisierung entlang der Zielhierarchie notwendig wird. Im Kontext des strategischen Managements folgt man häufig einer Zielhie-rarchie, die neben den erwähnten Ebenen Vision und (Unterneh-mens)Leitbild noch unterscheidet in Unternehmens-, Geschäftsbereichs- und Funktionsbereichsziele (mit zunehmender Konkretisierung). Je nach Situation lässt sich diese Unterteilung für die Herleitung der Ziele der In-formationslogistik verwenden oder muss ggf. modifiziert werden. Letztlich wird durch wiederholte deduktive Zielauflösung ein Zielsystem abgeleitet, das den Handlungsspielraum für die nachfolgenden Schritte für die darin einzupassende IL-Strategie absteckt. Ein transparentes und abgestimmtes Vorgehen kann und sollte die Durchsetzung von Partikularsichten, die hin-sichtlich der Grundidee der Informationslogistik kontraproduktiv wirken würden, verhindern. Hingegen müssen die Ziele auf allen Ebenen mit den Unternehmenszielen bzw. mit den Zielen der unternehmensweiten IT kon-form gehen.

Werden die abgeleiteten Ziele noch in Kennzahlen konkretisiert und beispielsweise in Form einer Balanced Scorecard dargestellt, gewinnt man Messbarkeit und Transparenz. In einer Balanced Scorecard können zusätz-lich noch Abhängigkeiten zwischen den Zielen in einer so genannten Stra-tegy Map (Kaplan u. Norton 1992) erfasst werden.

3.3 Strategieentwicklung

Die einzelnen Aktivitäten dieser Phase lassen sich gut von Heinrichs Vor-gehensweise bei der Entwicklung einer IT-Strategie (Heinrich 2002, S. 109ff.) auf die Informationslogistik übertragen:

Generieren alternativer IL-Strategien


Evaluieren (beispielsweise mithilfe der Nutzwertanalyse und unter Be-achtung der jeweiligen Risiken) und Bestimmen der optimalen IL-Strategie

Abstimmen mit der Unternehmensstrategie Ableiten von Teilstrategien.

Im strategischen Management werden zahlreiche Strategiearten unter-schieden (wie etwa bei Bea u. Haas 2001, S. 164), deren Übertragung auf die Informationslogistik jedoch nur bedingt sinnvoll ist, da die angewand-ten Differenzierungskriterien auf die IL nicht zutreffen. Lohnenswerter scheint es, eine Systematisierung und Komplexitätsreduzierung mit der Auswahl und Ausgestaltung der Teilstrategien zu erreichen, wie sie etwa in Abschnitt 2 vorgeschlagen wurden. Ergänzend lässt sich Heinrichs Auf-listung der Inhalte einer IT-Strategie (Heinrich 2002, S. 113) als Checklis-te verwenden.

Hat man sich für eine Strategie (bzw. der Repräsentation in Teilstrate-gien), entschieden, gilt es in einem nächsten Schritt, zugehörige Maßnah-men abzuleiten und in einem IL-(Master)Plan anzuordnen (Heinrich 2002). Er enthält neben dem Katalog konzeptioneller Vorhaben auch Aussagen zum Projektportfolio, kritischen Ressourcen, Umsetzungsszenarien und ei-nen Umsetzungsplan.

3.4 Weitere Phasen

Auf die anschließenden Phasen der Umsetzung einer IL-Strategie bzw. der im vorangegangenen Schritt entwickelten Maßnahmen, idealerweise in Kombination mit Controlling-Aktivitäten, wird hier nicht näher eingegan-gen, da sie sehr situationsabhängig auszugestalten sind. Insgesamt sollte der oben vorgestellte Strategieentwicklungsprozess für die Informationslo-gistik als ein iteratives Vorhaben betrachtet wird, das wiederholt durchlau-fen wird aufgrund sich ändernder Rahmenbedingungen, steigender Reife der IL oder von Lerneffekten in der Organisation.

4 Zusammenfassung

Es wurde vielfach erkannt, dass eine BI/IL-Strategie nicht nur aus der Auswahl von Software, Plattformen und Architekturen besteht. Dennoch ist diese eingeschränkte Sichtweise in der Praxis durchaus noch zu finden, auch wenn sie viel zu kurz greift und den eigentlichen Zweck einer Strate-gie mit einem langfristigen und umfassenden Blickwinkel verfehlt. Bisher


sind noch kaum systematische und umfassende Vorgehensweisen zur Ge-staltung einer IL-Strategie zu finden, daher wird in diesem Kapitel eine Möglichkeit vorgestellt, mit Hilfe zweier Sichten (der Produkt- und der Prozesssicht) IL-Strategien zu entwickeln.

Nicht zuletzt angesichts der hohen Investitionsvolumina ist das Thema für die Praxis von hoher Relevanz – ganz abgesehen davon, welche strate-gischen Nachteile eine unzureichende Informationsversorgung im Unter-nehmen mit sich bringen kann. Dabei ist eine IL-Strategie keinesfalls sta-tisch, sondern analog zur Unternehmensstrategie kontinuierlich Verände-rungen und Anpassungen unterworfen. Damit die Strategie die aktuellen Bedürfnisse widerspiegelt, muss sie in regelmäßigen Zyklen überprüft und aktualisiert werden.

Kritisch ist dabei der Einbezug aller Stakeholder, zudem muss die Koordination mit anderen Strategien (auf der IT- und der Fachseite) si-chergestellt werden. Wolf weist darauf hin, dass eine sorgfältige Abstim-mung von Strategie und Organisationsstruktur von unvermindert hoher Re-levanz ist (Wolf 2004). Diese Beobachtung gilt auch in besonderem Maße für die Informationslogistik.

Literatur

Ansoff, I.: Corporate strategy: An analytical approach to business policy for growth and expansion, McGraw-Hill, New York 1965.

Bea, F. X.; Haas, J.: Strategisches Management, 3. Aufl., Lucius & Lucius, Stutt-gart 2001.

Chamoni, P.; Gluchowski, P.: Integrationstrends bei Business-Intelligence-Systemen - Empirische Untersuchung auf Basis des Business Intelligence Ma-turity Model, in: Wirtschaftsinformatik 46 (2004) 2, S. 119-128.

Dubs, R.; Euler, D.; Rüegg-Stürm, J.; Wyss, C.: Einführung in die Manage-mentlehre, Haupt, Bern et al. 2004.

Earl, M.: Management Strategies for Information Technology, Prentice Hall, New York et al. 1989.

Heinrich, L. J.: Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur, 7. Aufl., Oldenbourg, München, Wien 2002.

Henderson, J. C.; Venkatraman, N.: Strategic Alignment: Leveraging Information Technology for Transforming Organizations, in: IBM Systems Journal 32 (1993) 1, S. 4-16.

Hoffmann, O.: Performance Management - Systeme und Implementierungsan-sätze, 3. Aufl., Haupt, Bern et al. 2002.

Kaplan, R. S.; Norton, D. P.: The Balanced Scorecard - Measures that Drive Per-formance, in: Harvard Business Review 70 (1992) 1, S. 71-79.


Klesse, M.: Leistungsverrechnung im Data Warehousing - Entwicklung einer Methode, Dissertation, Universität St. Gallen, St. Gallen 2007.

Klesse, M.; Wilhelmi, C.: Ergebnisdokumentation 5. CC BPM Workshop, 2005. Mintzberg, H.: The Strategy Concept I: Five Ps For Strategy, in: California Man-

agement Review 30 (1987) 3, S. 11-24. Müller-Stewens, G.; Lechner, C.: Strategisches Management - Wie strategische

Initiativen zum Wandel führen, 2. Aufl., Schäffer-Poeschel, Stuttgart 2003. Steria Mummert Consulting AG: Business Intelligence-Studie 2006 - Wie gut sind

die BI-Lösungen der Unternehmen im deutschsprachigen Raum?, Steria Mummert Consulting AG, Düsseldorf 2006.

Supply Chain Council, I.: Supply Chain Operations Reference-model (SCOR) Version 8.0, Supply Chain Council Inc., Pittsburgh 2006.

Totok, A.: Entwicklung einer Business-Intelligence-Strategie, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 51-70.

Trost, U.; Zirkel, M.: Wege aus dem Informationschaos, in: BI-Spektrum 1 (2006) 3, S. 16-19.

Wolf, J.: Strategie und Organisationsstruktur, in: Schreyögg G. et al. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, 4. Aufl., Schäffer-Poeschel, Stuttgart 2004, S. 1374-1382.

Zarnekow, R.; Brenner, W.; Grohmann, H.: Informationsmanagement - Konzepte und Strategien für die Praxis, dpunkt.verlag, Heidelberg 2004.

Zarnekow, R.; Brenner, W.; Pilgram, U.: Integriertes Informationsmanagement, Springer, Berlin et al. 2005.

Zeid, A.: Your BI Competency Center: A Blueprint for Successful Deployment, in: Business Intelligence Journal 11 (2006) 3, S. 14-20.

5 Organisationsformen für die Informationslogistik

Mario Klesse, Moritz Schmaltz


1 Einleitung ......................................................................................... 772 Das Data Warehouse-Konzept .......................................................... 783 DWH-Leistungserbringertypen in der Praxis ................................... 824 Auswahl der geeigneten Organisationsform ..................................... 955 Zusammenfassung und Ausblick ...................................................... 96

Literatur ............................................................................................ 97

1 Einleitung

Seit seiner Etablierung in den späten 1980ern ist Data Warehousing in vie-len Unternehmen ein integraler Bestandteil der Informationslogistik (Win-ter 2000, vgl. auch Kap. 3). In der Vergangenheit konzentrierte sich die Forschung hauptsächlich auf Aspekte der Entwicklung und Einführung ei-nes Data Warehouse (DWH) (Meyer 2000, S. VII). Die nachhaltige orga-nisatorische Implementierung des Data-Warehousing-Prozesses rückt da-gegen erst seit kurzem in den Fokus der Betrachtungen. Bisherige Arbeiten zum Thema DWH-Organisation konzentrieren sich vorrangig auf struktu-relle Aspekte der Organisation, wie z. B. Projektmanagement, Entwick-lungsmethoden, Modellierungstechniken (Devlin 1997; Adelman u. Moss 2000; Inmon 2002; Kimball u. Ross 2002; Herrmann 2004; Strauch u. Winter 2004). Vorwiegend von Praktikern wurden Funktions- oder Rollen-modelle vorgestellt, die für das Data Warehousing langfristig organisato-risch zu implementieren sind (Kachur 2000; McKnight 2000; Winter u. Meyer 2001; Gallo 2002; Smith 2005). Für ausgewählte Aspekte des Data

78 Mario Klesse, Moritz Schmaltz

Warehousing wurden Referenzmodelle entwickelt, die Gestaltungsvor-schläge zur organisatorischen Implementierung wesentlicher Aufgaben des Data Warehousing liefern (Auth 2003; Herrmann 2006). In jüngster Zeit werden überdies Betreibermodelle diskutiert, welche sich mit dem Out-sourcing und Offshoring von DWH-Teilprozessen beschäftigen (Philippi 2004). Dabei wird jedoch vernachlässigt, dass in den Unternehmen bereits sehr unterschiedliche organisatorische Strukturen für das Data Warehou-sing implementiert oder gewachsen sind, in die sich derartige Gestaltungs-vorschläge einpassen lassen müssen. Kern der DWH-Organisation ist häu-fig eine spezielle Organisationseinheit, welche ausgewählte Kompetenzen für das Data Warehousing bündelt und diesen Prozess koordiniert (Meyer 2000, S. 147; Strange u. Dresner 2002a). Sie wird im Folgenden als DWH-Leistungserbringer bezeichnet. Über die Positionierung einer solchen Ein-heit existieren jedoch bisher kaum gesicherte Erkenntnisse. Dies verhindert die Entwicklung speziell auf existierende Organisationsformen ausgerich-teter Referenzmodelle und Methoden, was wiederum die Effektivität ihrer Anwendung in Frage stellt (Fiedler 1964).

In diesem Beitrag wird daher die organisatorische Realität des Data Warehousing beleuchtet, indem die Zusammenarbeit dieser Organisations-einheit mit Fachabteilungen, internen und externen IT-Dienstleistern un-tersucht wird. Basis ist eine empirische Studie mit 96 Unternehmen, die Data Warehousing betreiben. Für die strukturierte Erfassung der Positio-nierung der verschiedenen Einheiten im Data-Warehousing-Prozess wird dieser zunächst in Teilprozesse zerlegt (Abschn. 2). Die sich anschließende empirische Untersuchung extrahiert vier verschiedene Typen von DWH-Leistungserbringern (Abschn. 3). In Abschn. 4 wird die Auswahl der ge-eigneten Organisationsform erörtert, zum Abschluss werden Implikationen für die Praxis diskutiert (Abschn. 5).

2 Das Data Warehouse-Konzept

2.1 Data Warehousing als Basis der Informationslogistik

Die Informationslogistik (IL) beschäftigt sich mit der Bereitstellung von entscheidungsunterstützenden Datenflüssen über die Grenzen von Organi-sationseinheiten hinaus (vgl. Kap. 3). Das Data Warehouse ist in vielen Unternehmen das zentrale Informationssystem zur Umsetzung der Infor-mationslogistik. Innerhalb der Informationslogistik erfüllt das Data Ware-house die Funktion einer zentralen Integrationsinfrastruktur, die die Bereit-stellung von Datenflüssen zur Erfüllung von Informationsbedarfen innerhalb des Unternehmens ermöglicht. Die IL hat zwar einen weiteren

Organisationsformen für die Informationslogistik 79

Fokus als das Data Warehousing, der größeres Gewicht auf organisatori-sche und strategische Aspekte legt und der auch unternehmensübergrei-fende Datenflüsse umfasst, das Data Warehousing bildet jedoch in der Regel den Kern der Informationslogistik.

2.2 Data Warehouse-Informationssysteme

DWH-Informationssysteme versorgen Führungs- und Geschäftsprozesse mit entscheidungs- oder handlungsrelevanten Informationen. Sie folgen dazu im Regelfall einem weitgehend festen konzeptionellen Aufbau aus Datenquellen, DWH-Integrationsinfrastruktur und DWH-Applikationen (Hackney 2000; Hwang u. Cappel 2001; Ariyachandra u. Watson 2005; Humm u. Wietek 2005). Innerhalb dieser logischen Architektur werden Daten aus den Datenquellen über definierte Schnittstellen extrahiert. In ei-ner von allen DWH-Applikationen gemeinsam genutzten Schicht, der DWH-Integrationsinfrastruktur, werden diese gesammelt, konsolidiert und meist auch gespeichert. Diese Schicht enthält darüber hinaus weitere zen-trale Komponenten, wie Systeme zur Datenqualitätssicherung, für das Me-tadatenmanagement und zur Administration. Sie versorgt die DWH-Applikationen mit vereinheitlichten, qualitätsgesicherten Daten. Die DWH-Applikationen stellen den verwendungsspezifischen Teil des DWH-Informationssystems dar. In vielen Fällen enthalten sie für den jeweiligen Analysezweck speziell aufbereitete Daten (Data Marts) und stellen Analy-sefunktionalität (z. B. OLAP-Navigation, Data-Mining-Algorithmen) zur Verfügung. Darüber hinaus beliefert die DWH-Integrationsinfrastruktur häufig auch OLTP-Systeme mit Daten (Jung u. Winter 2000), welche je-doch nicht Bestandteil des DWH-Informationssystems sind. DWH-Informationssysteme laufen auf physischen DWH-Plattformen, welche Ba-sisdienste zur Speicherung, Verarbeitung und Übertragung von Daten an-bieten (technische Architektur).

2.3 Der Prozess Data Warehousing

Unter Data Warehousing wird die Gesamtheit von Prozessen und Syste-men zum Betrieb und Nutzung eines DWH-Informationssystems verstan-den (Jung u. Winter 2000; Klesse 2007). Die Prozesse umfassen die analy-tische Nutzung sowie Entwicklung, Betrieb und Support des DWH-Informationssystems (Wang et al. 1998; Winter 2000; Bauer u. Günzel 2004). Für die Zwecke der nachfolgenden Analysen werden diese Haupt-prozesse wie folgt detailliert (vgl. Abb. 1).


Nutzung: Das Data Warehouse kann auf verschiedene Art und Weise ge-nutzt werden. Ergebnis der Nutzung sind aufbereitete Informationen, die direkt in Führungs- und Geschäftsprozesse einfließen können. Damit erge-ben sich folgende Teilprozesse der Nutzung:

Durchführen von Standardauswertungen: Hierunter werden Abrufe vorgefertigter Berichte und eng eingegrenzte multidimensionale Analy-sen subsumiert. Standardanalysen sind durch einen breiten Empfänger-kreis und geringe Parametrisierbarkeit gekennzeichnet.

Durchführen von Sonderanalysen: Diese Nutzungsform ist durch ei-nen weitgehend freien Zugriff auf die Daten im Data Warehouse und durch die Verwendung komplexerer Analysemethoden gekennzeichnet. Hierfür sind sowohl tiefergehendes Wissen über Analysemethoden als auch detaillierte Kenntnisse über Inhalt und Bedeutung der Daten erfor-derlich.

Durchführen eines informationskonsumierenden Prozesses: Das DWH-Informationssystem versorgt Führungs- oder Geschäftsprozesse mit Informationen. Denkbar ist, dass ein DWH-Leistungserbringer auch einen Teil dieser Prozesse selbst erbringt. Beispielsweise könnte auch das Erstellen einer Marktanalyse oder eines Konzernabschlusses noch Bestandteil des DWH-Prozesses sein (z. B. o. V. 2004).

Entwicklung: Die Entwicklung des DWH-Informationssystems kann auf Teilentwicklungsprozesse seiner Komponenten heruntergebrochen werden. Entlang der DWH-Architektur ergeben sich nachfolgend aufgeführte Teil-prozesse:

Entwicklung von DWH-Applikationen: Dies umfasst die Erstellung und Pflege von Anwendungen und Data Marts von der Anforderungs-analyse bis zur Übergabe an den Betrieb.

Entwicklung der DWH-Integrationsinfrastruktur: Dies umfasst die Erstellung und Pflege der DWH-Integrationsinfrastruktur von der An-forderungsanalyse bis zur Übergabe an den Betrieb.

Auswahl, Einrichtung und Konfiguration von DWH-Plattformen: Das Pendant zur Entwicklung auf Informationssystemebene ist auf Ebe-ne der technischen Architektur die Einrichtung und Konfiguration von DWH-Plattformen.


Nutzung

Technischer Betrieb der

DWH-Plattform

Technischer Support der DWH-

Plattform

Fachlicher Betrieb der DWH-Integra-tionsinfrastruktur

Fachlicher Support der DWH-Integra-tionsinfrastruktur

Fachlicher Betrieb der DWH-

Applikationen

Fachlicher Support der DWH-

Applikationen

Entwicklung der DWH-

Applikationen

Entwicklung der DWH-Integrations-

infrastruktur

Auswahl und Einrichten der DWH-Plattform

Durchführen von Sonderanalysen

Durchführen von Standardauswertungen

Durchführen von informations-

konsumierenden Prozessen

DWH-Applikationen/

Data Marts

DWH-Integrations-infrastruktur

DWH-Plattform (Hardware, DBMS, etc.)

Komponente Prozess

komponentenspezifischer Prozess

Legende:

Entw

ickl

ung

Pro

dukt

ion

Abb. 1. Prozesse im Data Warehousing

Betrieb: Analog zur Entwicklung kann auch der Betrieb komponenten-orientiert in Teilbetriebsprozesse zerlegt werden:

Fachlicher Betrieb der DWH-Applikationen: Unter dem fachlichen Betrieb der DWH-Applikationen sind alle Tätigkeiten zu verstehen, die den Prozess der Informationsverteilung aus der DWH-Integrationsinfra-struktur in die DWH-Applikationen unterstützen.

Fachlicher Betrieb der DWH-Integrationsinfrastruktur: Unter dem fachlichen Betrieb der DWH-Integrationsinfrastruktur sind alle Tätig-keiten subsumiert, die der Unterstützung der Informationsintegration dienen.

Technischer Betrieb der DWH-Plattform: Um einen reibungslosen Betrieb des DWH-Informationssystems gewährleisten zu können, muss die technische Infrastruktur unterhalten und überwacht werden. Alle damit verbundenen Tätigkeiten werden als technischer Betrieb bezeich-net.


Support: Für den Support des DWH-Informationssystems lassen sich ent-lang der DWH-Architektur nachfolgend aufgeführte Teilprozesse unter-scheiden:

Fachlicher Support der DWH-Applikationen: Der fachliche Support der DWH-Applikationen adressiert vorwiegend die Endbenutzer des In-formationssystems.

Fachlicher Support der DWH-Integrationsinfrastruktur: Der fach-liche Support der DWH-Integrationsinfrastruktur bedient vorrangig de-ren direkte Datenabnehmer.

Technischer Support der DWH-Plattform: Der technische Support der DWH-Plattform bedient vor allem die Abnehmer der Plattformleis-tungen.

3 DWH-Leistungserbringertypen in der Praxis

3.1 Untersuchungsdesign

Die zuvor beschriebenen Teilprozesse zerlegen den Data-Warehousing-Prozess entlang der orthogonalen Dimensionen Funktion und Komponen-te: Zum einen wird eine Zerlegung in Entwicklung, Betrieb, Support und Nutzung vorgenommen, zum anderen eine Zerlegung entlang der Kompo-nenten DWH-Plattform, DWH-Integrationsinfrastruktur und DWH-App-likationen. Diese Teilprozesse können durch verschiedene Rollen im Un-ternehmen im unterschiedlichen Maße wahrgenommen werden. Grob unterschieden werden im Folgenden der DWH-Leistungserbringer, Fach-abteilungen, die interne IT des betreffenden Unternehmens sowie externe Dienstleister, die in den Prozess eingebunden sind.

Für die empirische Untersuchung wurde darauf aufbauend ein Fragebo-gen entwickelt, welcher die Tätigkeitsverteilung der vier Rollen an den zwölf Teilprozessen erfasst. Der Tätigkeitsanteil jeder Rolle am entspre-chenden Teilprozess kann darin prozentual angegeben werden. Die Be-zugsbasis bildet der anfallende Gesamtaufwand im jeweiligen Teilprozess.

Auf Basis der erhobenen Tätigkeitsanteile sollte eine explorative Analy-se Klarheit darüber verschaffen, ob (1) die Aufgabenverteilung vorrangig nach dem Objekt- oder dem Funktionsprinzip festgelegt wird und (2) ver-schiedene Typen von DWH-Leistungserbringern hinsichtlich der Aufga-benverteilung existieren.

Eine qualitative Untersuchung typischer Vertreter der identifizierten DWH-Leistungserbringertypen sollte anschließend aufzeigen, wie derarti-ge Organisationsformen in der Praxis implementiert sind, und einen wei-


tergehenden Einblick in Vor- und Nachteile der jeweiligen Organisations-form geben (Abschn. 3.4).

3.2 Datenerhebung und -selektion

Die schriftliche Befragung wurde auf dem 15. St. Galler Anwenderforum des Instituts für Wirtschaftsinformatik der Universität St. Gallen mithilfe eines Fragebogens durchgeführt. Die Tätigkeitsanteile konnten darin mit einer Genauigkeit von etwa 10% angegeben werden. Um das Verständnis der Fragen sicherzustellen, wurde der Erhebungsbogen zuvor von Testper-sonen aus der Praxis geprüft und auf der Veranstaltung kurz erläutert. An dem Forum zum Thema „Data Warehousing, Customer Relationship Ma-nagement und Business Performance Management – vom Business Case bis zur Umsetzung“ nahmen ca. 150 Fach- und Führungskräfte teil. 96 Fragebögen wurden ausgefüllt retourniert. Dies entspricht einer Rücklauf-quote von ca. 61%.

Bei den Befragten handelt es sich um Mitarbeiter aus Unternehmen der Schweiz, Deutschlands und Österreichs, wobei Großunternehmen, insbe-sondere Banken am stärksten vertreten waren. Etwas mehr als die Hälfte der Befragten (53%) arbeiten in einer DWH-Abteilung. Etwa 20 Prozent der Umfrageteilnehmer sind in einer höheren Management-Position, 12 Prozent in einer Fachabteilung und 8% in einer sonstigen IT-Abteilung be-schäftigt. Data Warehousing und Business Intelligence sind etablierte Themen in den Unternehmen: Fast ein Viertel der befragten Unternehmen betreibt seit mehr als 10 Jahren Data Warehousing. Ungefähr die Hälfte der Befragten beschäftigt sich seit mehr als 5 Jahren mit dem Thema. Zwei Drittel der befragten Unternehmen unterhalten eine dedizierte DWH-Or-ganisationseinheit, 23% mehrere. Damit kann die Zentralisierung von DWH-Know-how in einer speziellen Organisationseinheit als gängige Pra-xis angesehen werden, die von fast 90% der befragten Unternehmen prak-tiziert wird. Die DWH-Organisationseinheit umfasst in ca. der Hälfte der Fälle bis zu 19 Mitarbeiter. Mehrere Einheiten werden häufig dann unter-halten, wenn die Anzahl der Mitarbeiter der Abteilung die Grenze von 20 überschreiten würde.

Da der DWH-Leistungserbringer im Mittelpunkt der Untersuchung steht, wurden für die folgenden Analysen lediglich jene Fälle selektiert, welche eine DWH-Abteilung mit mindestens einem Mitarbeiter haben und bei welchen vollständige Angaben zu den durchgeführten Aufgaben vor-handen waren. Insgesamt wurden 68 Datensätze in die Analyse aufge-nommen.


3.3 Auswertung

Die Auswertung der Daten zeigte, dass sich die abgefragten Teilprozesse des Data Warehousing zu drei Faktoren zusammenfassen lassen:1

Tätigkeitsanteil an der DWH-Informationssystembetreuung: Der erste Faktor fasst die Tätigkeitsanteile der Entwicklung, des fachlichen Betriebs und des fachlichen Supports von DWH-Integrationsinfrastruk-tur und der DWH-Applikationen zusammen.

Tätigkeitsanteil an der DWH-Plattformbetreuung: Der zweite Fak-tor beinhaltet im Wesentlichen die Auswahl, Einrichtung und Konfigu-ration sowie den technischen Betrieb und Support der DWH-Plattform.

Tätigkeitsanteil an der DWH-Nutzung: Der dritte Faktor fasst die verschiedenen Arten der Nutzung zusammen, d. h. die analyseintensiven Prozesse sowie das Durchführen von Standard- und Sonderauswertun-gen.

Die Extraktion dieser Faktoren legt den Schluss nahe, dass nicht die funktionale Prozesszerlegung die verschiedenen DWH-Leistungserbringer unterscheidet, sondern die Positionierung entlang der Komponenten des DWH-Informationssystems. Das bedeutet, dass sich DWH-Leistungser-bringer danach unterscheiden, welche Tätigkeitsanteile sie an der DWH-Informationssystembetreuung, an der DWH-Plattformbetreuung und an der DWH-Nutzung einnehmen.

Auffällig ist zudem die Zusammenfassung der Tätigkeitsanteile von DWH-Applikationen und DWH-Integrationsinfrastruktur in einen einzigen Faktor. Eine Korrelationsanalyse auf den Tätigkeitsanteilen an der Ent-wicklung, dem Betrieb und dem Support von DWH-Integrationsinfrastruk-tur und DWH-Applikationen verdeutlicht die Ursache hierfür: Die Tätig-keitsanteile aller genannten Teilprozesse weisen starke, signifikante Kor-relationen auf. Das bedeutet, dass DWH-Leistungserbringer im Regelfall die Verantwortung für Entwicklung, Betrieb und Support beider Teilkom-ponenten des DWH-Informationssystems integriert wahrnehmen.

Anschließend wurde auf den extrahierten Faktoren eine Clusteranalyse durchgeführt, um verschiedene Typen von DWH-Leistungserbringern zu

1 Um ein besseres Verständnis über die Daten zu erhalten, wurde eine explorative

Faktoranalyse durchgeführt. Sie dient dazu, aus den Tätigkeitsanteilen der zwölf abgefragten Teilprozesse voneinander unabhängige Faktoren zu extrahieren, welche den Datensatz beschreiben. Die Faktoranalyse reduziert die 12 Messva-riablen auf die 3 beschriebenen Faktoren.


identifizieren.2 Dabei wurden 4 Cluster gebildet, die die Basis der folgen-den Ausführungen bilden. Um die praktische Ausgestaltung der ermittelten Leistungserbringer-Typen zu konkretisieren, wurde zusätzlich im Rahmen von ergänzenden Experteninterviews die Umsetzung der Typen in bei-spielhaften Unternehmen erhoben.

3.4 Typen von DWH-Leistungserbringern

Die untersuchten Leistungserbringer lassen sich demzufolge in vier ver-schiedene Typen gruppieren, die anhand der oben beschriebenen drei Tä-tigkeitsanteile beschrieben werden können. Die Leistungserbringer-Typen und ihre Tätigkeitsanteile sind in Abb. 2 überblicksartig dargestellt.

Interpretierend lassen sich die vier Leistungserbringertypen in ein Koor-dinatensystem mit den Dimensionen „Geschäftsnähe“ und „Fertigungstie-fe“ einordnen (vgl. Abb. 2). Die Geschäftsnähe ist durch den Tätigkeitsan-teil im Nutzungsprozess determiniert. Je mehr Aufgaben die DWH-Abteilung im Nutzungsprozess wahrnimmt, desto fachnäher ist sie ausge-richtet. Die Fertigungstiefe lässt sich anhand der Tätigkeitsanteile in der Informationssystem- und Plattformbetreuung charakterisieren. Eine hohe Fertigungstiefe bedeutet, dass der DWH-Leistungserbringer einen relativ hohen Tätigkeitsanteil an der Plattformbetreuung wahrnimmt.

2 Als Clusteralgorithmus wurde der K-Means-Algorithmus von SPSS 12 verwen-

det. Dabei handelt es sich um ein partitionierendes Verfahren, welches die Clus-teranzahl als Eingabewert benötigt. Als Distanzmaß diente die euklidische Dis-tanz. Die Startpartitionen wurden zufällig festgelegt. Um die optimale Anzahl von Clustern festzulegen, wurden mehrere Clusteranalysen mit einer Anzahl von 2 bis 9 Clustern durchgeführt. Die Obergrenze 9 wurde aus Gründen der Repräsentativität der Cluster gewählt: Bei 68 Datensätzen ist es bei mehr als 9 Clustern sehr unwahrscheinlich, dass noch repräsentative Klassifikationen ent-stehen. Für jede Lösung wurde anschließend die Fehlersumme errechnet, die sich aus den Distanzen aller Fälle zu ihren Clusterzentren ergibt. Auf Basis die-ser Fehlersumme wurde das Ellbow-Kriterium verwendet (Deimer 1986, S. 76). Dieses legt nahe, diejenige Lösung zu bevorzugen, bis zu welcher eine erhöhte Clusteranzahl eine überdurchschnittliche Verbesserung der Fehlersumme be-wirkt. Ellbows traten im vorliegenden Datensatz bei 2, 4 und 7 Clustern auf. Da die Lösung mit 2 Clustern keine ausreichende Differenzierung der Leistungserb-ringer ergibt und bei der 7-Cluster-Lösung einzelne Cluster zu klein sind, wurde eine Clusterzahl von 4 als optimale Lösung ausgewählt.


Abb. 2. DWH-Leistungserbringertypen

In den folgenden Abschnitten sind die einzelnen Leistungserbringerty-pen jeweils im Detail mit beispielhaften Kunden-Lieferantenbeziehungen dargestellt. In der Praxis sind selbstverständlich auch Mischformen zwi-schen den Typen anzutreffen, die hier dargestellten Ausprägungen sind le-diglich als typische Beispiele zu betrachten.

3.4.1 Full Service Provider (DWH-FSP)

Dieser Typ Leistungserbringer ist relativ stark in den Nutzungsprozess in-volviert: Sein Aufgabenanteil am Nutzungsprozess beträgt 50%, d. h. er übernimmt ca. die Hälfte aller darin anfallenden Tätigkeiten, während die andere Hälfte von den Fachabteilungen übernommen wird. Das Leistungs-spektrum des DWH-FSP im Nutzungsbereich umfasst typischerweise die Bereitstellung vordefinierter, standardisierter Analysen sowie die Durch-führung von kundenspezifischen Reports und individuellen Sonderanaly-sen. Ebenso wirkt er stark an allen DWH-Informationssystembezogenen Aufgaben mit (Aufgabenanteil 60%, verbleibende 40% werden von der internen IT, Externen oder der Fachabteilung erbracht). Auch die Plattform wird von diesem Typ betreut (Aufgabenanteil 70%, verbleibende 30% werden von der internen IT oder Externen erbracht). Damit ist der Full Service Provider ein DWH-Leistungserbringer, der die Aufgaben des DWH-Prozesses vorwiegend selbst wahrnimmt und das Geschäft mit Ana-lyseergebnissen unterstützt. Dennoch wird das bereitgestellte DWH-Informationssystem auch selbständig von Fachabteilungen genutzt.


Leistungsabnehmer

DWH-Leistungserbringer

Fachabteilungen

Nutzung des DWHDurchführung von Geschäfts- und FührungsprozessenDurchführung von Standardauswertungen

Erweiterungen der DWH-Services

Betrieb der DWH-Services

DWH-InformationssystemDWH-Plattform

Lieferung von Analyse-ergebnissen

DWH Full Service Provider (DWH-FSP)

Planung/Entwicklung der DWH-PlattformKonfiguration der DWH-PlattformWartung der DWH-Platform

Betrieb der DWH PlattformBetrieb der PlattformRoutinebetrieb von Ladeprozessen

Support der DWH PlatformLösung technischer Probleme

Planung/Entwicklung des DWH-ISProjektmanagementProdukt- und ArchitekturmanagementEntwicklung von DWH-Applikationen und Erweiterungen der Integrationsinfrastruktur

Betrieb des DWH-ISProblembehebungDatenqualitätsmanagementReferenzdatenmanagementMetadatenmanagement

Support des DWH-ISBenutzeradministrationEndbenutzerunterstützungDurchführen von Sonderanalysen

...Legende: Komponente, betreut durch Einheit

Komponente, verantwortet durch EinheitAbb. 3. Kunden-Lieferanten-Beziehungen eines Full Service Providers

In Abb. 3 sind die Kunden-Lieferanten-Beziehungen eines DWH-FSP beispielhaft dargestellt. Die Abbildung zeigt die Aufgabenverteilung zwi-schen dem DWH-Leistungserbringer (d. h. dem DWH-FSP) und dem Leis-tungsabnehmer (d. h. den Fachabteilungen) und die Verantwortlichkeit für die Informationssysteme, die hier beim DWH-FSP liegt. Der DWH-FSP deckt den Prozess des Data Warehousing fachnah und in voller Tiefe ab. Kernkompetenzen eines Full Service Providers sind demzufolge umfang-reiches Wissen über DWH-Plattformen, über DWH-Informationssysteme als auch über verschiedene Auswertungsmethoden im Data Warehousing.


Diese Vielzahl von Kompetenzen lässt sich nur abdecken, wenn wie im vorliegenden Fall die Anwendungen homogen und standardisierbar sind. Damit eignet sich dieses Modell vorrangig für ausgelagerte IT-Abteilungen bzw. für Nutzerorganisationen, denen eigene Kompetenzen und Ressourcen für das Data Warehousing fehlen und bei denen gleichzei-tig nur ein geringer Bedarf nach stark individualisierten Auswertungen be-steht. Herausforderungen ergeben sich für den Full Service Provider vor allem im Management der Datenquellen, wenn diese nicht von der glei-chen Organisation gemanagt werden, der der DWH-Leistungserbringer un-terstellt ist.

3.4.2 Business Service Provider (DWH-BSP)

Dieser Typ Leistungserbringer ist sehr stark in den Nutzungsprozess in-volviert oder führt ihn selbst durch (Aufgabenanteil 60%). Das Leistungs-angebot umfasst die Bereitstellung von Standardauswertungen und die Ers-tellung von kundenspezifischen Analysen, Berichten und Auswertungen. Diese starke Konzentration auf fachliche Leistungen führt offenbar dazu, dass die DWH-Informationssystembezogenen Aufgaben nur noch zum Teil wahrgenommen werden (Aufgabenanteil 40%). Hier erfolgt dann eine Aufgabenteilung mit der internen IT oder mit externen Dienstleistern, wo-bei der DWH-BSP sich auf die fachliche Koordination und Steuerung der Weiterentwicklung konzentriert. Plattformbezogene Aufgaben werden nur noch in geringem Umfang unterstützt (Aufgabenanteil 20%), sie werden primär von externen IT-Dienstleistern übernommen. Der DWH-BSP arbei-tet somit sehr fachnah und ist in die Geschäftsprozesse der Unternehmen als Informationsversorgungsstelle integriert. Abbildung 4 zeigt beispielhaft die Aufgabenverteilung für einen DWH-BSP. Für die Plattformbetreuung und die Implementierung sind externe Dienstleister verantwortlich. Die Aufgaben des DWH-BSP gliedern sich in eine technische und eine fachli-che Seite, während die Leistungsabnehmer selber nicht direkt die analyti-schen Systeme nutzen.

Diese Organisationsform scheint vor allem dann geeignet, wenn häufig stark verschiedene Analysen angefordert werden, die erhebliches methodi-sches Know-how benötigen (z. B. Kundensegmentierung mittels Data Mi-ning). Ein weiteres Argument für diesen Typ Leistungserbringer ist die Tatsache, dass in den Fachbereichen selbst nur geringe Kompetenzen der Datenanalyse bestehen, jedoch ein breiter Bedarf nach Auswertungen und Analysen besteht. Ein Business Service Provider hat darüber hinaus eine geringe Fertigungstiefe am DWH-Informationssystem.


Externe Service Provider

Leistungsabnehmer


Dienstleister Plattformen

Betrieb der DWH-PlattformRoutinebetrieb der Ladeprozesse

Dienstleister Implementierung

Implementierung spezifizierter DWH-Softwaremodule

DWH Business Service Provider (DWH-BSP)

Fachabteilung

Nutzung DWHDurchführung von Geschäfts- und FührungsprozessenKeine direkte Nutzung des DWH-Informationssystems

DWH-Plattform

Implemen-tierte DWH-Software-module

Betreute DWH-Plattform

Reports, Markt-analysen, Kunden-profile, etc.

DWH-ISDWH-IS

Planung DWH-ISProjektmanagementDWH-Programm- u. Architekturmana-gement

Nutzung DWHDurchführung von Standard-auswertungenDurchführung von Sonderanalysen

Entwicklung DWH-ISFachkonzeption von DWH-Applikationen u. Erweiterungen an der Integrationsinfra-struktur

Betrieb DWH-ISProblembehebungDatenqualitätsmgmt.Stammdatenmgmt.Metadatenmgmt.

Support DWH-ISUnterstützung der Fachanwender im DWH-BSP

Analyse-aufträge


Komponente, verantwortet durch EinheitAbb. 4. Kunden-Lieferanten-Beziehungen eines Business Service Providers

Die Organisationsform eignet sich damit wie das DWH-CC bei begrenz-ten Kompetenzen und Ressourcen an DWH-Fachkräften. Um das Data Warehouse vom Zulieferer jedoch zuverlässig betreiben lassen zu können, ist ein hoher Automatisierungsgrad der Datenbewirtschaftungsprozesse nö-tig. Eine derartige Organisationsform birgt zudem mehrere Gefahren: Zum einen ist das interne Wissen über Prozesse des Data Warehousing mitunter


sehr gering, so dass eine hohe Abhängigkeit vom Zulieferer besteht. Zum anderen kann die Unterstellung unter einen Fachbereich auf Grund einer mangelnden gesamtbetrieblichen Koordination zu einer konzernweit stark zersplitterten DWH-Landschaft mit inkonsistenten Daten führen.

3.4.3 DWH Platform Provider (DWH-PP)

Bei diesem Typ Leistungserbringer liegt im Gegensatz zum Business Ser-vice Provider der Fokus auf dem DWH-Informationssystem (Aufgabenan-teil 50%) und der Plattform (Aufgabenanteil 60%). In diesen Bereichen liegt die Kernkompetenz des DWH-PP, dessen Aufgaben das Entwerfen, Implementieren und Erweitern eines integrierten Data Warehouse und von DWH-Applikationen umfassen sowie den fachlichen Betrieb, wie Daten-qualitätssicherung, Metadatenpflege, Referenzdatenpflege, Nutzeradmi-nistration und den fachlichen Support. Der Nutzungsprozess wird lediglich unterstützt (Aufgabenanteil 30%). Die Nutzung erfolgt schwerpunktmäßig durch die Fachbereiche. Speziell ausgebildete Power User in den Fachbe-reichen übernehmen die Erstellung von Standardreports und Sonderanaly-sen, wobei der DWH-PP in techniknahen Bereichen Unterstützung leistet.

Die Kunden-Lieferanten-Beziehungen eines DWH-PP sind in Abb. 5 exemplarisch dargestellt. Der (externe oder interne) Service Provider über-nimmt hier nur den Routinebetrieb. Die Planung und Implementierung er-folgt beim DWH-PP, ebenso wie fachlicher und technischer Support. Die Nutzung erfolgt hingegen durch die Fachabteilungen.

Kernkompetenzen eines DWH-PPs sind demzufolge nicht nur die Ko-ordination des Data Warehousing im Unternehmen (vgl. auch Ab-schn. 3.4.4), sondern zusätzlich die Entwicklung und Anpassung einer spe-ziellen DWH-Plattform. Dieser Typ Leistungserbringer eignet sich daher dann, wenn genügend internes IT-Wissen verfügbar ist, um eine eigene Kompetenz für DWH-Plattformen aufbauen zu können. Die Dezentralisie-rung der Nutzungsprozesse bietet sich insbesondere dann an, wenn Analy-sen weniger methodisches Wissen als vielmehr fachliches Wissen benöti-gen, das in den Fachbereichen vorhanden ist (end user computing). Bei einem geringen Involvement in die Nutzung des Data Warehouse kann problematisch werden, dass die Mitarbeiter der DWH-Abteilung die Da-teninhalte des Data Warehouse nur ungenau kennen. Damit besteht die Ge-fahr, dass sich langfristig die Datenqualität verschlechtert und dass das Verständnis für die fachlichen Anforderungen der Nutzer sinkt.


IT-Betriebsabteilung

Betrieb der DWH-Plattform Routinebetrieb und Überwachung von Ladeprozessen

DWH Platform Provider (DWH-PP)

Planung/Entwicklung des DWHProjektmanagement DWH-Programm- & Architektur-managementEntwicklung von DWH-Applikationen und DWH-Erweiterungen

Planung/Entwicklung der DWH-PlattformKonfiguration der DWH-PlattformWartung der DWH-Plattform

Betrieb des DWHProblembehebungDatenqualitätsmanagementReferenzdatenmanagementMetadatenmanagement

Support des DWHBenutzeradministrationEndbenutzerbetreuung

Service Provider

Leistungsabnehmer


Fachabteilungen

Nutzung des DWHDurchführung von Führungs- und GeschäftsprozessenDurchführung von StandardauswertungenDurchführung von Sonderauswertungen durch „Power User“

Konfigurierte DWH-Plattform

Implementierte DWH-Software-Module

DWH-Plattform-Betrieb

Erweiterung der DWH-Services


DWH-PlattformDWH-IS

DWH-Plattform

DWH-Applikationen


Komponente, verantwortet durch EinheitAbb. 5. Kunden-Lieferanten-Beziehungen eines DWH Platform Providers

3.4.4 DWH Competence Center (DWH-CC)

Das DWH Competence Center ist der am häufigsten vorkommende Typ Leistungserbringer. Ähnlich wie der DWH Platform Provider ist dieser Typ lediglich unterstützend am Nutzungsprozess beteiligt (Aufgabenanteil 30%). Jedoch auch in Bezug auf das DWH-Informationssystem (Aufga-


benanteil 40%) und die Plattform (Aufgabenanteil 30%) werden nicht alle Aufgaben allein wahrgenommen. Vielmehr werden diese Leistungen in Zusammenarbeit mit anderen IT-Abteilungen oder Externen erbracht, die die Implementierung und den Betrieb schwerpunktmäßig übernehmen (vgl. Abb. 6).

Das Leistungsspektrum des DWH-CC umfasst damit typischerweise die Planung, die Entwicklung und den Betrieb der DWH-Anwendungen. Die Aufgabenschwerpunkte umfassen z. B. Programm- und Architekturmana-gement für die DWH-Landschaft, Anforderungsmanagement für die DWH-Systeme, Projektmanagement für die Umsetzung von Anforderun-gen, Fachkonzeption sowie Test und Abnahme von neuen DWH-Applika-tionen sowie der dazu nötigen Komponenten der DWH-Integrationsinfra-struktur, fachlichen Betrieb des DWH-Informationssystems, insbesondere die Qualitätssicherung von Daten und Analysefunktionen, Referenzdaten-pflege und Metadatenpflege, Anwendersupport und Analyseunterstützung sowie die Gewährleistung von Datensicherheit und Datenschutz.

Während die Nutzung primär durch die Fachbereiche erfolgt, kann das DWH-CC unterstützend tätig werden, falls im Rahmen von Sonderanaly-sen spezielles Know-how benötigt wird.

Die Kernkompetenz eines DWH-CC ist die Begleitung und Koordinie-rung des gesamten DWH-Prozesses mit zahlreichen Zulieferern. Wichtig ist dabei vor allem, dass für jede zugelieferte Leistungsart genügend Kom-petenzen im DWH-CC vorhanden bleiben, um Leistungsmengen planen und die Qualität der zugelieferten Leistungen beurteilen zu können. He-rausforderungen ergeben sich vor allem in der Zusammenführung aller Teilleistungen zu hochqualitativen Informationsprodukten für die Infor-mationskonsumenten. Diese Organisationsform wird mitunter als „opti-mal“ für das Data Warehousing dargestellt (Strange u. Dresner 2002b). Ihr Vorteil liegt vor allem darin, dass mit einer verhältnismäßig geringen An-zahl von internen Mitarbeitern die Ziele des Data Warehousing verfolgt werden können. Die Teile der Kernprozesse, die Kenntnisse über den In-halt des Data Warehousing benötigen, wie z. B. fachliche Planung und Entwicklung, Datenqualitätssicherung, Metadatenmanagement und End-benutzerbetreuung werden daher intern ausgeführt, während Commodities wie Programmierungsarbeiten und Routinebetrieb ausgelagert werden. Auffällig ist auch die starke Dezentralisierung der Nutzungsprozesse. Dies ist dann erstrebenswert, wenn für die Analysen vorrangig fachliches Wis-sen benötigt wird und zahlreiche, verschiedene Fachbereiche bedient wer-den. Gleichzeitig sollten die Nutzerkreise in den betreffenden Fachberei-chen groß genug sein, um dort den Aufbau von Analysekompetenz unter Wirtschaftlichkeitsgesichtspunkten rechtfertigen zu können.


Externe Zulieferer

Leistungsabnehmer


Dienstleister Platformen

Betrieb und Support der DWH-Plattform Routinebetrieb der Ladeprozesse und Überwachung des Ladevorgangs

Dienstleister Implementierung

Implementierung spezifizierter DWH-Software-Module

DWH Competence Center (DWH-CC)

Fachl. Planung/Entwicklung des DWH-ISProjekt- und LieferantenmanagementDWH-Programm- und Architektur-managementFachkonzeption von DWH-Applikationen und nötigen Erweiterungen der DWH-Integationsinfrastruktur

Fachl. Betrieb des DWH-ISProblembehebungDatenqualitätsmanagementReferenzdatenmanagementMetadatenmanagement

Fachlicher Support des DWH-ISEndbenutzeradministrationEndbenutzersupportErstellen von „Quick Solutions“

Fachabteilungen

Nutzung des DWHNutzung in Führungs- und GeschäftsprozessenStandardauswertungenSonderanalysen, durchgeführt durch speziell ausgebildete Endbenutzereinheiten

DWH-InformationssystemDWH-Plattform

Implementierte Software-Module

Betreute DWH-Plattform


Komponente, verantwortet durch Einheit

Erweiterung der DWH-Services


Abb. 6. Kunden-Lieferanten-Beziehungen eines DWH Competence Centers

3.5 Zusammenfassung

Tabelle 2 fasst die Einsatzszenarien sowie die beschriebenen Herausforde-rungen der verschiedenen Organisationsformen zusammen. Es wird deut-lich, dass die verschiedenen DWH-Leistungserbringertypen sowohl für un-


terschiedliche Einsatzszenarien geeignet sind als auch unterschiedliche He-rausforderungen angehen müssen.

Tabelle 2. Einsatzszenarien und Herausforderungen für die DWH-Leistungs-erbringertypen

DWH-FSP DWH-BSP DWH-PP DWH-CC Einsatzszenarien Organisatori-sche Zuordnung

Eigenständiger Dienstleister

Geschäftsbe-reichsleitung

IT-Führung IT-Führung

Erforderliche Nutzerkom-petenz Analy-semethoden

gering gering hoch hoch

Analysepro-zesse (fach-lich Anwen-dung)

standardisierbar (sonst nicht handhabbar)

standardisierbar – individuell, je nach organisato-rischer Zuordnung

individuell (benötigt ge-schulte Nutzer)

individuell (benötigt ge-schulte Nutzer)

Vorhandene DWH-Kompeten-zen, IS-Ebene

hoch mittel mittel-hoch mittel

Vorhandene DWH-Kom-petenzen, Plattformen

hoch gering mittel-hoch gering

Herausforderungen Nutzerunter-stützung und DWH-Support

Aufbau und Er-halt fachlicher Kenntnisse über unterstützte Pro-zesse und Ana-lysemethoden

Aufbau und Er-halt fachlicher Kenntnisse über unterstützte Pro-zesse und Ana-lysemethoden

Förderung des End User Computing / Schulung der Nutzer

Förderung des End User Computing / Schulung der Nutzer

DWH-Entwicklung

Standardisie-rung von Applikationen

Exakte, umsetz-bare Formulie-rung von Anfor-derungen für die Umsetzung, Vermeidung unkoordinierter DWH-Land-schaften

Verständnis der fachlichen Anforderungen

Verständnis der fachlichen Anforderungen, Koordination der Imple-mentierungs-zulieferer, Bedarfsplanung


DWH-FSP DWH-BSP DWH-PP DWH-CC DWH-Betrieb Abstimmung der

Zulieferer von extern gelager-ten Daten

Abstimmung der Zulieferer von Daten und Platt-formleistungen, Kapazitäts-bedarfsplanung

Abstimmung der Zulieferer von Daten, Datenqualität

Abstimmung der Zulieferer von Daten, Imple-mentierungs- und Plattform-leistungen, Kapazitäts-bedarfsplanung, Datenqualität

DWH-Plattform-entwicklung / -betrieb

Technologiema-nagement, Ka-pazitätsplanung

Grundlegendes Verständnis der Technologien behalten

Technologie-management, Kapazitätspla-nung

Grundlegendes Verständnis der Technologien behalten

4 Auswahl der geeigneten Organisationsform

Die Auswahl der geeigneten Organisationsform für die Informationslogis-tik hängt im Wesentlichen von der gewählten IT-Strategie und von der Or-ganisation des Unternehmens ab.

Von den in Kap. 4 dargestellten Teilstrategien für die Informationslogis-tik haben insbesondere die Sourcing-Strategie und die Portfoliostrategie Einfluss auf die Wahl der Organisationsform und damit den geeignetsten Leistungserbringertypen. Die in diesem Beitrag vorgestellten Organisati-onsformen unterscheiden sich in den Dimensionen Geschäftsnähe und Fer-tigungstiefe DWH-Informationssystem (vgl. Abb. 2). Dabei beeinflussen die in der Sourcing-Strategie festgelegten Sourcing-Ziele die Wahl der Or-ganisationsform in der Dimension Fertigungstiefe: Falls eine geringe Fer-tigungstiefe angestrebt wird, empfehlen sich die Organisationsformen DWH Competence Center und DWH Business Service Provider, anderen-falls sind der DWH Full Service Provider bzw. der DWH Platform Provi-der die angemesseneren Organisationsformen. Die Tatsache, dass das DWH Competence Center die verbreitetste Organisationsform ist, zeigt, dass tendenziell geringere Fertigungstiefen bevorzugt werden. Die ist auf Grund der zunehmenden Reife der eingesetzten Technologien auch nicht verwunderlich – je mehr die Basistechnologien reifen, desto weniger bie-ten sie die Möglichkeit zur Differenzierung und zur Schaffung von lang-fristigen Wettbewerbsvorteilen. Daher kann es sinnvoll sein, die technolo-gische Seite der Informationslogistik nicht mehr im Unternehmen bereitzustellen, sondern von einem Outsourcing-Partner extern zu beziehen (Quinn u. Hilmer 1994).


Analog beeinflusst die Portfolio-Strategie die Wahl der Organisations-form in der Dimension Geschäftsnähe: Falls das Produktportfolio einen großen Anteil an fachnahen analytischen Dienstleistungen wie Sonderana-lysen oder Data Mining vorsieht, ist eine entsprechende Organisationsform wie der Business Service Provider bzw. der Full Service Provider sinnvoll. Andererseits ist dort, wo die Analysekompetenz primär bei den Leistungs-abnehmern (d. h. in den Fachabteilungen) liegt, das DWH Competence Center bzw. der DWH Platform Provider die sinnvollste Organisations-form.

Ziel der Informationslogistik ist es, unternehmensweit übergreifende Datenflüsse zur Befriedigung von Informationsbedarfen zur Verfügung zu stellen (vgl. Kap. 3). Dieser übergreifende Charakter erfordert eine Veran-kerung der Informationslogistik auf Konzernebene im Rahmen einer zen-tralen IT-Funktion. Allerdings ist gerade in großen, divisionalisierten Un-ternehmen in der Praxis oft eine Vielzahl von lokal gewachsenen, dezentralisierten IL-Initiativen anzutreffen, deren Zentralisierung weder organisatorisch noch wirtschaftlich sinnvoll scheint. In solchen Konstella-tionen ist denkbar, dass mehrere der beschriebenen Leistungserbringerty-pen bewusst kombiniert werden. Fachbereichbezogene Business Service Provider könnten durch ein zentrales DWH-CC der IT unterstützt werden (Meyer 2000; Burton et al. 2006). Auf diese Weise ließen sich sowohl Synergieeffekte durch die gebündelte Nutzung des Data Warehouse erzie-len, als auch eine effiziente Informationssystementwicklung und ein wirt-schaftlicher fachlicher Betrieb des Data Warehouse sicherstellen (Burton et al. 2006). Diese Konstellation wird durch die Entwicklung unterstützt, dass in Anwenderunternehmen Kompetenzzentren und Infrastrukturservi-ces in organisatorischen Einheiten gebündelt werden, die sich zunehmend spezialisieren (Weill u. Vitale 2002).


Aufbauend auf den leistungserstellenden Prozessen im Data Warehousing und den verschiedenen Komponenten des DWH-Informationssystems wurde explorativ untersucht, welche Tätigkeiten DWH-Abteilungen in der Unternehmenspraxis wahrnehmen. Es konnten vier verschiedene Leis-tungserbringertypen identifiziert werden, die sich hinsichtlich ihres Invol-vierungsgrads im Nutzungsprozess und hinsichtlich der Fertigungstiefe aus Informationsmanagementsicht unterscheiden.

Für die Praxis bietet die Klassifikation einen Orientierungsrahmen zur Organisation des Data Warehousing. In der Gründungsphase eines DWH-


Leistungserbringers lässt sich beobachten, dass vorhandene Kompetenzen eher willkürlich zu einer Abteilung gebündelt werden. Die Klassifikation zeigt dagegen die Möglichkeit, eine bewusste Positionierung der DWH-Abteilung auf Basis von vorhandenen DWH-Kompetenzen und der ange-strebten Unterstützung des Nutzungsprozesses vorzunehmen. Vor dem Hintergrund der zunehmenden Industrialisierung von IT-Services (Zarne-kow et al. 2005) kann beispielsweise die Empfehlung ausgesprochen wer-den, dass im Kontext von Anwenderunternehmen neu zu etablierende DWH-Leistungserbringer bewusst mit einer geringen Fertigungstiefe auf-gestellt werden. Die Existenz von zwei DWH-Leistungserbringertypen mit bereits stark reduzierter Fertigungstiefe zeigt deutlich die praktische Um-setzbarkeit einer Konstellation, bei der fachliche DWH-Kompetenzen in-tern im Unternehmen gebündelt werden, während standardisierbare Leis-tungen wie der Unterhalt einer DWH-Plattform oder die Implementierung von fachlich spezifizierten IS-Komponenten extern vergeben werden. An-gebote von vorkonfigurierten DWH-Plattformen von Herstellern wie IBM, Teradata und Netezza erleichtern diesen Schritt. Auch die Implementie-rung von DWH-Komponenten wird bereits heute durch zahlreiche Bera-tungsunternehmen angeboten.

Literatur

Adelman, S.; Moss, L.: Data Warehouse Project Management, Pearson Education, New Jersey 2000.

Ariyachandra, T.; Watson, H. J.: Key Factors in Selecting a Data Warehouse Architecture, in: Business Intelligence Journal 10 (2005) 2, S. 19-27.

Auth, G.: Prozessorientierte Organisation des Metadatenmanagements für Data-Warehouse-Systeme, Universität St. Gallen, Bamberg 2003.


Burton, B.; Friedman, T.; Hostmann, B.; Beyer, M.: Findings From the Chicago BI Summit: Decouple Business Intelligence and Data-Warehousing Efforts, G00138579, Gartner, 2006.

Deimer, R.: Unscharfe Clusteranalysemethoden: Eine problemorientierte Darstel-lung zur unscharfen Klassifikation gemischter Daten, Schulz-Kirchner, Frank-furt 1986.

Devlin, B.: Data Warehouse: From Architecture to Implementation, Addison Wes-ley, Reading et al. 1997.

Fiedler, F. E.: A Contingency Model of Leadership Effectiveness, in: Advances in Experimental Social Psychology 1 (1964), S. 149-190.

Gallo, J.: Operations and Maintenance in a Data Warehouse Environment, in: DM Review (2002) 12.


Hackney, D.: Architecture Anarchy and How to Survive It: God Save the Queen, in: Enterprise Systems Journal 15 (2000) 4, S. 24-30.

Herrmann, C.: Exploring the Structural Dimension of Data Warehouse Organiza-tions: Results of a Survey and Implications, in: Meredith R. et al. (Hrsg.): Proceedings of the 2004 IFIP International Conference on Decision Support Systems (DSS2004), Monash University, Prato, Italy 2004, S. 350-358.

Herrmann, C.: Referenzprozesse für die Wartung von Data-Warehouse-Systemen, Bamberg 2006.

Humm, B.; Wietek, F.: Architektur von Data Warehouses und Business Intelligen-ce Systemen, in: Informatik Spektrum 23 (2005) 2, S. 3-14.

Hwang, M.; Cappel, J.: An Assessment of Company Data Warehousing Practices, in: Proceedings of the Seventh Americas Conference on Information Systems (AMCIS 2001), 2001, S. 318-321.

Inmon, W.: Building the Data Warehouse, 3. Aufl., Wiley, New York 2002. Jung, R.; Winter, R.: Data Warehousing: Nutzungsaspekte, Referenzarchitektur

und Vorgehensmodell, in: Jung R. et al. (Hrsg.): Data Warehousing Strategie, Springer, Heidelberg 2000, S. 3-20.

Kachur, R.: Data Warehouse Management Handbook, Prentice Hall, USA 2000. Kimball, R.; Ross, M.: The Data Warehouse Toolkit - The Complete Guide to

Dimensional Modeling, 2. Aufl., Wiley, New York 2002. Klesse, M.: Leistungsverrechnung im Data Warehousing - Entwicklung einer Me-

thode, Dissertation, Universität St. Gallen, St. Gallen 2007. McKnight: Effective Data Warehouse Organizational Roles and Responsibilities,

McKnight Associates, 2000. Meyer, M.: Organisatorische Gestaltung des unternehmensweiten Data Warehou-

sing, Bamberg 2000. o. V. : Dresdner Bank bezieht Risiko-Controlling on demand, in: Computerwoche

o. J. (2004) 1/2, S. 1. Philippi, J.: Outsourcing und Offshoring von Business-Intelligence-Lösungen -

Empirische Studien und Praxiserfahrungen, in: Proceedings der DW2004 - Data Warehousing und EAI: Auf dem Weg zur Integration Factory, Physica, 2004, S. 73-106.

Quinn, J.; Hilmer, F.: Strategic Outsourcing, in: Sloan Management Review 35 (1994) 4, S. 43-55.

Smith, A.: Data Warehouse - Roles and Responsibilities, http://www.tdan.com/ i008ht04.htm, 30.05.2006.

Strange, K.; Dresner, H.: The BI Competency Center's Role in the New Architec-ture, COM-17-4721, Gartner, 2002a.

Strange, K. H.; Dresner, H. J.: The BI Competency Center's Role in the New Architecture, COM-17-4721, Gartner, 2002b.

Strauch, B.; Winter, R.: Information Requirements Engineering for Data Ware-house Systems, in: Haddad H. et al. (Hrsg.): Proceedings of the 2004 ACM Symposion on Applied Computing (SAC 2004), Cyprus, Nicosia 2004, S. 1359-1365.

Wang, R.; Lee, Y.; Pipin, L.; Strong, D.: Manage Your Information as a Product, in: MIT Sloan Management Review 39 (1998) 4, S. 95-105.


Weill, P.; Vitale, M.: What IT Infrastructure Capabilities are Needed to Implement E-Business Models?, in: MIS Quarterly Executive 1 (2002) 1, S. 17-34.

Winter, R.: Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur, in: Jung R. et al. (Hrsg.): Data Warehousing Strategie, Springer, Heidelberg 2000, S. 127-139.

Winter, R.; Meyer, M.: Organization Of Data Warehousing In Large Service Companies: A Matrix Approach Based On Data Ownership and Competence Centers, in: Proceedings of the Seventh Americas Conference on Information Systems (AMCIS 2001), 2001, S. 322-328.

Zarnekow, R.; Brenner, W.; Pilgram, U.: Integriertes Informationsmanagement - Strategien und Lösungen für das Management von IT-Dienstleistungen, Springer, Heidelberg 2005.

6 Interaktionseffekte zwischen prozessorientierter Organisation und Informationslogistik

Tobias Bucher


1 Einleitung ....................................................................................... 1012 Begriffliche Grundlagen ................................................................. 1033 Grundannahmen der prozessorientierten Informationslogistik ....... 1084 Nutzeneffekte der prozessorientierten Informationslogistik........... 1105 Ausgestaltung der prozessorientierten Informationslogistik .......... 1126 Vorgehensmodell für die Einführung der prozessorientierten

Informationslogistik ....................................................................... 1197 Fazit und Ausblick .......................................................................... 123

Literatur .......................................................................................... 124

1 Einleitung

Es gilt heute sowohl in der Wissenschaft als auch in der Praxis als nahezu unbestritten, dass die prozessorientierte Organisation und das prozess-orientierte Management signifikante Beiträge zur Steigerung der Effekti-vität und Effizienz unternehmerischen Handelns leisten können. Prozess-organisation und Prozessmanagement haben zum Ziel, die rein funktionale Arbeitsteilung, welche mit einem hohen Maß an Aufgabenspezialisierung verbunden ist, durch Arbeitsabläufe zu ersetzen, die sowohl funktionale als auch organisatorische Abteilungsgrenzen überschreiten und den Mitarbei-tenden eines Unternehmens eine in deutlich stärkerem Maß selbstbe-stimmte und verantwortungsvolle Arbeitsgestaltung ermöglichen (Gaitani-des 2004). Zahlreiche Autoren stimmen darin überein, dass für die mit der

102 Tobias Bucher

Prozessausführung betrauten Mitarbeitenden eines Unternehmens zur Um-setzung der genannten Ziele während der Prozessausführung uneinge-schränkte Zugriffsmöglichkeiten auf alle relevanten Informationsquellen und auf geeignete Analysewerkzeuge zur Verfügung gestellt werden müs-sen (Inmon 2000; Davenport u. Glaser 2002; Gile et al. 2004; Imhoff 2005; Herschel u. Burton 2006; Ericson 2007).

In zahlreichen Unternehmen sind derzeit aktive Bemühungen zu erken-nen, die Informationslogistik auf die Unterstützung ausgewählter betriebli-cher Prozesse – insbesondere auch operativer Prozesse – hin auszurichten. Die heute existierenden analyseorientierten und entscheidungsunterstüt-zenden Konzepte richten sich überwiegend an Fach- und Führungskräfte. Informationslogistik versetzt diese Personen bspw. in die Lage, sich mit-tels standardisierter periodischer Berichte über Finanzkennzahlen zu in-formieren, sich mit Hilfe verschiedener Visualisierungstechniken einen Überblick über die wichtigsten Kennzahlen zu verschaffen, große Daten-bestände systematisch und hinsichtlich verschiedener Dimensionen aus-zuwerten oder diese gar automatisiert nach Mustern durchsuchen zu las-sen. Der Informationsversorgung derjenigen Mitarbeitenden, die mit der Ausführung operativer betrieblicher Prozesse betraut sind, wurde in der Vergangenheit in deutlich geringerem Maß Beachtung geschenkt.

An dieser Stelle setzt der vorliegende Artikel an, der sich wie folgt glie-dert: Zunächst werden in Abschn. 2 die terminologischen Grundlagen der Themenfelder Prozessorganisation und Prozessmanagement dargestellt. Bezüglich des Begriffsverständnisses zum Thema Informationslogistik wird auf das entsprechende Kapitel in diesem Sammelband verwiesen. Ab-schließend werden zwei Blickrichtungen auf die Integration von Prozess-orientierung und Informationslogistik kurz dargestellt und voneinander ab-gegrenzt. In Abschn. 3 wird sodann eine der beiden Varianten, in diesem Artikel als prozessorientierte Informationslogistik bezeichnet, detailliert diskutiert. Nutzeneffekte des Konzepts werden im folgenden Abschn. 4 auf Grundlage der Ergebnisse einer hypothesenprüfenden statischen Analyse erörtert. Abschnitt 5 ist der Darstellung der Ergebnisse einer explorativen statistischen Untersuchung gewidmet, welche zum Ziel hatte, Gestaltungs-faktoren und Realisierungsformen der prozessorientierten Informationslo-gistik zu identifizieren. In Abschn. 6 wird ein Vorgehensmodell für die Einführung des Konzepts in der Praxis dargestellt, welches im Rahmen ei-nes Expertenworkshops erarbeitet wurde. Abschnitt 7 fasst die we-sentlichen Aussagen dieses Artikels zusammen und gibt einen Ausblick auf weitere Forschungsaktivitäten im Kontext der prozessorientierten In-formationslogistik.

Prozessorientierte Organisation und Informationslogistik 103

2 Begriffliche Grundlagen

Der Darlegung des Begriffsverständnisses der Informationslogistik ist in diesem Sammelband breiter Raum gewidmet (vgl. Kap. 1). Der vorlie-gende Artikel verfolgt das Ziel, die Prozessorientierung der Informations-logistik zu beleuchten. Dementsprechend werden im Folgenden die be-grifflichen Grundlagen zur Prozessorganisation (Abschn. 2.1) und zum Paradigma des prozessorientierten Managements (Abschn. 2.2) gelegt. So-dann werden in Abschn. 2.3 zwei Blickrichtungen auf die Integration von Prozessorganisation und Informationslogistik voneinander abgegrenzt.

2.1 Prozessorganisation

Prozessorganisation wird von vielen Autoren als geeignetes Konzept be-schrieben, um schnell und flexibel auf Veränderungen innerhalb eines Un-ternehmens sowie der sozialen, ökonomischen und/oder technischen Rah-menbedingungen reagieren zu können (Osterloh u. Frost 1998; Rüegg-Stürm 2003; Becker u. Kahn 2005; Schmelzer u. Sesselmann 2006). Gaitanides unterscheidet zwischen drei erkenntnistheoretischen Perspekti-ven der Prozessorganisation (Gaitanides 2004):

Praxeologische Perspektive: Ausgangspunkt der praxeologischen Pers-pektive der Prozessorganisation sind Aufbau- und Ablauforganisation eines Unternehmens. Während diese bei klassischer, funktionsorien-tierter Organisationsgestaltung eng miteinander verwoben sind und die Arbeitsabläufe in hohem Maß durch eine bereits vorgegebene Aufbau-organisation bedingt werden, hat prozessorientierte Organisationsge-staltung zum Ziel, Arbeitsabläufe zunächst unabhängig von der Aufbau-organisation zu gestalten. Die Elemente der Aufbauorganisation werden in einem nachgelagerten Schritt so entworfen und/oder angepasst, dass sie der Logik der Ablauforganisation folgen („Aufbauorganisation folgt Ablauforganisation“ anstelle von „Ablauforganisation folgt Aufbauor-ganisation“) (Gaitanides 2007).

Ökonomische Perspektive: Wesentliche Grundlage für die ökonomische Perspektive der Prozessorganisation stellt die Transaktionskostentheorie (Coase 1937; Williamson 1981) dar. Diese beschäftigt sich mit der effi-zienten Abwicklung von Tauschgeschäften unter bestimmten institutio-nellen Arrangements und versucht zu erklären, welche Organisations-form für welche Art von Austauschbeziehungen die erwarteten Trans-aktionskosten minimiert (Fritz 2006). Übertragen auf die unternehmens-interne Koordination des Leistungsaustauschs vermag die Transaktions-

104 Tobias Bucher

kostentheorie zu begründen, dass die Prozessorganisation die Vorteile rein funktionaler, dem Verrichtungsprinzip folgender Organisation (hierarchiebasierte, funktionale Spezialisierung) einerseits und dezen-traler, dem Objektprinzip folgender Organisation (marktbasierte, pro-dukt- oder kundenorientierte Differenzierung) andererseits miteinander vereint. Drei Eigenschaften von Transaktionen bestimmen deren Kos-ten: Spezifität, Unsicherheit und Häufigkeit (Williamson 1979,1991). Prozessorganisation minimiert die Transaktionskosten bei mittleren Ausprägungen von Spezifität, Unsicherheit und Häufigkeit des unter-nehmensinternen Leistungsaustauschs (Gaitanides 2004).

Konstruktivistische Perspektive: Als konstruktivistische Perspektive der Prozessorganisation bezeichnet Gaitanides den Umstand, dass die Pro-zessorganisation keine „objektive Realität“ darstellt, sondern vielmehr ein „soziales Konstrukt“ (Gaitanides 2007, S. 99), welches für die Mi-tarbeitenden eines Unternehmens erst durch sicht- und erfahrbare Ele-mente wie bspw. veränderte Abläufe, veränderte Verantwortlichkeiten und Zuständigkeiten sowie zusätzliche, übergeordnete Aufgaben des Prozessmanagements verständlich und begreifbar wird: „Prozessorgani-sation ist in diesem Sinne nicht ein an einer Rezeptur oder einem Refe-renzmodell festzumachendes organisatorisches Design, sondern eine kollektiv erzeugte und mithin sozial konstruierte Realität“ (Gaitanides 2004).

In der Literatur finden sich unzählige unterschiedliche Definitionen des Begriffs „Prozess“. Nahezu all diesen Begriffsverständnissen ist gemein, dass sie Prozesse in generischer Art und Weise als Ablauffolge von Akti-vitäten oder Aufgaben beschreiben, welche darauf abzielen, unter Einbe-ziehung von Eingangsobjekten (Inputs, Ressourcen) eine spezifische Leis-tung (Output, Prozessleistung) zu erbringen (Harrington 1991; Davenport 1993; Hammer u. Champy 1993; Ould 1995; Zairi 1997). Nach Davenport stellen Prozessbeschreibungen strukturierte Vorgaben dar, auf welche Art und Weise die Arbeitsabläufe innerhalb eines Unternehmens und/oder zwischen Unternehmen durchzuführen sind. Im Gegensatz zur funktions-orientierten Organisation steht also nicht die Frage nach dem „Was?“ im Vordergrund, sondern nach dem „Wie?“ (Davenport 1993). Prozesse sind stets auf Prozesskunden hin ausgerichtet, die sowohl im Unternehmen selbst als auch außerhalb des Unternehmens angesiedelt sein können (Har-rington 1991; Davenport 1993; Hammer u. Champy 1993; Hammer 2001).

Ein Unternehmen stellt im Sinne der Prozessorganisation ein System aus miteinander verbundenen Prozessen dar (DeToro u. McCabe 1997). In der von Porter geprägten Wertschöpfungskette wird zwischen zwei Grup-pen wertschöpfender Prozesse unterschieden, nämlich zwischen primären


Aktivitäten einerseits und unterstützenden Aktivitäten andererseits (Porter 2004). Auf dieser Unterscheidung aufbauend differenzieren bspw. Gaitani-des sowie Becker/Kahn zwischen Kernprozessen und Supportprozessen. Kernprozesse sind Prozesse, die unmittelbar mit Produkten und/oder Dienstleistungen eines Unternehmens in Verbindung stehen, auf externe Kunden ausgerichtet sind und damit einen Wertschöpfungsbeitrag leisten. Supportprozesse sind im Gegensatz dazu per se zwar nicht wertschöpfend, jedoch zur Unterstützung der Ausführung der Kernprozesse erforderlich und damit primär auf interne Kunden ausgerichtet (Gaitanides 2004; Be-cker u. Kahn 2005). In Erweiterung dessen unterscheidet das neue St. Gal-ler Management-Modell zwischen den drei Kategorien Geschäftsprozesse, Unterstützungsprozesse und Managementprozesse (Rüegg-Stürm 2003). Während das Verständnis von Geschäftsprozessen und Unterstützungspro-zessen im Wesentlichen den von Porter begründeten und etablierten Defi-nitionen entspricht, werden Managementprozesse explizit als neue Katego-rie eingeführt. Eine vergleichbare Unterscheidung zwischen operativen Kern- und Supportprozessen sowie Managementprozessen nimmt auch Ould vor (Ould 1995). Managementprozesse beschäftigen sich primär mit der unternehmerischen Führungsarbeit (Rüegg-Stürm 2003), unter Um-ständen jedoch auch mit der Führung und Kontrolle operativer Prozesse (Ould 1995).

2.2 Prozessorientiertes Management

Ebenso wie der Begriff „Prozess“ ist auch der Terminus „Prozessmanage-ment“ inhaltlich nicht eindeutig definiert (Armistead et al. 1999). Dies kommt unter anderem dadurch zum Ausdruck, dass im allgemeinen Sprachgebrauch die unterschiedlichsten Ansätze wie bspw. die prozess-orientierte Organisationsgestaltung, die Erneuerung oder Verbesserung be-stehender Prozesse sowie gesamthaft die Gestaltung, Einführung, Lenkung und Fortentwicklung von Prozessen unter diesem Begriff subsumiert wer-den. Im Kontext dieses Artikels wird der Begriff „Prozessmanagement“ ausschließlich im letztgenannten Sinne verstanden.

Im Rahmen einer umfassenden Literaturanalyse haben Bucher/Winter vier generische Phasen des Prozessmanagements abgeleitet (Bucher u. Winter 2006,2007):

Phase A: „Identifikation, Definition und Modellierung von Prozessen“. Die erste Phase umfasst die Identifikation und Analyse der Abläufe in einem Unternehmen. Darauf aufbauend sind, unter Einbezug möglichst aller beteiligten Akteure, Prozesse im Sinne strukturierter Aktivitätsab-lauffolgen zur Erreichung festgelegter Ziele zu definieren, zu gestalten

106 Tobias Bucher

und zu modellieren. Besonderes Augenmerk ist in diesem Zusammen-hang auch auf das Zusammenwirken aller betrieblichen Prozesse sowie auf wechselseitige Abhängigkeiten zu richten.

Phase B: „Implementierung und Ausführung von Prozessen“. Die Pro-zessimplementierung im Rahmen der zweiten Phase schließt die Ein-richtung bzw. Anpassung aller Aktivitäten, Arbeitsabläufe, Ressourcen und unterstützenden informationstechnischen Komponenten ein, die für eine reibungslose Prozessausführung erforderlich sind. Der Schulung und fortlaufenden Betreuung der prozessausführenden Mitarbeitenden kommt ebenfalls entscheidende Bedeutung zu.

Phase C: „Überwachung und Steuerung von Prozessen“. Unabhängig vom Automatisierungsgrad der betrieblichen Prozesse ist eine zeitnahe Überwachung der Prozessausführung sinnvoll, um bei Planabweichun-gen oder Prozessfehlern unmittelbar korrigierend eingreifen zu können. Neben diesem Aspekt können die im Rahmen der dritten Phase des Pro-zessmanagements ermittelten Prozesskennzahlen auch zur Unterstüt-zung unternehmerischer Entscheidungen herangezogen werden oder als Gestaltungs- und Entscheidungsgrundlage im Rahmen der kontinuierli-chen Prozessverbesserung dienen.

Phase D: „Weiterentwicklung von Prozessen“. Für ein Unternehmen führt bereits das erstmalige Durchlaufen der ersten drei Phasen des Pro-zessmanagements zu weitreichenden Veränderungen. Gleichwohl darf die beständige Weiterentwicklung der Prozesse und der Prozessland-schaft keinesfalls vernachlässigt werden. Das Prozessmanagement muss als kontinuierlicher Ansatz begriffen werden, wobei die einzelnen Pha-sen in iterativen Zyklen zu durchlaufen sind.

In diesem Zusammenhang sei noch einmal betont, dass die vorgenann-ten vier Phasen des Prozessmanagements für die einzelnen betrieblichen Prozesse zunächst sequentiell zu durchlaufen sind. Gleichwohl können die mit dem Prozessmanagement zusammenhängenden Aktivitäten zu keinem Zeitpunkt als abgeschlossen betrachtet werden. Vielmehr wiederholen sich die Phasen des Prozessmanagements im Zuge der Weiterentwicklung von Prozessen. Der so entstehende Prozessmanagement-Zyklus stellt die konti-nuierliche Leistungssteigerung von Prozessen sicher (Zairi 1997).

2.3 Thematische Abgrenzung

In Literatur und Praxis werden derzeit zwei verschiedene Varianten bzw. Blickrichtungen auf die Integration der prozessorientierten Organisation einerseits und der Informationslogistik andererseits diskutiert.


Zum einen existieren zahlreiche Beiträge, die die Unterstützung der Ausführung von betrieblichen Prozessen durch die Einbettung analyti-scher, entscheidungsunterstützender Informationen in den Kontext der Prozessausführung adressieren. Die praktische Relevanz und die poten-ziellen Nutzeneffekte dieses als prozessorientierte Informationslogistik be-zeichneten Konzepts wurden in zahlreichen Arbeiten aufgezeigt und be-schrieben (Inmon 2000; Gile et al. 2004; Imhoff 2005; Gile et al. 2006; Bucher 2007a; Bucher u. Dinter 2008b,2008a). Prozessorientierte Informa-tionslogistik betrifft primär die Prozessmanagement-Phase B („Implemen-tierung und Ausführung von Prozessen“). Die Phasen A („Identifikation, Definition und Modellierung von Prozessen“) bzw. D („Weiter-entwicklung von Prozessen) sind betroffen, wenn Fragestellungen der Ein-führung bzw. der Fortentwicklung des Konzepts im Vordergrund stehen. Phase C („Überwachung und Steuerung von Prozessen“) ist hingegen nicht betroffen.

Davon abzugrenzen ist zum anderen die Überwachung und Analyse der Prozessausführung, vor deren Hintergrund die Integration von Prozess-orientierung und Informationslogistik ebenfalls diskutiert wird (Glu-chowski u. Kemper 2006; Oehler 2006). Derartige Konzepte, die in der Wissenschaft und der Praxis unter Schlagworten wie bspw. „Business Ac-tivity Monitoring“ (Adams 2002) oder „Business Performance Manage-ment“ (Dinter u. Bucher 2006) erörtert werden, sind vom Konzept der pro-zessorientierten Informationslogistik – wie es in diesem Artikel definiert und diskutiert wird – zu unterscheiden. Die Überwachung und Analyse der Prozessausführung betreffen primär die Prozessmanagement-Phase C („Überwachung und Steuerung von Prozessen“) und dienen zwei Zielen (Adams 2002; Gassman 2004; White 2006): Zum einen ist es möglich, durch die Verfolgung von Prozesskennzahlen schnell und flexibel auf Pro-zessfehler, Störungen im Prozessablauf oder sich verändernde Rahmenbe-dingungen zu reagieren. Zum anderen lassen sich aus der integrierten Ana-lyse aktueller und historisierter Prozesskennzahlen Ansatzpunkte für Maßnahmen zur Leistungssteigerung ableiten. Ebenso wie bei der prozess-orientierten Informationslogistik sind die Prozessmanagement-Phasen A („Identifikation, Definition und Modellierung von Prozessen“) bzw. D („Weiterentwicklung von Prozessen“) betroffen, wenn Fragestellungen der Einführung bzw. der Fortentwicklung des Konzepts im Vordergrund ste-hen. Phase B („Implementierung und Ausführung von Prozessen“) ist hin-gegen nicht betroffen.

Abbildung 1 zeigt die im vorangegangenen Abschnitt erläuterten Phasen des Prozessmanagements und verdeutlicht, welcher bzw. welchen der bei-den vorstehend beschriebenen Blickrichtungen auf die Integration von

108 Tobias Bucher

prozessorientierter Organisation und Informationslogistik in welchen Pha-se Bedeutung zukommt.

Phase A:Identifikation, Definition und Modellierung

Identifikation der kritischen Geschäftsprozesse/KernprozesseModellierung der Prozesse unter Berücksichtigung spezifischer Charakteristika der EntwicklungssituationAbstimmung, Modifikation und Verbesserung der Prozessmodelle

Phase B:Implemen-tierung und Ausführung

Anpassung all derjenigen Aktivitäten, Arbeitsabläufe, Ressourcen und unterstützenden Systeme, die für eine reibungslose Prozessausführung erforderlich sindMiteinbeziehung und Schulung aller betroffenen Mitarbeitenden

Phase C:Überwach-ung und Steuerung

Fortdauernde Prozessüberwachung zur Identifikation von Planabweichungen und Prozessfehlern als Grundlage für korrigierende EingriffeProzessmetriken zur Unterstützung von Führungsentscheidungen und zur kontinuierlichen Prozessverbesserung

Phase D:Weiter-entwicklung

Beständige Weiterentwicklung und Optimierung der ProzessabläufeGeschäftsprozessmanagement als „Continuous Approach to Optimization“

Prozessorientierte Informationslogistik

(Einführung)

Überwachung und Analyse der Prozessausführung

(Einführung)


(Betrieb)


(Betrieb)

Prozessorientierte Informationslogistik (Fortentwicklung)


(Fortentwicklung)

Abb. 1. Phasen des Prozessmanagements und Unterscheidung zweier Blickrich-tungen auf die Integration von Prozessorientierung und Informationslogistik

3 Grundannahmen der prozessorientierten Informationslogistik

Dem Artikel liegt folgendes Verständnis des Begriffs der prozessorien-tierten Informationslogistik zugrunde:

„Prozessorientierte Informationslogistik“ bezeichnet als Sammelbe-griff all diejenigen Funktionalitäten zur Datenanalyse und zur In-formationsbereitstellung, die in einen betrieblichen Prozess einge-bettet sind und darauf abzielen, durch einen menschlichen Akteur zu treffende prozessinhärente Entscheidungen informatorisch optimal zu unterstützen. Das Konzept entfaltet seinen Nutzen insbesondere im Kontext der Ausführung operativer betrieblicher Prozesse (d. h. von Geschäfts- und Unterstützungsprozessen).

Das Konzept der prozessorientierten Informationslogistik wird primär in der angelsächsischen Literatur unter dem Begriff „Operational Business Intelligence“ diskutiert. Die Mehrzahl dieser Veröffentlichungen be-


schreibt und diskutiert mehr oder minder konkrete Ansätze oder Ideen. Obgleich es einzelne wissenschaftliche Veröffentlichungen gibt, geht die Mehrzahl der einschlägigen Beiträge doch auf Analysten, Beratungs- und Marktforschungsunternehmen sowie auf Softwarehersteller zurück.

Prozessorientierte Informationslogistik zielt darauf ab, die wertschöp-fende Geschäftstätigkeit eines Unternehmens durch Informationsbereit-stellung und Entscheidungsvorbereitung im operativen Kontext effektiv und effizient zu unterstützen (Inmon 2000; Gile et al. 2004; Chemburkar u. Keny 2006). In vielen Veröffentlichungen wird direkt oder indirekt auf die Tatsache Bezug genommen, dass die wertschöpfenden Aktivitäten ent-sprechend dem prozessorientierten Managementparadigma im Rahmen von operativen Prozessen vollzogen werden. Aus diesem Grund betonen zahlreiche Autoren die Notwendigkeit einer prozessorientierten Gestaltung und Ausrichtung der Informationslogistik zur Unterstützung der effektiven und effizienten Ausführung operativer Prozesse (Gile et al. 2004; Schlegel 2005; Gile et al. 2006; Herschel u. Burton 2006; Ericson 2007; Marjanovic 2007). Weiterhin leiten viele Veröffentlichungen zur prozessorientierten Informationslogistik das Erfordernis ab, Informationen im operativen Kon-text in Echtzeit bzw. in Nahe-Echtzeit bereitzustellen (Watson 2005; Az-vine et al. 2006; Davis 2006; Gassman et al. 2006). Ansätze zur Datenin-tegration in Echtzeit bzw. in Nahe-Echtzeit zielen darauf ab, die sog. Latenzzeit zwischen dem Auftreten eines Ereignisses und der Ent-scheidungsfindung bzw. der Einleitung ggf. zu ergreifender Maßnahmen zu minimieren (Bruckner et al. 2002). Als typische Anwendungsfälle für die Nutzung analytischer Informationen im operativen Kontext werden Prozesse wie Preisermittlung, Kundenbindungsmanagement, Betrugser-kennung und Risikomanagement genannt (Inmon 2000).

Es steht außer Frage, dass prozessorientierte Informationslogistik auf einer zentralen, integrierten Informationsschicht – der sog. Informationslo-gistik-Infrastruktur – aufsetzen muss. Diese Informationslogistik-Infra-struktur stellt die technische Basis für die Befriedigung der analytischen Informationsbedarfe im Rahmen der Prozessausführung dar. Eine ausführ-liche Darstellung und Diskussion verschiedener Systemarchitekturen für die Informationslogistik findet sich in Kap. 7.

Wie im einleitenden Kapitel bemerkt, kann durch die systematische, be-reichsübergreifende Zusammenführung und Nutzung von Informationen nachhaltig Mehrwert in einem Unternehmen geschaffen werden. Da bei der prozessorientierten Informationslogistik die Unterstützung von Ent-scheidungen im Kontext der Ausführung operativer betrieblicher Prozesse im Vordergrund steht, kann von analytischer Nutzung der bereitgestellten Informationen gesprochen werden (vgl. Kap. 1). Klesse/von Maur betonen, dass die Integration interner und externer Daten, die Möglichkeit der Be-

110 Tobias Bucher

rücksichtigung sog. „weicher Informationen“ sowie die Bereitstellung ent-scheidungsrelevanter Informationen sofort nach ihrer Entstehung von zent-raler Bedeutung für die Unterstützung von Entscheidungsprozessen seien (Klesse u. von Maur 2003).

Prozessorientierte Informationslogistik beinhaltet jedoch nicht nur die Bereitstellung analytischer Informationen zum Zweck der Unterstützung prozessinhärenter Entscheidungen auf Grundlage einer integrierten Infor-mationsbasis, sondern sollte (in der Reifephase) auch um die Rückführung kontextueller Informationen zu einmal getroffenen Entscheidungen in eine sog. Erfahrungsdatenbank ergänzt werden (Bucher 2007a). Diese Ent-scheidungsdatenbank kann ihrerseits wiederum Teil der integrierten In-formationsschicht sein, die die Grundlage für prozessorientierte Informati-onslogistik darstellt.

4 Nutzeneffekte der prozessorientierten Informationslogistik

Durch die Unterstützung der Ausführung operativer Prozesse mit Hilfe ei-ner integrierten Bereitstellung entscheidungsrelevanter Informationen las-sen sich sowohl unternehmensinterne als auch unternehmensexterne Nut-zeneffekte realisieren. Zur ersten Gruppe zählen bspw. die durch die verbesserte informatorische Unterstützung der Prozessausführung bedingte Reduktion von Durchlaufzeiten, die qualitative Verbesserung der Prozess-leistung sowie Effizienzgewinne in der Ressourcennutzung. Unterneh-mensexterne Nutzeneffekte umfassen z. B. die Steigerung der Kundenzu-friedenheit und der Kundenprofitabilität sowie die Verbesserung der an unternehmensexterne Prozesskunden gerichteten Leistungen.

Die Nutzeneffekte der prozessorientierten Informationslogistik wurden im Rahmen einer hypothesenprüfenden Kausalanalyse untersucht (Bucher u. Dinter 2008b).1 Die Kausalanalyse hatte zum Ziel, Hypothesen über po-sitive Abhängigkeiten zwischen den latenten Variablen „prozessorientierte Informationslogistik“, „unternehmensinterne Nutzeneffekte“ und „unter-nehmensexterne Nutzeneffekte“ zu prüfen. Die latenten Variablen sind nicht direkt beobachtbar, sondern müssen über Messmodelle erhoben wer- 1 Die Stichprobe umfasst 43 mittelständische und große Unternehmen aus ver-

schiedenen Branchen. Die Befragung wurde im Dezember 2006 im Rahmen des 21. St. Galler Anwenderforums durchgeführt. An dieser Konferenz nahmen et-wa 110 Fach- und Führungskräfte von Unternehmen aus dem deutschsprachigen Raum teil, die eine umfassende Expertise im Bereich Informationslogistik sowie hohes Interesse an der Thematik besitzen.


den. Das Messmodell der latenten Variable „prozessorientierte Infor-mationslogistik“ wird durch die vier Indikatorvariablen „Verfügbarkeit analytischer Informationen zum Zeitpunkt der Prozessausführung“, „Zu-sammenfallen von Prozessausführung und Informationszugriff“, „hohe Priorität des Themas bei der Unternehmensleitung“ und „hohe Priorität des Themas bei der Unternehmens-IT“ gebildet. Je höher der Umsetzungs-/ Erreichungsgrad jeder einzelner dieser Variablen ist, desto höher ist auch der Umsetzungsgrad der prozessorientierten Informationslogistik. Die bei-den latenten Variablen „unternehmensinterne Nutzeneffekte“ und „unter-nehmensexterne Nutzeneffekte“ werden durch die eingangs in diesem Ab-schnitt genannten Indikatorvariablen determiniert. Abbildung 2 zeigt das beschriebene Kausalmodell zur Erklärung der Nutzeneffekte der prozess-orientierten Informationslogistik.

Die Analyse des Kausalmodells zeigt, dass alle durch gerichtete Pfeile dargestellten Kausalbeziehungen zwischen den Variablen positive Pfad-koeffzienten aufweisen. Dies deutet auf positive Kausalzusammenhänge hin, d. h. je höher die Umsetzungs-/Erreichungsgrade einer verursachenden Variable sind, desto höhere Werte nimmt auch diejenige Variable an, die in kausaler Abhängigkeit zur verursachenden Variable steht. Des Weiteren sind alle Pfadkoeffizienten statistisch hoch signifikant, so dass die zu prü-fenden Hypothesen wie angenommen nicht verworfen werden können.

Demnach ist festzustellen, dass die Einführung bzw. die Etablierung der prozessorientierten Informationslogistik in einem Unternehmen in der Tat mit signifikant positiven Nutzeneffekten einhergeht, welche sowohl inner-halb als auch außerhalb des Unternehmens ihre Wirkung entfalten. Außer-dem werden die unternehmensexternen Nutzeneffekte der prozessorien-tierten Informationslogistik durch die innerhalb des Unternehmens auftre-tenden Geschwindigkeits-, Qualitäts- und Effizienzsteigerungen zusätzlich in ihrer Wirkung verstärkt.2

2 Die Pfadkoeffizienten der beiden Beziehungen zwischen der latenten Variable

„prozessorientierte Informationslogistik“ und den latenten Variablen „unter-nehmensinterne Nutzeneffekte“ sowie „unternehmensexterne Nutzeneffekte“ sind bei einem Signifikanzniveau von = 0,05 signifikant. Alle anderen Pfad-koeffizienten sind sogar bei einem Niveau von = 0,01 signifikant. Die erklär-ten Varianzanteile betragen 16,9% für die latente Variable „unternehmensinter-ne Nutzeneffekte“ und 71,9% für die latente Variable „unternehmensexterne Nutzeneffekte“. Die Maßzahlen für die Güte des Kausalmodells weisen auf eine gute Anpassung hin (GFI = 0,877; NFI = 0,867; CFI = 0,999; RMSEA = 0,001). Eine Zusammenfassung der verwendeten Methodik findet sich bspw. bei Byrne (Byrne 2001).

112 Tobias Bucher

Unternehmensinterne Nutzeneffekte1

Unternehmensexterne Nutzeneffekte 2


Verfügbarkeit analytischer Informationen zum Zeitpunkt der

Prozessausführung1

Hohe Priorität des Themas bei der Unternehmens-IT 4Hohe Priorität des Themas bei der

Unternehmensleitung3

Zusammenfallen von Prozessausführung und

Informationszugriff2

Reduktion von Durchlaufzeiten1

Qualitative Verbesserung der Prozessleistung2

Effizienzgewinne in der Ressourcennutzung3

Steigerung der Kundenzufriedenheit 4

Steigerung der Kundenprofitabilität 5

Verbesserung der Leistungen für externe Prozesskunden 6

0.55

0.62

0.63

0.81

0.87

0.92

0.66

0.85

0.89

0.76

0.53

0.41 0.48

0.17 0.72

0.30

0.38

0.40

0.65

0.75

0.85

0.43

0.72

0.79

0.59 Abb. 2. Kausalmodell zur Erklärung der Nutzeneffekte prozessorientierter Infor-mationslogistik (Bucher u. Dinter 2008b)

5 Ausgestaltung der prozessorientierten Informationslogistik

Die prozessorientierte Informationslogistik stellt ein vergleichsweise brei-tes Themenfeld dar. Dementsprechend steht zu vermuten, dass verschie-dene Unternehmen sich dem Thema mit unterschiedlichen Herangehens-weisen und Zielstellungen nähern. Im Folgenden soll ein Überblick über die die unternehmensindividuelle Ausgestaltung der prozessorientierten In-formationslogistik hauptsächlich beeinflussenden Faktoren gegeben wer-den (Abschn. 5.1). Die aus diesen Faktoren resultierenden Realisierungs-varianten der prozessorientierten Informationslogistik werden in Ab-schn. 5.2 dargestellt. Die Ergebnisse entstammen einer explorativen


statistischen Analyse (vgl. Bucher u. Dinter 2008b) und werden im vorlie-genden Artikel in verkürzter Form präsentiert.3

5.1 Gestaltungsfaktoren

Im Kontext einer explorativen Analyse haben Bucher/Dinter vier Gestal-tungsfaktoren der prozessorientierten Informationslogistik identifiziert (Bucher u. Dinter 2008b).4 Diese Gestaltungsfaktoren fassen einzelne Ge-staltungselemente (im Folgenden als „Variable“ bezeichnet) zusammen, die die Ausgestaltung der prozessorientierten Informationslogistik in ei-nem Unternehmen beschreiben. Mit Hilfe der vier nachfolgend dargestell-ten Gestaltungsfaktoren ist es deshalb möglich, die Herangehensweise bzw. den Entwicklungsstand eines Unternehmens in Bezug auf das The-menfeld der prozessorientierten Informationslogistik auf stark verdichte-tem Niveau zu charakterisieren:

Gestaltungsfaktor 1: „Entwicklungsstand der Informationsversorgung“. Der erste Faktor wird durch sieben Variablen gebildet, deren gemein-same Grundlage in Fragestellungen der Qualität und Reife der Informa-tionsversorgung besteht (vgl. Tabelle 1). Hierzu zählen insbesondere die Zuverlässigkeit, Verfügbarkeit, Granularität, Darstellungsform und der Adressatenkreis der im Kontext der Prozessausführung bereitgestellten analytischen Informationen. Dieser Gestaltungsfaktor fasst dementspre-chend primär technische Fragestellungen zusammen. Der Entwicklungs-stand der Informationsversorgung in einem Unternehmen ist als umso höher zu bezeichnen, je größer der durchschnittliche Zielerreichungs- bzw. Erfüllungsgrad der sieben Variablen ebendieses Gestaltungsfaktors ist.

3 Der der explorativen Analyse zugrunde liegende Datensatz entspricht dem in

Abschn. 4 beschriebenen Datensatz. Zusätzliche Informationen zur Charakteri-sierung der Stichprobe finden sich in (Bucher u. Dinter 2008b).

4 Zum Zweck der Extraktion von Gestaltungsfaktoren wurde eine Faktorenanaly-se (Hauptkomponentenanalyse) durchgeführt. Aus 14 Variablen wurden vier Faktoren extrahiert (Kaiser-Kriterium, Eigenwerte größer eins). Das Kaiser-Meyer-Olkin-Kriterium beträgt 0,710. Die Durchführung einer Faktorenanalyse erscheint dementsprechend sinnvoll. Die vier extrahierten Faktoren sind in der Lage, gemeinsam etwa 64% der Ausgangsvarianz zu erklären. Eine Zusammen-fassung der verwendeten Methodik findet sich bspw. bei Backhaus et al. (Back-haus et al. 2006).

114 Tobias Bucher

Tabelle 1. Variablen des ersten Gestaltungsfaktors

Gestaltungsfaktor 1: „Entwicklungsstand der Informationsversorgung“ Variable 1.1 Analytische Informationen werden im Kontext der Prozessausfüh-

rung mit hoher Zuverlässigkeit bzw. Verfügbarkeit bereitgestellt. Variable 1.2 Analytische Informationen werden mit einer für den Sachverhalt

angemessenen Geschwindigkeit bereitgestellt. Verzögerungen ent-stehen bei der Informationsinterpretation/Maßnahmenumsetzung.

Variable 1.3 Die bereitgestellten Informationen weisen eine für die Unterstüt-zung der Prozessausführung geeignete Granularität auf.

Variable 1.4 Alle mit der Prozessausführung betrauten Mitarbeitenden haben Zugriff auf die erforderlichen analytischen Informationen. Es besteht keine asymmetrische Informationsverteilung.

Variable 1.5 Die mit der Prozessausführung betrauten Mitarbeitenden erhalten alle für ihre Arbeit erforderlichen analytischen Informationen. Zusätzliche Informationen sind nicht erforderlich.

Variable 1.6 Die Benutzerschnittstellen zum Abruf der analytischen Informatio-nen sind benutzerfreundlich gestaltet und einfach/intuitiv bedienbar.

Variable 1.7 Die Quelldaten werden auf Grundlage eines unternehmensweit harmonisierten Datenmodells konsolidiert und zu analytischen Informationen aufbereitet.

Gestaltungsfaktor 2: „Integrationsgrad analytischer Informationen in

Prozesse“. Der zweite Faktor wird durch drei Variablen gebildet, die im Wesentlichen den Integrationsgrad von Prozessausführung und Infor-mationsbereitstellung beschreiben (vgl. Tabelle 2). Im Unterschied zum ersten Gestaltungsfaktor fasst dieser zweite Gestaltungsfaktor primär fachlich-organisatorische Fragestellungen zusammen. Demzufolge ist der Integrationsgrad von Prozessausführung und Informationsbereit-stellung umso höher, je größer der durchschnittliche Zielerreichungs- bzw. Erfüllungsgrad der drei vorherrschenden Variablen dieses Gestal-tungsfaktors ist. Insbesondere die Variable 2.2, der zufolge der Integra-tionsgrad zunimmt, wenn Prozessabläufe in Abhängigkeit von analyti-schen Informationen angepasst werden können, stellt ein charakterisie-rendes Merkmal der prozessorientierten Informationslogistik dar.


Tabelle 2. Variablen des zweiten Gestaltungsfaktors

Gestaltungsfaktor 2: „Integrationsgrad analytischer Informationen in Prozesse“ Variable 2.1 Analytische Informationen werden zeitlich synchron zur Prozess-

ausführung bereitgestellt sowie in den Prozesskontext/Workflow eingebettet präsentiert.

Variable 2.2 Die Ablauffolge der Aktivitäten eines Prozesses wird in Abhängig-keit von analytischen Informationen, die im Prozesskontext zur Verfügung gestellt werden, einzelfallbasiert verändert/angepasst.

Variable 2.3 Analytische Informationen werden von einem dedizierten Analys-tenteam aufbereitet und vorselektiert. Nur derart aufbereitete Informationen werden im Prozesskontext bereitgestellt.

Gestaltungsfaktor 3: „Einsatz-/Nutzungsgrad einfacher Instrumente für

die Datenanalyse und die Informationsbereitstellung“. Zwei Variablen konstituieren den dritten Gestaltungsfaktor (vgl. Tabelle 3). Die beiden Gestaltungselemente beschreiben den Einsatz- bzw. Nutzungsgrad ein-facher Instrumente zum Zweck der Datenanalyse und der Informations-bereitstellung. Hierzu zählt insbesondere die Verwendung von standar-disieren Berichten, die entweder über eigenständige Reporting-Applika-tionen oder eingebunden in die Benutzeroberfläche des für die Prozess-ausführung verwendeten Anwendungssystems bereitgestellt werden. Der Einsatz- bzw. Nutzungsgrad ist umso höher, je größer der durch-schnittliche Zielerreichungs- bzw. Erfüllungsgrad der beiden Variablen dieses Gestaltungsfaktors ist.

Tabelle 3. Variablen des dritten Gestaltungsfaktors

Gestaltungsfaktor 3: „Einsatz-/Nutzungsgrad einfacher Instrumente für die Datenanalyse und die Informationsbereitstellung“ Variable 3.1 Analytische Informationen werden nur zeitlich synchron zur

Prozessausführung bereitstellt, d. h. sind zur Laufzeit des Prozesses verfügbar, müssen jedoch über eine separate Applikation bzw. Benutzerschnittstelle abgerufen werden.

Variable 3.2 Analytische Informationen werden primär durch vordefinierte Reports oder sonstige vordefinierte Darstellungen in den Prozesskontext eingebettet.

Gestaltungsfaktor 4: „Einsatz-/Nutzungsgrad erweiterter Instrumente für

die Datenanalyse und die Informationsbereitstellung“. Der vierte Ge-staltungsfaktor wird ebenfalls durch zwei Variablen begründet, die ih-rerseits den Einsatz- bzw. Nutzungsgrad erweiterter Instrumente zum Zweck der Datenanalyse und der Informationsbereitstellung widerspie-geln (vgl. Tabelle 4). Zu diesen Instrumenten zählen sowohl Ad-hoc-

116 Tobias Bucher

Abfragen als auch der Gebrauch von Anwendungssystemen, die benut-zerdefinierte, mathematisch-statistische Analyse- und Simulationsmög-lichkeiten bereitstellen. Wie auch bei den anderen Gestaltungsfaktoren ist der Einsatz- bzw. Nutzungsgrad umso höher, je größer der durch-schnittliche Zielerreichungs- bzw. Erfüllungsgrad der beiden Variablen dieses Gestaltungsfaktors ist.

Tabelle 4. Variablen des vierten Gestaltungsfaktors

Gestaltungsfaktor 3: „Einsatz-/Nutzungsgrad erweiterter Instrumente für die Datenanalyse und die Informationsbereitstellung“ Variable 4.1 Analytische Informationen werden primär durch Ad-hoc-Abfragen

bzw. Instrumente des Ad-hoc-Reporting in den Prozesskontext eingebettet.

Variable 4.2 Auf Grundlage analytischer Informationen können im Prozesskon-text Simulationen, Auswirkungs- und/oder Sensitivitätsanalysen durchgeführt werden.

Die Gestaltungsfaktoren 3 und 4 beschreiben unabhängig voneinander

verschiedene Herangehensweisen bezüglich der Datenanalyse und der In-formationsbereitstellung. Verschiedene Autoren betonen, dass die er-wähnten einfachen und erweiterten Instrumente ein Kontinuum von Ana-lyse- und Präsentationstechniken darstellen (Chamoni u. Gluchowski 2004; Jones 2004). Unternehmen können dementsprechend sowohl bezüg-lich nur eines der beiden genannten Gestaltungsfaktoren als auch bezüglich beider Gestaltungsfaktoren gleichzeitig hohe Einsatz- bzw. Nutzungsgrade aufweisen.

5.2 Realisierungsformen

Auf Grundlage der im vorhergehenden Abschnitt beschriebenen Gestal-tungsfaktoren haben Bucher/Dinter darüber hinaus – ebenfalls im Kontext der bereits genannten explorativen Analyse – vier disjunkte Realisierungs-formen der prozessorientierten Informationslogistik ermittelt (Bucher u. Dinter 2008b).5 Diese Realisierungsformen ergeben sich aus wiederkeh- 5 Für die Identifikation der Realisierungsformen wurde eine hierarchische Clus-

teranalyse auf Grundlage der mittels der Regressionsmethode berechneten Fak-torenwerte der vier Gestaltungsfaktoren durchgeführt. Für die Fusionierung der Cluster wurde der Ward-Algorithmus verwendet, als Distanzmaß kam die quad-rierte Euklidische Distanz zum Einsatz. Das Dendrogramm, das den Fusionie-rungsalgorithmus graphisch darstellt, legt die Bildung von fünf Clustern als mutmaßlich optimale Lösung des Clustering-Problems nahe. Der fünfte Cluster


renden Mustern in den Gestaltungsfaktoren, die bei den in die Untersu-chung einbezogenen Unternehmen zu beobachten sind. Die Unterschiede zwischen den vier Realisierungsformen bestehen primär hinsichtlich der Ausprägungen der beiden Gestaltungsfaktoren 1 und 2 („Entwicklungs-stand der Informationsversorgung“ und „Integrationsgrad analytischer In-formationen in Prozesse“). Die Realisierungsformen 3 und 4 unterscheiden sich darüber hinaus auch hinsichtlich der Gestaltungsfaktoren 3 und 4 („Einsatz-/Nutzungsgrad einfacher Instrumente für die Datenanalyse und die Informationsbereitstellung“ und „Einsatz-/Nutzungsgrad erweiterter Instrumente für die Datenanalyse und die Informationsbereitstellung“):

Realisierungsform 1: „Ausgereifte prozessorientierte Informationslogis-tik“. Die erste Realisierungsform weist sowohl hinsichtlich des Ent-wicklungsstands der Informationsversorgung als auch hinsichtlich des Integrationsgrads analytischer Informationen in Prozesse hohe Werte auf. Des Weiteren ist diese Realisierungsform dadurch gekennzeichnet, dass primär erweiterte Instrumente für Datenanalyse und Informations-bereitstellung zum Einsatz kommen. Diese Realisierungsform weist folglich einen hohen Reifegrad der prozessorientierten Informationslo-gistik auf. Sowohl informationstechnische Fragestellungen im Zusam-menhang mit der Datenaufbereitung und der Informationsbereitstellung als auch fachlich-organisatorische Probleme der Integration von analyti-schen Informationen in den Kontext der Prozessausführung sind in die-ser Realisierungsform betrachtet und gelöst worden.

Realisierungsform 2: „Informationstechnisch getriebener Ansatz zur Etablierung der prozessorientierten Informationslogistik“. Die zweite Realisierungsform ist durch hohe Werte bezüglich des Entwicklungs-stands der Informationsversorgung einerseits und niedrige Werte be-züglich des Integrationsgrads analytischer Informationen in Prozesse gekennzeichnet. Gemäß den Ergebnissen der explorativen Untersuchung setzen Unternehmen, die dieser Realisierungsform zuzurechnen sind, sowohl einfache als auch erweiterte Instrumente für Datenanalyse und Informationsbereitstellung ein. Auf Grund des stark technisch getriebe-nen Ansatzes werden fachlich-organisatorische Fragestellungen der Einbettung analytischer Informationen in Prozesse nur mit untergeord-neter Priorität adressiert. Dementsprechend weist diese Realisierungs-

umfasst nur zwei Unternehmen, wobei diese beiden Beobachtungen als Ausrei-ßer zu charakterisieren sind. Dementsprechend werden in diesem Artikel nur vier Realisierungsformen der prozessorientierten Informationslogistik unter-schieden. Ein Überblick über die verwendeten Methodik findet sich wiederum bspw. bei Backhaus et al. (Backhaus et al. 2006).

118 Tobias Bucher

form nur eine mittelhohe Reife der prozessorientierten Informationslo-gistik auf.

Realisierungsform 3: „Fachlich-organisatorisch getriebener Ansatz zur Etablierung der prozessorientierten Informationslogistik unter Berück-sichtigung einfacher Instrumente für Datenanalyse und Informationsbe-reitstellung“. Bezüglich der ersten beiden Gestaltungsfaktoren verhalten sich die beiden Realisierungsformen 3 und 4 genau gegensätzlich zur zweiten Realisierungsform. Die beiden Realisierungsformen 3 und 4 weisen hohe Werte bezüglich des Integrationsgrads analytischer Infor-mationen in Prozesse und niedrige Werte bezüglich des Entwicklungs-stands der Informationsversorgung auf. Damit kann auch diesen beiden Gestaltungsfaktoren eine mittlere Reife der prozessorientierten Infor-mationslogistik attestiert werden, wobei der Fokus auf der Betrachtung fachlich-organisatorischer Fragestellungen liegt. Informationstechnische Belange werden erst in zweiter Linie adressiert. Zusätzlich unterschei-den sich die beiden Realisierungsformen 3 und 4 hinsichtlich ihrer He-rangehensweisen bezüglich der Datenanalyse und der Informationsbe-reitstellung. Unternehmen, die gemäß der explorativen Untersuchung der dritten Realisierungsform zuzurechnen sind, setzten hierfür sowohl einfache wie auch erweiterte Instrumente ein.

Realisierungsform 4: „Fachlich-organisatorisch getriebener Ansatz zur Etablierung der prozessorientierten Informationslogistik unter Berück-sichtigung erweiterter Instrumente für Datenanalyse und Informations-bereitstellung“. Im Unterschied zur dritten Realisierungsform setzen Unternehmen, die dieser vierten Realisierungsform zuzurechnen sind, ausschließlich erweiterte Instrumente für Datenanalyse und Informati-onsbereitstellung ein, d. h. Ad-hoc-Abfragen sowie mathematisch-sta-tistische Analysen und Simulationsmöglichkeiten. Abgesehen von die-sem Unterschied entsprechen sich die Charakterisierungen der dritten und der vierten Realisierungsform der prozessorientierten Informati-onslogistik.

Aus den Ergebnissen der explorativen Untersuchung lässt sich die Hy-pothese ableiten, dass zumindest zwei unterschiedliche Entwicklungspfade bestehen, auf welchen Unternehmen eine hohe Reife der prozessorientier-ten Informationslogistik (Realisierungsform 1) anstreben bzw. erreichen können. Hierbei gibt es zwei Handlungsfelder: In technischer Hinsicht sind die notwendigen Vorkehrungen zu treffen, um einen hohen Entwicklungs-stand der Informationsversorgung zu erreichen. In fachlich-organisatori-scher Hinsicht sind die erforderlichen Schritte zu unternehmen, um einen hohen Integrationsgrad analytischer Informationen in Prozesse realisieren zu können. Die Ergebnisse der in diesem Abschnitt dargestellten explora-


tiven Untersuchung lassen darauf schließen, dass viele Unternehmen die beiden Handlungsfelder sequentiell adressieren. Realisierungsform 2 stellt in diesem Zusammenhang den technisch getriebenen Ansatz dar, die Rea-lisierungsformen 3 und 4 repräsentieren hingegen die fachlich-organisato-risch getriebene Herangehensweise. Ob ein Unternehmen in einem einzi-gen Schritt von einem geringen zu einem hohen Reifegrad der prozess-orientierten Informationslogistik gelangen kann, d. h. beide Handlungsfel-der simultan zu adressieren vermag, kann auf Grund der Ergebnisse der explorativen Untersuchung nicht beantwortet werden.

Abbildung 3 zeigt die Realisierungsformen, die assoziierten Reifegrade sowie die postulierten Entwicklungslinien der prozessorientierten Infor-mationslogistik.

Entw

icklu

ngss

tand

derI

nfor

mat

ions

vers

orgu

ngH

och Mittlere Reife

der prozessorientiertenInformationslogistik

Hohe Reifeder prozessorientierten

Informationslogistik

Nie

drig Geringe Reife

der prozessorientiertenInformationslogistik

Mittlere Reifeder prozessorientierten

Informationslogistik

Niedrig Hoch

Integrationsgrad analytischer Informationen in Prozesse

Realisierungs-form 1




Abb. 3. Realisierungsformen, Reifegrade und Entwicklungslinien der prozess-orientierten Informationslogistik (in Anlehnung an Bucher u. Dinter 2008b)

6 Vorgehensmodell für die Einführung der prozessorientierten Informationslogistik

Im Rahmen eines Expertenworkshops, an dem Vertreter unterschiedlicher Unternehmen aus den Branchen Finanzdienstleistungen, Energieversor-gung und Maschinenbau teilnahmen, wurde ein Vorgehensmodell zur Ein-führung der prozessorientierten Informationslogistik erarbeitet. Als Grund-lage für die gemeinsame Arbeit wurden die beteiligten Experten in das in

120 Tobias Bucher

diesem Artikel skizzierte Verständnis der prozessorientierten Informati-onslogistik, deren Anwendungsfälle und Nutzenpotenziale sowie Gestal-tungsfaktoren und Realisierungsformen eingeführt. Weiterhin lag ein Ak-tivitätskatalog vor, in welchem die Aktivitäten etablierter Methoden für die Prozessneu- und -umgestaltung sowie für die Informationsbedarfsanalyse dokumentiert waren.

Das im Rahmen des Expertenworkshops erarbeitete Vorgehensmodell ist in Abb. 4 dargestellt. Das Modell umfasst 15 Aktivitäten (in Abb. 4 so-wie im folgenden Text mit A01 bis A15 bezeichnet), welche sich zum Zweck der Strukturierung wiederum in sieben Phasen einteilen lassen.

Abb. 4. Vorgehensmodell zur Einführung der prozessorientierten Informationslo-gistik (Bucher 2007b)

Im Folgenden werden die einzelnen Phasen des Vorgehensmodells dis-kutiert (Bucher 2007b):

Phase I: „Projektinitialisierung“. Die erste Phase umfasst die beiden Ak-tivitäten A01 („Business Case erstellen“) und A02 („Projektteam aufset-zen“). Damit widmet sich diese Phase vornehmlich Fragestellungen, die im Zusammenhang mit dem Management bzw. der Administration des Einführungsprojekts für prozessorientierte Informationslogistik stehen. Bezüglich der Ausgangslage wird unterstellt, dass die politisch-kultu-rellen Voraussetzungen für die Einführung der prozessorientierten In-formationslogistik im Unternehmen bereits geschaffen sind, indem die Relevanz des Themas aufgezeigt, Nutzenpotenziale kommuniziert und Unterstützung für das Projekt mobilisiert wurden.


Phase II: „Ist-Analyse Informationsversorgung“. Die zweite Phase um-fasst lediglich die Aktivität A03 („Ist-Zustand der Informationsversor-gung bestimmen“). Diese Aktivität kann nebenläufig zu den Phasen III, IV und V („Ist-Analyse Prozesse“, „Soll-Entwurf Prozesse“ und „Soll-Entwurf Informationsversorgung“) durchgeführt werden und umfasst die Aufnahme und Analyse des derzeitigen Zustands der Informations-versorgung. Die Ergebnisse der Analyse werden in Form einer Informa-tionslandkarte dokumentiert, welche wiederum einen wesentlichen Input für die Phase VI („Konsolidierung“) darstellt.

Phase III: „Ist-Analyse Prozesse“. Die dritte Phase umfasst die beiden Aktivitäten A04 („Ist-Prozesslandschaft analysieren“) und A05 („Pro-zesse identifizieren“). Zunächst werden die bestehenden Prozesse und deren wechselseitige Abhängigkeiten untersucht sowie dokumentiert. Die Prozesslandkarte des Unternehmens bzw. des untersuchten Unter-nehmens-/Geschäftsbereichs stellt einen wesentlichen Output der ersten Aktivität dieser Phase dar. Darauf aufbauend sind in einem Bewertungs- und Priorisierungsschritt diejenigen Prozesse auszuwählen, die im wei-teren Projektverlauf mit dem Ziel umgestaltet werden sollen, prozessin-härente operative Entscheidungen durch eine integrierte Bereitstellung relevanter analytischer Informationen zu unterstützen.

Phase IV: „Soll-Entwurf Prozesse“. Die vierte Phase umfasst die zwei Aktivitäten A06 („Prozesse und Rahmenbedingungen verstehen / analy-sieren“) und A07 („Prozessvision entwickeln“). Ziel der Aktivitäten die-ser Phase ist, die in der vorangehenden Phase ausgewählten Prozesse zunächst detailliert zu analysieren und zu verstehen sowie anschließend erste Ansatzpunkte für die Prozessverbesserung zu identifizieren. Dies schließt die Definition von Prozessleistungen und Prozesszielen sowie die Entwicklung von Empfehlungen für die (Grob-) Gestaltung der Pro-zessabläufe mit ein.

Phase V: „Soll-Entwurf Informationsversorgung“. Die fünfte Phase um-fasst die drei Aktivitäten A08 („Informationsbedarf ermitteln“), A09 („Informationen homogenisieren und abstimmen“) sowie A10 („Quell-systeme bestimmen / analysieren“). Aufbauend auf der in der vorange-henden Phase entwickelten Prozessvision sind sodann diejenigen Infor-mationen zu identifizieren, die für die Entscheidungsunterstützung im Rahmen der Prozessausführung wesentlich sind. Weiterhin sind Berech-nungs-, Darstellungs- und Entscheidungsregeln zu definieren, Termi-nologien zu harmonisieren, die Informationsbedarfe in fachlicher wie technischer Hinsicht abzustimmen sowie die zugrunde liegenden Quell-daten und Quellsysteme festzulegen.

122 Tobias Bucher

Phase VI: „Konsolidierung“. Die sechste Phase umfasst ausschließlich die Aktivität A11. Diese Aktivität führt die beiden nebenläufigen Akti-vitätsablauffolgen „Ist-Analyse Informationsversorgung“ (Phase II) so-wie „Ist-Analyse Prozesse“, „Soll-Entwurf Prozesse“ und „Soll-Entwurf Informationsversorgung (Phasen III, IV und V) wieder zusammen. Des Weiteren werden die Ergebnisse der vorangehenden Phasen (Informati-onslandkarte, Prozesslandkarte, Prozessentwürfe sowie Spezifikationen der Informationsbedarfe für die prozessinhärente Entscheidungsunters-tützung) als Input für die anschließende Veränderungsphase konsoli-diert.

Phase VII: „Veränderung“. Die siebte Phase umfasst die vier Aktivitäten A12 („Veränderungsansätze bestimmen“), A13 („Soll-Prozesse und Soll-Informationsversorgung bestimmen“) A14 („Technische Voraus-setzungen für Informationsversorgung schaffen“) und A15 („Umgestal-tete Prozesse implementieren“). Aufbauend auf den konsolidierten Er-gebnissen aus Aktivität A11 sind nun konkrete Veränderungsansätze für die Prozessneu- und -umgestaltung zu entwickeln. Sofern im Rahmen von Aktivität A12 kein definitives Zielszenario für die Prozessge-staltung bestimmt werden kann (d. h. sofern unter den betroffenen Sta-keholdern keine Einigung über die Prozessgestaltung und die infor-matorische Unterstützung erzielt werden kann), sind die Anforderungen bzw. Rahmenbedingungen entsprechend anzupassen bzw. neu zu for-mulieren. Anschließend ist die Aktivitätenfolge A07 bis A12 abermals zu durchlaufen. Auf Grundlage eines definitiven Zielszenarios sind so-dann die Soll-Prozesse und die erforderliche Soll-Informationsversor-gung (detailliert) zu definieren, die technischen Voraussetzungen für die Informationsversorgung zu schaffen und die umgestalteten Prozesse zu implementieren.

Das Vorgehensmodell für die Einführung der prozessorientierten Infor-mationslogistik deckt somit Fragestellungen aus den Bereichen der Identi-fikation, Definition und Modellierung von Prozessen (Prozessmana-gement-Phase A, vgl. Abschn. 2.2) sowie der Implementierung und Aus-führung von Prozessen (Prozessmanagement-Phase B) ab. Bei wiederhol-ter Anwendung werden implizit auch Aspekte der Weiterentwicklung von Prozessen (Prozessmanagement-Phase D) adressiert. Fragestellungen im Zusammenhang mit der Überwachung und Steuerung von Prozessen (Pro-zessmanagement-Phase C) werden hingegen nicht thematisiert.


7 Fazit und Ausblick

Im diesem Artikel wurden mit der prozessorientierten Informationslogistik einerseits und der Überwachung und Analyse der Prozessausführung ande-rerseits zwei unterschiedliche Blickrichtungen auf die Integration von Pro-zessorganisation und Informationslogistik aufgezeigt sowie anhand der je-weils betroffenen Phasen des Prozessmanagements voneinander abge-grenzt.

Prozessorientierte Informationslogistik adressiert die Unterstützung der Ausführung von betrieblichen Prozessen durch die Einbettung analyti-scher, entscheidungsunterstützender Informationen in den Kontext der Prozessausführung. Davon zu unterscheiden sind Konzepte, die auf die Überwachung und Analyse der Prozessausführung abzielen, wie bspw. Business Activity Monitoring oder Business Performance Management. Derartige Ansätze wurden explizit aus den Betrachtungen im Rahmen die-ses Artikels ausgeschlossen. Im weiteren Verlauf des Artikels wurden so-dann die Grundannahmen, die potenziellen Nutzeneffekte, die in der un-ternehmerischen Praxis beobachtbare Ausgestaltung der prozessorien-tierten Informationslogistik sowie ein mögliches Vorgehensmodell für die Einführung des Konzepts dargestellt.

Aus den aktuellen wissenschaftlichen Veröffentlichungen zum Themen-feld der prozessorientierten Informationslogistik sowie aus Rückmeldun-gen und Interessensbekundungen seitens der Praxis wird deutlich, dass das Themenfeld derzeit noch hohes Forschungs- und Entwicklungspotenzial aufweist. Der vorliegende Artikel stellt eine Zusammenfassung verschie-dener Forschungsarbeiten dar, die innerhalb des letzten Jahres entstanden sind. Obgleich diese Forschungsarbeiten bereits ein breites Spektrum der prozessorientierten Informationslogistik abdecken, existieren nach wie vor viele Themenbereiche, die lohnenswerte Forschungsmöglichkeiten bieten. Explizit zu nennen ist in diesem Zusammenhang bspw. die Entwicklung einer ganzheitlichen und praxiserprobten Methode für die Einführung der prozessorientieren Informationslogistik. Diese Methode sollte den Unter-nehmen einerseits eine systematische Anleitung für die Identifikation, Analyse und Spezifikation prozessbezogener Informationsbedarfe bieten. Darüber hinaus sollten auch Fragestellungen im Zusammenhang mit der Umgestaltung der betrieblichen Prozesse, deren Ausführung durch die in-tegrierte Bereitstellung analytischer Informationen unterstützt werden soll, adressiert werden. Aber auch Fragestellungen im Zusammenhang mit möglichen Varianten der technischen Umsetzung des Konzepts erscheinen interessant. In diesem Zusammenhang sollte auch untersucht werden, wel-che kommerziellen Softwarelösungen für die Realisierung der prozess-

124 Tobias Bucher

orientierten Informationslogistik geeignet sind bzw. die erforderlichen Funktionalitäten bereitstellen.

Literatur

Adams, P.: Business Activity Monitoring - What's Going on?, in: Manufacturing Engineer 81 (2002) 6, S. 282-283.

Armistead, C.; Pritchard, J.-P.; Machin, S.: Strategic Business Process Manage-ment for Organizational Effectiveness, in: Long Range Planning 32 (1999) 1, S. 96-106.

Azvine, B.; Cui, Z.; Nauck, D.; Majeed, B.: Real Time Business Intelligence for the Adaptive Enterprise, in: IEEE Computer Society (Hrsg.): Proceedings of the 8th IEEE International Conference on E-Commerce Technology and the 3rd IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services (CEC/EEE'06), IEEE Computer Society, Los Alamitos 2006, S. 29-39.

Backhaus, K.; Erichson, B.; Plinke, W.; Weiber, R.: Multivariate Analysemetho-den - Eine anwendungsorientierte Einführung, 11. Aufl., Springer, Berlin 2006.

Becker, J.; Kahn, D.: Der Prozess im Fokus, in: Becker J.; Kugeler M. e.a. (Hrsg.): Prozessmanagement - Ein Leitfaden zur prozessorientierten Organisationsge-staltung, Springer, Berlin 2005, S. 3-16.

Bruckner, R.; List, B.; Schiefer, J.: Striving Toward Near Real-Time Data Integra-tion for Data Warehouses, in: Kambayashi Y.; Winiwarter W. e.a. (Hrsg.): Data Warehousing and Knowledge Discovery (Proceedings of the Fourth International Conference, DaWaK 2002, Aix-en-Provence, France, September 4-6, 2002), Springer, Berlin 2002, S. 317-326.

Bucher, T.: Process-Centric Business Intelligence - Case Study, Interner Arbeits-bericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2007a.

Bucher, T.: Prozess-zentrierte Business Intelligence, in: Bucher T.; Dinter B. e.a. (Hrsg.): Ergebnisdokumentation 7. CC EIW Workshop, Institut für Wirt-schaftsinformatik, Universität St. Gallen, St. Gallen 2007b, S. 21-44.

Bucher, T.; Dinter, B.: Anwendungsfälle der Nutzung analytischer Informationen im operativen Kontext, in: Tagungsband der Multikonferenz Wirtschaftsin-formatik 2008 (MKWI 2008), 2008a.

Bucher, T.; Dinter, B.: Process Orientation of Information Logistics - An Empiri-cal Analysis to Assess Benefits, Design Factors, and Realization Approaches, in: IEEE Computer Society (Hrsg.): Proceedings of the 41th Hawaii Interna-tional Conference on System Sciences (HICSS-41), 2008b.

Bucher, T.; Winter, R.: Classification of Business Process Management Approa-ches - An Exploratory Analysis, in: BIT - Banking and Information Techno-logy 7 (2006) 3, S. 9-20.


Bucher, T.; Winter, R.: Realisierungsformen des Geschäftsprozessmanagements - Eine explorative Klassifikationsanalyse, in: Oberweis A.; Weinhardt C. e.a. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering, Universitäts-verlag Karlsruhe, Karlsruhe 2007, S. 695-712.

Byrne, B.: Structural Equation Modeling with AMOS – Basic Concepts, Applica-tions, and Programming, Lawrence Erlbaum Associates, Mahwah 2001.

Chamoni, P.; Gluchowski, P.: Integrationstrends bei Business-Intelligence-Systemen - Empirische Untersuchung auf Basis des Business Intelligence Ma-turity Model, in: Wirtschaftsinformatik 46 (2004) 2, S. 119-128.

Chemburkar, A.; Keny, P.: Trends in Operational BI, http://www.dmreview.com/ article_sub.cfm?articleId=1057833, 04.12.2007.

Coase, R.: The Nature of the Firm, in: Economica 4 (1937) 16, S. 386-405. Davenport, T.: Process Innovation - Reengineering Work through Information

Technology, Harvard Business School Press, Boston 1993. Davenport, T.; Glaser, J.: Just-in-Time Delivery Comes to Knowledge Manage-

ment, in: Harvard Business Review 80 (2002) 7, S. 107-111. Davis, J.: Right-Time Business Intelligence - Optimizing the Business Decision

Cycle, http://www.teradata.com/library/pdf/eb4762.pdf, 04.12.2007. DeToro, I.; McCabe, T.: How to Stay Flexible and Elude Fads, in: Qualiy Progress

30 (1997) 3, S. 55-60. Dinter, B.; Bucher, T.: Business Performance Management, in: Chamoni P.; Glu-

chowski P. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technologien und -Anwendungen, Springer, Berlin et al. 2006, S. 23-50.

Ericson, J.: Process or Data-Centric, http://www.bireview.com/bnews/2600306-1.html, 04.12.2007.

Fritz, C.-T.: Die Transaktionskostentheorie und ihre Kritik sowie ihre Beziehung zum soziologischen Neo-Institutionalismus, Peter Lang, Frankfurt 2006.

Gaitanides, M.: Prozessorganisation, in: Schreyögg G.; von Werder A. (Hrsg.): Handwörterbuch Unternehmensführung und Organisation, Schäffer-Poeschel, Stuttgart 2004, S. 1208-1218.

Gaitanides, M.: Prozessorganisation - Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen, 2. Aufl., Verlag Franz Vahlen, Mün-chen 2007.

Gassman, B.: Management Update - BAM Enhances Operationally Focused Busi-ness Intelligence, Research Report ID G00121953, Gartner, Stamford 2004.

Gassman, B.; Schlegel, K.; Beyer, M.: Survey Shows BI Users Want Fresher Da-ta, Research Report ID G00142718, Gartner, Stamford 2006.

Gile, K.; Russom, P.; Moore, C.; Teubner, C.: The Emergence of Process-Centric BI, Forrester Research, Cambridge 2004.

Gile, K.; Teubner, C.; Moore, C.; Fossner, L.: Business Intelligence Meets BPM in the Information Workplace, Forrester Research, Cambridge 2006.

Gluchowski, P.; Kemper, H.-G.: Quo Vadis Business Intelligence?, in: BI-Spektrum 1 (2006) 1, S. 12-19.

Hammer, M.: The Agenda - What Every Business Must Do to Dominate the De-cade, Crown Business, New York 2001.

126 Tobias Bucher

Hammer, M.; Champy, J.: Reengineering the Corporation - A Manifest for Busi-ness Revolution, HarperCollins Publishers, New York 1993.

Harrington, J.: Business Process Improvement - The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness, McGraw-Hill, New York 1991.

Herschel, G.; Burton, B.: The Four Styles of Integrating Analytics into Business Processes, Research Report ID G00139727, Gartner, Stamford 2006.

Imhoff, C.: Streamlining Processes for Front-Line Workers - Adding Business In-telligence for Operations, White Paper, Intelligent Solutions, Boulder 2005.

Inmon, W.: Accessing the Data Warehouse from the Operational Environment, White Paper, Inmon Data Systems, Castle Rock 2000.

Jones, K.: Populating the Accounting Data Warehouse, in: Anandarajan M.; Anandarajan A. e.a. (Hrsg.): Business Intelligence Techniques - A Perspective from Finance and Accounting, Springer, Berlin 2004, S. 41-54.

Klesse, M.; von Maur, E.: Informationsintegration für Entscheidungsprozesse im Corporate Knowledge Center, in: von Maur E.; Winter R. (Hrsg.): Data War-ehouse Management - Das St. Galler Konzept zur ganzheitlichen Gestaltung der Informationslogistik, Springer, Berlin 2003, S. 25-46.

Marjanovic, O.: The Next Stage of Operational Business Intelligence - Creating New Challenges for Business Process Management, in: IEEE Computer So-ciety (Hrsg.): Proceedings of the 40th Annual Hawaii International Conferen-ce on System Sciences (HICSS-40), IEEE Computer Society, Los Alamitos 2007.

Oehler, K.: Corporate Performance Management mit Business Intelligence Werk-zeugen, Hanser, München 2006.

Osterloh, M.; Frost, J.: Prozessmanagement als Kernkompetenz, Gabler, Wiesba-den 1998.

Ould, M.: Business Processes - Modelling and Analysis for Re-Engineering and Improvement, John Wiley & Sons, Chichester 1995.

Porter, M.: Competitive Advantage - Creating and Sustaining Superior Perfor-mance, Free Press, New York 2004.

Rüegg-Stürm, J.: Das neue St. Galler Management-Modell - Grundkategorien ei-ner integrierten Managementlehre - Der HSG-Ansatz, 2. Aufl., Haupt, Bern 2003.

Schlegel, K.: Deliver Process-Driven Business Intelligence with a Balanced BI Platform, Gartner, Research Report ID G00139377, Stamford 2005.

Schmelzer, H.; Sesselmann, W.: Geschäftsprozessmanagement in der Praxis - Kunden zufrieden stellen, Produktivität steigern, Wert erhöhen, Hanser, Mün-chen 2006.

Watson, H.: Real Time - The Next Generation of Decision-Support Data Mana-gement, in: Business Intelligence Journal 10 (2005) 3, S. 4-6.

White, C.: A Process-Centric Approach to Business Intelligence, http://www.dm review.com/issues/20061201/1069958-1.html, 04.12.2007.

Williamson, O.: Transaction-Cost Economics - The Governance of Contractual Relations, in: Journal of Law and Economics 22 (1979) 2, S. 233-261.


Williamson, O.: The Economics of Organization - The Transaction Cost App-roach, in: The American Journal of Sociology 87 (1981) 3, S. 548-577.

Williamson, O.: Comparative Economic Organization - The Analysis of Discrete Structural Alternatives, in: Administrative Science Quarterly 36 (1991) 2, S. 269-296.

Zairi, M.: Business Process Management - A Boundaryless Approach to Modern Competitiveness, in: Business Process Management 3 (1997) 1, S. 64-80.

7 Informationslogistik-Systemarchitekturen

Gerrit Lahrmann, Florian Stroh

Universität St.Gallen

1 Einleitung ....................................................................................... 129 2 Anforderungsrahmen und Einflussfaktoren .................................... 130 3 Architekturtypen der Informationslogistik ..................................... 138 4 Bewertung von Systemarchitekturen .............................................. 148 5 Ausblick .......................................................................................... 154

Literatur .......................................................................................... 154

1 Einleitung

Die Informationslogistik (IL) beschäftigt sich mit der „Planung, Steuerung und Kontrolle der Gesamtheit der Datenflüsse, die über eine Betrachtungs-einheit hinausgehen, sowie der Speicherung und Aufbereitung dieser Da-ten“ (vgl. Kap. 1). Kernpunkt unseres Verständnisses der IL ist die Be-trachtung von übergreifenden Datenflüssen zur analytischen Nutzung die-ser Daten. Das Ziel der Informationslogistik ist also die Bereitstellung re-levanter Informationen in geeigneter Qualität zur effektiven und effizien-ten Befriedigung von Informationsbedarfen, die im Rahmen der unter-nehmerischen Entscheidungsfindung entstehen. Als technische Basis für die Befriedigung der analytischen Informationsbedarfe dienen hierbei Sys-teme der Informationslogistik, d. h. Informationssysteme. Gemäß (IEEE 2000) sind Systeme zur Erfüllung bestimmter Aufgaben organisierte Komponenten. Informationssysteme sind soziotechnische Systeme, die zum Ziel der zieladäquaten Bereitstellung von Informationen eingesetzt werden (vgl. Krcmar 2005, S. 25). In diesem Beitrag werden Informations-systeme aus dem Data Warehouse (DWH)-Umfeld sowie deren Architek-turen, die sich allgemein als Anordnung von Komponenten, deren Bezie-hungen zueinander sowie deren Gestaltungsregeln definieren (IEEE 2000),

130 Gerrit Lahrmann, Florian Stroh

untersucht und hinsichtlich ihrer Eignung in der Informationslogistik be-wertet.

Dieser Beitrag ist wie folgt aufgebaut: In Abschn. 2 werden Anforde-rungen und Einflussfaktoren hinsichtlich der Auswahl von Systemarchi-tekturen der Informationslogistik vorgestellt. Abschn. 3 beschreibt rele-vante Architekturtypen und Erweiterungsformen dieser Architekturtypen, die in Abschn. 4 bewertet werden. Ein kurzer Ausblick in Abschn. 5 rundet den Beitrag ab.

2 Anforderungsrahmen und Einflussfaktoren

In diesem Abschnitt wird ein für die Untersuchung und Bewertung der Systemarchitekturen erforderlicher Anforderungsrahmen konstruiert. Im Anschluss an die Konstruktion werden die einzelnen Anforderungen de-tailliert betrachtet.

Zentrale Bereiche im Kontext einer Untersuchung relevanter System-architekturen stellen zum einen die Qualität des Informationsangebots (im folgenden Datenqualität1 genannt), zum anderen die Qualitätseigenschaften der Architektur per se dar. Der Begriff der Datenqualität wird in der Lite-ratur zumeist als mehrdimensionales Konzept betrachtet (Wand u. Wang 1996). Themen wie Aktualität, Vollständigkeit, Konsistenz oder Transpa-renz werden in der Arbeit von (Wand u. Wang 1996) zu den wesentlichen Anforderungen eines Unternehmens im Bereich der Datenqualität gezählt (vgl. auch Kap. 10).

Neben der Datenqualität existieren Anforderungen an die Systemarchi-tektur selbst, deren unterschiedliche Erfüllungsgrade wiederum Auswir-kungen auf die gesamte Informationslogistik haben können. Als Rahmen hierfür wird im weiteren Verlauf des Kapitels die Architecture Tradeoff Analysis Method (ATAM) verwendet, anhand derer eine Architektur unter Berücksichtigung der vier Qualitätsanforderungen bzw. Qualitätsattribute Performanz, Modifizierbarkeit und Flexibilität, Verfügbarkeit sowie Si-cherheit bewertet wird (Clements et al. 2002, S. 51). Diese Anforderungen werden unter dem Begriff der Systemqualität betrachtet.

1 Die Begriffe Datenqualität und Informationsqualität werden häufig synonym

verwendet (Brändli et al. 2004).

Informationslogistik-Systemarchitekturen 131

Tabelle 1. Terminologische Gegenüberstellung von Einflussfaktoren aus (Ariya-chandra u. Watson 2005; Jung 2006; Wilhelmi 2006)

In diesem Buch verwendeter Begriff

Ariyachandra u. Watson 2005 Jung 2006 Wilhelmi 2006

Strategische Bedeutung

Strategische Ausrich-tung, Wichtigkeit

Relevanz -/-

Ressourcen Ressourcenbeschrän-kungen

-/- Budgetumfang

Auswertung analytischer Daten

Umfang nicht routi-nierter Datenanalysen

Periodizität Auswertungssysteme

Horizontale Informationsin-tegration

Kooperation zwischen Organisationseinheiten

Horizontale Informations-integration

Bedürfnis nach Geschäftsbereich übergreifenden Auswertungen

Vertikale Informations-integration

-/- Granularität Management-unterstützung

Verwendungs-form

-/- Verwendungs-form (create, read, update, delete)

-/-

In der Literatur zur Informationslogistik werden (zusätzlich zu den be-reits vorgestellten Anforderungen) noch weitere Einflussfaktoren auf eine Architekturauswahl genannt (Ariyachandra u. Watson 2005; Jung 2006; Wilhelmi 2006). Deshalb wurde der Anforderungsrahmen um weitere As-pekte ergänzt, die zwar nicht zwingend als klassische Anforderungen zu sehen sind (wie z. B. „Verwendungsform“), dennoch aber erheblichen Ein-fluss auf die Architekturwahl haben können. Da die o. g. Autoren teilweise unterschiedliche Begrifflichkeiten benutzen, findet in Tabelle 1 ein termi-nologischer Abgleich statt. Die dort abgeleiteten Begriffe werden im Wei-teren als Einflussfaktoren bzw. Bewertungskriterien verwendet.

Abbildung 1 stellt den zuvor eingeführten Anforderungsrahmen für die anschließende Bewertung der einzelnen Architekturtypen dar.

Die folgenden Abschnitte erläutern die einzelnen Anforderungen bzw. Einflussfaktoren, der Bezug zu den Systemarchitekturen wird im Zuge ei-ner Architekturbewertung in Abschn. 4 hergestellt.


Horizontale Informationsintegration

Vertikale Informationsintegration

Strategische Bedeutung

Ressourcen

Verwendungsform

Aktualität

Vollständigkeit

Konsistenz

Transparenz

Datenqualität

Performanz

Flexibilität

Verfügbarkeit

Sicherheit

Systemqualität

Weitere Einflussfaktoren

Abb. 1. Anforderungsrahmen für die Bewertung der Systemarchitekturen

2.1 Datenqualität

Im Folgenden werden die Anforderungen näher betrachtet, die sich unter dem Begriff Datenqualität subsumieren lassen. Eine schlechte Datenqua-lität kann weit reichende Auswirkungen auf den Erfolg von Unternehmen haben. So entstehen US-Firmen Kosten, die auf Datenqualitätsprobleme zurückzuführen sind, in Höhe von über 600 Milliarden Dollar pro Jahr (Eckerson 2002).

2.1.1 Aktualität

Anforderungen bezüglich der Aktualität der Daten beziehen sich darauf, inwieweit die analytische Datenbasis den Zustand der Realität zu einem bestimmten Bezugszeitpunkt wiedergibt (Jung 2006, S. 111). Typische Da-tenaktualisierungsintervalle im Data Warehouse sind z. B. die monatliche, tägliche oder stündliche Aktualisierung. Die zur Verfügung gestellten ana-lytischen Informationen können jedoch niemals aktueller als die operative Datenbezugsbasis sein. „Real-Time Business Intelligence“ bietet die glei-chen Funktionalitäten wie herkömmliche Business Intelligence, der Daten-bezug erfolgt jedoch aus den operativen Systemen ohne zeitliche Verzöge-rung (Azvine et al. 2005). Die Forderungen nach „Real-Time Analytics“ oder auch „Real-Time Business Intelligence“ sind dabei bei weitem nicht


neu (Brobst u. Venkatesa 1999), jedoch immer noch aktuell (Bitterer et al. 2007). Betriebswirtschaftlich macht die Forderung nach der kostenin-tensiven Bereitstellung von Real-Time Business Intelligence nur dann Sinn, wenn auch die Entscheidungen, die auf den in Echtzeit bereitgestell-ten analytischen Daten basieren, zeitnah getroffen werden. Verschiedene Autoren relativieren daher diese Forderung und sprechen von Near-Time oder Right-Time Business Intelligence, also eine auf den jeweiligen Sach-verhalt passende Geschwindigkeit der Informationsbedarfsbefriedigung (Brobst 2005; Schelp 2006, S. 426).

2.1.2 Vollständigkeit

Unter dem Begriff der Vollständigkeit wird häufig der Anspruch verstan-den, alle relevanten Zustände und Entitäten innerhalb eines Informations-systems abzubilden (Wand u. Wang 1996; Bauer u. Günzel 2004, S. 44). Dies setzt voraus, dass Daten nicht mehr nur einzeln, sondern - zur besse-ren Interpretierbarkeit - als Kombinationen betrachtet werden. Genauso kann bspw. die Datenbereitstellung aus sämtlichen Unternehmensberei-chen in puncto Vollständigkeit von Bedeutung sein. Auch der Aspekt der Zeit bzw. der Informationshistorie wird zur Vollständigkeit gezählt. Die Notwendigkeit entsprechender historisierter Daten beispielsweise für Zeit-reihenanalysen über den gewünschten Zeitraum macht dies deutlich (Jung 2006, S. 119).

2.1.3 Konsistenz

Die Anforderung nach Konsistenz kann mehrere Aspekte umfassen. So wird beispielsweise zwischen der Konsistenz der Datenwerte, der Konsis-tenz der Repräsentation der Daten sowie der Konsistenz der physischen Repräsentation der Daten (Wand u. Wang 1996) unterschieden. Die Kon-sistenz der Datenwerte findet jedoch in der Literatur mit die höchste Be-achtung (Wand u. Wang 1996; Bauer u. Günzel 2004; Ariyachandra u. Watson 2005), daher wird im weiteren Verlauf dieses Kapitels nur dieser Aspekt betrachtet. Ziel einer konsistenten Datenhaltung ist es also, logi-sche Widersprüche zwischen Daten zu verhindern (Wand u. Wang 1996). Dies kann unter Rückgriff auf entsprechende Datenintegrationskonzepte ermöglicht werden, beispielsweise durch die Verwendung von einheitli-chen Stammdaten (u. a. Kundendaten als gemeinsame Datenbasis für das gesamte Unternehmen).


2.1.4 Transparenz

Die Transparenz der durch die analytischen Systeme zur Verfügung ge-stellten Daten ist eine weitere Dimension der Datenqualität. Die Transpa-renz beinhaltet die intrinsischen Qualitätsmerkmale Glaubwürdigkeit und Reputation (vgl. Pipino et al. 2002, S. 214). Die Glaubwürdigkeit ist Ge-genstand einer subjektiven Einschätzung durch die Fachanwender und wird direkt durch die Reputation, eine aus Erfahrung resultierende Ein-flussgröße, beeinflusst (Jung 2006, S. 115). In analytischen Informations-systemen werden Daten oftmals hochverdichtet betrachtet, so dass die ur-sprünglichen Datenquellen nicht mehr direkt erkennbar sind. Der Fachan-wender benötigt also noch weitere Daten, um den Ursprung eines Daten-satzes sowie seine Zusammensetzung zurückverfolgen und damit die Glaubwürdigkeit der Daten beurteilen zu können. Diese zusätzlichen Da-ten werden als Metadaten bezeichnet und in der Praxis oftmals vereinfacht als „Daten über Daten“ definiert (Kachur 2000, S. 37). Weitere detaillierte Informationen zu Metadaten finden sich in Kap. 9.

2.2 Systemqualität

In diesem Abschnitt werden Anforderungen, die sich dem Aspekt der Sys-temqualität zuordnen lassen, diskutiert.

2.2.1 Performanz

Unter dem Stichwort Performanz werden fachliche Anforderungen zu-sammengefasst, die die Antwortzeit auf Informationsanfragen von Endan-wendern oder auch die rechtzeitige Bereitstellung von Analyseergebnissen betreffen (Jung 2006, S. 110f.). Die für den Endanwender wahrnehmbare Performanz wird demzufolge maßgeblich durch das Antwortverhalten der Frontend-Analysesysteme beeinflusst. Betrachtet man jedoch den gesam-ten Prozess bis hin zur Bereitstellung der Informationen, so sind neben der Verarbeitung in den Analysesystemen auch die Extraktion der Daten aus den Vorsystemen, das Laden in das Data Warehouse und die Verarbeitung im Data Warehouse Vorgänge, die die Performanz wesentlich beeinflussen (vgl. Schelp 2006, S. 430). Um eine gute Performanz auch bei Verände-rung des Nutzungsverhaltens der analytischen Systeme gewährleisten zu können, muss eine Systemarchitektur skalierbar ausgelegt sein. Dies be-deutet insbesondere, dass die Systeme z. B. durch zusätzliche Hardware an größere Datenvolumina, höhere Benutzerzahlen und gestiegene Nutzung angepasst werden können, um so eine adäquate Antwortzeit und Pünkt-


lichkeit von Anfragen gewährleisten zu können (Ariyachandra u. Watson 2005, S. 17).

2.2.2 Flexibilität

Die Befriedigung analytischer Informationsbedarfe im Sinne der gesamt-heitlichen Betrachtung der Datenflüsse (vgl. Kap. 1) erfordert, dass sämtli-che verfügbaren Datenquellen als Teil einer Systemarchitektur der Infor-mationslogistik genutzt werden können. Technisch wird dieser fachliche Anspruch durch die Integrationsfähigkeit der Quellsysteme sichergestellt. Zur Verbindung der operativen Systeme untereinander werden seit einigen Jahren Enterprise Application Integration (EAI)-Werkzeuge eingesetzt, die als Hub oder Bus zwischen die zu verbindenden Systeme geschaltet wer-den und zwischen diesen vermitteln (Schelp 2006, S. 432). Generell wird eine möglichst geringe Anzahl von Systemschnittstellen als hilfreich ange-sehen, um die Wartbarkeit eines Systems zu verbessern und damit die Fle-xibilität zu erhöhen. Weiterhin ist sicherzustellen, dass die übergeordneten Systeme flexibel auf Änderungen in den Quellsystemen reagieren können (z. B. geänderte Schnittstellen auf Grund von Versionswechseln). Auch können geänderte analytische Informationsbedarfe Änderungen an den Quellsystemen erfordern. So muss z. B. bei einer Real-Time Business In-telligence Lösung sichergestellt werden, dass die analytischen Systeme kontinuierlich mit Daten aus den operativen Systemen versorgt werden (vgl. Azvine et al. 2005, S. 218).

2.2.3 Verfügbarkeit

Der Verfügbarkeitsanspruch an analytische Systeme gleicht sich dem der operativen Systeme zusehends an (vgl. Kap. 6). So existieren beispiels-weise Schätzungen, dass 70 Prozent aller Unternehmen bis 2010 mit einem Ausfall eines operativen Systems zu rechnen haben, der auf ein analyti-sches System zurückzuführen ist und womöglich eine Unterbrechung eines operativen Prozesses zur Folge hat (Beyer et al. 2007). Derartige Annah-men beschleunigen Bemühungen, entsprechende Managementmechanis-men, z. B. Service-Level-Agreements (SLAs), die schon seit Längerem für analytische Systeme existieren, noch weiter zu forcieren. Neben Aspekten wie der Datenqualität oder der Antwortzeit kann dadurch auch der Bereich der Verfügbarkeit abgedeckt werden. Teilweise wird die Verfügbarkeit der Systeme auch als Sicherheitsaspekt aufgefasst (siehe folgender Abschnitt).


2.2.4 Sicherheit

Dadurch, dass die Informationslogistik Daten aus unterschiedlichsten Quellen in einer integrierten und aufbereiteten Form zur Verfügung stellt und diese Daten damit einen entscheidenden Wettbewerbsfaktor darstellen, entstehen besonders hohe Anforderungen an den Schutz dieser Daten. Als zentrale Sicherheitsanforderungen sind hierbei beispielsweise Vertraulich-keit, Integrität und Verfügbarkeit zu sehen (vgl. Oppliger 1997, S. 10). Die Vertraulichkeit kann durch entsprechende Zugriffskontrollmechanismen sichergestellt werden. Es wird nur denjenigen Personen und Organisatio-nen Zugriff gewährt, die dafür berechtigt sind. Nur wenn auf Grund der Aufgaben eines Fachanwenders ein bestimmter Informationsbedarf be-steht, sollte Zugriff auf die notwendigen Informationen gewährt werden. Die Integrität erfordert, dass nur erlaubte und beabsichtigte Veränderungen an Daten vorgenommen werden können. Unter der Verfügbarkeit versteht man die Möglichkeit, dass der Zugriff auf gewünschte Informationen er-folgen kann und nicht, z. B. auf Grund von Systemausfällen, verhindert wird.

2.3 Weitere Einflussfaktoren

In diesem Abschnitt werden weitere Einflussfaktoren, die sich auf die Architekturauswahl auswirken können, vorgestellt. Die genannten Ein-flussfaktoren ergänzen die in den vorhergehenden Abschnitten beschriebe-nen Anforderungen an die Daten- und Systemqualität.

2.3.1 Strategische Bedeutung

Die Frage nach der strategischen Bedeutung eines Systems zur Informati-onslogistik im Unternehmen ist nicht als klassische Anforderung zu ver-stehen, gleichwohl können diverse Anforderungen und Einflussfaktoren wie z. B. die Verfügbarkeit oder der Ressourceneinsatz vom strategischen Stellenwert der Informationslogistik geprägt werden. Aspekte wie die Un-terstützung des Managements, das die Notwendigkeit einer unterneh-mensweiten Informationslogistik erkannt hat oder der Integrationsgrad der Informationsversorgung in die Geschäftsprozesse (vgl. Kap. 6) beeinflus-sen die strategische Bedeutung.

2.3.2 Ressourcen (Personal / Finanzierung)

Personalbedarf und finanzielle Mittel – kurzum der Ressourceneinsatz – sind bei der Architekturauswahl von erheblicher Bedeutung. Der Lebens-


zyklus eines Systems zur Umsetzung einer Informationslogistik im Unter-nehmen kann in die vier Phasen Erstentwicklung, Wartung, Betrieb sowie Außerbetriebnahme unterteilt werden (Herrmann 2006). Auch in (Ariya-chandra u. Watson 2005) wird bei der Betrachtung ausgewählter Architek-turtypen von einer Einteilung in unterschiedlichen Phasen ausgegangen. Ferner bestehen zwischen den Architekturtypen z. T. erhebliche Unter-schiede bezüglich des Ressourceneinsatzes. Dies lässt darauf schließen, dass vor der Einführung eines Systems zur Verfügung stehende Mittel in Form von Personal und Budgetumfang eine wesentliche Rolle bei der Fest-legung auf den Architekturtyp spielen.

2.3.3 Horizontale Informationsintegration

Aus dem Anspruch der Informationslogistik, Informationen bereichsüber-greifend zur Verfügung zu stellen, resultiert die Anforderung nach hori-zontal und vertikal durchgängiger Befriedigung von Informationsbedarfen (vgl. Picot et al. 2001, S. 181). Einen horizontal durchgängigen Informati-onsfluss stellt z. B. der Informationsaustausch entlang der Wert-schöpfungskette zwischen der Einkaufs- und der Produktionsabteilung in-nerhalb eines Unternehmens dar (Jung 2006, S. 30). Neben dem Informati-onsaustausch unternehmensinterner Betrachtungseinheiten findet hierbei ebenfalls die Kommunikation mit unternehmensexternen Einheiten Be-achtung. Dies spielt beispielsweise im Rahmen von komplexen Supply Chains oder von „Virtuellen Unternehmen“ eine Rolle (Jung 2006, S. 33).

2.3.4 Vertikale Informationsintegration

Die vertikale Informationsintegration umfasst den Aspekt des Informati-onsaustauschs zwischen strategischer, taktischer und operativer Ebene in-nerhalb eines Unternehmens oder einer Konzernstruktur (Gorry u. Scott Morton 1971, S. 33; Jung 2006). Die Rolle des Aggregationsgrades der In-formationen ist in diesem Zusammenhang von wesentlicher Bedeutung. Im Sinne der Informationslogistik zeichnet sich beispielsweise eine vertikal durchgängige Befriedigung von Informationsbedarfen durch die Versor-gung des strategischen Managements mit aggregierten Daten niedrigerer Organisationsebenen aus (vgl. Gorry u. Scott Morton 1971; Ariyachandra u. Watson 2005, S. 15). Dahingegen ist der Informationsbedarf auf operati-ver Ebene durch einen hohen Detailgrad sowie eine hohe Nutzungsfre-quenz gekennzeichnet. Ein weiteres Unterscheidungsmerkmal der einzel-nen Ebenen im Kontext der vertikalen Informationsintegration ist der Strukturierungsgrad der Entscheidungen, die auf den analytischen Daten basieren. Auf strategischer Ebene sind überwiegend unstrukturierte, auf


taktischer Ebene semistrukturierte und auf operativer Ebene strukturierte Entscheidungen vorzufinden (Gorry u. Scott Morton 1971).

2.3.5 Verwendungsform

Die Verwendungsform beschreibt die fachlichen Anforderungen bezüglich der Verwendung der Daten aus Sicht der Fachanwender (Jung 2006). Die klassische Verwendungsform ist die passive, rein informative Nutzung be-reits vorab verdichteter Daten, ohne dass die Datenbasis basierend auf den zuvor analysierten Daten verändert wird. Systeme, die eine aktive analyti-sche Komponente besitzen, werden als Active Data Warehouse bezeichnet. Ein Active Data Warehouse ermöglicht die ereignisgesteuerte, automati-sierte Entscheidungsfindung bei standardisierten Entscheidungsaufgaben und bei den routinemäßigen Elementen von semi-routinemäßigen Ent-scheidungsaufgaben. Ein Active Data Warehouse kann das Ergebnis von Entscheidungen direkt oder nach Bestätigung durch Anwender/Nutzer in das operative System übertragen. Dadurch wird ein Closed-Loop-Ent-scheidungs-Ansatz realisiert. In Abhängigkeit vom Ergebnis der Daten-analyse wird ggf. eine Aktion im operativen System ausgelöst (vgl. Thal-hammer et al. 2001, S. 242). Ein Active Data Warehouse ist nicht für alle Entscheidungssituationen geeignet. Insbesondere gut strukturierte Pro-blemstellungen aus dem operativen und taktischen Bereich können auto-matisiert verarbeitet werden. Schwach strukturierte strategische Entschei-dungen sind dagegen für das Konzept des Active Data Warehouse eher ungeeignet (Gelhoet u. Rieger 2005, S. 1414).

3 Architekturtypen der Informationslogistik

In diesem Abschnitt werden Architekturtypen und Erweiterungsformen der Architekturtypen als Systemarchitekturen der Informationslogistik be-schrieben. Die Auswahl orientiert sich an entsprechender Literatur und Studien Informationslogistik-naher Konzepte (Ariyachandra u. Watson 2005; Eckerson 2006).

3.1 Architekturtypen

Im Folgenden werden Architekturtypen für Systemarchitekturen der In-formationslogistik vorgestellt. Die dargestellten Architekturbeispiele gene-ralisieren jeweils eine Vielzahl in der Realität auftretender Architekturen und stellen insofern idealtypische Architekturmodelle dar. In der Literatur


werden auch andere Architekturtypen genannt; tendenziell sind dies jedoch meist Variationen der hier vorgestellten Architekturen (vgl. Ariyachandra u. Watson 2005, S. 11).

3.1.1 Unabhängige Data Marts

Unternehmen mit einem geringen Reifegrad der Informationslogistik (vgl. Burton u. Rayner 2007) weisen oftmals in einzelnen Organisationseinhei-ten unabhängig voneinander entwickelte Analysemöglichkeiten, bei-spielsweise in Form von Data Marts, auf. Sie erfüllen die relativ homoge-nen Anforderungen, für die sie in ihrer jeweiligen Organisationseinheit geschaffen wurden, Anforderungen wie z. B. die Schaffung einer „single version of the truth“ werden jedoch nicht erfüllt. Die Vorteile einer Archi-tektur mit unabhängigen Data Marts liegen darin, dass einzelne Unterneh-mensbereiche schrittweise bei Bedarf mit passenden Informationen ver-sorgt werden können, es entstehen dabei keine zusätzlichen Aufwände wie z. B. für die Abstimmung mit anderen Geschäftsbereichen. Entsteht jedoch der Bedarf, auch bereichsübergreifende, kombinierte Analysen zu erstel-len, so gelangt man schnell an die Grenzen dieser Architektur: Die Daten sind in einer siloartigen Struktur abgelegt, Datendefinitionen sind inkonsis-tent und die Benutzung von unterschiedlichen Dimensionen und Fakten er-schwert eine übergreifende Analyse.

ETL

Data MartQuellsystem1

Quellsystem2

Quellsystem3

Data Mart

Data Mart

Sales-Analysen

Finanz-Analysen

HR-Analysen

Abb. 2. Architektur mit unabhängigen Data Marts (in Anlehnung an Sen u. Sinha 2005, S. 80)

3.1.2 Data Mart-Busarchitektur

Im Gegensatz zu den in den nächsten Abschnitten vorgestellten Architek-turtypen wird bei der Data Mart-Busarchitektur auf eine zentrale Daten-


haltungs- und Integrationskomponente verzichtet. Vielmehr werden die Daten direkt durch eine Vielzahl von Data Marts aus den Quellsystemen bezogen und den analytischen Applikationen bereitgestellt. Jeder einzelne Data Mart ist für einen bestimmten Geschäftsprozess (z. B. Beschaffung oder Auftragsmanagement) konzipiert. In Bezug auf die Governance teilen sich Betrachtungseinheiten (z. B. Abteilungen) die entsprechenden Data Marts und verfügen über keine entsprechenden Eigenschaften und Rechte als System Owner an den Marts (Breslin 2004). Weitere wesentliche Diffe-renzierungsmerkmale dieser Architektur liegen in der dimensionalen Da-tenmodellierung mit übereinstimmenden Dimensionsdaten, deren Konsis-tenz durch ein zentrales Metadatenrepository sichergestellt wird.

Bei der dimensionalen Datenmodellierung wird ein sog. Sternschema aus einer Fakttabelle (z. B. Verkaufstabelle) im Zentrum des Schemas und mehreren Dimensionstabellen (z. B. Zeit, Produkt-, Kunden- und Filialta-bellen) aufgebaut. Um Dateninkonsistenzen und Redundanzen zu vermei-den, werden zwischen den einzelnen Data Marts übereinstimmende Di-mensionsdaten ausgetauscht und verwendet. Beispielsweise sollen seman-tisch identische Attribute auch die gleiche Bezeichnung erhalten oder der Schlüssel eines bestimmten Produkts soll in allen Data Marts gleich lauten (Kimball u. Ross 2002; Breslin 2004). Kimball setzt sich mit seinem Architekturentwurf zum Ziel, Informationen leichter zugänglich zu ma-chen und unternehmensweit konsistent darzustellen, sie gleichzeitig aber auch vor unbefugten Zugriffen zu schützen.

Abb. 3. Data Mart-Busarchitektur (in Anlehnung an Sen u. Sinha 2005, S. 80)


3.1.3 Zentralisierte Architektur

Eine zentralisierte Architektur zeichnet sich dadurch aus, dass sämtliche Datenzugriffe über ein zentrales Data Warehouse (DWH) erfolgen (Ariya-chandra u. Watson 2005, S. 12). Im zentralen DWH werden konsolidierte und bereinigte Daten aus den Quellsystemen abgelegt. Die ETL-Prozesse werden wie bei Data Mart Bus-Architekturen (siehe 3.1.2) anhand der Me-tadaten aus einem zentralen Metadaten-Repository gesteuert. Zusätzlich kann durch den zentralen Zugriff die Anzahl der Schnittstellen zu den Quellsystemen auf ein Minimum reduziert werden und es finden keine re-dundanten Zugriffe auf die Quellsysteme zur Datenextraktion statt.

Analysen setzen direkt auf dem zentralen DWH auf. Da keine dedizierte Analyseschicht vorhanden ist, muss das zentrale DWH hochperformant ausgelegt sein, z. B. durch eine massiv-parallele Architektur. Zum Teil ist auch eine nicht physische Implementierung einer Analyseschicht vorzufin-den (z. B. durch Views), so dass die zentralisierte Architektur einer logi-schen Implementierung der Hub and Spoke-Architektur entspricht (Ariya-chandra u. Watson 2005, S. 12).

Abb. 4. Zentralisierte Architektur (in Anlehnung an Sen u. Sinha 2005, S. 80)

3.1.4 Hub and Spoke-Architektur

Hauptmerkmale einer Hub and Spoke-Architektur, auch Corporate Infor-mation Factory genannt, sind ein zentrales DWH und auf diesem DWH aufsetzende Data Marts (vgl. Inmon 2002). Es findet eine weitgehende Trennung zwischen Aufbereitungs- und Persistierungsprozessen einerseits (DWH) sowie Analyseprozessen andererseits (Data Marts) statt. Der ETL-Prozess nutzt die Metadaten aus einem zentralen Repository, um das zen-trale DWH mit konsolidierten und bereinigten Daten aus den Quellsyste-men zu befüllen. Die Anzahl der Schnittstellen zu den Quellsystemen kann


Abb. 5. Hub and Spoke-Architektur

durch den zentralen Zugriff auf ein Minimum reduziert werden und es fin-den keine redundanten Zugriffe auf die Quellsysteme zur Datenextraktion statt. Analysen basieren größtenteils auf subjektorientierten Data Marts, es können jedoch auch die im zentralen DWH vorliegenden Daten direkt ana-lysiert werden.

Die Data Marts können auf unterschiedlichen Technologien wie z. B. re-lationalen Datenbanken, persistente OLAP-Cubes oder In-Memory Analy-sen basieren und so für den jeweiligen Anwendungsfall das optimale Werkzeug (Best of Breed-Ansatz) zur Verfügung stellen. Auch können weitere Aspekte wie Erweiterbarkeit, Datentrennung, Sicherheit und Per-formanz für die Erstellung von themenorientierten Data Marts sprechen. Die Hub and Spoke-Architektur ähnelt der zentralisierten Architektur, mit dem Unterschied, dass für spezielle Analysezwecke Data Marts zur Verfü-gung stehen.

3.1.5 Föderierte Architektur

In den meisten größeren Organisationen existieren parallel mehrere, mit Aspekten der Informationslogistik beschäftigte Organisationseinheiten, die unabhängig voneinander agieren und jeweils eigene Systemlandschaften betreuen. Ergebnis dieser Bemühungen sind heterogene, auf die gesamte Organisation verteilte Data Warehouses und Data Marts. Auf Grund dieser gewachsenen Struktur existiert im engeren Sinne kein einzelnes zentrales DWH, sondern ein Konglomerat von Systemen. In der Summe bilden die-se Data Warehouses und Data Marts ein föderiertes Data Warehouse-System (vgl. Hackney 2000).


Abb. 6. Föderierte Architektur (in Anlehnung an Sen u. Sinha 2005, S. 80)

Kennzeichen solcher Systeme sind die punktuelle gemeinsame Nutzung von Daten. Dadurch sollen Redundanzen soweit möglich vermieden und eine konsistente und einheitliche Sichtweise auf die wichtigsten Daten für das Unternehmen sichergestellt werden. Ein gemeinsames Metadatenma-nagement für die wichtigsten Unternehmensdaten kann zur Konsistenzsi-cherung beitragen. Die föderierte Architektur stellt für viele Unternehmen ggf. übergangsweise eine praktikable, organisatorisch durchsetzbare Lö-sung dar, um sich dem Ziel einer integrierten Informationslogistik zu nä-hern. Größere Schwierigkeiten kann die Entwicklung eines einheitlichen Verständnisses aller Beteiligten bezüglich Semantik der Daten und Ge-schäftsregelwerk bereiten. Bei föderierten Systemen können Probleme bei Konnektivität und Datendurchsatz auftreten, da Daten über unterschied-lichste Systeme ausgetauscht werden müssen.


3.1.6 Virtuelle Architektur

Die virtuelle Architektur unterscheidet sich grundlegend von anderen Architekturen, da neben den eigentlichen Quellsystemen keine weiteren Datenspeicher existieren (Bold et al. 1997, S. 11). Die virtuelle Architektur soll verbesserte Zugriffsmöglichkeiten für Endanwender auf das Daten-material der operativen Systeme bieten, indem suggeriert wird, dass die Abfragen auf einem System ausgeführt würden. Neben einer vollständig virtuellen Architektur ist auch die Virtualisierung einzelner Komponenten möglich.

Die Analysetools beziehen ihre Daten direkt aus den operativen Syste-men. Daher ist die Anbindung heterogener Quellsysteme sehr aufwändig und mehrere Quellsysteme können kaum integriert betrachtet werden. Fer-ner werden die operativen Systeme durch den direkten Abfragezugriff sehr stark belastet. Um die Analyse von historischem Datenmaterial zu ermög-lichen, müssten sämtliche Daten in den Quellsystemen vorgehalten wer-den.

Auf Grund der oben genannten Nachteile (keine Integration, keine His-torisierung, Belastung der operativen Systeme) und der geringen Ver-breitung in der Praxis ist die Relevanz dieser Architektur äußerst fraglich. Nur wenige Unternehmen setzen eine virtuelle Architektur ein, bei der die Analysetools direkt auf den OLTP-Systemen aufsetzen (Eckerson 2006, S. 15).

Abb. 7. Virtuelle Architektur


3.2 Erweiterungsformen

Im Folgenden werden Erweiterungen zu den zuvor beschriebenen System-architekturen vorgestellt. Den Erweiterungen ist gemeinsam, dass sie auf den zuvor beschriebenen Architekturen aufsetzen und diese um bestimmte Fähigkeiten ergänzen oder typische Architekturdefizite durch zusätzliche Architekturkomponenten auszugleichen versuchen.

3.2.1 Active Data Warehouse

Ein Active Data Warehouse (ADWH) erweitert ein klassisches Data Ware-house um die Fähigkeit, basierend auf einem automatisierten Analysepro-zess Entscheidungen automatisch zu fällen und auf Grund dieser Entschei-dungen Aktionen in den operativen Systemen auszulösen, d. h. aktiv in die operativen Prozesse einzugreifen und diese auch aktiv zu verändern (vgl. Thalhammer et al. 2001). Durch ein ADWH können parallel strategische und operative Entscheidungen unterstützt werden (Active Enterprise Intel-ligence, vgl. (Graham 2007, S. 3-4)).

Die Komponenten eines ADWH stellen sich nach (Thalhammer et al. 2001, S. 243) wie folgt dar: Analog zu klassischen DWHs, deren Basis-architektur eine der zuvor vorgestellten, wie z.B. eine zentralisierte DWH-Architektur, sein kann, beinhaltet ein ADWH ein (passives) Data Ware-house, aus dem Ad-hoc Anfragen beantwortet werden können. Bei Auftre-ten von vordefinierten Ereignissen (z. B. bei Überschreiten eines Schwell-wertes) erkennt und verarbeitet ein Event-Manager diese und löst basie-rend auf Regeln Aktionen aus. Analysten können auf die Regelbasis mittels unterschiedlichster Tools zugreifen, um Analyseregeln und Ereig-nisse etc. zu definieren oder zu modifizieren.

Abb. 8. Konzeptionelle Architektur eines Active Data Warehouse (in Anlehnung an Thalhammer et al. 2001)


Quellsystem

Quellsystem

Quellsystem

ETL

Batch

Feed

Zentrales DWH

Data Mart

Data Mart

Rule Engine

Daten-Analysen

Daten-Analysen

Alerts, etc.

1

2

3

Abb. 9. Beispiel eines (Near-)Real-Time-DWH auf Basis einer Hub and Spoke-Architektur

3.2.2 Real-Time Warehousing

Aus dem Anspruch, möglichst aktuelle Daten für analytische Systeme be-reitzuhalten, entstanden in den vergangenen Jahren mehrere Konzepte zum sog. Real-Time bzw. Near-Real-Time-Warehousing. Durch die Tatsache, dass trotz bestehender, technischer Beschleunigungsmechanismen im Da-tenlade- und Datenanalysebereich weiterhin Verzögerungen bei der Ent-scheidungsfindung auftreten, wird der Begriff „Real-Time“ teilweise rela-tiviert und als „Right-Time“-Warehousing aufgefasst (Schelp 2006, S. 426).

Die folgenden Aspekte sind insbesondere im Aufbau einer echtzeit-orientierten Architektur von Bedeutung (Justin 2007). Analog zum Verlauf der Datenströme wird zunächst das Laden der Daten betrachtet. Hierbei existieren in der Praxis zum einen Batch-Lade-Prozesse mit entsprechend kurzen Intervallen (Near-Real-Time), zum anderen kontinuierliche Daten-ströme („Feeds“) aus den Quellsystemen, die höchst mögliche Datenaktua-lität gewährleisten (vgl. Abb. 9.).

Des Weiteren ist bei der Konzeption einer Real-Time-Architektur die Integration der Real-Time-Daten zu beachten. Zur Vermeidung von Inkon-sistenzen zwischen Real-Time- und Nicht-Real-Time-Daten können Real-Time-Daten beispielsweise in separaten Fakttabellen geladen werden, die entweder die gleiche oder eine andere Struktur wie die Nicht-Real-Time-Fakttabellen vorweisen.

Dem Risiko falscher Abfrageergebnisse kann ferner mit speziellen Nut-zungsvorgaben entgegengewirkt werden. Beispielsweise ist es denkbar, komplexe Abfragen, die Real-Time-Daten mit einbeziehen und sich über mehrere Tabellen im Data Warehouse erstrecken, zu verbieten. Um den-noch auch komplexe Abfragen mit Real-Time-Inhalten zu ermöglichen,


können Snapshots der Real-Time-Daten verwendet werden. Darüber hi-naus sind die fachlichen Benutzer über die Potenziale und die Risiken zu informieren, die durch den Einbezug von Real-Time-Daten im Data Ware-house entstehen.

Durch die hohe Aktualität der Daten ergeben sich im Bereich der Da-tenanalyse der Informationslogistik neue Möglichkeiten. So sollte in Er-wägung gezogen werden, Real-Time-Daten nicht nur durch individuelle Abfragen auf der Nutzerseite auszuwerten, sondern auch dem Aspekt der Ereignisorientierung mehr Bedeutung beizumessen. Die hochaktuellen Da-ten können automatisch in regelbasierten Systemen (Rule Engines) verar-beitet werden. Beim Überschreiten gewisser vordefinierter Grenzwerte können entsprechende Alerts zur Weiterleitung an Nutzer bzw. weitere In-formationssysteme erzeugt werden.

3.2.3 In-Memory Analytics

Die Möglichkeit, durch Ad-hoc-Abfragen Detailinformationen aus dem Data Warehouse zu erhalten, kann mit einer nicht befriedigenden Antwort-zeit auf die Abfrage einhergehen. Zur Umgehung dieses Problems können auf die Abfragen optimierte (physische) Data Marts erstellt werden, die Daten verdichtet zur Verfügung stellen. Oftmals wird eine Verbesserung des Abfrage-Antwortverhaltens erreicht, dafür treten jedoch andere Prob-leme auf (Schlegel et al. 2006, S. 2):

• Die Erstellung der Data Marts ist Ressourcen intensiv, es werden Perso-nal- und Rechnerressourcen benötigt.

• Neue Daten müssen den voraggregierten Daten hinzugefügt werden, d. h. es müssen regelmäßig neue Berechnungen durchgeführt werden. Ggf. stehen in den Data Marts daher zwischenzeitlich keine aktuellen Daten zur Verfügung.

• Die Wartung der Data Marts bindet Ressourcen, die z. B. für die Weiter-entwicklung nicht mehr zur Verfügung stehen.

Um die Performanz der BI-Applikationen zu verbessern, kann eine weitere Architekturkomponente, genannt In-Memory Analytics, eingesetzt werden. Zwar handelt es sich bei In-Memory Analytics nicht um eine Komponente mit grundlegend veränderndem Charakter, auf Grund des zunehmenden Interesses in der Praxis wird dennoch dieses Konzept als Erweiterungs-form in diesem Kapitel betrachtet.

Anstatt eine voraggregierte Zwischenschicht zu erstellen, werden sämt-liche Daten in den Speicher geladen und Berechnungen werden zur Abfra-gezeit durchgeführt. Endanwender können detaillierte Daten einfacher er-kunden. Virtuelle Data Marts basieren auf ähnlichen Prinzipien, aufgrund


der Themenorientierung eines Data Marts steht in einem Data Mart jedoch nicht die gesamte Datenbasis zur Verfügung.

Abb. 10. Hub and Spoke-Architektur, erweitert um In-Memory Analytics (vgl. Schlegel et al. 2006, S. 4)

Schlegel et al. äußern die Erwartung, dass bis 2012 ca. 70% der welt-weit größten Unternehmen In-Memory Analytics als primäre Methode zur Verbesserung der BI-Anwendungsperformanz einsetzen werden (Schlegel et al. 2006, S. 3). Dieser Trend könnte weitreichende Auswirkungen auf bisher etablierte Techniken wie relationale Aggregattabellen und Data Marts haben (Schlegel et al. 2006, S. 3). Kritisch zu hinterfragen ist, ob bei Ad-hoc Aggregation der Daten eine weiterhin ausreichende Abfrageper-formanz erreicht werden kann.

4 Bewertung von Systemarchitekturen

In diesem Abschnitt wird untersucht, inwieweit die zuvor präsentierten Architekturtypen den in diesem Beitrag dargestellten Anforderungen aus Sicht einer bereichsübergreifenden Informationslogistik gerecht werden. Als Bewertungsgrundlage wird zum einen auf entsprechende evaluierende Literatur zurückgegriffen, zum anderen wird überprüft, ob der jeweilige Architekturtyp Merkmale enthält, die in der Literatur zur Erfüllung der entsprechenden Anforderung genannt werden. Tabelle 2 stellt die Bewer-tungsergebnisse zusammenfassend dar. Architektur-Anforderungs-Kons-tellationen, für die eine genauere Bewertungsaussage nicht abzuleiten ist, werden mit einem „-/-“ (z. B. Verfügbarkeit oder Auswertung) versehen. Da Erweiterungsformen wie das Active Data Warehouse oder In-Memory Analytics prinzipiell auf alle Architekturtypen anwendbar sind und somit das Verhalten der jeweiligen erweiterten Architektur „erben“, werden in der Tabelle nur ihre Differenzierungsmerkmale aufgeführt und durch ent-


sprechende Häkchen vermerkt. Die hier vorgestellten Bewertungen orien-tieren sich nur an den Architekturbeschreibungen in Abschn. 3.1. Bei Er-gänzung um entsprechende Komponenten oder Mechanismen kann die entsprechende Architektur einzelne Anforderungen in erhöhtem Maße er-füllen.

Die unterschiedlichen Ausprägungen der Erfüllungsgrade einer Archi-tektur in Bezug auf die entsprechende Anforderung werden durch die fol-genden Symbole dargestellt:

Der Architekturtyp erfüllt die Anforderung bzw. entspricht dem

Einflussfaktor in vollem Umfang und ist für diesen Bereich in der Regel empfehlenswert.

Der Architekturtyp erfüllt die Anforderung bzw. entspricht dem Einflussfaktor in weiten Teilen. Eine Eignung ist für diesen Bereich möglich.


Einflussfaktor in einigen Teilen. Eine Empfehlung für diesen Be-reich kann nicht explizit gegeben werden.


Einflussfaktor kaum und ist für diesen Bereich in der Regel weniger empfehlenswert.

Die folgenden Ausführungen dienen zur Erläuterung der in Tabelle 2 vorgestellten Bewertungsergebnisse.


Tabelle 2. Bewertungsübersicht der untersuchten Architekturtypen und Erweite-rungen

Architekturen Erweiterungen

1. U

nabh

ängi

-ge

Dat

a M

arts

2. D

ata

Mar

t B

us

3. Z

entra

lisie

rt

4. H

ub a

nd

Spok

e

5. F

öder

iert

6. V

irtue

lle

Arc

hite

ktur

7. A

ctiv

e D

WH

8. R

eal T

ime

DW

H

9. In

Mem

ory

Ana

lytic

s

Dat

enqu

alitä

t

Aktualität

Vollständigkeit Konsistenz

Transparenz

Syst

emqu

alitä

t Performanz Flexibilität

Verfügbarkeit Sicherheit

Wei

tere

Ei

nflu

ssfa

ktor

en Ressourcenbedarf

Eignungsgrad horizon-tale Informations-integration

Eignungsgrad vertikale Informationsintegration Lese- & Schreibzugriff


Aktualität: Ladezyklen zwischen Quellsystemen und möglichen Daten-integrationsebenen werden oftmals als Einflussfaktor auf die Aktualität der in den analytischen Systemen vorliegenden Daten betrachtet (Schelp 2006, S. 428). Zusätzliche Ladevorgänge in nachgelagerte Data Marts wie bei-spielsweise bei der Hub and Spoke-Architektur können sich ebenso verzö-gernd auswirken wie komplexere Transformationsprozesse über mehrere Data Marts, die bei der Bus Variante zur Konsistenzsicherung erforderlich sind. Die virtuelle Architektur zeichnet sich durch eine hohe Aktualität aus, da keinerlei Ladevorgänge o.ä. erforderlich sind. Real-Time-Archi-tekturen setzen an diesem Punkt an und zeichnen sich im Allgemeinen durch eine den Erfordernissen entsprechende hohe Aktualität aus. Vollständigkeit: Sowohl einem zentralisierten Ansatz als auch einer Hub and Spoke-Architektur wird eine höhere Vollständigkeit der Daten be-scheinigt (Ariyachandra u. Watson 2005, S. 39). Des Weiteren wird ver-einzelt festgestellt, dass die Vollständigkeit der Daten insgesamt in allen Architekturtypen zu wünschen übrig lässt, da nicht alle für Entscheidungen relevanten Daten durch Quellsysteme zur Verfügung gestellt werden bzw. erfasst werden (Ariyachandra u. Watson 2005, S. 39). Daher können nicht technische, sondern organisatorische Maßnahmen, zu einer weiteren Ver-besserung der Vollständigkeit beitragen. In Bezug auf die Historisierung von Daten ergeben sich bei Architekturen mit einer Datenintegrationsebe-ne entsprechende Vorteile. Konsistenz: In einer Studie wird der zentralisierte Ansatz sowie die Hub and Spoke-Architektur als führend bei der erreichbaren Konsistenz be-trachtet, alle anderen Typen – insbesondere unabhängige Data Marts als „Informationssilos“ – schneiden hier schlechter ab (Ariyachandra u. Wat-son 2005). Gründe hierfür liegen u. a. in einem zentralen Metadatenmana-gement. Transparenz: Die Entwicklung und der Betrieb eines Repositories zur Verwaltung aller relevanten Metadaten beispielsweise innerhalb eines Data Warehouse Systems wird in der Literatur als essentielle Maßnahme zur Erhöhung der Nachvollziehbarkeit bzw. der Transparenz erachtet (Bauer u. Günzel 2004, S. 329). Ein zentrales Repository, wie z. B. in einer zentralen oder Hub and Spoke-Architektur möglich (siehe Abb. 4 und Abb. 5), bietet umfassendere Informationen zu den vorliegenden Daten. Im Vergleich zu den anderen Typen, die nur teilweise oder gar nicht über ein zentrales Me-tadatenmanagement verfügen, ist bei den Architekturtypen drei und vier mit einer erhöhten Transparenz über die im System vorliegenden Daten und deren Flüsse zu rechnen. Performanz: Einer der Haupttreiber für die Entwicklung von Data Marts ist die damit verbundene Performanzverbesserung, z. B. durch entspre-chende Lastverteilungsmechanismen oder die Verwendung denormalisier-


ter Dimensionstabellen in den Marts (Kimball u. Ross 2002; Bauer u. Günzel 2004, S. 59). Architekturen mit Data-Mart-Komponenten werden folglich in diesem Bereich besser bewertet. Als Erweiterung kann parallel zu oder anstelle von Data Marts eine In-Memory-Engine eingesetzt wer-den, die durch Wegfall der zeitaufwendigen Vorberechnungen zu einer besseren Performanz führen kann. Eine virtuelle Architektur belastet die Quellsysteme permanent, da bei sämtlichen analytischen Zugriffen Daten aus den Quellsystemen gelesen werden müssen. Dies kann zu extremen Nachteilen bis hin zur Gefährdung des Betriebs der operativen Systeme führen. Massiv parallele Architekturen können zu einer insgesamt höheren Performanz beitragen (und wirken sich ebenfalls positiv auf die Verfüg-barkeit aus). Flexibilität: Hinsichtlich hoher Flexibilität der Architektur, wichtig bei-spielsweise bei Integration neuer Quellsysteme oder Verwendung der Da-ten für weitere Informationssysteme, sind unabhängige Data Marts (iso-lierte „Datensilos“) und föderierte Systeme auf Grund ihrer Heterogenität als kritisch zu erachten. Generell ist die Anzahl zu verwaltender bzw. an-zupassender Schnittstellen ein entscheidendes Kriterium, weshalb die Architekturtypen drei und vier durch ihre zentrale Datenintegrationsebene besser abschneiden. Verfügbarkeit: In Bezug auf ihre Verfügbarkeit (im Sinne von Ausfallsi-cherheit) weisen Architekturansätze wie beispielsweise unabhängige Data Marts oder Bus-Architekturen auf Grund ihres verteilten Aufbaus Vorteile auf. Wegen ihrer monolithischen Struktur (nur eine integrierte Datenbasis) erfüllen zentralisierte Ansätze im Allgemeinen die Anforderung einer ho-hen Verfügbarkeit in weniger starkem Maße, massiv parallele Architektu-ren können hierbei jedoch zu einen weitreichenden Erhöhung der Verfüg-barkeit beitragen. Da bei einer Hub and Spoke-Architektur nicht direkt auf die integrierte Datenbasis, sondern auf Data Marts zugegriffen wird, kön-nen bei einem Ausfall der zentralen Komponente Analysen bis zu einem gewissen Grad fortgeführt werden. Bei einer föderierten Architektur hängt die Verfügbarkeit des Gesamtsystems vom Grad der Verzahnung der ein-zelnen Komponenten ab. Fällt beispielsweise in einem derartigen System eine Komponente aus, auf der keine nachgelagerten Systeme aufsetzen, kann dies sicherlich als weniger kritisch bewertet werden. Letztlich ist je-doch zu beachten, dass sich die soeben vorgenommene Bewertung nur auf die Architekturtypen per se sowie deren grundlegenden Aufbau konzent-riert hat. Durch technische Detaillösungen können bei allen Typen Verbes-serungen hinsichtlich ihrer Verfügbarkeit erzielt werden. Sicherheit: Die Verwendung entsprechender Sichten („Views“) kann als weiterer Vorteil von Data Mart-Komponenten verstanden werden. Hier-durch ist der Zugriff auf eine Integrationsebene, die alle Daten enthält,


eingeschränkt. Dies kann zu einer erhöhten Sicherheit im Betrieb der Sys-teme beitragen (siehe auch Abschn. 2.2.4). Somit erhalten Architekturen, die auf Data Marts zurückgreifen, eine tendenziell bessere Bewertung hin-sichtlich ihrer Sicherheit. Bei Verwendung einer Bus-Architektur muss je-doch eine erhöhte Komplexität des Systems in Kauf genommen werden, die beispielsweise durch die Verschlüsselung der Datenflüsse zur Erhö-hung der Sicherheit auftreten kann. Somit wird dieser Architekturtyp ent-sprechend niedriger bewertet. Die aufwändige Administration von föde-rierten Systemen, die teilweise aus äußerst heterogenen Systemen bestehen, erschwert ein effektives Sicherheitsmanagement. Ressourcenbedarf: An dieser Stelle wird der Grad des Ressourceneinsat-zes während der Einführung und beim Betrieb und der Wartung des jewei-ligen Systems betrachtet. Ressourcenschonende Architekturen wie bei-spielsweise unabhängige Data Marts werden entsprechend positiv bewer-tet. Neben dieser Einschätzung verdeutlichen (Ariyachandra u. Watson 2005, S. 44) in ihrer Studie, dass eine Hub and Spoke-Architektur speziell bei der Einführung eindeutig am ressourcenintensivsten ist. Bus- oder zentralisierte Architekturen hingegen verhalten sich laut dieser Studie hierbei ähnlich wie unabhängige Data Marts. Langfristig gesehen kann sich ein anfangs hoher Ressourceneinsatz positiv auf den zukünftigen Res-sourcenbedarf z. B. bei der Wartung oder beim Betrieb auswirken. Deshalb sollte der Ressourceneinsatz bei einer Architekturauswahl individuell und über längere Zeithorizonte betrachtet werden. Horizontale Informationsintegration: Durch die zentrale Datenintegrati-onsebene der Architekturtypen drei und vier oder die gemeinsame Ver-wendung von Stammdaten bei Data Mart Bus-Architekturen erscheint die Verwendung dieser Architekturen zur Schaffung einer horizontalen Infor-mationsintegration, wie in Abschn. 2.3.3 beschrieben, als vorteilhaft (Ariyachandra u. Watson 2005, S. 42). Im Kontext einer ganzheitlichen In-formationslogistik, bei der nicht nur einzelne Unternehmen, sondern auch Unternehmensnetzwerke betrachtet werden, ist das Problem der durchgän-gigen horizontalen Informationsintegration als durch die vorgestellten Architekturen noch nicht vollständig beherrschbar anzusehen. Vertikale Informationsintegration: Eine vertikale Informationsintegra-tion kann durch Architekturtypen mit Data Marts, die nur für die regionale Subjektorientierung bzw. einen Ausschnitt (einer Ebene) des Unterneh-mens konzipiert worden sind, beeinträchtigt werden. Bei der Nutzung von In-Memory Analytics sind derartige Restriktionen nicht existent, da die Einschränkung der Subjektorientierung hier nicht vorhanden ist. Lese- und Schreibzugriff: Klassische Data Warehouse Architekturen se-hen einen rein lesenden Zugriff auf die Daten der operativen Systeme vor. Durch Active DWH-Komponenten kann dieses Verhalten erweitert und


Schreibzugriff ermöglicht werden, um z. B. anhand von analytischen Auswertungen Prozessparameter in operativen Systemen zu modifizieren.

Auch wenn sich keine einheitliche Handlungsempfehlung für die Aus-wahl einer bestimmten Architektur geben lässt, zeigen bestimmte Archi-tekturen in bestimmten Situationen deutliche Vorteile auf. Oftmals wirken sich situative Faktoren auf die Auswahl einer Architektur aus oder schrän-ken die zur Auswahl stehenden Architekturtypen ein. Einzelne Architek-turtypen wie z. B. die virtuelle Architektur oder unabhängige Data Marts weisen jedoch deutliche Schwächen auf und sollten nur in Ausnahmefällen dauerhaft genutzt werden.

5 Ausblick

In diesem Beitrag wurde ein Überblick über etablierte Architekturtypen der Informationslogistik und aktuelle Entwicklungen von Erweiterungen dieser Architekturtypen gegeben sowie eine Bewertung vorgenommen. Bei der Auswahl einer Systemarchitektur ist einerseits zu berücksichtigen, dass oftmals auf eine bestehende Architektur aufgesetzt wird, andererseits sollte versucht werden, eine möglichst zukunftssichere Basis für die Informati-onslogistik des gesamten Unternehmens (oder auch Unternehmensnetz-werks) zu schaffen. Für die Etablierung einer nachhaltigen Systemarchi-tektur der Informationslogistik sind fachliche und organisatorische As-pekte zu beachten (vgl. Kap. 5) sowie eine strukturelle Analogie zwischen Organisation und Systemarchitektur zu realisieren (vgl. Krallmann et al. 2002, S. 193, 210 ff).

Literatur

Ariyachandra, T.; Watson, H.: Data Warehouse Architectures: Factors in the Se-lection Decision and the Success of the Architectures, Athens 2005.

Azvine, B.; Cui, Z.; Nauck, D. D.: Towards Real-Time Business Intelligence, in: BT Technology Journal 23 (2005) 3, S. 214-225.


Beyer, M.; Friedman, T.; Feinberg, D.: Mission-Critical Data Warehouses De-mand New SLAs, Gartner, Stamford 2007.

Bitterer, A.; Schlegel, K.; Hostmann, B.; Gassman, B.; Beyer, M. A.; Herschel, G.; Radcliffe, J.; White, A.; Payne, T.; Andrews, W.; Newman, D.: Hype Cyc-le for Business Intelligence and Performance Management, 2007, Gartner, Stamford 2007.


Bold, M.; Hoffmann, M.; Scheer, A.-W.: Datenmodellierung für das Data Ware-house, 139, Scheer, August-Wilhelm, Saarbrücken 1997.

Brändli, P.; Mügeli, T.; Maier, D.; Winter, M.; Klesse, M.; Herrmann, C.: Custo-mer Investigation Process at Credit Suisse: Meeting the Rising Demands of Regulators, in: Schelp J. et al. (Hrsg.): Auf dem Weg zur Integration Factory: Proceedings der DW2004 - Data Warehousing und EAI, Physica, Heidelberg 2004, S. 437-458.

Breslin, M.: Data Warehousing Battle of the Giants: Comparing the Basics of the Kimball and Inmon Models, in: Business Intelligence Journal 9 (2004) 1, S. 6-20.

Brobst, S.; Venkatesa, A.: Active Warehousing, in: Teradata Magazine 2 (1999) 1 (Spring), S. 26-33.

Brobst, S. A.: Twelve Mistakes to Avoid When Constructing a Real-Time Data Warehouse, in: Schelp J. et al. (Hrsg.): Auf dem Weg zur Integration Factory - Proceedings der DW2004 - Data Warehousing und EAI, Physica, Heidelberg 2005, S. 153-166.

Burton, B.; Rayner, N.: Toolkit: Gartner's Business Intelligence and Performance Management Maturity Model, Gartner, Stamford 2007.

Clements, P.; Kazman, R.; Klein, M.: Evaluating Software Architectures, Addi-son-Wesley, Boston et al. 2002.

Eckerson, W.: Data Quality and the Bottom Line: Achieving Business Success through a Commitment to High Quality Data, TDWI, Chatsworth 2002.

Eckerson, W.: 2006 TDWI BI Benchmark Report, TDWI, Chatsworth 2006. Gelhoet, M.; Rieger, B.: Mehrstufige Entscheidungsunterstützung durch Active

Data Warehouses, in: Ferstl O. K. et al. (Hrsg.): Wirtschaftsinformatik 2005 - eEconomy, eGovernment, eSociety, Physica-Verlag HD, 2005, S. 1405-1419.


Graham, D.: Enabling the Agile Enterprise with Active Data Warehousing, Tera-data Corporation, 2007.

Hackney, D.: Architecture Anarchy and How to Survive It: God Save the Queen, in: Enterprise Systems Journal 15 (2000) 4, S. 24-30.

Herrmann, C.: Referenzprozesse für die Wartung von Data-Warehouse-Systemen, Dissertation, Universität St. Gallen, St. Gallen 2006.

IEEE: IEEE Recommended Practice for Architectural Description of Software In-tensive Systems (IEEE Std 1471-2000), IEEE Std 1471-2000, IEEE Computer Society, New York, NY 2000.

Inmon, W.: Building the Data Warehouse, 3. Aufl., Wiley, New York 2002. Jung, R.: Architekturen zur Datenintegration: Gestaltungsempfehlungen auf der

Basis fachkonzeptueller Anforderungen, Deutscher Universitätsverlag, Wies-baden 2006.

Justin, L.: Real-time reality, http://www.teradata.com/t/page/115223/index.html, 14.01.2008.

Kachur, R.: Data Warehouse Management Handbook, Prentice Hall, USA 2000. Kimball, R.; Ross, M.: The Data Warehouse Toolkit, 2. Aufl., Wiley, New York

2002.


Krallmann, H.; Frank, H.; Gronau, N. (Hrsg.): Systemanalyse im Unternehmen – Vorgehensmodelle, Modellierungsverfahren und Gestaltungsoptionen, 4. Auf-lage. Aufl., München, Wien 2002.

Krcmar, H.: Informationsmanagement, 4. Aufl., Springer, Berlin et al. 2005. Oppliger, R.: IT-Sicherheit – Grundlagen und Umsetzung in der Praxis, Vieweg,

Braunschweig 1997. Picot, A.; Reichwald, R.; Wigand, R. T.: Die grenzenlose Unternehmung - Infor-

mation, Organisation und Management, 4. Aufl., Gabler, Wiesbaden 2001. Pipino, L.; Lee, Y. W.; Wang, R. Y.: Data Quality Assessment, in: Communicati-

ons of the ACM 45 (2002) 4, S. 211-218. Schelp, J.: Real-Time Warehousing und EAI, in: Chamoni P. et al. (Hrsg.): Analy-

tische Informationssysteme - Business Intelligence-Technologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 425-438.

Schlegel, K.; Beyer, M. A.; Bitterer, A.; Hostmann, B.: BI Applications Benefit From In-Memory Technology Improvements, Gartner, Stamford 2006.

Sen, A.; Sinha, A. P.: A Comparison of Data Warehousing Methodologies, in: Communications of the ACM 48 (2005) 3 (March), S. 79-84.

Thalhammer, T.; Schrefl, M.; Mohania, M.: Active data warehouses: complemen-ting OLAP with analysis rules, in: Data & Knowledge Engineering 39 (2001), S. 241-269.

Wand, Y.; Wang, R. Y.: Anchoring data quality dimensions in ontological founda-tions, in: Communications of the ACM 39 (1996) 11, S. 86-95.

Wilhelmi, C.: Erfolgsfaktoren für die Informationslogistik, BE HSG/EIW/02, In-stitut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2006.

8 Nutzenpotenziale unternehmensweiter Informationslogistik

Moritz Schmaltz


Jochen Töpfer

Teradata

1 Einleitung ....................................................................................... 157 2 Eigenschaften von Informationslogistik-Projekten ........................ 158 3 Nutzendimensionen der Informationslogistik ................................. 160 4 Wertbeiträge der Informationslogistik ............................................ 163 5 Kostensenkung durch Informationslogistik .................................... 168 6 Organisatorische Einbettung ........................................................... 172 7 Methodenbeispiel zur Bewertung der Informationslogistik ........... 173

Literatur .......................................................................................... 176

1 Einleitung

Die Informationslogistik (IL) hat zum Ziel, betrachtungseinheit-übergrei-fend Informationsbedarfe im Unternehmen zu befriedigen (vgl. Kap. 3). Dazu werden erhebliche Anstrengungen unternommen; die Projektbudgets erreichen bei ungebrochen steigender Tendenz oft Millionenhöhe (Watson et al. 2001, S. 50; Sommer 2007). Wie andere Vorhaben im Unternehmen auch muss die IL den Nachweis erbringen, dass diese Anstrengungen für das Unternehmen Nutzen stiften, also letztlich das Zielsystem des Unter-nehmens unterstützen (Whittemore 2003, S. 4). Dies gilt sowohl für initia-

158 Moritz Schmaltz, Jochen Töpfer

le Projekte, die z. B. ein unternehmensweites Data Warehouse (DWH) etablieren sollen, als auch für Folgeprojekte, die den Ausbau der bestehen-den IL-Infrastruktur bzw. der darauf aufsetzenden analytischen Anwen-dungen zum Ziel haben.

Getrieben aus der Praxis wurden daher erhebliche Anstrengungen unter-nommen, den Nutzen der IL nachzuweisen. In einigen Teilbereichen kann dieser Nutzen quantifiziert werden, in anderen Teilbereichen ist dies nur unvollständig bzw. nur näherungsweise möglich (Nagel 1990). Dieser Bei-trag zeigt die unterschiedlichen Nutzenpotenziale der IL auf und gibt Hin-weise auf Möglichkeiten zur Quantifizierung.

Für eine Wirtschaftlichkeitsbetrachtung ist neben der Nutzenbetrachtung auch eine Betrachtung der Kosten erforderlich. Die Kosten von IL-Projekten sind im Gegensatz zu den Nutzenpotenzialen deutlich einfacher zu quantifizieren, wobei die mit der Budgetierung von Großprojekten und den häufig unvollständigen Anforderungen einhergehenden Risiken beach-tet werden müssen (Frie u. Wellmann 2000, S. 28; Winter u. Jung 2000, S. 32). Die bekannten Methoden zur Schätzung von Softwareprojekt-Kosten lassen sich – bei entsprechender Modularisierung der IL-Projekte – auch auf die IL anwenden (Watson et al. 2001, S. 51). Daher wird an die-ser Stelle auf die Kostenschätzung und die anschließende Berechnung ei-nes Return on Investment nicht vertiefend eingegangen.

Dieser Beitrag ist wie folgt aufgebaut: In Abschn. 2 werden diejenigen Eigenschaften der IL, die eine Einschätzung der Nutzenpotenziale beein-flussen, erläutert sowie die Anwendbarkeit etablierter Methoden zur Nut-zenschätzung von Informationstechnologie diskutiert. In Abschn. 3 werden die verschiedenen Nutzendimensionen der IL vorgestellt und in Abschn. 4 und 5 weiter detailliert. Die Notwendigkeit einer organisatorischen Veran-kerung von IT-Projekten zur Realisierung der Nutzenpotenziale wird in Abschn. 6 erörtert. In Abschn. 7 wird beispielhaft eine Methode zur Be-wertung von IL-Projekten vorgestellt.

2 Eigenschaften von Informationslogistik-Projekten

Projekte im Bereich der IL weisen eine Reihe von Eigenschaften auf, die eine Nutzenbewertung erschweren. Im Folgenden werden diese Eigen-schaften kurz dargestellt und in Abschn. 2.2 wird ihr Einfluss auf die An-wendbarkeit traditioneller IT-Bewertungsmethoden erörtert.

Nutzenpotenziale unternehmensweiter Informationslogistik 159

2.1 Spezifika von Informationslogistik-Projekten

2.1.1 Indirekte Nutzeneffekte

Wie die Kostenzurechnung wird auch die Messung des Nutzens der IL durch den Infrastrukturcharakter der IL erschwert. Die IL selbst erwirt-schaftet keine direkten Marktleistungen, daher ist eine direkte Berechnung des Nutzens nicht möglich (Whittemore 2003). Allerdings ermöglicht sie einerseits Kostenersparnisse, z. B. durch die Ablösung von Altsystemen und die Vereinfachung der Informationsversorgung, andererseits ermög-licht sie aber auch eine Verbesserung der Informationsversorgung von Ent-scheidungsprozessen und neue, informationsgetriebene Geschäftsmodelle (vgl. Abschn. 4.4). Diese indirekte Wirkung in einer Vielzahl von Ge-schäftsprozessen, u. U. über mehrere Stufen hinweg, erschwert die Beur-teilung der Nutzenpotenziale der IL. Eine prozessorientierte Betrachtung der Datenflüsse ist erforderlich, um die Wirkungen der IL über die Stufen der Wertschöpfungskette verfolgen zu können (McKnight 1999; Watson et al. 2004, S. 8; Tallon u. Kraemer 2006). Dabei ist bei Projekten zur Ein-führung analytischer Applikationen, die auf bestehender IL-Infrastruktur aufbauen, die Bestimmung der Nutzenpotenziale tendenziell einfacher, da eine spezifische analytische Applikation in der Regel in direkterem Zu-sammenhang mit den beeinflussten Geschäftsprozessen steht. Bei Basis-komponenten wie z. B. DWHs kann hingegen nur ein indirekter Zusam-menhang zu Geschäftsprozessen hergestellt werden kann.

Bei der Beurteilung von Nutzenpotenzialen kommt erschwerend hinzu, dass der Erfolg von Geschäftsprozessen neben der Informationsversorgung noch von einer Vielzahl weiterer Faktoren abhängig ist. Die Einführung eines IT-Systems macht in der Regel eine Umgestaltung der Geschäftspro-zesse erforderlich, außerdem ist der Erfolg u. a. von den Mitarbeitern, Pro-dukten und externen Faktoren abhängig. Dies erschwert eine Beurteilung des Einflusses von IL, da die Isolation des Einflusses und damit die Zu-rechnung nicht einfach ist (Huber 1999, S. 113).

2.1.2 Komplexität

Die IL ist auf hochgradig komplexe, mehrstufige Systemarchitekturen an-gewiesen. Komponenten zur Extraktion und Aufbereitung der Daten, Spei-cherungsschichten und darauf aufbauende analytische Applikationen bil-den ein komplexes Gesamtsystem (vgl. Kap. 7). Diese Systemar-chitekturen entstehen in der Regel nicht auf einmal, da auf Grund der sonst nicht handhabbaren Komplexität ein inkrementelles Vorgehen beim Auf-bau der Systeme erforderlich ist (Bauer u. Günzel 2004, S. 368 ff.). Hinzu kommt, dass oftmals bestehende Subsysteme weiterentwickelt und an sich


ändernde operative Systeme angepasst werden müssen (Winter u. Jung 2000, S. 26). Dies erschwert die Nutzenschätzung für das Gesamtsystem, da die Zurechnung des Nutzens zu einzelnen Teilsystemen bzw. Projekt-phasen kaum möglich ist.

Mit fortschreitendem Reifegrad der IL-Architektur ist davon auszuge-hen, dass neue Entwicklungen in erster Linie im Bereich der analytischen Applikationen stattfinden. Hier wird die Beurteilung einfacher, da einer-seits eine geringere Zahl von infrastrukturnahen Systemkomponenten tan-giert wird und andererseits analytische Applikationen oft nur eine be-schränkte Zahl von Geschäftsprozessen beeinflussen, wodurch die Kom-plexität der Nutzenanalyse deutlich abnimmt.

2.2 Anwendbarkeit traditioneller IT-Bewertungsmethoden

Zur Bewertung des Nutzens von IT-Projekten existiert eine Vielzahl von Methoden (für einen detaillierten Überblick vgl. Nagel 1990).

Diese Methoden haben das Ziel, auf Basis einer Kosten- und Nutzen-schätzung einen eindimensionalen Wert für den Nettonutzen des Projekts zu prognostizieren, der dann z. B. zum Vergleich mit alternativen Investi-tionsszenarien herangezogen werden kann. Diese Methoden erfordern als Eingabegrößen eine Schätzung für die Kosten und eine Schätzung für den Nutzen des Projekts. Das Hauptproblem für die Bewertung von IL-Projekten liegt dabei in der Bezifferung des Nutzens, dessen Quantifizie-rung auf Grund der oben beschriebenen Eigenschaften der Projekte nur schwer möglich ist – eine präzise Bezifferung des Gesamtnutzens, wie sie etwa in der Investitionsrechnung angestrebt wird, kann als unrealistisch angesehen werden (Watson et al. 2004). Daher bleibt die Nutzenbewertung mit einem erheblichen Grad an Unsicherheit behaftet. Die Hauptschwie-rigkeit bei der Anwendung von Bewertungsmethoden ist also nicht die Durchführung der Methoden selbst, sondern die Gewinnung von realisti-schen Eingabegrößen für diese Methoden.

In den folgenden Abschnitten werden die verschiedenen Arten von Nut-zenpotenzialen und deren Bewertbarkeit beschrieben. Abschn. 7 gibt an-hand eines Methodenbeispiels Hinweise auf praktisch anwendbare Mög-lichkeiten der Nutzenschätzung.

3 Nutzendimensionen der Informationslogistik

Häufig wird versucht, die Nutzeneffekte der IL zu klassifizieren und sie von einer Stichwortsammlung in eine Art Systematik zu überführen. Dabei


sind drei Klassen von Nutzeneffekten der IL erkennbar, die sich in der Di-rektheit ihrer Wirkung unterscheiden. Die Klasseneinteilung ist nicht im-mer scharf trennbar, manche Autoren sprechen daher von einem Konti-nuum der Nutzeneffekte (s. Tabelle 1, Watson et al. 2001, S. 51).

Diese Klassen entsprechen den Einsatzmöglichkeiten von Informations-systemen (Nagel 1990; Stickel 2001). Einerseits können Informationssys-teme substitutiv eingesetzt werden, um manuelle Tätigkeiten zu automati-sieren. Dieser Einsatz ermöglicht Nutzenpotenziale im Bereich der Kostensenkung. Andererseits können Informationssysteme komplementär eingesetzt werden, um bestehende Tätigkeiten und Prozesse besser zu un-terstützen. Diese inkrementellen Innovationen ermöglichen Nutzenpoten-ziale im Bereich der Prozessoptimierung. Die potenziell weitreichendsten Änderungen bringt der strategische Einsatz von Informationssystemen mit sich. Dieser ermöglicht radikale Innovationen, die zu strategischen Wett-bewerbsvorteilen führen (Nagel 1990, S. 29; Ladley 2003; Whittemore 2003, S. 6; Williams u. Williams 2003; Tallon u. Kraemer 2006).

Kostenersparnisse sind die am einfachsten zu bewertenden Nutzeneffek-te. Sie entstehen z. B. durch die Konsolidierung mehrerer analytischer Sys-teme in einem DWH oder durch die gesteigerte Produktivität von Analys-ten. In der Regel ist die Wirkung der Kosteneffekte gut einzelnen Prozessen zuzuordnen – häufig direkt im IT-Bereich – und auf eine gerin-ge Anzahl von Prozessen begrenzt. Durch die direkte Kostenwirkung las-sen sich für diese Nutzeneffekte verhältnismäßig einfach konkrete Werte für den Nutzen ermitteln und nach der Implementierung auch nachprüfen.

Tabelle 1. Nutzenkategorien der IL (vgl. Nagel 1990; Watson et al. 2004)

Nutzeneffekte Kosteneffekte

Strategische Wettbewerbsvorteile

Prozessoptimierung Kostenersparnis

Einflussbereich global lokal

Wirkung indirekt direkt

Messbarkeit entscheidbar kalkulierbar rechenbar


Prozessoptimierungen umfassen all jene Prozessverbesserungen, die durch optimierte Informationsversorgung ermöglicht werden. Diese Ver-besserungen können sowohl operative Prozesse wie auch Managementpro-zesse betreffen (Williams u. Williams 2003, S. 32). Hierzu zählen z. B. die gezieltere Selektion von Kunden für Marketing-Maßnahmen oder die ge-nauere Vorhersage von Nachfrageschwankungen. Diese Nutzeneffekte sind weniger direkt, da der Mehrwert von der Fachabteilung geschaffen wird und von der IL zwar ermöglicht, aber nicht direkt gesteuert wird: Auch wenn eine Analyse einen vielversprechenden Kunden selektiert, liegt doch die Verantwortung für das Herbeiführen einer tatsächlichen Transak-tion beim Vertrieb. Eine Bewertung des Nutzens ist nur noch einge-schränkt möglich, die Kalkulation ist mit zunehmenden Unsicherheiten behaftet.

Strategische Wettbewerbsvorteile schließlich sind von Natur aus weni-ger konkret als die vorgenannten Nutzenkategorien. Sie ergeben sich z. B. aus komplett neuen Geschäftsmodellen, die nur durch integrierte Informa-tionslogistik möglich sind. Diese Nutzenpotenziale haben strategischen Charakter: Sie entfalten ihre Wirkung längerfristig und ihr Einflussbereich ist grösser als bei den anderen Nutzenkategorien. In der Regel entstehen sie durch die Wirkung einer Vielzahl von Geschäftsprozessen und Einflüs-sen, die teils sehr indirekt und über mehrere Stufen der Wertschöpfungs-kette hinweg zu Stande kommen. Diese Nutzeneffekte sind nicht quantifi-zierbar, man kann höchstens eine subjektive Einschätzung gewinnen. Einige Autoren empfehlen daher, diese immateriellen Nutzeneffekte so weit wie möglich auf einzelne Prozessoptimierungen zurückzuführen, um sie messbar zu machen (McKnight 1999; Williams u. Williams 2003, S. 32). So sollte z. B. erhöhte Kundenzufriedenheit möglichst in Kennzahlen wie Kundenwert, Anzahl der Kundendienstvorgänge o. ä. gemessen wer-den.

Für Prozesse im Unternehmen identifiziert Österle die vier allgemein-gültigen Erfolgsfaktoren Zeit (Geschwindigkeit und Termintreue der Pro-zessausführung), Qualität (Erfüllen der Kundenbedürfnisse), Kosten (effi-ziente Leistungserstellung zu wettbewerbsfähigem Preis) und Flexibilität (Abdecken von variierenden Kundenanforderungen) (Österle 1995, S. 109). Zu diesen Erfolgsfaktoren tragen die Nutzenpotenziale der IL in un-terschiedlichem Umfang bei. Während Kostensenkungspotenziale in erster Linie auf den Erfolgsfaktor Kosten wirken, haben die Nutzenpotenziale aus dem Bereich Prozessoptimierung und strategische Wettbewerbsvortei-le auch Auswirkungen auf die Erfolgsfaktoren Zeit, Qualität und Flexibili-tät. Die Zuordnung erfolgt dabei nach dem überwiegend beeinflussten Er-folgsfaktor, eine trennscharfe Abgrenzung ist nicht immer möglich.


Die Nutzeneffekte der Kategorien strategische Wettbewerbsvorteile und Prozessoptimierung werden in Abschn. 4 erläutert, Abschn. 5 befasst sich mit den Kosteneffekten der IL.

4 Wertbeiträge der Informationslogistik

Die IL trägt durch die Bereitstellung integrierter Informationen in vielfa-cher Weise zur Entstehung von Synergien bei, die ohne integrierende Sys-teme und Prozesse nur mit erheblichem Mehraufwand zu erzielen wären (siehe Kap. 3). Die Beiträge der einzelnen Nutzenpotenziale zu den Er-folgsfaktoren sind in Tabelle 2 dargestellt. Die strategischen Wettbewerbs-vorteile sind dabei als Sonderfall zu betrachten, da sie nicht durch Opti-mierung bestehender Prozesse wirken, sondern vielmehr zu ihrer Umsetzung die Schaffung komplett neuer Prozesse erfordern. Daher sind sie in der Tabelle nicht aufgeführt.

In den folgenden Abschnitten werden diese Synergiepotenziale im ein-zelnen dargestellt. Abschnitt 4.6 zeigt mögliche Probleme bei mangelnder Informationsversorgung auf.

Tabelle 2. Beiträge der Nutzenpotenziale

Erfolgsfaktor Zeit Qualität Kosten Flexibili-tät

Kundenorientierung durch ganzheit-liche Informationsversorgung Nutzen durch eventgesteuerte Aktivitäten Nutzen durch detaildatenbasierte Massenkalkulationen Alignment strategischer und operati-ver Entscheidungsprozesse durch integrierte Informationslogistik

4.1 Kundenorientierung durch ganzheitliche Informationsversorgung

Aktuelle Entwicklungen im Marketing – hin zu zunehmend informations-getriebenen Marketingkonzeptionen – lassen der IL für die Optimierung der Marktbearbeitung eine stark steigende Bedeutung zukommen.

Um eine Kundenbeziehung optimal zu monetarisieren, ist es erforder-lich, eine langfristige, intensive und stabile Beziehung zum Kunden aufzu-


bauen. Je länger eine Kundenbeziehung dauert, desto höher wird der ku-mulierte Wert des Kunden und damit der Gewinn des Unternehmens (Bruhn 2001, S. 4). Wenn die Abwanderung von Kunden nur um einen kleinen Prozentsatz gesenkt werden kann, lassen sich erhebliche kunden-bezogene Gewinnsteigerungen realisieren (Reichheld u. Sasser 1990, S. 110), da einerseits Akquisitionskosten sinken und sich andererseits posi-tive Wirkungen durch steigende Kauffrequenz, Cross-Buying, Weiteremp-fehlung und steigende Preisbereitschaft kumulieren (Bruhn 2001, S. 5).

Wenngleich diese Entwicklungen bereits seit den Neunzigerjahren des vorigen Jahrhunderts beobachtet werden, treten diese Phänomene in letzter Zeit in einem zunehmend größeren Rahmen auf. Unternehmen und Märkte sind zunehmend global organisiert, fallende Zollschranken lassen weltweit transparente Märkte entstehen (O'Connor u. Galvin 2001, S. 10).

Dies erfordert eine global integrierte IL, um multinationale Kunden in ihrer Gesamtheit analysieren zu können. Einerseits ermöglicht dies eine Analyse des tatsächlichen Kundenwerts, andererseits hilft es aber auch, Arbitragegeschäfte der Kunden z. B. auf lokale Preisdifferenzen zu ver-hindern.

Eine unternehmensweite IL ermöglicht es, die notwendigen integrierten Daten bereitzustellen, um diese komplexen Analysen durchzuführen. Der Nutzen entsteht hier in den Absatz- und Marketingprozessen, allerdings ist er leicht operationalisierbar, da z. B. der Erfolg von Marketingkampagnen und die Abwanderungsrate von Kunden gut messbar sind.

4.2 Nutzen durch eventgesteuerte Aktivitäten

Die oben dargestellten Marketingmaßnahmen basieren auf längerfristig ge-sammelten Daten und auf im Voraus geplanten Kampagnen. Zusätzlich kann das Unternehmen aber oft kurzfristig zusätzliche Umsätze realisieren, wenn auf die sich plötzlich ändernde Situation einzelner Kunden zeitnah reagiert werden kann (Lundberg 2006, S. 56 ff.). Beispielsweise können überdurchschnittlich hohe Einzahlungen oder Abhebungen Anzeichen für geänderten Finanzierungsbedarf eines Bankkunden geben, dem die Bank bei schneller Reaktion mit einem eigenen Angebot begegnen kann. Hierfür muss aber die IL in der Lage sein, zeitnah Daten zu integrieren und analy-sieren. Diese Vorgänge sollten im Idealfall automatisiert ablaufen und oh-ne menschlichen Eingriff einen Prozess anstoßen, der die Reaktion des Un-ternehmens umsetzt. Hier ist eine Nutzenbeurteilung einfach, solange die Maßnahmen einem bestimmten auslösenden Analyseprozess und den da-zugehörigen Applikationen zuzuordnen sind.


4.3 Nutzen durch detaildatenbasierte Massenkalkulationen

Um den Mitteleinsatz im Marketing optimal zu steuern, ist eine Segmen-tierung der Kunden in Gruppen mit unterschiedlichen Bedürfnissen und unterschiedlichen Profitaussichten unerlässlich. Um eine genaue Zuord-nung des Kunden zu einzelnen Segmenten zu ermöglichen, sind integrierte Daten aus sämtlichen Kundenkontaktkanälen erforderlich. Zusätzlich kön-nen extern bezogene Daten das Bild der eigenen Kunden abrunden, etwa indem durch mikrogeographische Marktdaten aus der Adresse des Kunden wertvolle Informationen über das soziodemografische Umfeld gewonnen werden können (O'Connor u. Galvin 2001, S. 56 ff.).

Genaue Kenntnis des Kunden und seines Verhaltens eröffnet dann ver-schiedene Reaktionsmöglichkeiten:

Individualisierte Preisgestaltung hilft, die individuelle Preisbereitschaft des Kunden optimal auszunutzen. Integrierte Informationen ermöglichen dabei eine globale Koordination der Preisstrategien und zeitnahes Reagie-ren auf das Verhalten von Konkurrenz und Kunden (vgl. Kap. 6 sowie O'Connor u. Galvin 2001, S. 124 ff.).

Die Kenntnis der Kaufhistorie des Kunden ermöglicht es, mit gezielten Angeboten das Cross-Selling-Potenzial des Kunden optimal auszuschöp-fen, indem gezielt komplementäre Produkte angeboten werden.

Intern berechnete Bonitäts-Scores können schließlich dem Unternehmen helfen, die Kreditwürdigkeit des Kunden zu beurteilen und daraus Konse-quenzen etwa für die Art der angebotenen Zahlungswege abzuleiten, um die Wahrscheinlichkeit von Zahlungsausfällen zu minimieren.

Die IL-Infrastruktur muss dabei in der Lage sein, Kalkulationen auf Ebene der einzelnen Kunden durchzuführen und tatsächlich für jeden indi-viduellen Kunden die notwendigen Aggregationen in angemessener Zeit vorzunehmen.

Während die Effektivität von Pricing-Mechanismen und individualisier-ten Angeboten ohne weiteres quantifizierbar ist, lässt sich der Nutzen von Bonitäts-Scores u. U. weniger einfach berechnen. Dennoch bieten Kenn-zahlen zu Zahlungsausfällen hinreichend Ansatzpunkte für eine belastbare Nutzenschätzung.

4.4 Alignment strategischer und operativer Entscheidungs-prozesse durch integrierte Informationslogistik

Entscheidungsprozesse im Unternehmen laufen auf unterschiedlichen Ebenen ab – strategische Entscheidungen durch das Topmanagement be-einflussen taktische Entscheidungen des mittleren Managements, die wie-


derum die operativen Entscheidungen auf unteren Hierarchieebenen be-einflussen (Gorry u. Scott Morton 1971). Wo eine integrierte IL fehlt, müssen Entscheidungen auf diesen Ebenen auf unterschiedlichen Daten-grundlagen getroffen werden – es ist den taktischen und operativen Ebenen nicht möglich, die integrierten Daten der obersten Ebene zu nutzen. Dies kann zu Fehlentscheidungen führen, etwa wenn die Wichtigkeit globaler Kunden mangels Daten von lokalen Organisationseinheiten nicht einge-schätzt werden kann. Nur mit integrierter IL ist es möglich, die strategi-schen Entscheidungen durchgehend auf operative Handlungsanweisungen herunterzubrechen. Dabei stellen integrierte Informationen sicher, dass Alignment zwischen den Entscheidungen hergestellt wird, indem alle Ent-scheidungen auf denselben Daten basieren. Zudem können den taktischen und operativen Entscheidungsträgern ohne großen Aufwand die für sie re-levanten Teile der strategischen Analysen zugänglich gemacht werden. Über Drill-Down-Funktionalitäten können zudem detailliertere Daten ver-fügbar gemacht werden, als sie im Normalfall für strategische Entschei-dungen notwendig sind.

Erforderlich ist hierzu, dass die IL den Zugriff auf Daten sämtlicher Aggregationsstufen ermöglicht. Management-Informationssysteme älterer Architektur, die mit voraggregierten Daten aus operativen Systemen ge-speist werden, sind hierzu nicht in der Lage.

4.5 Informationsgetriebene Geschäftsmodelle

Integrierte und schnell verfügbare Unternehmensinformationen verschaf-fen agilen Unternehmen neue Marktanteile und lassen gar neue Märkte entstehen. Geschwindigkeit und Agilität im unternehmerischen Handeln werden nicht nur benötigt, wenn unerwartete Ereignisse eintreten. Viel wertvoller ist es, anhand aktueller und detaillierter Unternehmensdaten die Geschäftsentwicklung zu gestalten und vorherzusehen, um sowohl Neuge-schäft zu generieren als auch Nachteile vor der Entstehung zu vermeiden. Ein Großteil der Zeit, die ein Unternehmen für die Problembearbeitung aufwendet, könnte direkt und gewinnbringend am Kunden eingesetzt wer-den.

Genau an diesem Punkt der Interaktion mit dem Kunden entstehen in vielen Branchen neue und innovative Geschäftsmodelle. Die Dauer einer verfügbaren Kundeninteraktion gilt als Messlatte für die Bereitstellung al-ler relevanten Unternehmensinformationen inklusive erforderlicher Analy-tik. Dasjenige Unternehmen gewinnt, dem es gelingt den Kunden zur rich-tigen Zeit mit für ihn relevanten Produkten und Dienstleistungen zu überzeugen. So kommt die Zeit ins Spiel.


So erfasst die RBC Financial Group Canada (RBC) täglich Millionen von Transaktionen und verarbeitet diese Detaildaten u. a. für Kundenseg-mentierungen (Coleman 2003). Mittlerweile wurde der Kundenfokus so verbessert, dass jeder Kunde praktisch ein einzelnes Segment darstellt und jederzeit über jeden Verkaufskanal mit der richtigen Botschaft zur richti-gen Zeit adressiert werden kann. Als Ergebnis dieses Vorgehens

wuchs der Umsatz pro Marketingbudgeteinheit zweistellig, stiegen die Response-Raten der Direktmarketing-Kampagnen stark an,

teilweise erreichten sie eine Rate von bis zu 40% – im Vergleich mit dem Branchen-Durchschnitt von 2–4 %,

führte eine gezielte Marketing-Kampagne zu einer Steigerung der Ein-lagen für einen spezifischen Altersvorsorge-Plan um 51%.

4.6 Opportunitätsvergleich: Probleme mangelnder Informationsintegration

Die Quantifizierung der positiven Nutzeneffekte bleibt unvollständig. Um die subjektiven Einschätzungen von Nutzenpotentialen mit Ideen zu ver-sorgen, kann in einem Opportunitätsvergleich auf die Probleme mangeln-der Informationsintegration hingewiesen werden.

Ist eine detaildatenbasierte und ganzheitliche Kundensicht nicht vorhan-den, kann lediglich mit aggregierten Daten gearbeitet werden. Eine Aggre-gation bedeutet jedoch für einen einzelnen Kunden die Anwendung eines Mittel- bzw. Durchschnittswertes. Der Kunde ist, und so spürt er es auch, mittelmäßig betreut. Angebote, die auf durchschnittlichen Daten beruhen, sind auch nur mittelmäßig gut. Der Kunde wird naturgemäß das Angebot bevorzugen, dass individuell auf seine Bedürfnisse zugeschnitten ist.

Wird eine Kundenaktion vom Unternehmen nicht wahrgenommen, da keine eventgesteuerte Informationsverarbeitung existiert, entsteht je nach Erwartungshaltung des Kunden eine negative bzw. keine positive Erfah-rung. Die Möglichkeit, mit dem Kunden ein Geschäft zu tätigen, ver-streicht ungenutzt.

Das fehlende Alignment von strategischen und operativen Entschei-dungsprozessen ist insbesondere für global tätige Unternehmen mit Risi-ken behaftet. Werden Entscheidungen auf Basis unterschiedlich erzeugter Unternehmensdaten (Datensilos) getroffen, so ist eine Divergenz zwischen zentraler Strategie und lokaler Umsetzung in den Unternehmenseinheiten unvermeidlich. Bei dem heutigen Veränderungstempo der Märkte, Ge-schäftsmodelle und Unternehmensstrategien ist jedoch jederzeit sicherzu-


stellen, dass Strategie und Umsetzung aufeinander abgestimmt sind, we-nigstens jedoch konvergieren.

5 Kostensenkung durch Informationslogistik

Eine integrierte IL hilft auf verschiedene Art und Weise, Kosten zu sparen. Diese Kosteneffekte sind meist ohne weiteres quantifizierbar und sollten daher in jeder Wirtschaftlichkeitsbetrachtung berücksichtigt werden. Den-noch sollte ein ausgewogener Business Case nicht allein auf die Kostenef-fekte abstellen, sondern muss immer auch die Nutzenpotenziale berück-sichtigen, zumal die Investitionen in die IL in der Regel nicht alleine durch Kosteneffekte gerechtfertigt werden können (McKnight 1999; Ladley 2003).

Die Kosteneffekte können direkt oder indirekt sein. Direkte Kostenef-fekte treten im Bereich der Informationslogistik selber auf. Zu ihnen zäh-len Infrastrukturkosten und Kosteneffekte der Lieferfähigkeit. Indirekte Kosteneffekte treten in den Bereichen auf, die die Informationslogistik nutzen. Zu ihnen zählen die Aspekte Datenqualität, Geschwindigkeit und Compliance sowie Risikomanagement. Dabei ist anzumerken, dass insbe-sondere die indirekten Kosteneffekte neben den Kosten auch andere Er-folgsfaktoren positiv beeinflussen – so wirkt eine höhere Geschwindigkeit neben den Kosten auch auf den Erfolgsfaktor Zeit.

5.1 Datenqualität

Wenn Daten aus verschiedenen analytischen Systemen zur Entscheidungs-unterstützung genutzt werden, sind Inkonsistenzen unausweichlich, selbst da, wo verschiedene Quellen eigentlich dieselben Daten zu liefern vorge-ben. Diese Diskrepanzen können unterschiedliche Gründe haben. Einer-seits ändern sich die Dimensionsdaten von DWH-Datenmodellen. Wo die-se nicht zentral verwaltet werden, können Unterschiede in den Dimensio-nen zu abweichender Zurechnung von Daten bei der Aggregation führen (Schmaltz u. Dinter 2006, S. 87f.). Andererseits können unterschiedliche Aggregationsprozesse mit verschiedenen Algorithmen zu Unterschieden führen. Insbesondere können sich Fehler summieren, wenn auf Basis von voraggregierten Daten gerechnet wird. Schließlich können unterschiedli-che Stichtage der verschiedenen Systeme zu den Differenzen beitragen. Diese Diskrepanzen führen zu erheblichen Reibungsverlusten in den Ent-scheidungsprozessen, wenn vor der Sachdiskussion erst zeitaufwändige Abstimmungsprozesse notwendig werden. Eine zentrale „Single Version


of the Truth“ führt zu organisationsweit konsistenten, glaubwürdigen Da-ten.

Eine zentrale IL erleichtert das Management der Datenqualität erheb-lich, da Fehlerquellen nur noch einmalig identifiziert und beseitigt werden müssen. Wo in dezentralen Systemen mehrere ETL-Prozesse für unter-schiedliche Zielsysteme dieselben Daten aus den operativen Systemen ex-trahieren, vervielfacht sich die Zahl der möglichen Fehlerquellen. Eine zentrale IL-Infrastruktur kann hier sicherstellen, dass jede Datenquelle nur einmal angeschlossen werden muss, dass ETL-Prozesse nach konsistenten Regeln durchgeführt werden, dass Aggregationen gleichartig durchgeführt werden und dass Kennzahlen stets gleichen Definitionen folgen.

5.2 Compliance und Risikomanagement

In zunehmendem Maße sehen sich Unternehmen mit gesetzlichen Kon-trollvorschriften wie z. B. dem Sarbanes-Oxley-Act (SOX), Basel II oder Solvency II konfrontiert. Diese Vorschriften erfordern seitens der Unter-nehmen genaue Kenntnis über die Situation des eigenen Unternehmens. Im Falle von Verfehlungen drohen erhebliche Mehrkosten oder bei SOX gar empfindliche Strafen für die verantwortlichen Manager.

Zur Erfüllung dieser Kontrollauflagen ist eine integrierte IL erforder-lich, die notwendige revisionssichere, konzernweite Konsolidierung von Daten ist auf Basis von Spreadsheets nicht zu erreichen. Während die Vermeidung von Haftstrafen keinen monetären Nutzen im engeren Sinne stiftet, kann doch von einer motivierenden Wirkung dieser Vorschriften ausgegangen werden. Zudem liefern die gewonnenen Erkenntnisse über die Risikopositionen des Unternehmens wertvolle Hinweise für die Unter-nehmenssteuerung (Ladley 2003; Ramchandra u. Srikant 2006, S. 19).

5.3 Geschwindigkeit

Der Wert von Informationen für das Unternehmen ist über die Zeit nicht konstant, sondern verfällt i. d. R. mit zunehmendem Alter der Informatio-nen (Hackathorn 2003). Insbesondere bei taktischen und operativen Ent-scheidungen besteht vielfach nur ein kurzes Zeitfenster, in dem die Ent-scheidung Mehrwert generieren kann. Reagiert das Unternehmen zu spät, ist die Gelegenheit vorbei. Die IL kann wertvolle Beiträge leisten, um die Latenzzeit, d. h. die Zeit zwischen dem Eintreten eines Ereignisses, dem Aufbereiten und Analysieren der Informationen und dem Einleiten einer Maßnahme, zu verringern.


Die Latenzzeit lässt sich in drei Teile einteilen: Datenlatenz, Analysela-tenz und Entscheidungslatenz, die jeweils durch eine entsprechende Ge-staltung der IL beeinflusst werden können (Hackathorn 2003; Melchert et al. 2004; Schelp 2006).

Die Datenlatenz ist die Zeit, die vergeht, bis die Daten aus einer ge-schäftlichen Transaktion (bzw. bei externen Datenquellen aus einem exter-nen Ereignis) im DWH bereitstehen. Sie umfasst die für die ETL-Prozesse und die Vorverarbeitung im DWH notwendige Zeit. Vielfach werden in analytischen Systemen nur einmal täglich Daten geladen – hier kann ein Übergang zur Datenverarbeitung in Echtzeit bzw. in „Near-Real-Time“ wertvolle Zeit sparen. Da Echtzeitverarbeitung in der Regel technisch sehr aufwändig ist, ist hier aber eine genaue Analyse der Kosten-Nutzen-Relation unumgänglich.

Die Analyselatenz bezeichnet die Zeit, die vom Eintreffen der Daten bis zur Bereitstellung der Analyseergebnisse für den Entscheidungsträger ver-geht. Sie setzt sich zusammen aus der Zeit zur Aggregation der Daten und zur Identifikation und Bewertung von Entscheidungsalternativen. Wo die Datenquellen für die IL nicht integriert sind, kann diese Latenzzeit unak-zeptabel lang sein. Wenn Daten erst aus unterschiedlichen Systemen zu-sammengetragen und manuell konsolidiert werden müssen, wird neben dem Personalaufwand auch der Zeitbedarf schnell unwirtschaftlich groß. Eine integrierte IL verkürzt diese Prozesse erheblich. Wo zusätzlich die Analyseergebnisse nach dem Push-Prinzip an die Empfänger verteilt wer-den können, statt nach dem Pull-Prinzip vom Nutzer abgeholt zu werden, kann zusätzlich Zeit gespart werden.

Die Entscheidungslatenz schließlich bezeichnet die Zeit vom Bereitste-hen der Analyseergebnisse bis zur Initiierung von Maßnahmen. In dieser Phase des Reaktionsprozesses sind oft menschliche Entscheidungsträger involviert, weshalb technische Maßnahmen nicht der einzige Ansatz zur Reduktion der Latenz sind. Eine sorgfältige Gestaltung der Entscheidungs-prozesse mit klar abgegrenzten Aufgaben und Kompetenzen sowie eine nutzeradäquate Aufbereitung der Analyseergebnisse können erhebliche Sparpotenziale bergen. Zudem können technische Lösungen die Entschei-dung unterstützen, indem mit Hilfe von Geschäftsregeln und Schwellen-werten bestimmte Entscheidungen automatisch gefällt werden oder auto-matisiert den inhaltlich kompetenten und organisatorisch befugten Entscheidungsträgern zugeleitet werden.


5.4 Lieferfähigkeit

Eine dienstleistungsorientierte IT-Organisation muss in der Lage sein, kurzfristig auf geänderte Anforderungen aus den Fachabteilungen zu rea-gieren. Dezentrale IL erfordert ein vielfaches Duplizieren von System-komponenten und Prozessen, insbesondere in den unteren Schichten der Systemarchitektur und bei Basisdiensten wie Metadatenmanagement, Au-thentifizierung, Datenqualität etc.

Eine vereinheitlichte Applikationsplattform für die IL kann diese Kom-ponenten zentral zur Verfügung stellen und damit die Entwicklungsprozes-se der IL entscheidend beschleunigen. Dabei sinken nicht nur Kosten und Zeitbedarf, auch die Qualität der Lösungen kann gesteigert werden. Aller-dings sind zur Durchsetzung zentraler Lösungen effektive Governance-Prozesse erforderlich, um lokale „Quick and Dirty“-Lösungen zu verhin-dern, die später nicht in die Gesamtarchitektur eingebunden werden kön-nen und deren Wartung und Evolution überproportional teuer sind.

5.5 Infrastrukturkosten

Hand in Hand mit der erhöhten Lieferfähigkeit gehen geringere IT-Kosten. Eine zentralisierte IL ermöglicht durch eine schlankere und nicht redun-dante Infrastruktur Kosteneinsparungen sowohl im Bereich von Sachkos-ten als auch bei den Personalkosten.

Wo möglichst viele Systeme für die IL auf einer gemeinsamen Plattform konsolidiert werden, können die Sachkosten für Hardware und Software erheblich sinken. Einerseits können mehrere Applikationen auf einer ge-ringeren Anzahl von physischen Servern betrieben werden, was die Hard-warekosten senkt. Andererseits können durch vereinheitlichte Software-plattformen, z. B. für ETL-Systeme und Frontend-Applikationen, Lizenz-kosten eingespart werden. Falls kostenintensive Altsysteme abgelöst wer-den können, ist das Sparpotenzial besonders hoch.

Zusätzlich können bei einer zentralisierten Plattform Infrastrukturkom-ponenten mehrfach genutzt werden, so dass die anteiligen Kosten für die nutzende Applikation sinken bzw. so dass Infrastruktur zur Verfügung steht, die für dezentrale Applikationen nicht vorhanden wäre, wie z. B. zentrales Metadatenmanagement.

Darüberhinaus können Personalkosten gespart werden, einerseits durch sinkenden Arbeitsaufwand, andererseits durch höhere Produktivität und niedrigere Ausbildungskosten.

Für den Betrieb einer kleineren Anzahl von Servern und Datenbanken ist eine geringere Anzahl von Personen und unterschiedlichen Skillsets nö-


tig. Dies gilt ebenso für die Softwareentwicklung, wenn Modellierung, Anwendungsentwicklung und Qualitätssicherung auf einer einheitlichen Plattform erfolgen. Schließlich sinken die Kosten für die Datenanalyse an sich, wenn Analysten nur noch für eine einheitliche Softwareplattform ausgebildet werden müssen und durch den Wegfall manueller Dateninteg-ration höhere Produktivität erreichen.

6 Organisatorische Einbettung

Um die Nutzenpotenziale von Informationstechnologie zu realisieren, müssen die beeinflussten operativen Prozesse so umgestaltet werden, dass die neu zur Verfügung stehenden Systeme auch tatsächlich genutzt wer-den. Andernfalls ist es wahrscheinlich, dass die neuen Systeme verwaisen und weitgehend ungenutzt bleiben, was zu einem Scheitern des Projekts oder zumindest zu ungenügender Rendite führt.

Für die IL ist diese Voraussetzung von besonderer Bedeutung. Während bei operativen Systemen die enge Einbindung in Geschäftsprozesse si-cherstellt, dass Systeme genutzt werden, ist dies bei indirekt wirkenden Systemen der IL nicht ohne weiteres sichergestellt: Wo ein neues System zur Auftragsbearbeitung eingeführt wird, können die entsprechenden Ge-schäftsprozesse nicht ohne Nutzung des Systems ausgeführt werden, so-bald eventuell existierende Vorläufersysteme abgeschaltet werden. Wenn eine neue analytische Applikation zur Verfügung gestellt wird, können Entscheidungsprozesse durchaus auch ohne Nutzung der Applikation aus-geführt werden. Die tatsächliche Nutzung des Systems muss hier mögli-cherweise durch flankierende organisatorische Maßnahmen gefördert wer-den.

Während diese Erkenntnis vorderhand trivial scheint, ist dies doch ein Aspekt, der in der Praxis vielfach zu Problemen führt, weshalb die Wich-tigkeit einer organisatorischen Einbettung in der neueren Literatur vielfach hervorgehoben wird (vgl. z. B. Watson et al. 2002; Smith u. McKeen 2003; Williams u. Williams 2003; Kohli u. Devaraj 2004; Tallon u. Krae-mer 2006). Tatsächlich ist die frühere DWH-Literatur vielfach sehr tech-nologiezentriert und vernachlässigt organisatorische Aspekte weitgehend.

Für die IL gilt diese Bedingung in besonderem Maße, da die IL durch ihre indirekte Wirkung nur die Voraussetzungen für den Nutzen schafft. Insbesondere die in Abschn. 4 diskutierten Wertbeiträge müssen durch die Optimierung von Geschäftsprozessen in den Fachabteilungen realisiert werden. Empirische Studien zeigen, dass klar definierter und messbarer


Geschäftsnutzen zu den wichtigsten Erfolgsfaktoren von DWH-Projekten zählt (Hwang u. Xu 2005).

Die erfolgreiche Umsetzung umfassender IL-Projekte erfordert daher in-tensive Zusammenarbeit zwischen der IT-Abteilung und den Fachabtei-lungen sowie intensives Change Management (Watson et al. 2002, S. 500 f.). Dabei ist es über die Umgestaltung der Prozesse hinaus erforderlich, vorab eine Vision zu entwickeln und die Unterstützung des Managements sicherzustellen. Im Nachgang müssen der Erfolg der Veränderungen sicht-bar gemacht und die Basis für weitergehende, auf dem Erreichten auf-bauende Veränderungen geschaffen werden (Kotter 1995, S. 61).

Hierzu empfiehlt sich die Definition von Kennzahlen für die zu ändern-den Prozesse. Falls diese schon vor Beginn des Projekts mit den Prozess-verantwortlichen auf der Fachseite festgelegt und im Projektverlauf regel-mäßig gemessen werden, kann sichergestellt werden, dass einerseits der Erfolg des Projekts messbar wird und andererseits auch die Fachabteilung die notwendige Motivation entwickelt, die Änderungen tatsächlich umzu-setzen (Daddah 2005).

Langfristiges Ziel der IL ist es, die Verwendung von integrierten Infor-mationen in Entscheidungsprozessen zur Selbstverständlichkeit zu machen und das Unternehmen zu einer faktenbasierten Entscheidungskultur hin weiterzuentwickeln (Pfeffer u. Sutton 2006).

7 Methodenbeispiel zur Bewertung der Informationslogistik

Wie in Abschn. 2.2 dargestellt, ist die gesamthafte Bewertung des Nutzens von IL im Sinne einer vollständigen Erfassung des Nutzens wenig realis-tisch. Tatsächlich hält sich die Wissenschaft mit der Entwicklung praktisch anwendbarer, ganzheitlicher Bewertungsmethoden sichtbar zurück (Tallon u. Kraemer 2006, S. 995 f.).

Watson et al. empfehlen daher bei der Messung die Konzentration auf die „Sweet Spots“, um anhand der Wirkung einzelner analytischer Appli-kationen die Vorteilhaftigkeit des Gesamtsystems nachzuweisen (Watson et al. 2004). Ziel dieses Vorgehens ist weniger die Genauigkeit des ermit-telten Endwerts als vielmehr die Möglichkeit, die postulierten Nutzenpo-tenziale so zu kalkulieren, dass sie auch von Management und Fachabtei-lungen nachvollzogen werden können.

Als Fallbeispiel für eine an der praktischen Messbarkeit orientierten Methode wird im Folgenden die Methode Business Impact Assessment des Softwareherstellers Teradata vorgestellt (o.V. 2002; Daddah u. Sweeney


2004; Daddah 2005; Ferrell 2005a,2005b). Ziel dieser Methode ist eine Bewertung der Nutzenpotenziale von IL-Projekten sowie die Schaffung von Mechanismen zur Überwachung des erzielten Nutzens nach Umset-zung des Projekts. Die Methode dient der Bewertung von IL-Projekten sowohl vor dem Projektstart als auch ex post, soweit im Vorfeld hinrei-chend genaue Vergleichszahlen erhoben wurden.

Die Methode zielt dabei nicht primär auf eine möglichst genaue Bewer-tung des Gesamtnutzens, sondern vielmehr auf eine nachvollziehbare Be-zifferung von Nutzenpotenzialen und auf die Schaffung einer Basis von Kennzahlen für das laufende Projektcontrolling ab. Durch die enge Anbin-dung an die Fachabteilungen wird sichergestellt, dass einerseits die Schät-zung des Nutzens auf realistischen Annahmen beruht. Andererseits soll durch Einbeziehung der Fachabteilungen in die Verantwortung für den Projekterfolg sichergestellt werden, dass die richtigen Anreize gesetzt werden, um das Projekt zum Erfolg zu führen (wie z. B. von Smith u. McKeen 2003 gefordert).

Die Methode besteht aus sieben sequenziellen Phasen, wobei die letzte Phase in einen kontinuierlichen Prozess münden soll. Priorisierung von Geschäftsprozessen: Zu Beginn der Potenzialbeurtei-lung werden, um den Analyseaufwand in vertretbarem Rahmen zu halten, einzelne Geschäftsprozesse ausgewählt, die im Folgenden auf ihre Nut-zenpotenziale untersucht werden. Diese Auswahl erfolgt anhand der Ge-schäftsstrategie sowie anhand von technologischen und finanziellen Über-legungen. Aus der Geschäftsstrategie werden Prozesse abgeleitet, die für die Entwicklung des Unternehmens besondere Bedeutung haben, oder die besonderem Konkurrenzdruck ausgesetzt sind. Technologische Überle-gungen zeigen Prozesse auf, die unzureichend von der IT unterstützt wer-den oder die nicht hinreichend flexibel sind. Anhand finanzieller Kennzah-len werden Prozesse ausgewählt, deren Rendite unzureichend ist, oder die z. B. unregelmäßigen Cash-Flow generieren. Schließlich können auch wei-tere Überlegungen wie z. B. regulatorische Anforderungen die Auswahl beeinflussen. Während diese Auswahl vor der Erhebung konkreter Daten naturgemäß subjektiv sein muss, ist dies akzeptabel, da eine vollständige Erhebung der Nutzenpotenziale nicht Ziel der Methode ist. Vielmehr sol-len in dieser Phase Geschäftsprozesse ausgewählt werden, deren Optimie-rungspotenzial offensichtlich ist, um möglichst klaren Nutzen nachweisen zu können. Datenerhebung und Metrik-Definition: Im Rahmen von strukturierten Interviews mit den Fachabteilungen und mit IT-Verantwortlichen wird dann der Status Quo der untersuchten Geschäftsprozesse erhoben. Diese Interviews fokussieren auf der einen Seite auf die Kennzahlen der unter-suchten Prozesse. Es wird analysiert, was die Ziele des Geschäftsprozesses


sind und anhand welcher konkreter, messbarer Kennzahlen (z. B. Konver-sionsraten von Werbekampagnen) der Erfolg gemessen wird. Diese Kenn-zahlen dienen später der Erfolgskontrolle für die einzelnen Prozesse.

Der andere Schwerpunkt der Interviews liegt im Bereich der Informati-onsbedarfe. Detailliert werden die benötigten Datenobjekte, ihre Granulari-tät, Aktualität und Verlässlichkeit erfasst. Dazu werden die genutzten IT-Systeme und die zugehörigen Datenbeschaffungs- und Analyseprozesse dokumentiert. Zusätzlich wird gezielt nach Verbesserungspotenzialen bei besserer Informationsversorgung und nach Problemen bei der bestehenden Informationsversorgung gefragt. Projektauswahl: Basierend auf den erhobenen Verbesserungspotenzialen werden zu realisierende Infrastrukturkomponenten und analytische Appli-kationen ausgewählt, anhand derer die Berechnung der Projektkennzahlen erfolgt. Diese Auswahl wird primär von strategischen Überlegungen be-einflusst. Zusätzlich wird sichergestellt, dass die Teilprojekte keine wider-sprüchlichen Ziele haben und möglichst in anderen Kontexten wiederver-wendbar sind. Kostenschätzung: Anhand von Erfahrungen aus bestehenden Projekten werden die Kosten für die Umsetzung der ausgewählten Initiativen ge-schätzt. Dabei werden neben Hardware- und Softwarekosten auch Kosten für Customizing und Implementierung sowie Schulung und Kommunikati-on berücksichtigt. Prognose der Nutzenpotenziale: Anhand der im zweiten Schritt erhobe-nen Metriken und Verbesserungspotenziale werden für die betrachteten Geschäftsprozesse konkrete Verbesserungspotenziale und Zielwerte defi-niert. Dabei werden einerseits Sollwerte für die zuvor definierten Kenn-zahlen festgelegt, andererseits werden auch der zusätzlich zu erwirtschaf-tende Umsatz bzw. die möglichen Einsparungen beziffert. Beispielsweise wird basierend auf den erhobenen Zeitbedarfen für bestimmte Analysen die Ersparnis durch schnellere Prozessabwicklung kalkuliert. Dabei wird Wert darauf gelegt, diese Sparpotenziale konservativ zu schätzen und ei-nen Konsens mit der Fachseite über erreichbare Zielwerte zu erzielen. Damit wird sichergestellt, dass die später für die Zielerreichung verant-wortlichen Nutzer der Systeme im Vorfeld von den Prognosen überzeugt werden; zudem erleichtert es eine konservative Schätzung, die Projektziele zu erreichen. Konsolidierung der Nutzenpotenziale: Die prognostizierten Nutzenef-fekte und die geschätzten Kosten werden dann konsolidiert und mit Ver-fahren der finanziellen Investitionsrechnung (Blohm et al. 2006, S. 41 ff.) in einwertige Kennzahlen wie Kapitalwert (Net Present Value), Kapital-rendite (Return on Investment) oder Amortisationszeitraum (Payback Pe-riod) überführt (Nagel 1990, S. 59 ff.; Kütz 2005, S. 148 ff.). Diese haben


den Vorteil, dass sie in der Praxis weit verbreitet sind und daher gut ver-standen werden (Blohm et al. 2006, S. 44 ff.). Zudem sind die Ergebnisse mit den Kennzahlen konkurrierender Investitionen auch außerhalb des IT-Bereichs vergleichbar. Organisatorische Verankerung und Review: Im letzten Schritt werden Verantwortlichkeiten für die definierten Nutzenziele zugewiesen. Für jede Kennzahl wird ein Verantwortlicher auf der Fachseite bestimmt. Zusätz-lich wird ein Prozess zur Überwachung der Kennzahlen geschaffen, damit der Fortschritt des Projekts kontinuierlich überprüft werden kann, und da-mit Fehlentwicklungen frühzeitig erkannt und korrigiert werden können.

Die Business Impact Assessment-Methode hat nicht das Ziel, einen ma-thematisch korrekten Beweis für den Gesamtnutzen von IL-Projekten zu führen. Daher wird auch auf die Anwendung von fortschrittlichen, mehr-dimensionalen oder nichtmonetären Bewertungsverfahren (Nagel 1990, S. 71 ff.; Kütz 2005, S. 259 ff.; Tallon u. Kraemer 2006, S. 1001 ff.) verzich-tet. Vielmehr ist es Ziel der Methode, neben einem Nachweis der Vorteil-haftigkeit der Projekte auch die notwendige organisatorische Einbettung sicherzustellen und das Change Management zu unterstützen. Damit reprä-sentiert das Business Impact Assessment einen pragmatischen Ansatz zur Lösung des komplexen Problems der Nutzenbewertung.

Literatur


Blohm, H.; Lüder, K.; Schaefer, C.: Investition, 9. Aufl., Vahlen, München 2006. Bruhn, M.: Relationship Marketing, Vahlen, München 2001. Coleman, A.: Value-Based Measurement, in: Journal of Data Warehousing 8

(2003) 3, S. 45-50. Daddah, C.: A Metric's Journey, http://www.teradata.com/t/page/142189/

index.html, 27.09.2007. Daddah, C.; Sweeney, R. J.: Teradata Business Value Consulting - A Proven App-

roach to Forecasting and Measuring Data Warehousing Value, Teradata, 2004.

Ferrell, K.: The Value Cascade, in: Teradata Magazine 5 (2005a) 4. Ferrell, K.: Wellspring of business value, in: Teradata Magazine 5 (2005b) 4. Frie, T.; Wellmann, R.: Der Business Case im Kontext des Data Warehousing, in:

Jung R.; Winter R. (Hrsg.): Data Warehousing Strategie - Erfahrungen, Me-thoden, Visionen, Springer, Berlin et al. 2000.



Hackathorn, R. D.: Minimizing Action Distance, http://www.tdan.com/ i025fe04.htm, 01.09.2005.

Huber, H.: Die Bewertung des Nutzens von IV-Anwendungen, in: von Dobschütz L.; Baumöl U. e.a. (Hrsg.): IV-Controlling aktuell, Gabler, Wiesbaden 1999.

Hwang, M. I.; Xu, H.: A Survey of Data Warehousing Success Issues, in: Busi-ness Intelligence Journal 10 (2005) 4.

Kohli, R.; Devaraj, S.: Realizing the Business Value of Information Technology Investments: An Organizational Process, in: MIS Quarterly Executive 3 (2004) 1, S. 53-68.

Kotter, J. P.: Leading Change: Why Transformation Efforts Fail, in: Harvard Bu-siness Review 73 (1995) 2, S. 59-67.

Kütz, M.: IT-Controlling für die Praxis - Konzeption und Methoden, dpunkt, Hei-delberg 2005.

Ladley, J.: Beyond the Data Warehouse: The Return on Information, http://www. dmreview.com/article_sub.cfm?articleId=6903, 13.09.2007.

Lundberg, A.: Leverage Complex Event Processing to Improve Operational Per-formance, in: Business Intelligence Journal 11 (2006) 1, S. 55-65.

McKnight, W.: Data Warehouse Justification and ROI, in: DM Review 9 (1999) 11.

Melchert, F.; Winter, R.; Klesse, M.: Aligning Process Automation and Business Intelligence to Support Corporate Performance Management, in: Romano N. C., Jr. (Hrsg.): Amcis 2004, New York 2004, S. 4053-4063.

Nagel, K.: Nutzen der Informationsverarbeitung, 2. Aufl., Oldenbourg, München, Wien 1990.

o.V. : Realizing ROI. Projecting and harvesting the business value of an enterprise data warehouse, Teradata, 2002.

O'Connor, J.; Galvin, E.: Marketing in the Digital Age, 2. Aufl., Prentice Hall, Harlow et al. 2001.

Österle, H.: Business Engineering: Prozess- und Systementwicklung, Band 1: Entwurfstechniken, 2. Aufl., Springer, Berlin 1995.

Pfeffer, J.; Sutton, R.: Evidence Based Management, in: Harvard Business Review 84 (2006) 1, S. 62-74.

Ramchandra, V.; Srikant, S.: Data Quality for Enterprise Risk Management, in: Journal of Business Intelligence 11 (2006) 2, S. 18-21.

Reichheld, F. F.; Sasser, W. E.: Zero defections: Quality comes to services, in: Harvard Business Review 68 (1990) 5, S. 105-111.

Schelp, J.: Real-Time Warehousing und EAI, in: Chamoni P.; Gluchowski P. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technolo-gien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 425-438.

Schmaltz, M.; Dinter, B.: Wartung von Dimensionsdaten in verteilten Data Ware-house-Systemen, in: Schelp J.; Winter R. e.a. (Hrsg.): DW2006 - Integration, Informationslogistik und Architektur, Gesellschaft für Informatik, Friedrich-shafen 2006, S. 83-106.

Smith, H. A.; McKeen, J. D.: Developments in practice VII: Developing and deli-vering the IT value proposition, in: Communications Of The Association For Information Systems 11 (2003), S. 438-450.


Sommer, D.: Spending Preferences for Business Intelligence and Information In-frastructure, 2007, Gartner, 2007.

Stickel, E.: Informationsmanagement, Oldenburg Wissenschaftsverlag GmbH, München 2001.

Tallon, P. P.; Kraemer, K. L.: The development and application of a process-oriented "thermometer" of IT business value, in: Communications Of The As-sociation For Information Systems 17 (2006), S. 995-1027.

Watson, H. J.; Abraham, D. L.; Chen, D.; Preston, D.; Thomas, D.: Data Ware-housing ROI: Justifying and Assessing a Data Warehouse, in: Business Intel-ligence Journal 9 (2004) 2, S. 6-17.

Watson, H. J.; Annini, D.; Wixom, B. H.; Avery, L.; Rutherford, M.: Current Practices in Data Warehousing, in: Information Systems Management 18 (2001) 1, S. 47-55.

Watson, H. J.; Goodhue, D. L.; Wixom, B. H.: The benefits of data warehousing: why some organizations realize exceptional payoffs, in: Information & Mana-gement 39 (2002) 6, S. 491-502.

Whittemore, B.: The Business Intelligence ROI Challenge: Putting It All Toge-ther, in: Business Intelligence Journal 8 (2003) 1, S. 4-10.

Williams, S.; Williams, N.: The Business Value of Business Intelligence, in: Busi-ness Intelligence Journal 8 (2003) 3, S. 30-39.

Winter, R.; Jung, R.: Ökonomische Beurteilung von Entwicklungsvorhaben im Umfeld des Data Warehousing, in: Schütte R.; Rotthowe T. e.a. (Hrsg.): Data Warehouse Managementhandbuch, Springer, Berlin u.a. 2000, S. 25-37.

9 Metadaten, Referenzdaten, Stammdaten

Hans Wegener

Zurich Financial Services

1 Einleitung ....................................................................................... 179 2 Modelle und der Prozess von Integration und Evolution ............... 183 3 Die Rolle von Meta-, Stamm- und Referenzdaten in der

Entwicklung und Pflege integrativer Systeme ................................ 193 4 Zusammenfassung .......................................................................... 197

Literatur .......................................................................................... 198

1 Einleitung

Jede Organisation setzt sich ab einer bestimmten Größe kontinuierlich mit der Frage auseinander, wie Daten aus verschiedenen Bereichen integriert werden können. Dort, wo Daten eine wichtige Rolle in der Wertschöp-fungskette spielen (z. B. in der Finanzindustrie), wo strikte regulatorische Anforderungen über die Nachverfolgbarkeit von Ereignissen und Ent-scheidungen zu beachten sind (z. B. in der Pharmaindustrie) oder wo die Erzielung von Effizienz und Agilität im Vordergrund stehen (z. B. in der Automobilindustrie), ist die systematische Datenintegration eine zwingend zu beherrschende Fähigkeit.

Die Mechanik der Datenintegration, wie Konnektivität oder lexikalische und syntaktische Transformation, ist dabei immer seltener ein substanziel-les Hindernis. Moderne Werkzeuge decken diesen Bereich zuverlässig ab. Dieser Aspekt wird deshalb hier nicht weiter betrachtet. Auch die nach wie vor wichtige Performanz und Stabilität von Lösungen findet hier keine nä-here Berücksichtigung. Dieses Kapitel setzt sich ausschließlich mit der Unterstützung der semantischen Datenintegration auseinander, d. h. wie si-

180 Hans Wegener

chergestellt werden kann, dass Integration aus fachlicher Sicht korrekt stattfindet.

Ein zentraler Teil der Überlegungen ist die Nutzung von Modellen als Ausdrucksmittel bei der Lösung dieser Aufgaben. Modelle können als ex-pliziertes, vereinfachtes Abbild der Realität begriffen werden. Ihnen kommt damit große Bedeutung bei der systematischen Handhabung von Datenintegration zu.

In diesem Zusammenhang ist festzustellen, dass integrative Tätigkeit immer auch mit der Aufgabe konfrontiert ist, mit Veränderungen an Mo-dellen umzugehen, die über die Zeit erforderlich werden. Dies führt einen neuen Aspekt in die Diskussion ein, nämlich die Frage, wie die statischen im Gegensatz zu den dynamischen Facetten der Integration zu handhaben sind, also wie zum Beispiel Modellintegration im Unterschied zu Modell-evolution systematisch bewältigt werden kann.

Speziell im Umfeld von Data Warehouses (DWH) und Operational Data Stores (ODS) ist das Management von Integration und Evolution eine zentrale Herausforderung. Diese Systeme integrieren Daten aus verschie-denen Bereichen einer Organisation und bilden, um zu einem einheitlichen Ganzen zu kommen, die zu Grunde liegenden Modelle aufeinander ab. Dieser Beitrag beschäftigt sich mit einer speziellen Gruppe von Daten, die dabei zum Einsatz kommen: Metadaten, Referenzdaten und Stammdaten. Insbesondere soll dabei die Prozessperspektive in den Vordergrund gestellt werden (Auth 2003), um die dynamischen Aspekte zu betonen.

1.1 Die Herausforderung systematischer Modellintegration und -evolution

Im traditionellen Verständnis des Entwicklungsprozesses wird ein Soft-wareprodukt bereitgestellt, indem es die verschiedenen Phasen Analyse, Entwurf, Implementation, Test und Verteilung durchläuft, bevor es genutzt wird. Jede Änderung an den Anforderungen bedeutet damit, dass poten-ziell eine neue Version des Produkts erstellt werden muss. Wenn man da-von absieht, dass Änderungen üblicherweise und – so muss betont werden – sinnvollerweise gruppiert werden, so bleibt doch der Sachverhalt beste-hen, dass Veränderungen immer durch den gleichen (nämlich den Ent-wicklungs-) Prozess geschleust werden.

Ein DWH oder ODS integriert Daten aus vielen verschiedenen Berei-chen der Organisation und ist gegenüber Veränderungen in allen diesen Bereichen exponiert. Jede Änderung, die sich ereignet, erfordert potenziell auch eine Änderung im DWH oder ODS; je höher die Zahl der integrierten Bereiche, desto größer die Wahrscheinlichkeit einer Veränderung, die sich

Metadaten, Referenzdaten, Stammdaten 181

auswirkt. Erschwerend kommt hinzu, dass sich solche Veränderungen nicht immer zum gleichen Zeitpunkt und auch nicht immer mit der glei-chen Kadenz ereignen, mithin auch die Gruppierung von Änderungen schwerer fällt. Folgt man dem traditionellen Entwicklungsprozess, ist leicht vorstellbar, dass mit einer steigenden Zahl von Veränderungen und integrierender Lösungen deren systematische Handhabung zusehends schwieriger und komplexer wird. Oder, und dies ist ein nicht selten zu be-obachtendes Phänomen, die Organisation passt die Adoption von Verände-rungen an die Möglichkeiten des Entwicklungsprozesses an, indem Verän-derungen später oder nur selektiv übernommen werden. Mit einer steigenden Zahl zu integrierender Datenquellen sinkt daher zuweilen die Fähigkeit, Veränderungen zügig umzusetzen.

Offenkundig müssen Integration und Veränderung auf Dauer nachhaltig bewältigt werden, auch wenn Kadenz und Komplexität größer werden. Das haben vor allem multinationale Firmen realisiert, die mit steigender Größe regelmäßig den folgenden Aufgaben gegenüberstehen:

Firmenfusionen und -akquisitionen: Die Übernahme eines Konkurrenten oder ein strategischer Zukauf führten immer zu beachtlichen Aufwänden bei der Integration und Migration von Daten, da sie in der Regel nicht basierend auf den gleichen Modellen entworfen und gepflegt wurden.

Variabilität des Geschäfts: Zwischen verschiedenen Branchen und Märkten bestehen zum Teil erhebliche Unterschiede in den Produkten und Geschäftsgewohnheiten, die sich dann auch in den Prozess- und Da-tenmodellen niederschlagen.

Regulatorische Anforderungen: Firmen, und hier vor allem Konzerne, die in verschiedenen Jurisdiktionen operieren, müssen gleichzeitig den Ansprüchen mehrerer Regulatoren gerecht werden, die sich sowohl bei der Ausführung von Prozessen als auch im Berichtswesen auswirken.

Nur eine Minderheit dieser Firmen hat eine zentralisierte Organisation etabliert. In der Mehrzahl der Fälle sind sie dezentral aufgebaut und ge-währen ihren Markt-, Geschäfts- und Rechtseinheiten gewisse Autonomie bei der Gestaltung des Betriebs. Dadurch wird die oben beschriebene Si-tuation noch einmal verschärft: die sozusagen „natürlich“ bei der Integra-tion auftretende Variabilität wird noch verstärkt, indem sich Veränderun-gen unabhängig voneinander und ohne wechselseitige Koordination ereignen.

Mit anderen Worten: Ein DWH oder ODS kann unter solchen Umstän-den nicht sinnvoll betrieben werden, ohne eine entsprechende Logistik im Rücken zu wissen, die Daten zuverlässig, systematisch und zu sachge-rechten Kosten bereitstellt, auch über die Zeit und die damit verbundenen

182 Hans Wegener

Veränderungen hinweg. Diese Logistik muss hierbei nicht nur einem „Meister“ gerecht werden, sondern viele beteiligte Parteien – Lieferanten wie Konsumenten – zufrieden stellen.

Die zugehörigen Prozesse wollen wir daher näher unter die Lupe neh-men; dabei wird deutlich werden, dass die Wechselwirkungen zwischen Geschäfts-, Management- und Unterstützungsprozessen wichtig sind. Wei-ter wird illustriert, welche Rolle die in diesen Prozessen genutzten Meta-, Referenz- und Stammdaten spielen und wo ihre Bedeutung am größten ist. Wie sich im Weiteren zeigt, ist es für das systematische Management von Integration und Veränderung unverzichtbar, die Unterstützungsprozesse des Entwicklungsprozesses in einer bestimmten Weise aufzubauen und in diesem Rahmen Meta-, Referenz- und Stammdaten zielgerichtet einzuset-zen.

1.2 Die terminologische Herausforderung

Die Bedeutung der Begriffe „Metadaten“, „Referenzdaten“ und „Stamm-daten“ hat schon mehrfach zu Diskussionen Anlass gegeben. Auch ist die semantische Abtrennung immer wieder Ursache für Verwirrung. Eine häu-fig anzutreffende Meinung ist beispielsweise, dass Stammdaten sich durch ihre Eigenschaft sich nur langsam zu ändern von Bewegungsdaten unter-scheiden (Schmaltz u. Dinter 2006). Was das konkret bedeutet, also etwa

wie schnell oder langsam solche Änderungen sich an einem Datum ereignen dürfen, damit man es als Stammdatum klassifizieren muss,

ob Bewegungsdaten und Stammdaten disjunkte Mengen sind und welche Auswirkungen all das auf den Umgang mit diesen Daten hat,

wird nicht weiter ausgeführt. Referenzdaten werden ebenso unklar defi-niert; wahlweise wird der Begriff synonym zu Stammdaten verwendet oder die Wiederverwendung in den Vordergrund gestellt (Loser et al. 2004). Auch hier ist die Abgrenzung unscharf und verursacht Probleme im syste-matischen Umgang. Metadaten zuletzt werden meist als Daten über Daten definiert (Poole et al. 2002), ohne dass näher angegeben wird, welche Im-plikationen daraus resultieren. Allenfalls, wie dies bei (Tozer 1999) der Fall ist, werden verschiedene Arten von Metadaten unterschieden und so der Verwendungszweck betont. Diese Kritik wurde auch schon von ande-ren Autoren angebracht, z. B. von (Tannenbaum 2002), die die Limitie-rung des Begriffs Metadaten auf Daten über Daten als „misconception“ bezeichnet. Allerdings ist in der letzten Zeit (z. B. von Auth 2003; Mel-chert 2006) darauf hingewiesen worden, dass die Rolleneigenschaften von Metadaten in den Vordergrund zu rücken sind, um zu einem vertieften


Verständnis zu gelangen; auch wurde schon früher die beschreibungs-sprachliche Nutzung von Metadaten betont (Strahringer 1996).

Trotz allem ist die terminologische Situation unbefriedigend und bedarf der Klärung. Die Frage, wo und wie Organisationen Modelle nutzen, um Einigung über die Semantik von Daten zu erzielen, wird hierbei eine zen-trale Rolle spielen. Die Konsequenzen für die systematische Handhabung von Integration und Veränderung werden entsprechend aufgezeigt.

1.3 Überblick

In Abschn. 2 werden zwei Aspekte des Managements von Integration und Evolution genauer betrachtet: Prozess und Modell. Insbesondere wird das Verhältnis der beiden zueinander im Rahmen von Entwurf und Verände-rung beleuchtet. Ergebnis dieser Betrachtung wird sein, dass Meta-, Stamm- und Referenzdaten bei der Integration und Evolution von Daten unterschiedlich verwendet werden. Es folgt eine Definition der drei Be-griffe.

Abschnitt 3 beschäftigt sich mit den praktischen Konsequenzen und be-schreibt verschiedene industrietypische Situationen, in denen diese Daten zum Einsatz kommen. Insbesondere werden die Möglichkeiten und Gren-zen diskutiert, auch in Bezug auf die Nutzung internationaler Standards wie des Common Warehouse Metamodel (CWM).

In Abschn. 4 wird eine Zusammenfassung der Erkenntnisse vorgenom-men und auf weitere Möglichkeiten für Forschung und Praxis hingewie-sen.

2 Modelle und der Prozess von Integration und Evolution

2.1 Das neue St. Galler Management-Modell

Wie bereits von (Auth 2003) ausgeführt, kann die Einbeziehung der Pro-zessperspektive neue Erkenntnisse bei der Betrachtung des Managements von Metadaten bringen. Wir beziehen uns hier auf das neue St. Galler Ma-nagement-Modell (Rüegg-Strüm 2003), das drei Kategorien von Prozessen (Geschäfts-, Unterstützungs- und Managementprozesse) vorsieht. Im Zu-sammenhang von Datenintegration und -evolution interpretieren wir diese Dreiteilung wie folgt:

184 Hans Wegener

Der Geschäftsprozess ist die Bereitstellung eines die Daten des Unter-nehmens integrierenden Systems (DWH, ODS). Dies kann mehr oder minder direkt im Sinne des klassischen Entwicklungsprozesses inter-pretiert werden, der die Phasen Analyse, Entwurf, Implementation, Test und Verteilung enthält. Man beachte, dass Integration je nachdem auch die Evolution beinhaltet, wenn man davon ausgeht, dass die Übernahme von Modellveränderungen durch Bereitstellung einer neuen Version der Lösung geschieht.

In diesem Kontext dienen als Unterstützungsprozesse alle Maßnahmen, die dazu geeignet sind, den Geschäftsprozess zu beschleunigen. Insbe-sondere sollen hier diejenigen Beiträge betrachtet werden, die einer schnelleren und Kosten sparenden Integration und Evolution dienlich sind.

Die Managementprozesse zuletzt versuchen, die Erreichung strategi-scher Ziele im Geschäftsprozess sicherzustellen. Sie sollen im Zusam-menhang dieses Beitrags keine größere Rolle spielen und werden daher nicht weiter betrachtet.

Was bedeutet diese Unterteilung? Zunächst einmal wird die zentrale Leistung eines integrativ wirkenden Systems einem Vorgang zugeordnet, innerhalb dessen sie erbracht wird. Weiterhin wird zwischen der Kernauf-gabe (Integration und Evolution) und unterstützend wirkenden Aufgaben (Vereinfachung von Evolution und Integration) unterschieden. Diese Auf-teilung ermöglicht es, genauer zu definieren, welche unterstützenden Ziele erreicht werden müssen, um im Sinne einer umfassenden Informationslo-gistik Vereinfachungen zu erreichen. Dies sind insbesondere:

Beschleunigung des fachlichen Verständnisses: Zu Beginn jeder Integra-tion muss sichergestellt werden, dass die zu integrierenden Dateninhalte aus fachlicher Sicht kompatibel sind. Insbesondere beinhaltet dies das Studium der Systemdokumentation, der Geschäftsterminologie und ähn-licher Dokumente. Beschleunigung entsteht unter anderem, wenn glei-che oder übertragbare Standards verwendet werden, wie dies im Sinne standardisierter Fachsprachen bereits gefordert wurde (Turowski 2002). Ein Glossar unterstützt verschiedene Ziele von Daten-Wiederver-wendung wie z. B. Abstraktion, Selektion, Integration und Spezialisie-rung (Krueger 1992).

Effiziente Nutzung existierender struktureller Beschreibungsmerkmale: Nachdem ein fachliches Verständnis erarbeitet wurde, muss die Integra-tion bewerkstelligt werden. Für die zu integrierenden Systeme existieren meist Artefakte, die ihre Eigenschaften formal beschreiben, wie z. B. Datenmodelle, Ladeketten und ähnliches. Das Ziel muss es sein, sie


z. B. durch Transformation und Abbildung, effizient im integrierenden System nutzbar zu machen. Dies ist vor allem ein Problem der Werk-zeugintegration, wie sie im Detail von (Poole et al. 2002) beschrieben ist.

Integration gemeinsamer Datenquellen: In jeder größeren Organisation werden bestimmte Daten geteilt, wenn sie den Kontext geschäftlicher Transaktionen beschreiben. Dies ist entscheidend, um integrierende Sys-teme überhaupt erst möglich zu machen (Marti 2003).

Welche unterstützenden Mittel helfen nun dabei? Offenkundig ist die Verwendung von Modellen der Schlüssel dazu. Einerseits sind sie ein (ver-einfachtes) Abbild des realen Gegenstandsbereichs, stellen also in einem gewissen Sinn wieder verwendbaren fachlichen Konsens dar; insofern un-terstützen sie die Aneignung des fachlichen Verständnisses. Sie können auch automatisiert in eine andere Struktur überführt werden und damit (ef-fizient) in einem anderen Kontext nutzbar gemacht werden. Dies ist die wesentliche Idee hinter dem CWM und der Model-Driven Architecture (MDA). Zuletzt wird die Integration gemeinsam geteilter Datenquellen durch Nutzung gleicher Modelle möglich gemacht. Hier ergeben sich interessante Einsichten, wenn man die Frage aufwirft, wo und wie solche Modelle ihre Umsetzung in Systemen wiederfinden.

2.2 Ein ausführliches Beispiel

Um zu verstehen, welche Optionen beim Entwurf einer umfassenden In-formationslogistik zur Wahl stehen, wird im Nachfolgenden ein etwas aus-führlicheres Beispiel gegeben. Es ist der Versicherungsindustrie entlehnt; in abgewandelter Form ist eine Übertragung auf andere Industrien mög-lich.

Es ist durchaus üblich, von einer stabilen Menge von Währungen aus-zugehen, insbesondere wenn es sich um so genannte „investitionswürdige“ Währungen wie US Dollar, Britisches Pfund oder Japanische Yen handelt – eine Kategorie von Währungen, die sich nicht allzu häufig ändert. Kon-sequenterweise trifft man im Entwurf von Systemen selten Vorkehrungen für den Fall der Veränderung, welche dann im Rahmen eines Durchlaufs durch den Entwicklungsprozesses (Releasewechsel) bewältigt werden.

Auf der anderen Seite ist es äußerst unüblich, von stabilen Währungs-kursen ausgehen und sie fest im System zu codieren. Vielmehr werden se-parate, dedizierte Quellen angeschlossen. Externe Anbieter für Marktdaten wie Bloomberg, Reuters, Financial Times und Datastream sind hier bereits seit langer Zeit etabliert. Insbesondere bleibt das System unter Verände-rungen stabil, der Entwicklungsprozess muss nicht erneut durchlaufen

186 Hans Wegener

werden. Vielmehr wird ein separater Unterstützungsprozess ausgeführt: Auf täglicher, stündlicher oder (wie beispielsweise im Handel) gar konti-nuierlicher Basis werden die aktuellen Wechselkurse von der führenden Quelle übernommen. Dieser Vorgang findet wegen der hohen Änderungs-frequenz automatisch statt.

Die kostspieligen Umstellungen im Rahmen der Einführung des Euro sind Zeugnis für die zuweilen unvorhersehbaren Folgen der oben erwähn-ten Annahmen. (Wobei hinzugefügt werden muss, dass die Umstellungs-kosten nicht allein durch die Existenz einer neuen Währung entstanden, sondern auch durch die teilweise komplexen Regeln der Koexistenzphase von alten Währungen und Euro bedingt waren.) Beim Entwurf einer In-formationslogistik, die sich der Integration und Evolution von Modellen widmet, muss die Kadenz und Auswirkung erwarteter Veränderungen in Betracht gezogen werden, insbesondere:

1. Die dem Systementwurf zu Grunde liegenden Modelle müssen darauf geprüft werden, ob sie als instabil angenommenen werden müssen.

2. Falls ja, insbesondere wenn hohe Anpassungskosten zu gewärtigen sind, müssen die entsprechenden Modellaspekte externalisiert und auf andere Art in den Systementwurf eingebunden werden.

3. Die Brücke zwischen den instabilen und den im Systementwurf als stabil angenommenen Modellaspekten wird über eine dedizierte sta-bile Schnittstelle aufgebaut.

4. Im Weiteren widmet sich der Entwicklungsprozess nur noch der Er-stellung und Pflege von stabilen Modellaspekten, der Unterstützungs-prozess hingegen den instabilen.

5. Die Integration von stabilen und instabilen Modellaspekten findet im Rahmen des Betriebs statt, indem Modelländerungen im instabilen Teil über die definierte Schnittstelle an den stabilen übergeben wer-den.

Im oben vorgestellten Fall wird z. B. angenommen, dass Währungskurse sich schnell verändern; konsequenterweise wird die anpassende Tätigkeit (Übernahme der aktuellen Kurse) in einen Unterstützungsprozess ausgela-gert und im System möglichst wenig darüber angenommen, genauer: Die Schnittstelle zwischen stabilem und instabilem Teil beschäftigt sich nur mit Währungen, Märkten und Zeitpunkten. Während des Entwicklungs-prozesses wird im Systementwurf nur auf diese Schnittstelle Bezug ge-nommen. Während des Betriebs werden im Rahmen des Unterstützungs-prozesses z. B. stündlich die Kurse aus dem Quellsystem übernommen, das aktuell gehalten wird.

Bei den oben erwähnten Währungen ist die Lage anders: es wird ange-nommen, dass die Liste weitgehend unveränderlich ist. Daher ist es mög-


lich, diese Liste fest im Systementwurf zu verankern und somit zum Teil des stabilen Modells zu machen. Es gibt keinen Unterstützungsprozess, und wenn sich während der Betriebsphase Veränderungen an der Wäh-rungsliste ereignen, müssen sie über den Entwicklungsprozess bewältigt werden.

2.3 Metadaten, Referenzdaten, Stammdaten: eine Definition

Was also bedeutet das für Meta-, Stamm- und Referenzdaten? Dieser Ab-schnitt benutzt die obigen Überlegungen und gelangt so zu einer Klassifi-zierung der Begriffe (s. Abb. 1).

Ein wichtiges Kriterium bei der Abgrenzung der Begriffe ist ihre Rolle in der Daten-Wiederverwendung. Das oben genannte Beispiel der Wech-selkurse und Währungen ist dafür repräsentativ. Es ist ihr offenkundiger Zweck, an verschiedenen Orten in der Datenarchitektur genutzt zu werden, aber sie sollen nur an einem Ort „entstehen“, also genau eine dedizierte Referenzquelle aufweisen.

Terminologie ReferenzdatenMetadaten

Stammdaten

Abb. 1: Venn-Diagramm der Klassifizierung von Referenz-, Stamm- und Meta-daten. Die Darstellung gruppiert Mengen (als Ellipsen) innerhalb ihrer Ober-menge. (Geschäfts-)Terminologie ist als ein Beispiel für Metadaten aufgeführt, die nicht in die Menge der Referenzdaten fällt

Eine weitere Dimension, die es zu betrachten gilt, ist, ob das Manage-ment des Lebenszyklus der Daten im Vordergrund steht. Währungen ha-ben einen Lebenszyklus: die Nutzung des Euro war zunächst projektiert, in der nächsten Phase funktionierte er als Schattenwährung neben den bereits existierenden Währungen und zuletzt ersetzte er u. a. die Deutsche Mark und den Französischen Franc, deren Lebenszyklus zu diesem Zeitpunkt wiederum endete. Diese Ereignisse sind für integrierende Systeme wie DWH und ODS von entscheidender Bedeutung, da sie auch das Ziel der Harmonisierung haben: An den eingehenden Schnittstellen muss daher un-ter anderem geprüft werden, ob die gelieferten Daten mit dem zu Grunde

188 Hans Wegener

liegenden Modell im Einklang sind. Prüfungen wie: „Ist diese Währung gültig?“ beziehen sich vor allem auf den Lebenszyklus. Während einer Übergangsphase waren zwar Deutsche Mark und Euro gültige Währungen, aber Konti wurden nur noch in Euro geführt. Daher mussten Buchungen in Deutscher Mark umgewandelt, d. h. eine Abbildung auf das evolvierte Modell vorgenommen werden.

Währungskurse werden unterschiedlich genutzt: Dort ist vor allem der Zeitpunkt der Fixierung am Markt von Interesse. Eine Datenschnittstelle wird nicht davon beeinflusst, dass andere Kurse gelten. Insbesondere än-dert sich durch die Veränderungen auch nicht das fachliche Modell.

Ein drittes Kriterium ist, ob die Daten zur Automation eingesetzt wer-den oder sich eher an einen menschlichen Nutzer wenden. Geschäftstermi-nologie ist dem letzten Fall zuzuordnen, während beispielsweise Daten-modelle häufig zur Generierung von Programmcode eingesetzt werden.

Viertens, und dies ist möglicherweise der interessanteste Aspekt, ist es von Bedeutung, in welchem Prozess die Daten eingesetzt werden. Wie oben bereits betont, soll der Entwicklungsprozess als Geschäftsprozess be-trachtet werden. Im Rahmen dieses Prozesses wird ein Datenmodell ver-wendet, das auf Datenelemente Bezug nimmt. Der Lebenszyklus dieser Elemente wird entweder innerhalb oder außerhalb des zu erstellenden Sys-tems kontrolliert. Beispielsweise kann ein System Währungen verwenden, aber ob eine bestimmte Währung als gültig erachtet wird und wann, ist ei-ne Entscheidung, die meist an einem anderen Ort getroffen wird. Wenn wie hier die Kontrolle über den Lebenszyklus eines Modellelements au-ßerhalb des Entwicklungsprozesses liegt, benötigt der Entwicklungs- bzw. noch viel mehr der Betriebsprozess des Systems einen unterstützenden Prozess, der die effiziente Evolution der referenzierten Modellelemente ermöglicht. Dieser Prozess hat nun zum Gegenstandsbereich nicht mehr das Modell, das die zu integrierenden Daten beschreibt, sondern das Mo-dell, das Systeme beschreibt. Beispiel: Ein geographisches Informati-onssystem liefert die Liste der politischen Einheiten (Länder) über eine Schnittstelle an abnehmende Systeme. Der Unterstützungsprozess „verteile aktualisierte Länderliste“ beschäftigt sich mit Modellelementen wie

System: Wohin sollen die Daten geliefert werden? Aktualität: Wohin wurde bereits geliefert?

Der Prozess bezieht sich nicht mehr auf die eigentlichen Inhalte: Welche Länder aktuell sind oder nicht, ist hier irrelevant. Vielmehr ist von Bedeu-tung, sicherzustellen, dass die Aktualisierung quer über die gesamte Sys-temlandschaft stattfindet.


2.3.1 Metadaten

Metadaten sind Daten, die unter Nutzung ihres Lebenszyklus in ei-nem den Entwicklungs- bzw. Betriebsprozess unterstützenden Pro-zess dazu verwendet werden, Anpassungsleistungen an dort entstan-denen Produkten vorzunehmen.

Wir möchten dabei nicht unterscheiden, ob diese Anpassungsleistung automatisiert oder manuell erbracht wird (vgl. die Unterscheidung nach passiven und aktiven Metadaten in Auth 2003). Metadaten werden nur teil-weise in anderen Prozessen wieder verwendet, sondern oft einzig in einem bestimmten Unterstützungsprozess genutzt. Zuletzt fokussiert man bei Me-tadaten auf die Anpassung einer Gruppe von (strukturell gleichförmigen) Produkten, nicht auf ein einzelnes Produkt. Im obigen Beispiel der Länder-liste beschäftigt man sich mit verschiedenen Systemen, die die gleiche Schnittstelle zum geographischen Informationssystem teilen und darüber Veränderungen übernehmen. Hätte man es mit einem einzelnen Produkt zu tun, wäre der Entwicklungsprozess der richtige Ort für die Vollbringung der Anpassungsleistung. Insofern fallen unter anderem die folgenden Da-ten in die Kategorie Metadaten:

Fachbegriffe: Die Beschreibung der fachlichen Bedeutung von Modell-elementen wird quer über verschiedene Produkte hinweg geteilt. Ändert sich an dieser Bedeutung etwas, können die korrespondierenden Anpas-sungen quer über die Produkte gleichförmig vorgenommen werden (z. B. indem sich eine geänderte Berechnungsformel in einem geänder-ten ETL-Datenfluss widerspiegelt). Die Anpassung findet hierbei ma-nuell statt.

Datenmodelle: Die strukturellen Eigenschaften eines Modells können dazu genutzt werden, um Werkzeugintegration zu bewerkstelligen. Die Anpassungsleistung besteht darin, dass die sich im Rahmen des Ent-wicklungsprozesses ereignenden Veränderungen am Modell automa-tisch zwischen den verschiedenen Werkzeugen (z. B. ETL, Datenmo-dellierung, Reporting) ausgetauscht werden können.

Geschäftsregeln: Die Regeln können von verschiedenen Produkten ge-nutzt werden, um Änderungen in den fachlichen Anforderungen umzu-setzen. Hierbei kommt die Struktur der Regelsprache (Chisholm 2004) zum Einsatz um die Anpassung zu automatisieren.

Es ist hier übrigens nicht entscheidend, ob die Anpassungsleistung vor, während oder nach Abschluss des Entwicklungsprozesses stattfindet. Ge-nerative Ansätze (Czarnecki u. Eisenecker 2000) und interpretative An-

190 Hans Wegener

sätze (Riehle et al. 2001) wählen lediglich verschiedene Zeitpunkte der Bindung äußerer Veränderungen an einen Bezugskontext (das Produkt).

Die Nutzung von Metadaten basiert in ihrem Wesenskern einerseits auf der Vergegenständlichung der Struktureigenschaften, was sie der Syste-matisierung und (idealerweise auch) Automatisierung im Unterstützungs-prozess zugänglich macht. Andererseits basiert die Nutzung auf dem Le-benszyklus der (Meta-)Modellelemente, indem Veränderungsereignisse den Auslöser für den Start des Unterstützungsprozesses setzen.

Zuletzt noch einmal zurück zur Definition von Metadaten als „Daten über Daten“: Sie ist griffig, kann aber auch zu Missverständnissen führen. Metadaten umfassen mehr als nur Beschreibungen und Strukturmerkmale von Daten. Im Kontext von DWHs und ODSs kommt den Daten primäre Bedeutung zu; insofern sind beispielsweise Geschäfts- und Abbildungsre-geln sowie Ladeabhängigkeiten, die wir als Metadaten begreifen, durchaus Daten über Daten. Der Nachteil der griffigen Definition ist, dass sie nicht genau bestimmt, wo die Grenze ihrer Anwendbarkeit liegt. Da, wie oben betont, die Eigenschaft „meta“ eine relative ist, kann sie beliebig und da-mit undifferenziert eingesetzt werden. Wenn wir den Entwicklungs- und Betriebsprozesses in das Zentrum der Betrachtung rücken, wird deutlich klarer, welche Daten wir als „meta“ bezeichnen dürfen und welche nicht.

2.3.2 Referenzdaten

Referenzdaten sind wieder verwendbare, einfach strukturierte Meta-daten, deren Zweck darin besteht, Veränderungen im fachlichen Kontext automatisiert zu übernehmen.

Czarnecki und Eisenecker beschreiben verschiedene Komplexitätsstufen bei der generativen Nutzung von Metadaten (Czarnecki u. Eisenecker 2000). Sie unterscheiden drei wesentliche solcher Stufen, die entlang eines gedachten Kontinuums liegen:

Parametrisierung: Hierunter werden einfache Konfigurationsdaten ver-standen, die nur eine Anpassung gegenüber simplen Veränderungen er-lauben, z. B. eine Liste von Optionen.

Merkmals-Modellierung: Sie erlaubt die Kombination mehrerer ver-schiedener Merkmale zu einem durch Regeln bestimmten Ganzen, z. B. konditionale Ausdrücke wie bei der Modellierung verschiedener Sichten auf das Hauptbuch.

Meta-Programmierung: Dies ist die höchste, komplexeste Stufe, bei der die volle algorithmische Komplexität genutzt werden kann, z. B. Pro-grammiersprachen.


Marti beschreibt die Rolle von Referenzdaten in der Datenintegration und betont dabei deren Nutzung bei der Einbettung von Systemen in ihre Umgebung (Marti 2003). Referenzdaten repräsentieren dabei den einzubet-tenden Kontext. Mithin werden sie an verschiedenen Orten in der Daten-architektur (wieder)verwendet. Sie werden zur Automation benutzt: Es ist z. B. nicht unüblich, die Logik eines Systems in Abhängigkeit von selek-tierten Optionen anzupassen, etwa wenn für bestimmte Geschäftssparten andere rechtliche Anforderungen bei der Datenerfassung bestehen.

Änderungen an Referenzdaten werden, genauso wie bei Metadaten, durch Nutzung von Ereignissen im Lebenszyklus übernommen. Der Unter-schied besteht darin, dass Referenzdaten meistens im (durch das System unterstützten) Geschäftsprozess benutzt werden, ihr Fokus also fachlicher Natur ist. Aus praktischen Gründen nutzt man auch nur die Verweise auf geschäftlich relevante Objekte (die Referenzen), nicht aber die Objekte selbst.

Referenzdaten sind eine Form von Daten, die Vergegenständlichung be-nutzt, aber nur für die Übernahme simpler Veränderungen. Diese Be-schränkung ist aber praktischer, nicht formaler Natur. Durch die Einfach-heit können die Daten an verschiedenen Stellen in der Datenarchitektur benutzt werden, ohne dass dafür im Interesse der Konsistenz für jede die-ser Stellen explizit geregelt werden müsste, wie das Systemverhalten bei diesem oder jenem Datenwert auszusehen hat. Beispiele für Referenzdaten sind alle Formen von Listen, wie etwa

Währungen Risikoarten Orte Kunden oder Produkte

Geschäftsterminologie gehört nicht in die Kategorie Referenzdaten, da dort keine automatische Übernahme von Veränderungen erfolgen kann.

2.3.3 Stammdaten

Stammdaten sind Daten, die in verschiedenen Kontexten wieder ver-wendet werden, um automatisiert Veränderungen im fachlichen Um-feld zu übernehmen.

Diese letzte der drei Datenkategorien enthält zusätzlich solche Daten, die keinen natürlichen Lebenszyklus aufweisen wie z. B. Zinssätze oder Währungskurse. Sie werden in verschiedenen Geschäftsprozessen von den

192 Hans Wegener

unterstützenden Systemen genutzt, um Veränderungen zu übernehmen. Bei Stammdaten nutzt man standardisierte Quellen, wie sie für Währungen und Zinssätze sind in verschiedenen Industrien üblich und können auch von ex-ternen Anbietern bereitgestellt werden. Veränderungen werden isoliert in diesen Quellen vorgenommen und über eine (stabile) Schnittstelle von den abnehmenden Systemen übernommen.

Zur Klasse der Stammdaten kann man auch Referenz- und Metadaten zählen, da sie auch eine Übernahme von Veränderungen in der oben be-schriebenen Art ermöglichen. Beispiele für Stammdaten, die weder Refe-renz- noch Metadaten wären unter anderem:

Wechselkurse Zinssätze Marktpreise

Der wichtige Unterschied besteht darin, dass, sobald kein Lebenszyklus genutzt wird, das im Unterstützungsprozess genutzte Modell trivial wird (in der Essenz ein Kopieren der Daten). Was das bedeutet, beschreibt der nächste Abschnitt.

Tabelle 1. Übersicht über die charakteristischen Unterschiede zwischen Refe-renz-, Stamm- und Metadaten

Stammdaten (ohne Metadaten)

Metadaten (ohne Referenzdaten)

Referenzdaten

Nutzung für auto-matische Adoption von Veränderungen

Ja Teilweise Ja

Fokus auf Wieder-verwendung

Ja Selten Ja

Nutzt den Lebens-zyklus

Nein Ja Ja

Bevorzugter Zeit-punkt der Nutzung

Betrieb Entwicklung, Betrieb

Betrieb

Gegenstandsbereich Fachlichkeit Technik, Fachlichkeit

Fachlichkeit

2.4 Konsequenzen für die Informationslogistik

Was bedeutet nun die oben beschriebene Semantik von Meta-, Referenz- und Stammdaten für die Informationslogistik? Zunächst einmal ermöglicht sie eine differenziertere Betrachtung im Hinblick auf den jeweiligen Nut-


zungszweck. Im Rahmen der Datenintegration und -evolution bietet sich dem Betreiber von DWHs und ODSs somit folgendes Bild:

Bei der Integration sind im Rahmen des Entwicklungsprozesses vor al-lem die technischen und fachlichen Metadaten von Interesse, um einer-seits effizient arbeiten zu können bzw. sich andererseits ein schnelles Verständnis der Integrationsproblematik zu verschaffen.

Wiederverwendung beschleunigt vor allem bei Referenz- und Stammda-ten einerseits die Übernahme von Veränderungen, führt aber anderer-seits auch zu einer Integration der Veränderungsprozesse, die hier vor allem unterstützender Natur sind.

Evolution kann mit verschiedenen Mitteln (Vergegenständlichung, Iso-lation) unterstützt werden; je einfacher dabei die dem Veränderungs-prozess zu Grunde liegende Modellwelt, desto weniger werden Lebens-zyklusmodelle gebraucht, was die Daten nutzenden Systeme unter anderem weniger abhängig voneinander macht.

Insgesamt ist also eine dem Problem angemessene Auswahl der Daten-klasse notwendig; die daraus entstehenden Konsequenzen für die Prozess-landschaft sind dabei immer mit zu bedenken. Beispielsweise erfordert die Nutzung von Metadaten den Aufbau des Unterstützungsprozesses, der in der Regel eine entsprechende Organisation voraussetzt und technische Schnittstellen erfordert, die die Gesamtkomplexität (und damit die Kosten) erhöht. Auf der anderen Seite können häufige Veränderungen damit wo-möglich sehr viel kostengünstiger und schneller bewältigt werden, was im Gesamtbild die Entscheidung dafür erfordert.

3 Die Rolle von Meta-, Stamm- und Referenzdaten in der Entwicklung und Pflege integrativer Systeme

In diesem Abschnitt sollen nun einige Beispiele illustrieren, wie die drei Datenklassen in der Praxis eingesetzt wurden. Besondere Betonung wird auf die dabei gemachten Erfahrungen gelegt.

3.1 Systematisches Management von Referenz-, Meta- und Stammdaten

Eine Versicherung hat die Beschreibung von Daten über Geschäftsbegriffe systematisiert. Es wird zwischen Stammdaten („master data“), Referenz-daten („reference data“) und Metadaten unterschieden, die allerdings in

194 Hans Wegener

diesem Fall nicht dediziert ausgewiesen wurden, da es sich um Geschäfts-terminologie und Daten für die Merkmals-Modellierung handelt.

Stammdaten enthalten Referenzdaten, aber auch so genannte Kalkulati-onsparameter (z. B. Wechselkurse und Zinssätze). Referenzdaten beinhal-ten die Schlüssel von Aufzählungsattributen (z. B. Kunden, Verträge, Währungen, Risikoarten oder Länder) sowie auch die dazu gehörigen At-tributwerte. Stamm- und Referenzdaten werden im Rahmen der Architek-turprozesse unterschiedlich behandelt: Für die Referenzdaten werden Standardquellen definiert, die die offiziell sanktionierten Werte für ein At-tribut enthalten. Für den architekturellen Review eines Systems gibt es ei-ne genau festgelegte Definition für die Kompatibilität mit den Standard-quellen; sie zielt darauf ab, dass alle Modellelemente so, wie sie in der Quelle definiert sind, auch in den abnehmenden Systemen wieder zu fin-den sind. Diese Definition scheitert aber bei den Stammdaten, da es für diese keine (im Reviewprozess explizit machbaren) Modellelemente gibt. Daher beschränkt man sich in diesem Bereich darauf, lediglich die fach-sprachliche Kompatibilität zu prüfen.

3.2 Physische vs. logische Ebene in der Werkzeugintegration

Modelle haben bei der Werkzeugintegration eine herausragende Bedeu-tung. Das Common Warehouse Metamodel (Poole et al. 2002) verspricht hier einen entscheidenden Fortschritt, indem es das Metamodell standardi-siert und so eine nahtlose Integration der verschiedenen Werkzeuge er-laubt. Das CWM adressiert dabei Bereiche wie Datenstrukturen, Trans-formations- und Ableitungsregeln, Ladeprozesse, Datenquellen und -for-mate und vieles mehr.

Leider geht das CWM nicht weit genug und auch die Methodik der Werkzeugintegration hat sich in der Praxis an einem wichtigen Punkt als begrenzt erwiesen. Beinahe jedes DWH und ODS wird nicht nur auf einer Abstraktionsstufe modelliert, sondern auf mehreren, nämlich der physi-schen und logischen Stufe. Diese verschiedenen Betrachtungsperspektiven führen zunächst einmal zu verschiedenen Granularitätsstufen beim Meta-modell (technische vs. fachliche Sicht) und dann zu Problemen bei der In-tegration der Metadaten.

Beispielsweise war im Rahmen eines Projekts bei einer Bank geplant, die Datenmodelle über Metadaten mit Geschäftsterminologie zu verbin-den, um so den Benutzern eine gezielte Suche nach Dateninhalten zu er-möglichen („Data Shopping“). Das Metamodell war an das CWM ange-lehnt worden, aber es stellte sich unter anderem heraus, dass das CWM nicht allen Benutzergruppen gerecht wird: Hoch spezialisierte Data Miner


benutzten direkt das physische Datenmodell, um SQL-Anfragen zu formu-lieren, während informierte Endbenutzer in den Markteinheiten („Power User“) zunächst die logische Perspektive nutzten, um die von ihnen benö-tigten Daten im Warehouse zu suchen. Dies bedeutete doppelte Arbeit bei der Erstellung und Pflege der Verknüpfungen zwischen Daten und Begrif-fen, die zu den bekannten Aktualitäts- und Vollständigkeitsproblemen bei den Metadaten führte.

Vergleichbare Ergebnisse stellten sich auch bei der oben genannten Versicherung ein, bei der das Repository der Geschäftsterminologie be-nutzt wurde, um unter anderem Dimensionsdaten für die Systeme zu mo-dellieren und sie unmittelbar dorthin zu verteilen. Da aber natürliche Spra-che mehrgestaltig ist, kam es dazu, dass ein Begriff wie „Country“ zum einen als „Type of Location“, also als Dimensionswert benutzt wurde, an-dererseits auch als Attribut Verwendung fand. Die resultierende Komple-xität führte auch in diesem Fall zu verschiedenen Qualitätsproblemen und Redundanzen. Grund dafür war auch hier die Abbildung der logischen auf die physische Perspektive.

Zum Beispiel gestaltet der Fachentwurf Objekte wie „Kunde“ oder „Vertrag“ für die Nutzung in entsprechenden Unterstützungsprozessen. Der Status im Lebenszyklus, also ob z. B. ein Vertrag abgewickelt ist, wird dort nicht als Teil des Datenmodells erwähnt, sondern als Ereignis im Pro-zess. Im relationalen Datenmodell des implementierenden Systems findet sich hingegen ein „Status of Contract“ als Attribut einer Entität, weil der Status in der Datenbank abgelegt wird. Dieser durch die Abbildung auf die Technologie erforderliche Fachbegriff wird aber (möglicherweise) in einer Systemmaske angezeigt und damit über die Hintertüre zum Bestandteil der fachlichen Begriffswelt.

Insgesamt ist zu beobachten, dass die Beherrschung von Multi-Modell-Integration eine ungeheuer komplexe Herausforderung darstellt, die so-wohl von den verfügbaren Werkzeugen als auch Metamodellen nicht wirk-sam unterstützt wird. Tatsächlich belassen es dann viele Projekte auch bei eher lose gekoppelten (Meta)Modellwelten und die gewünschten Effi-zienz- und Effektivitätsgewinne können zu einem beachtlichen Teil nicht realisiert werden.

3.3 Unzulänglichkeiten der Werkzeuglandschaft

Ein kleineres, aber dennoch wichtiges Problem ist das marktpolitische Verhalten der großen Werkzeughersteller. Formal können viele Hersteller eine Kompatibilität zum CWM nachweisen. Viele Firmen erwerben diese Werkzeuge aufgrund bestimmter Alleinstellungsmerkmale, z. B. Ge-

196 Hans Wegener

schwindigkeit oder besondere Funktionalität. Diese Alleinstellungsmerk-male führen dann nicht selten dazu, dass das DWH oder ODS Merkmale des Werkzeuges benutzen, die sich nicht (ohne weiteres) über Metadaten austauschen lassen, da das gemeinsame Metamodell fehlt und v.a. das CWM diese Aufgabe nicht mehr leistet. Das beeinflusst wiederum den Entwicklungsprozess, indem mehr auf manuelle Werkzeugintegration zu-rückgegriffen werden muss.

Bei der oben genannten Bank wurde das dort eingesetzte ETL-Werk-zeug in eine größere System- und Prozesslandschaft eingebettet. Unter an-derem sollten die Abbildungsregeln und -jobs nach so genannten „Projek-ten“ gruppiert werden, die von jeweils einem dedizierten Entwicklerteam betreut wurden. Leider war das ETL-Werkzeug nicht in der Lage, extern benötigte Metadaten intern zu speichern, und es war auch nicht möglich, z. B. bei Erstellung eines neuen Projekts sozusagen einen organisatori-schen Rahmen im Werkzeug automatisch zu generieren. Das führte dazu, dass viele Hilfstabellen separat gepflegt und immer konsistent gehalten werden mussten.

Es stellte sich heraus, dass die Limitationen der Werkzeuge immer wie-der die Art und den Zeitpunkt der Bereitstellung von Metadaten ein-schränken. Ob sie vor Auslieferung des fertigen Produkts oder danach ge-sammelt werden, hat großen Einfluss auf die Metadatenqualität. Durch die üblichen Projektzwänge wie Kosten- und Zeitdruck geht man insbesondere bei letzterer Methode ein hohes Maß an Risiko ein, dass die Qualität nicht dem erwarteten Standard entspricht. Langfristig leidet darunter die Ak-zeptanz für Metadaten.

3.4 Den Kompromiss zwischen Bürokratie und Anarchie finden

Die Beschleunigung der Entwicklung und Pflege integrativ wirkender Sys-teme geht leider mit einem gesteigerten Maß an Bürokratie einher. Dies kann in komplexen Handlungskontexten schwierig werden.

In der oben erwähnten Versicherung wurde bewusst von der Idee einer „einzigen Wahrheit“ ausgegangen, d. h. Referenzdaten waren (zumindest im vorgestellten Ideal) für alle Systeme, Organisationen und Lokationen der Firma exakt gleich. Dies bietet gewisse Vorteile bei der Datenintegra-tion, machte aber den Erstellungs- und Pflegeprozess für die Referenzda-ten unheimlich aufwändig, bürokratisch und letzten Endes für einige in der Organisation unannehmbar.

Eine zumindest bei Referenz- und insbesondere bei Dimensionsattribu-ten oft anzutreffende Alternative ist die „gemeinsam geteilte Wahrheit“,


bei der lediglich eine Untermenge der Attributwerte von allen Systemen, Organisationen und Lokationen geteilt wird. Gerne gibt bei Konzern-strukturen die Zentrale die Untermenge vor (z. B. die obersten drei Ebenen der „Line of Business“) und dezentrale Einheiten sind frei, diese zu ergän-zen und dafür bei der Datenlieferung an die Zentrale eine sachgerechte Abbildung vorzunehmen. Das gestaltet sich allerdings bei komplex zu-sammengesetzten Daten wie Kunden- oder Produktstruturen schwieriger, da nicht eindeutig klar sein muss, wie zentrale und dezentrale Eigenschaf-ten der Daten zusammengehören.

Den „sweet spot“ zwischen Bürokratie und Anarchie zu treffen, ist eine große Kunst und zunehmend ein Problem, mit dem sich multinationale Un-ternehmen auseinandersetzen müssen. Durch die unterschiedlichen re-gulatorischen Anforderungen in den Ländern ergeben sich zum Teil auch sich wechselseitig ausschließende Anforderungen an die Datenmodelle. Vollständige Kontrolle über eine solche Situation auszuüben ist wenn überhaupt, nur mit einem fast unerträglichen Maß an Bürokratie denkbar. Auf der anderen Seite sind Organisationsformen mit geringer oder keiner (zentralen) Kontrolle nicht in der Lage, die zum Teil von Regulatoren (z. B. im Sarbanes-Oxley Act) geforderte Nachvollziehbarkeit zu garantie-ren.

4 Zusammenfassung

Dieser Beitrag hat die Unterschiede zwischen Stamm-, Referenz- und Me-tadaten herausgearbeitet. Alle haben zum Ziel, die Umsetzung von Verän-derungen zu verbessern; sie benutzen aber unterschiedliche Mittel, um ver-schiedenen Entwurfssituationen gerecht zu werden. Ein wesentliches Differenzierungsmerkmal ist der Prozess, in dem die Daten benutzt bzw. erstellt werden. Die Hinzuziehung der Prozessperspektive ermöglicht es, diese Unterschiede besser zu verstehen, und sie erlaubt es auch, genauere Konsequenzen daraus zu ziehen.

Referenz- und Metadaten sind, und in dieser Hinsicht weicht dieser Bei-trag ein wenig von der traditionellen Linie ab, für den Autor verschiedene Punkte entlang eines strukturellen Komplexitätsspektrums. Ansonsten sind sie von ihrer Natur auf das gleiche Ziel ausgerichtet: Kopplung von Un-terstützungsprozessen mit dem Geschäftsprozess unter Nutzung des Le-benszyklus der Daten. Stammdaten (insoweit Referenz- und Metadaten nicht darunter fallen) hingegen sind eine gesondert zu behandelnde Kate-gorie.

198 Hans Wegener

Die Rolle von Metadatenstandards, wie des CWM, ist noch immer nicht befriedigend gelöst. Dies ist zunächst eine unmittelbare Folge der man-gelnden Methodenstandardisierung, die damit einhergehen müsste. Aber es ist auch eine mittelbare Folge der mangelnden Kompatibilität der Werk-zeuge. Es erscheint zweifelhaft, ob dieser Zustand in der nächsten Zeit be-reinigt werden kann.

Zusammenfassend bilden Stamm-, Referenz- und Metadaten das Rück-grat einer soliden Informationslogistik. Das Management dieser Daten steht immer vor inhärenten Zielkonflikten. Daher muss man den für den konkreten Handlungskontext angemessenen Mix von Ansätzen finden und entsprechend handhaben.

Literatur

Auth, G.: Prozessorientierte Organisation des Metadatenmanagements für Data-Warehouse-Systeme, Dissertation, Universität St.Gallen, St.Gallen 2003.

Chisholm, M.: How to Build a Business Rules Engine: Extending Application Functionality through Metadata Engineering, Morgan-Kaufmann, San Fran-cisco 2004.

Czarnecki, K.; Eisenecker, U.: Generative Programming. Methods, Tools, and Applications, Addison-Wesley, Boston 2000.

Krueger, C.: Software Reuse, in: ACM Computing Surveys 24 (1992) 2, S. 132-183.

Loser, C.; Gizanis, D.; Christine, L.: Ansätze zum Management von Stammdaten über Systemgrenzen hinweg, Arbeitsbericht BE HSG/CCBN2/18, Universität St.Gallen, St.Gallen 2004.

Marti, R.: Information Integration in Enterprises. Some Experiences from a Finan-cial Services Company, in: Weikum G. et al. (Hrsg.): Database Systems for Business, Technology, and Web (BTW), 2003, S. 558-567.

Melchert, F.: Integriertes Metadatenmanagement, Dissertation, Universität St.Gallen, St.Gallen 2006.

Poole, J.; Chang, D.; Tolbert, D.; Mellor, D.: Common Warehouse Metamodel. An Introduction to the Standard for Data Warehouse Integration, John Wiley & Sons, New York 2002.

Riehle, D.; Fraleigh, S.; Bucka-Lassen, D.; Omorogbe, N.: The Architecture of a UML Virtual Machine, in: Proceedings of the16. Conference on Object-Oriented Programming Systems, Languages, and Applications, 2001, S. S. 327-341.

Rüegg-Strüm, J.: Das neue St. Galler Management-Modell. Grundkategorien einer integrierten Management-Lehre, Haupt, Bern et al. 2003.

Schmaltz, M.; Dinter, B.: Wartung von Dimensionsdaten in verteilten Data Ware-house-Systemen, in: Schelp J. et al. (Hrsg.): Proceedings der DW2006 - Inte-


gration, Informationslogistik und Architektur, Gesellschaft für Informatik, Friedrichshafen 2006, S. 83-106.

Strahringer, S.: Metamodellierung als Instrument des Methodenvergleichs, Disser-tation, Technische Universität Darmstadt, Darmstadt 1996.

Tannenbaum, A.: Metadata Solutions, Addison-Wesley, Boston 2002. Tozer, G.: Metadata Management for Information Control and Business Success,

Artech House, Norwood 1999. Turowski, K.: Vereinheitlichte Spezifikation von Fachkomponenten: Memoran-

dum des Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwen-dungssysteme, Universität Augsburg, Augsburg 2002.

10 Unternehmensweites Datenqualitätsmanagement: Ordnungsrahmen und Anwendungsbeispiele

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel


1 Datenqualität als Grundlage der Informationslogistik .................... 2012 Stand der Wissenschaft und Praxis ................................................. 2033 Ordnungsrahmen für Datenqualitätsmanagement .......................... 2054 DQM-Gestaltungselemente ............................................................ 2085 Zusammenfassung und Ausblick .................................................... 218

Literatur .......................................................................................... 219

1 Datenqualität als Grundlage der Informationslogistik

Das Marktumfeld vieler Unternehmen zeichnet sich heutzutage einerseits durch kurze Innovationszyklen und kurze Markteinführungszeiten aus. Andererseits wächst die zu beherrschende Komplexität z. B. durch global harmonisierte Geschäftsprozesse und weltweit einheitlichen Kundenser-vice. Beides führt dazu, dass Entscheidungen im Unternehmen in immer kürzeren Abständen und auf Grundlage einer wachsenden Menge an In-formationen getroffen werden müssen.

In diesem Kontext verfolgt die Informationslogistik das Ziel, Informa-tionen zur Unterstützung sämtlicher Arten von Entscheidungen im Unter-nehmen zur Verfügung zu stellen (vgl. Kap. 3). Die Leistungsfähigkeit der Informationslogistik hängt von der Qualität der zu Grunde liegenden Daten ab. Beispiele belegen die Bedeutung von Datenqualität für ihre analytische Nutzung:

202 Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

Kundenmanagement: Zur Steigerung der Kundenzufriedenheit und zur Verbesserung des Kundenservice müssen sämtliche Daten, die im Un-ternehmen zu einem Kunden existieren, verfügbar sein. In der Praxis er-fordert das häufig die Bereitstellung von Daten aus unterschiedlichen Informationssystemen, z. B. aus Systemen für das Customer Relation-ship Management (CRM) und aus Data Warehouse-Systemen. Voraus-setzung für diese Kundendatenintegration ist eine hohe Datenqualität in den beteiligten Systemen.

Unternehmenssteuerung: Entscheidungs- und Führungsprozesse in Un-ternehmen sind durch wachsende Mengen an Informationen, kurze Ent-scheidungszyklen und steigende Komplexität der Entscheidungsbe-reiche gekennzeichnet. Damit die richtige, eindeutige Information zur rechten Zeit in geeigneter Form und Granularität verfügbar ist, bedarf es eines Datenqualitätsmanagements über die Grenzen einzelner Systeme und Organisationseinheiten hinweg.

Behördliche und gesetzliche Auflagen: Die Zahl an Vorgaben und Rich-tlinien, die Unternehmen zu beachten haben, steigt kontinuierlich. Um der damit verbundenen Nachweispflicht nachkommen zu können, müs-sen Unternehmen die erforderlichen Daten bereitstellen können.

Unternehmensvernetzung: In viele Branchen sinkt die Fertigungstiefe einzelner Unternehmen, was zu einer verstärkten Vernetzung und zu ei-nem intensiven Einsatz des elektronischen Datenaustauschs führt. Ohne ein gemeinsames Verständnis über die auszutauschenden Daten sowie einen hohen Qualitätsstandard ist die Integration von Wertschöpfungs-ketten nicht denkbar.

Diese Beispiele zeigen, dass hohe Datenqualität über unterschiedliche Betrachtungseinheiten im Unternehmen hinweg sichergestellt sein muss und nicht etwa lediglich in einzelnen Organisationseinheiten bzw. Ge-schäftsbereichen (s. auch Kap. 3). Denn Probleme mangelhafter Daten-qualität treten in unterschiedlichen Organisationseinheiten auf, beispiels-weise im Einkauf, wenn auf Grund inkonsistenter Lieferantenstammdaten Einkaufsvolumina nicht gebündelt werden können, oder bei der Produkt-einführung, wenn Produktstammdaten nicht aktuell und vollständig an das Produktmanagement und an den Vertrieb übergeben werden (Russom 2006). Dies ist nicht verwunderlich, weil einige wenige Datenobjekte – z. B. Material, Kunde und Lieferant – in den meisten Geschäftsprozessen eines Unternehmens verwendet werden.

Die zugehörigen Datenflüsse bilden die Grundlage für Entscheidungen. Häufig wird jedoch die Datenqualität erst dann gemessen und, sofern er-forderlich, verbessert, wenn die Daten zur Entscheidungsfindung bereit-gestellt werden, und nicht bei ihrer Entstehung bzw. Pflege. Im Gegensatz

Unternehmensweites Datenqualitätsmanagement 203

zu reaktiven Maßnahmen der Datenqualitätsverbesserung zielt das präven-tive Datenqualitätsmanagement (DQM) darauf ab, die Datenqualität be-reits bei der Entstehung der Daten in den Geschäftsprozessen sicherzu-stellen (Eppler u. Helfert 2004).

DQM bezeichnet in diesem Zusammenhang das qualitätsorientierte Ma-nagement der Daten; es umfasst die Erzeugung, Verarbeitung, Speiche-rung, Pflege und Darstellung hochqualitativer Daten. Unternehmensweites DQM ist eine Querschnittsfunktion und betrifft sämtliche Geschäftsberei-che eines Unternehmens.

Trotz dieser strategischen Bedeutung liegt die Verantwortung für DQM in der Praxis häufig allein beim Management der Informationstechnologie (IT), ist also nicht mit den Geschäftsprozessen gekoppelt (Friedman 2006). Die Ursachen dafür umfassen ein fehlendes Verständnis für die fachlichen Auswirkungen des DQM, Budgetrestriktionen sowie fehlende Werkzeuge bei der Etablierung eines unternehmensweiten DQM (Eckerson 2002).

Das Ziel des vorliegenden Beitrags ist vor diesem Hintergrund die Ent-wicklung eines Ordnungsrahmens für unternehmensweites DQM sowie die Darstellung von Anwendungsbeispielen.

Dazu wird im folgenden Abschnitt zunächst der Stand der Wissenschaft und Praxis zu den Themen Datenqualität und DQM dargestellt, bevor an-schließend in Abschn. 3 die Anforderungen an Aufbau und Inhalt des Ord-nungsrahmens skizziert werden. Die einzelnen Elemente des Ordnungs-rahmens werden in Abschn. 4 vorgestellt und mit Beispielen verdeutlicht. Der Beitrag schließt mit einer kurzen Zusammenfassung und einem Aus-blick auf zukünftige Entwicklungen.

2 Stand der Wissenschaft und Praxis

2.1 Datenqualität

Zahlreiche Arbeiten beschäftigen sich mit der Abgrenzung der Begriffe „Daten“ und „Information“. Im Kontext von Datenqualität werden Daten zumeist als einfache Fakten bzw. als „Rohstoff“ interpretiert, wohingegen unter Information Daten in einem bestimmten Kontext verstanden werden (Wang et al. 1998; Price u. Shanks 2005; Jung 2006). Dieses Verständnis liegt auch der Verwendung des Datenbegriffs in den folgenden Ausfüh-rungen zu Grunde, ohne jedoch dabei die o. a. strategische Dimension zu vernachlässigen. Daten sind somit die Basis für Informationen, die wiede-rum Grundlage für Entscheidungen sind.

Datenqualität vereint zwei Aspekte: einerseits die Abhängigkeit von der subjektiven Wahrnehmung des Nutzers von Daten und andererseits die Fä-


higkeit, den Anforderungen für die Verwendung in einer bestimmten Si-tuation zu genügen. Letzteres wird oft mit dem Begriff „Fitness for use“ umschrieben (Redman 2000; Olson 2003). Einigkeit besteht darin, dass Datenqualität vielschichtig ist und sich aus mehreren Datenqualitätsdimen-sionen zusammensetzt (Wang u. Strong 1996). Beispiele für derartige Da-tenqualitätsdimensionen sind Aktualität, Konsistenz, Vollständigkeit, Re-levanz und Genauigkeit.

Darüber hinaus ist die Sicherstellung von Datenqualität eine unterneh-mensweite Aufgabe, insbesondere für diejenigen Datenobjekte, die in mehr als einem Geschäftsbereich Verwendung finden (vgl. Kap. 9). Diese Aufgabe stellt insbesondere Konzernstrukturen mit einer globalen Aus-richtung und dezentralen Organisationsformen vor Herausforderungen. Derartige Unternehmen erzeugen und vertreiben unterschiedliche Produkte in mehr oder weniger autonom agierenden Geschäftsbereichen und in meh-reren Ländern. Sie verfügen zumeist über eine komplexe und heterogene Landschaft an Informationssystemen zur Speicherung und Verarbeitung der Daten, die sich auf Grund von Unternehmensfusionen, unterschiedli-chen fachlichen Anforderungen einzelner Geschäftsbereiche und länder-spezifischen gesetzlichen Vorgaben entwickelt hat. Datenqualitätspro-bleme treten dabei auf, wenn Daten aus unterschiedlichen Systemen und über verschiedene Geschäftsbereiche und Länder hinweg zusammenge-führt werden sollen (Lee et al. 2006). Der Begriff Konzerndatenqualität bezieht sich in diesem Kontext auf Unternehmen, die in mehreren Ländern aktiv sind, unterschiedliche Geschäftsbereiche vereinen, und ein unter-nehmensweites DQM etablieren möchten.

2.2 Datenqualitätsmanagement (DQM)

Datenmanagement umfasst die Definition einer Datenarchitektur, unter-nehmensweite Datenmodelle und Datenmodellierungsstandards, die Ver-waltung der Daten und der Datenpflegeprozesse sowie die Informati-onssysteme zur Speicherung und Verarbeitung der Daten (Stahlknecht u. Hasenkamp 1999; Krcmar 2005). Datenqualitätsmanagement ist in diesem Sinne das qualitätsorientierte Datenmanagement, also die Modellierung, Erzeugung, Verarbeitung, Speicherung und Darstellung von Daten mit dem Ziel der Sicherstellung einer hohen Datenqualität.

In den vergangenen Jahren haben sich einige Ansätze für DQM heraus-gebildet. Zu den wichtigsten gehören:

Total Data Quality Management (TDQM): Das TDQM-Programm wur-de 1991 am MIT entwickelt und zielte darauf ab, DQM als Mana-gementaufgabe zu etablieren und eine fundierte wissenschaftliche Basis


für Datenqualität zu liefern (Wang u. Strong 1996; Lee et al. 2006). TDQM basiert auf der Annahme, dass Daten genauso gehandhabt und verwaltet werden müssten wie physische Produkte in einem Unterneh-men. TDQM umfasst deshalb die Analyse der Kundenbedürfnisse an Daten, das Management des Datenproduktionsprozesses, den Lebens-zyklus der Daten sowie die Benennung eines „Produktmanagers“ für einzelne Datenobjekte. Die TDQM-Methode setzt sich aus vier Phasen zusammen, nämlich der Definition, der Messung, der Analyse und der Verbesserung von Datenqualität. Der TDQM-Ansatz ist in unterschied-lichen Varianten weiterentwickelt worden, z. B. im Rahmen des Total Information Quality Management (TIQM), das zusätzlich Konzepte zur Kundenorientierung, zur Zusammenarbeit im Team, zur Führung und zur Erfolgsmessung umfasst (Nohr 2001).

Total Quality data Management (TQdM): Die TQdM-Methode fußt auf fünf Prozessen zur Messung und Verbesserung der Informationsqualität sowie einem übergeordneten Koordinationsprozess (English 1999). TQdM berücksichtigt betriebswirtschaftliche Erfolgsgrößen, nämlich die Verbesserung der Prozessleistung sowie die Erhöhung der Kunden-zufriedenheit durch Datenqualitätsverbesserungen.

Data Management Body of Knowledge (DMBOK): Das so genannte DMBOK wird von der Data Management Association entwickelt und zielt darauf ab, ein Rahmenwerk für das Datenmanagement zu etablie-ren, ein einheitliches Verständnis über Datenmanagementfunktionen zu schaffen sowie Leitfäden und „Best Practices“ für die Umsetzung be-reitzustellen. Aktuell ist die Version 2.0 des Rahmenwerks, die 2007 veröffentlicht wurde (DAMA 2007).

Daneben gibt es eine ganze Reihe von Erweiterungen dieser Ansätze, beispielsweise für das Datenqualitätsmanagement in wissensintensiven Geschäftsprozessen (Eppler 2006), sowie verschiedene Vorschläge von Beratungsunternehmen zur Organisation des DQM wie das Data Gover-nance Council von IBM (IBM 2007).

3 Ordnungsrahmen für Datenqualitätsmanagement

3.1 Anforderungen

Trotz der betriebswirtschaftlichen Bedeutung ist die Umsetzung des DQM in Unternehmen häufig mangelhaft: Bei der Verbesserung der Datenquali-tät herrschen manuelle Aktivitäten vor, es finden kaum präventive Maß-nahmen statt, sondern es wird erst reagiert, wenn Datenqualitätsprobleme


aufgetreten sind und es gibt kaum eine klare Regelung der Verantwortlich-keit für DQM (Russom 2006). Die Gründe dafür liegen oftmals in einem mangelnden Verständnis über die Bedeutung von DQM und über die zu-gehörigen Aufgaben sowie im Fehlen praktischer Werkzeuge zur Umset-zung (Wijnhoven et al. 2007). Hier schafft ein Ordnungsrahmen Abhilfe. Er identifiziert die Elemente eines bestimmten Gestaltungsbereichs und veranschaulicht die Beziehung der einzelnen Elemente untereinander (Meise 2001). Ein Ordnungsrahmen für DQM muss die folgenden Anfor-derungen erfüllen:

Berücksichtigung nicht allein informationstechnischer, sondern auch or-ganisatorisch-betriebswirtschaftlicher Aufgaben des DQM: DQM ist nicht ausschließlich eine Teilaufgabe des Managements der Informati-onstechnologie im Unternehmen. Die strategische Bedeutung hochqua-litativer Daten sowie die fachliche Hoheit über Daten im Unternehmen erfordern eine Kopplung mit den betriebswirtschaftlichen Zielen im Un-ternehmen und eine organisatorische Verankerung, die auch die Fach-seite einschließt (PwC 2004).

Unternehmensweite Anwendbarkeit, insbesondere über mehrere Ge-schäftsbereiche hinweg: DQM ist eine Querschnittsfunktion. Beste-hende Ansätze (siehe Abschn. 2.2) fokussieren jedoch häufig einen ein-zelnen Geschäftsprozess bzw. ein einzelnes Anwendungssystem oder geben keine Antwort auf die Frage der organisatorischen Verankerung in dezentralen Unternehmen.

3.2 Gestaltungselemente

Auf Basis der Anforderungen sowie einer Analyse bestehender DQM-An-sätze (siehe Absch. 2.2) können die folgenden sechs Gestaltungselemente für den Ordnungsrahmen abgeleitet werden:

Datenqualitätsstrategie Führungssystem Data Governance Datenmanagement-Prozesse Datenarchitektur und Datenhaltung Systemunterstützung

Die Gestaltungselemente werden in Abschn. 4 im Einzelnen erläutert.


3.3 Aufbau

Dem Aufbau des Ordnungsrahmens liegt der Ansatz des Business Engi-neering zu Grunde (vgl. Kap. 2), um der Forderung nach betriebswirt-schaftlich-organisatorischer Verankerung des Gestaltungsbereichs sowie der Anwendbarkeit über einzelne Organisationseinheiten hinweg Rech-nung zu tragen.

Grundsätzlich bestimmt die Unternehmensstrategie die Architektur der Geschäftsprozesse, die wiederum durch Informationstechnologie unter-stützt werden (Davenport 1993; Hammer u. Champy 1993). Für die Ge-staltung der drei Ebenen Strategie, Organisation und Systeme sowie ihrer Beziehungen untereinander stellt das Business Engineering verschiedene Methoden bereit (vgl. Kap. 2, Österle u. Blessing 2005). Die Ebenen des Business Engineering finden zur Strukturierung des Ordnungsrahmens für unternehmensweites DQM Anwendung, indem die einzelnen Gestaltungs-elemente den drei Ebenen zugeordnet werden (siehe Abb. 1).

Auf der Ebene „Strategie“ ist die Datenqualitätsstrategie angeordnet, um das DQM mit den strategischen Zielen des Unternehmens zu verknüpfen. Dazu wird ermittelt, welchen Beitrag das DQM zu den Unternehmenszie-len leisten soll. Das Führungssystem steuert die Umsetzung der Datenqua-litätsstrategie und verbindet die Ebenen „Strategie“ und „Organisation“. Die Organisationsebene umfasst einerseits die so genannte Data Gover-nance, also die Zuordnung von Aufgaben des DQM zu den DQM-Rollen sowie die Gestaltung der eigentlichen Datenmanagement-Prozesse, die im Sinne des DQM ausgestaltet werden müssen. Auf der „Systemebene“ legt die Datenarchitektur fest, welche organisatorische Reichweite (z. B. unter-nehmensweit gültige Warengruppenschlüssel einerseits und länderspezifi-sche Gewichtseinheiten andererseits) einzelne Datenobjekte besitzen und nach welchen Regeln die Daten erfasst und gepflegt werden. Die System-unterstützung umfasst zudem einerseits die Architektur der Informations-systeme, in denen die Daten gehalten werden sowie andererseits Vorgaben für Werkzeuge zur Erhöhung der Datenqualität, z. B. zur Datenbereini-gung.

Im folgenden Abschnitt werden die Gestaltungselemente des Ordnungs-rahmens genauer erläutert und anhand von Beispielen illustriert.


Strategie

Organisation

Systeme

Datenqualitätsstrategie

Führungssystem

Data Governance Datenmanagement-Prozesse

Datenarchitektur und Datenhaltung

lokal global

Systemunterstützung

Abb. 1. Ordnungsrahmen für Datenqualitätsmanagement

4 DQM-Gestaltungselemente

4.1 Datenqualitätsstrategie

Die Datenqualitätsstrategie zielt darauf ab, das DQM an der Unterneh-mensstrategie auszurichten. Das umfasst i. d. R. die folgenden vier Aufga-ben:


Bestimmung des Beitrags des DQM zur Informationslogistik Definition der DQM-Ziele Bestimmung des Nutzens des DQM Ableitung von DQM-Maßnahmen

Die Definition der Ziele erfolgt in der Praxis in unterschiedlichen De-taillierungen. Möglich sind messbare Ziele für die Datenqualität einzelner Objekte, z. B. 95-prozentige Vollständigkeit der Lieferantenstammdaten.

Häufig finden sich in der Praxis auch verbale Formulierungen der DQM-Ziele im Sinne eines strategischen Leitbilds. Beispiele für derartige Formulierungen sind:

Bereitstellung einer zentralen und konsistenten Datenbasis zur analyti-schen Nutzung („Single Point of Truth“) für den Finanz- und Produkt-planungsprozess eines Chemieunternehmens

Steigerung der Transparenz über Materialstammdaten als Voraussetzung für die Geschäftsprozessharmonisierung bei einem Konsumgüterher-steller

Konsolidierung der Lieferantenstammdaten für die Informationslogistik im Zentraleinkauf eines Automobilzulieferers

Steigerung der Flexibilität bei der Bereitstellung von Kundenstammda-ten in einem Telekommunikationsunternehmen

Etablierung klarer Verantwortlichkeiten für Produktstammdaten bei ei-nem Anlagen- und Maschinenbauer

Für die Bestimmung des Nutzens des DQM im Unternehmen wird eine Klassifikation unterschiedlicher Kosten- und Nutzenarten vorgeschlagen, wie in Abb. 2 dargestellt (Mirani u. Lederer 1998; Eppler u. Helfert 2004).

Datenqualitätskosten

Indirekte Kosten

Entdeckungs-kosten

Direkte Kosten

Bereinigungs-kosten

Präventions-kosten

Fachliche Nutzenpotentiale

Wettbewerbs-vorteile

Kundenzufriedenheit

…

Kosten schlechter Datenqualität

Kosten der Qualitäts-verbesserung und

-sicherungStrategisch Operativ

…

Verkürzte Prozess-durchlaufzeiten

Abb. 2. Kosten und Nutzen des DQM


Direkte Kosten schlechter Datenqualität fallen z. B an, wenn im Be-richtswesen unterschiedliche Systeme verschiedene Werte für den gleichen Sachverhalt liefern (unternehmensweites Einkaufsvolumen bei einem Lie-feranten o. ä.) und die Informationen verifiziert werden müssen. Zu in-direkten Kosten zählen die Auswirkungen von falschen Entscheidungen infolge schlechter Datenqualität. Präventionskosten umfassen u. a. Kosten für die Schulung von Mitarbeitern, Projektkosten zur Etablierung von Data Governance, wohingegen Bereinigungskosten anfallen, wenn die Daten-qualität in einzelnen Datenbeständen verbessert wird. Unter Entdeckungs-kosten wiederum fallen Kosten für das Messen der Datenqualität.

Auf der anderen Seite wirkt sich hohe Datenqualität positiv in den Fachbereichen und Geschäftsprozessen aus. Hier ist zu unterscheiden zwi-schen so genannten strategischen Potenzialen, die i. d. R. nicht messbar sind und quantifizierbaren Nutzenpotenzialen. Zu letzteren zählen z. B. re-duzierte Transportkosten durch genauere Gewichtsangaben bei Produkten und reduzierte Wartungskosten auf Grund der Verfügbarkeit von Anla-genstammdaten.

4.2 Führungssystem

Das Führungssystem hat im DQM die Aufgabe, die Datenqualität zu mes-sen, und bildet damit die Grundlage zur kontinuierlichen Verbesserung der Datenqualität im Unternehmen. In der Praxis haben sich einige Erfolgs-faktoren für die Etablierung von Führungssystemen herausgebildet:

Identifikation betriebswirtschaftlicher Führungsgrößen auf Basis der Anforderungen der Nutzer der Daten bzw. der aus ihnen resultierenden Informationen.

Festlegung von Zielwerten für die Führungsgrößen in Abstimmung mit den beteiligten Rollen (z. B. Prozess- und Systemverantwortliche).

Verankerung dieser Datenqualitätsziele in den Zielsystemen der betei-ligten Organisationseinheiten und der beteiligten Mitarbeiter.

Festlegung von Maßnahmen im Falle von Abweichungen von Zielwer-ten.

Sicherstellung der Messbarkeit der Führungsgrößen.

Die Gestaltung von Führungssystemen soll anhand eines Beispiels ver-anschaulicht werden. In Tabelle 1 ist das Führungssystem der Karstadt Warenhaus GmbH dargestellt (Schemm u. Otto 2007). Datenqualitätsprob-leme äußern sich im Einzelhandel darin, dass Artikel beim Warenausgang an der Kasse auf Grund einer fehlenden oder falschen Artikelnummer nicht eindeutig identifiziert werden können. Die ungenaue Warenaus-


gangsbuchung führt zu Fehlern in der Bestandsführung, die sich auf alle nachfolgenden Prozesse wie bspw. den Warennachschub auswirken.

Tabelle 1. Führungssystem für DQM bei Karstadt

Kennzahl Bezugsgrösse Berechnungsvorschrift Ebene Periodizität Formatwechsel Wert (Absolutwert der For-

matwechsel) / Verbrauch * 100

Filiale, Abteilung

Monatlich

Pseudo-Bepo Wert (Wert Pseudo-Bepo) / Wert Bepo Gesamt * 100

Filiale, Abteilung

Monatlich

Minusbestand Anzahl (Anzahl Bepo ohne Be-stand) / (Anzahl Bepo Gesamt) * 100

Filiale, Abteilung

Monatlich

Inventurbestand ohne Bestellpo-sitionen

Wert (Inventurbestand ohne Bepo) / Inventurbestand * 100

Filiale, Abteilung

Jährlich

EK-Differenzen Anzahl (Anzahl fehlerhafte Re-po) / (Anzahl Repo Ge-samt) * 100

Abteilung Monatlich

Rechnungen oh-ne Auftrag

Anzahl (Anzahl Rechnungen ohne Auftrag) / (Anzahl Rechnungen Gesamt) * 100

Filiale, Abteilung

Monatlich

Fehlerlisten Anzahl (Absolutwert der Menge mit Fehlern) / (Absolut-wert der Gesamtmenge) * 100

Filiale, Abteilung

Monatlich

Stapf-Korrekturen

Wert Wert der nachträglichen Ergebniskorrekturen

Filiale, Abteilung

Monatlich

Karstadt definierte zwei Kennzahlen zur Messung dieses Problembereichs:

Im Fall eines so genannten „Formatwechsels“ verbuchen die Kassierer den nicht erkannten Artikel rein wertmäßig unter Angabe von Abtei-lung, Preis und Menge. Diese rein finanzwirtschaftliche Buchung führt zu einer Divergenz zwischen Finanz- und Warenwirtschaft. Die Kenn-zahl setzt die wertmäßige Summe aller Formatwechsel ins Verhältnis zum gesamten warenwirtschaftlichen Umsatz.

Im Fall einer Pseudo-Bestellposition (Bepo) verbuchen die Kassierer den nicht erkannten Artikel unter Angabe von Preis und Menge auf ei-ner Pseudo-Artikelnummer. Analog zum Formatwechsel führt diese Bu-chung zu einem fehlerhaften Bestand, die Buchung ist jedoch in der Warenwirtschaft abgebildet und nachvollziehbar. Die Kennzahl setzt


den Wert aller Pseudo-Bepo ins Verhältnis zum Wert der gesamten Be-stellpositionen.

Die durch Formatwechsel und Pseudo-Bestellpositionen beeinflussten Bestandswerte misst Karstadt zusätzlich direkt durch zwei Qualitätskenn-zahlen:

Der Minusbestand setzt die Anzahl aller Bestellpositionen mit negativen Beständen ins Verhältnis zur Gesamtanzahl der Bestellpositionen.

Der Inventurbestand ohne Bepo misst einmal pro Jahr den wertmäßigen Anteil des nicht warenwirtschaftlich erfassten Inventurbestands.

Neben Fehlern im Warenausgang und in der Bestandsführung wirkt sich mangelhafte Datenqualität auch in den Einkaufprozessen aus. Karstadt misst in diesem Bereich den Anteil fehlerhafter Rechnungspositionen (EK-Differenzen) sowie die Anzahl an Rechnungen ohne Auftrag.

Über Fehlerlisten erfasst Karstadt darüber hinaus alle weiteren waren-wirtschaftlichen Vorgänge, die auf Grund von Datenfehlern nicht verbucht werden können und i. d. R. manuell nachbearbeitet werden müssen. Die Kennzahl Stapf-Korrekturen1 erfasst alle notwendigen nachträglichen Kor-rekturen in der Ergebnisrechnung.

4.3 Data Governance

Data Governance zielt darauf ab, die Aufgaben und Verantwortlichkeiten des DQM im Unternehmen zu definieren. Das erfolgt in drei Schritten:

Erstens benennt Data Governance die Aufgaben, die im DQM zu erfül-len sind. Hierzu gehören z. B. die Definition von Datenpflegeprozessen sowie die Definition von Metadaten.

Zweitens identifiziert Data Governance die an den Aufgaben beteiligten Rollen.

Drittens müssen Zuständigkeiten festgelegt werden, die die Aufgaben den Rollen zuordnen.

Die Zahl und Ausgestaltung der Rollen für DQM variiert von Unter-nehmen zu Unternehmen in Abhängigkeit von der bestehenden Gremien-landschaft und Rollenstruktur. Es haben sich aber die folgenden fünf Rol-len als übergreifend relevant herausgestellt (English 1999; Dyché u. Levy 2006):

1 Stapf: Statistisches Auswertungsprogramm Filialen.


Sponsor in der Geschäftsleitung, der das Mandat zur Umsetzung der DQM-Maßnahmen erteilt.

Data Governance-Komitee zur Koordination und Kontrolle der DQM-Maßnahmen über Geschäftsbereichsgrenzen hinweg.

Konzern-Datensteward zur Definition und Fortschreibung der Daten-qualitätsstrategie und deren Abstimmung mit allen involvierten Ge-schäftsbereichen.

Fachlicher Datensteward zur Umsetzung der Data-Governance-Vorga-ben im Tagesgeschäft (z. B. in Datenerfassungs- und Datenpflegepro-zessen). Fachliche Datenstewards werden für einzelne Datenobjekte (z. B. Kundenstammdaten, Materialstammdaten) oder Geschäftspro-zesse (z. B. Auftragsabwicklung, Einkauf) eingesetzt.

Technischer Datensteward zur Umsetzung der Regeln und Vorgaben für die Datenobjekte in den Anwendungssystemen, z. B. in Enterprise Re-source Planning (ERP)-Systemen.

In der praktischen Umsetzung konkretisiert sich Data Governance häu-fig in Verantwortlichkeitsdiagrammen, wie in Abb. 3 dargestellt. Dabei werden in Form einer Matrix Aufgaben des DQM und die beteiligten Rol-len gegenübergestellt. Die Beziehungen zwischen den Rollen und Aufga-ben eignen sich zur Modellierung von Verantwortlichkeiten. Folgende Zu-ständigkeitstypen lassen sich unterscheiden:

Rechenschaftspflichtig – und damit entscheidungsbefugt – z. B. im Sin-ne eines Budgets.

Verantwortlich im Sinne der Durchführung. Unterstützend, z. B. durch Einbringen von Fachkompetenz. Informiert, z. B. nachdem eine Aufgabe erledigt oder eine Entscheidung

getroffen wurde.

Speziell im angelsächsischen Wirtschaftsraum haben sich zur Benen-nung der Zuständigkeitstypen Notationen wie RACI (Responsible, Ac-countable, Consulted, Informed) eingebürgert (IT Governance Institute 2007).

Für die Zuordnung von Aufgaben zu Rollen über die Zuständigkeitsty-pen gibt es keine allgemeinen Handlungsempfehlungen. Vielmehr ist die Ausprägung des Verantwortlichkeitsdiagramms im Einzelfall von der spe-zifischen Situation abhängig, in dem sich das Unternehmen befindet. Zu den Einflussfaktoren, die auf die Verantwortlichkeitsmatrix wirken, gehö-ren u. a. (Wende u. Otto 2007):

Grad der Diversifikation des Unternehmens Grad der Geschäftsprozessharmonisierung


Bestehende Aufbauorganisation Branchenzugehörigkeit Wettbewerbsstrategie Vorhandene DQM-Expertise

In Abb. 3 ist exemplarisch ein Verantwortlichkeitsdiagramm für ein glo-bal agierendes Unternehmen mit verschiedenen Geschäftsbereichen (Ver-triebsgesellschaften) sowie Abstimmungsbedarf zur Konzernmutter (Hol-ding) dargestellt. Dabei erfolgt die Benennung der Zuständigkeiten gemäß der o. a. RACI-Notation.

Governance-Modell

StammdatenprozesseProzessüberwachungStammdatenqualität

Konzern-Daten-steward

Techn. Daten-steward

Prozess-verant-

wortlicher

Stammdatenobjekte

Rollen

Auf

gabe

n

R,ACC

R

CRR

R,AC

ICC

C

R: Responsible A: Accountable C: Consulted I: Informed

R,A

RR,AR

IACCR

I

C

CC

R,AR,A

CI

Gesell-schaft Holding

I

CC,II

IR

C

C

C,I

ICI

Qualitätsüberwachung

InformationsarchitekturProjekteSupport

Stammdatenpflege

TrainingKommunikation

Data-Gover-nance-Komitee

AA

A

AI

I

Abb. 3. Exemplarisches Verantwortlichkeitsdiagramm

4.4 Datenmanagementprozesse

Datenmanagementprozesse bestimmen die Erzeugung und die Pflege von Daten und sind häufig eingebettet in die Geschäftsprozesse eines Unter-nehmens, z. B. in Beschaffungs- und Vertriebsprozesse. Im Kontext eines präventiven Datenqualitätsmanagements sind die Datenmanagement-prozesse derartig zu gestalten, dass die Datenqualität bei der Erfassung und Aktualisierung der Daten sichergestellt ist, also im Vorfeld der analyti-schen Nutzung. Durch die Definition, Modellierung und Implementierung von Datenmanagementprozessen lassen sich Aufwendungen für nachfol-gende Maßnahmen zur Datenbereinigungen vermeiden.


Die unterschiedlichen Datenmanagementprozesse werden am Beispiel der Pflege von Materialstammdaten erläutert. Grundsätzlich werden drei Prozesse unterschieden:

Anlage: Die Auslöser für die Anlage eines neuen Materialstammdaten-satzes können vielfältig sein und hängen häufig von der Art des Mate-rials ab. Die Anlage eines neuen Fertigprodukts beispielsweise wird von der Entwicklungsabteilung angestoßen, während die Anlage eines Roh-materials vom Einkauf ausgelöst wird. Die Anlage sämtlicher Attribute erfolgt sukzessive gemäß der Sichten (nutzerspezifischen Attributmen-gen) durch die entsprechenden Prozessverantwortlichen.

Pflege: Über den Informationslebenszyklus eines Materials ergeben sich Änderungen, die in den Stammsatz übernommen werden müssen. Aus-löser dafür sind z. B. die Änderung der Herstellung eines Produkts, die Änderung der Verpackung oder die Erweiterung des Verkaufsgebiets.

Ausphasen: Wenn Materialdaten nicht mehr benötigt werden, z. B. weil ein Artikel schon längere Zeit vom Markt genommen wurde, müssen sie deaktiviert werden. In der betrieblichen Praxis dürfen derartige Stamm-sätze nicht sofort gelöscht werden, weil die Daten noch in historischen Bewegungsdaten (Bestellungen, Fertigungsaufträge usw.) referenziert werden. Statt dessen werden die Stammdatensätze zunächst deaktiviert und erst gelöscht, wenn alle Transaktionsdaten abgearbeitet wurden. Für die Nutzung in analytischen Informationen müssen diese Daten u. U. noch längere Zeit vorgehalten werden, da sie von historisierten Daten referenziert werden.

Diese drei Grundprozesse werden in der Praxis je nach Datenobjekt un-terschiedlich gestaltet. Zum Beispiel sind die Prozesse für die Anlage und Pflege der Grunddaten eines Lieferantenstammdatensatzes zumeist unter-nehmensweit standardisiert und einer zentralen Stelle (z. B. im Zentralein-kauf) zugeordnet, wohingegen einzelne Attribute (z. B. Adressen) lokal unterschiedlich erfasst und gepflegt werden.

4.5 Datenarchitektur

Die Datenarchitektur umfasst die Struktur der Daten und ihre Beziehungen zueinander sowie Modellierungs- und Gestaltungsrichtlinien (van den Ho-ven 2003). Im Rahmen des DQM umfasst die Gestaltung der Datenarchi-tektur folgende Aufgaben:

Identifikation der Menge an relevanten Datenobjekten und Attributen: Im unternehmensweiten DQM werden häufig nur diejenigen Objekte


betrachtet, die geschäftsbereichsübergreifend verwendet werden (z. B. Lieferanten- und Materialstammdaten).

Definition der Beziehungen der Datenobjekte und Attribute untereinan-der.

Festlegung einer eindeutigen Definition für die Datenobjekte und Attri-bute sowie Identifikation von Synonymen und Homonymen.

Festlegung der organisatorischen Gültigkeit der Datenobjekte und Attri-bute (z. B. unternehmensweit vs. länderspezifisch).

Festlegung des Wertebereichs für Attribute.

Die Gestaltung der Datenarchitektur bildet somit eine Grundlage für ef-fiziente Informationslogistik, denn sie ermöglicht durchgehende Daten-flüsse zwischen verschiedenen Organisationseinheiten.

In Abb. 4 sind ausgewählte Elemente der Datenarchitektur am Beispiel eines Materialstammsatzes veranschaulicht.

Grunddaten

Funktionsspezifische Sichten

Merkmale• Organisations-

einheiten

Vertrieb• Verkaufspreis• Skontofähig• Min. Auftragsmenge• …

Einkauf• Einkaufspreis• Toleranzen für Über-

/ Unterlieferung• ...

Disposition• Losgrösse• Dispositionsmerkmal• Sicherheitsbestand • ...

Buchhaltung• Preissteuerung• Bewertungsklasse• …• ...

Materialstammsatz

• Materialgruppe• …

• Abmessungen• Mengeneinheit

…

• Sprache• …

• Materialnummer• Materialbezeichnung

Abb. 4. Beispiel für den Aufbau eines Materialstammsatzes

Die verschiedenen Attribute werden der Übersichtlichkeit halber in so genannte Sichten gegliedert. Neben Grunddaten, die für alle Geschäftspro-zesse relevant sind, werden Sichten je nach Geschäftsprozess unterschie-den.

4.6 Systemunterstützung

Die Systemunterstützung des DQM umfasst Aspekte der Architektur der Systeme, in denen die Daten gehalten werden, sowie derjenigen Werk-zeuge, die zur Bereinigung von Datenbeständen bzw. zur Verbesserung der Datenqualität eingesetzt werden. Die Gestaltung der Datenhaltungssysteme ist Gestaltungsaufgabe im Rahmen des präventiven Verständnisses des


DQM, wohingegen Bereinigungswerkzeuge als reaktive Maßnahme in-folge schlechter Datenqualität in operativen Systemen eingesetzt werden. Die Systemarchitektur der Datenhaltungssysteme ist deswegen als Basis für effiziente Informationslogistik anzusehen, weil sie – in Analogie zu den Datenmanagementprozessen – reibungsfreie Datenflüsse ermöglicht, indem inkonsistente, falsche und unvollständige Datenbestände vermieden werden.

Die Gestaltungsvarianten der Systemarchitektur werden am Beispiel des Stammdatenmanagements veranschaulicht. Grundsätzlich können vier Architekturvarianten unterschieden werden (Legner u. Otto 2007):

Das führende System ist das in der Praxis am häufigsten verwendete Verfahren für die Stammdatenverteilung. Dabei wird eines der beste-henden Systeme als führendes System für eine Stammdatenklasse defi-niert und ist damit Ausgangspunkt für die Verteilung an die anderen Systeme. Das erstmalige Anlegen der Stammdaten geschieht im führen-den System mit den dort vorhandenen Attributen. Da in dieser Variante kein vollständig harmonisiertes Datenmodell vorliegt, sind bei der Ver-teilung Datenergänzungen in den empfangenden Systemen sowie ein Mapping von Primärschlüsseln und Attributen auf das Datenformat des Zielsystems notwendig.

Ein zentrales Stammdatensystem bedeutet Führung der Stammdaten in einem separaten Stammdatensystem, das diese an die lokalen Systeme verteilt. Auch bei diesem Ansatz findet die Erfassung und Pflege grund-sätzlich in einem zentralen System statt, allerdings auf Basis eines har-monisierten Stammdatenmodells. Die Verteilung geschieht in der Regel asynchron (d. h. mit Verzögerung) und im Push-Verfahren. Obwohl mit neuen Ansätzen wie Serviceorientierten Architekturen (SOA) ein di-rekter Zugriff der Applikationen auf das Stammdatensystem theoretisch möglich wäre, werden die Stammdaten meist auch lokal gespeichert. Im Vergleich zu einem führenden System verfügt ein zentrales Stammda-tensystem oft über zusätzliche Funktionalitäten und Workflow-Unter-stützung für die Datenmanagementprozesse.

Die Verwendung von Standards führt nicht zu einer zentralen Speiche-rung und Verteilung von Stammdaten, es werden nur unternehmensweit einheitliche Strukturen definiert. Ein harmonisiertes Stammdatenmodell gewährleistet, dass Aufbau und Anlage eines Stammdatensatzes über verschiedene Systeme hinweg gleich sind. Die Datenerfassung, -haltung und -pflege erfolgt jedoch dezentral in den lokalen Systemen. Die Stan-dardisierung der globalen Attribute stellt sicher, dass einerseits ein Mi-nimum an Attributen erfasst wird und diese andererseits in jedem Sys-tem dieselbe Bedeutung haben. In der praktischen Umsetzung führt ein


auf Standards basierender Ansatz häufig zu gewissen Inkonsistenzen im Datenbestand, z. B. Dubletten, da kein Stammdatenabgleich vorgesehen ist und kein „Single Point of Truth“ existiert.

Bei der Föderation über ein Verzeichnis (Registry) werden systemüber-greifend Zuordnungen der verschiedenen Stammdatensätze zu den ver-schiedenen Quellsystemen verwaltet. Benötigt beispielsweise ein Sys-tem Daten zu einem bestimmten Kunden, so startet es eine Anfrage an die Registry und erhält eine Antwort, in welchem System die Daten zu dem jeweiligen Kunden abgelegt sind. In einem weiteren Schritt werden die Daten dann direkt aus dem entsprechenden System abgerufen. Die Datensätze werden dezentral in den lokalen Systemen angelegt, gepflegt und gehalten. Eine Datenverteilung gibt es in diesem Szenario nicht, das Verzeichnis koordiniert lediglich den Datenzugriff. Änderungen in den Stammdatensätzen sind bei jedem Zugriff sofort verfügbar. Dieser An-satz wird typischerweise bei sehr großen und verteilten Datenbeständen verwendet.


Grundlage sowohl für die Informationslogistik als auch für die operative Nutzung von Daten in Geschäftsprozessen ist die Verfügbarkeit von Daten in der richtigen Qualität. Weil der Bedarf an hochqualitativen Daten die Grenzen einzelner Organisationseinheiten überschreitet, besitzt das DQM den Infrastrukturcharakter einer Querschnittfunktion. In der Praxis wird es jedoch häufig an die IT-Abteilung delegiert und die strategische Bedeu-tung des DQM als Managementaufgabe wird verkannt.

Als Werkzeug zur Verknüpfung des DQM mit den betriebswirtschaftli-chen Zielen eines Unternehmens, zur Verankerung in der Organisation sowie zur Gestaltung der einzelnen DQM-Aufgaben dient der vorgeschla-gene Ordnungsrahmen. Er besteht aus sechs DQM-Aufgaben, die in die Gestaltungsebenen „Strategie“, „Prozesse“ und „Systeme“ des Business Engineering eingeordnet werden. Er hilft damit bei der Positionierung und Umsetzung des DQM im Unternehmen.

Weiterentwicklungen des Ordnungsrahmens zielen auf die Detaillierung der Aufgaben im Sinne eines Reifegradmodells ab, um in der Anwendung zur Bestandsaufnahme und als Steuerungsinstrument für Maßnahmen zur Verbesserung des DQM eingesetzt werden zu können.

Sowohl die bestehenden Ergebnisse als auch die angestrebten Weiter-entwicklungen werden im Competence Center Corporate Data Quality des


Instituts für Wirtschaftsinformatik der Universität St. Gallen in Zusam-menarbeit mit Partnerunternehmen erarbeitet.

Literatur

DAMA: Data Management Body of Knowledge (DMBOK) Functional Frame-work, DAMA International, Lutz 2007.

Davenport, T.: Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston 1993.

Dyché, J.; Levy, E.: Customer Data Integration, Wiley, Hoboken 2006. Eckerson, W.: Data Quality and the Bottom Line, The Data Warehousing Institute,

Seattle 2002. English, L.: Improving Data Warehouse and Business Information Quality, Wiley,

New York 1999. Eppler, M.: Managing Information Quality, 2. Aufl., Springer, Berlin et al. 2006. Eppler, M.; Helfert, M.: A Framework for the Classification of Data Quality Costs

and an Analysis of Their Progression, in: Proceedings of the 9th International Conference on Information Quality, Cambridge 2004.

Friedman, T.: Gartner Study on Data Quality Shows That IT Still Bears the Bur-den, G00137680, Gartner Group, Stamford 2006.

Hammer, M.; Champy, J.: Reengineering the Corporation: A Manifesto for Busi-ness Revolution, Nicholas Brealey, London 1993.

IBM: IBM Data Governance, http://www-306.ibm.com/software/tivoli/ governance/servicemanagement/data-governance.html, 21.10.2007.

IT Governance Institute: COBIT 4.1, Rolling Meadows 2007. Jung, R.: Architekturen zur Datenintegration: Gestaltungsempfehlungen auf Basis

fachkonzetueller Anforderungen, Deutscher Universitätsverlag, Wiesbaden 2006.

Krcmar, H.: Informationsmanagement, 4. Aufl., Springer, Berlin 2005. Lee, Y.; Pipino, L.; Funk, J.; Wang, R.: Journey to Data Quality, MIT Press, Bos-

ton 2006. Legner, C.; Otto, B.: Stammdatenmanagement, in: WISU - Das Wirtschaftsstu-

dium 36 (2007) 4, S. 562-568. Meise, V.: Ordnungsrahmen zur prozessorientierten Organisationsgestaltung:

Modelle für das Management komplexer Reorganisationsprojekte, Kovac, Hamburg 2001.

Mirani, R.; Lederer, A.: An Instrument for Assessing the Organizational Benefits of IS Projects, in: Decision Sciences 29 (1998) 4, S. 803-838.

Nohr, H.: Management der Informationsqualität, Working Papers Knowledge Management Nr. 3/2001, Fachhochschule Stuttgart, Stuttgart 2001.

Olson, J.: Data Quality - The Accuracy Dimension, Morgan Kaufmann, San Fran-cisco 2003.

Österle, H.; Blessing, D.: Ansätze des Business Engineering, in: HMD 42 (2005) 241, S. 7-17.


Price, R.; Shanks, G.: A semiotic information quality framework: Development and comparative analysis, in: Journal of Information Technology 2005 (2005) 20, S. 88-102.

PwC: Global Data Management Survey 2004, PricewaterhouseCoopers, 2004. Redman, T.: Data Quality, Digital Press, Boston 2000. Russom, P.: Taking Data Quality to the Enterprise through Data Governance, The

Data Warehousing Institute, Seattle 2006. Schemm, J.; Otto, B.: Fallstudie Stammdatenmanagement bei der Karstadt Wa-

renhaus GmbH, BE HSG / CC CDQ / 3, Universität St. Gallen, Institut für Wirtschaftsinformatik, St. Gallen 2007.

Stahlknecht, P.; Hasenkamp, U.: Einführung in die Wirtschaftsinformatik, 9. Aufl., Springer, Heidelberg 1999.

van den Hoven, J.: Data Architecture: Principles for Data, in: Information Systems Management (2003), S. 93-96.

Wang, R.; Lee, Y.; Pipino, L.; Strong, D.: Manage Your Information as a Product, in: Sloan Management Review 39 (1998) 4, S. 95-105.

Wang, R.; Strong, D.: Beyond Accuracy: What Data Quality Means to Data Con-sumers, in: Journal of Management Information Systems 12 (1996) 4, S. 5-34.

Wende, K.; Otto, B.: A Contingency Approach to Data Governance, in: Robert M. et al. (Hrsg.): Proceedings of the 12th International Conference on Informa-tion Quality (ICIQ-07), Cambridge 2007, S. 163-176.

Wijnhoven, F.; Boelens, R.; Middel, R.; Louissen, K.: Total Data Quality Man-agement: A Study of Bridging Rigor and Relevance, in: Österle H. et al. (Hrsg.): Proceedings of the 15th European Conference on Information Sys-tems (ECIS), St. Gallen 2007.

11 Einsatzmöglichkeiten serviceorientierter Architekturen in der Informationslogistik

Barbara Dinter


1 Einleitung ....................................................................................... 221 2 Das Konzept der serviceorientierten Architektur ........................... 222 3 Einsatz serviceorientierter Architekturen in der Informations-

logistik ............................................................................................ 227 4 Anwendungsszenarien serviceorientierter Architekturen in der

Informationslogistik ....................................................................... 233 5 Zusammenfassung .......................................................................... 238

Literatur .......................................................................................... 239

1 Einleitung

Zur Umsetzung der in Kap. 3 skizzierten Ansprüche an eine erfolgreiche Informationslogistik (IL), insbesondere im unternehmensweiten Umfeld, werden innovative Architekturkonzepte benötigt. Gleichzeitig beherrschen serviceorientierte Architekturen (SOA) als aktueller Trend die Diskussion um IT-Architekturen. Sie sind auf dem Wege, sich als anerkanntes und Nutzen stiftendes Konzept für Informationssystemarchitekturen in Unter-nehmen zu etablieren. Sowohl unternehmensinterne IT-Abteilungen als auch externe IT-Service-Dienstleister stehen heute vielfach vor der Herausforderung, sich in immer kürzer werdenden Zeitabständen flexibel an Änderungen in der Unterneh-mensstruktur anpassen und neue bzw. geänderte Geschäftsprozesse unters-tützen zu müssen. Neben solchen fachlichen sind auch technische Treiber zu beachten, wie die Notwendigkeit, die zunehmende Komplexität der

222 Barbara Dinter

Anwendungslandschaft zu reduzieren. Hierbei sollen serviceorientierte Architekturen Unterstützung leisten.

Auch werden die IL-Organisationseinheiten angesichts der zunehmen-den Bedeutung von SOA im operativen Umfeld vor die Notwendigkeit ge-stellt, dieses Paradigma hinsichtlich seines Einsatzpotenzials in dispositi-ven Systemen zu beurteilen und dann SOA ggf. auch zu integrieren. So scheint eine Evaluation lohnenswert, ob die im operativen Kontext immer wieder genannten Nutzenpotenziale auch in der Informationslogistik zum Tragen kommen (wenn SOA in Kombination mit oder anstelle von „tradi-tionellen“ IL-(Architektur)-Konzepten zum Einsatz kommt) bzw. welche Anwendungsmöglichkeiten sich daraus ergeben.

Folglich ist das Spannungsfeld Informationslogistik und serviceorien-tierte Architektur derzeit von hoher Relevanz geprägt, und zwar nicht nur aus Anbietersicht, sondern auch in den Anwenderunternehmen. Wie in Abschn. 4 ausführlicher erläutert wird, lassen sich insbesondere folgende wesentliche Trends in der Informationslogistik mit SOA leichter realisie-ren:

• Beschleunigung der Datenintegration (ermöglicht Real Time Data Warehousing)

• Automatisierung in den Entscheidungen (ermöglicht Active Data Ware-housing)

• Integration von Geschäftsprozessmanagement und Informationslogistik (prozessorientierte Informationslogistik)

Das Kapitel gliedert sich wie folgt: In Abschn. 2 werden die grundle-genden Konzepte, Begriffe und Nutzenpotenziale von serviceorientierten Architekturen vorgestellt. Abschnitt 3 zeigt auf, wie Serviceorientierung in der Informationslogistik gestaltet werden kann und welchen Umsetzungs-status dieses Thema heutzutage in der Praxis hat. Welche Anwendungs-möglichkeiten sich durch SOA in dispositiven Systemen ergeben, wird in Abschn. 4 aufgezeigt. Der Beitrag schließt mit einer Zusammenfassung.

2 Das Konzept der serviceorientierten Architektur

2.1 Begriffsklärung

Serviceorientierung beschreibt ein Design-Paradigma, das die Bereitstel-lung und Nutzung von fachlichen Funktionalitäten als Dienstleistung er-möglicht. Damit stellt das Konzept der serviceorientierten Architekturen weniger eine technische Lösung, sondern vielmehr ein primär aus Busi-

Einsatzmöglichkeiten serviceorientierter Architekturen 223

ness-Sicht getriebenes (Architektur-)Paradigma dar. Hierbei wird die IT-Architektur im Idealzustand nicht mehr aus monolithischen Applikationen, sondern aus standardisierten, entlang der fachlichen Funktionalität ge-schnittenen Komponenten (Services) aufgebaut. Basierend auf den Ge-schäftsprozessen werden grobgranulare Funktionalitäten definiert, die in Form von Services gekapselt werden. Diese Services lassen sich über stan-dardisierte Schnittstellen ansprechen. Damit werden Softwarefunktionali-täten aus dem starren Gerüst einer Applikation herausgelöst und können in verschiedenen Kontexten verwendet werden. Dadurch wird die Ablauf-steuerung aus den Applikationen auf eine übergeordnete Instanz verscho-ben („lose Kopplung“ und „Orchestrierung“ von so genannten Applikati-onsservices zu so genannten Enterprise Services zur flexiblen Unter-stützung von Prozessaktivitäten und Geschäftsprozessen). Gleichzeitig wird das Beziehungsgeflecht zwischen den Applikationen aufgehoben. Die Integration der Funktionalitäten erfolgt nunmehr auf einer eigenständigen Architekturebene, der Integrationsschicht. Damit wird die vollständige Trennung von Geschäftsprozessen und implementierten Applikationen si-chergestellt. Die Prozesslogik, die bisher in den Applikationen gekapselt war, wird neu über einen Service Bus mit entsprechender Prozesssteuerung oder über prozessorientierte Services bereitgestellt, wo sie flexibel an sich ändernde Geschäftsanforderungen angepasst werden kann.

Zur genaueren Differenzierung des Servicebegriffs bietet sich die Veror-tung im Business Engineering Framework (vgl. Kap. 2) an. Wie in (Winter 2008) erläutert, lässt sich das Prinzip der Serviceorientierung auf den Ge-staltungsebenen Software, Integration und Organisation anwenden, um die jeweiligen Strukturen besser änderbar und flexibler nutzbar zu machen. Abbildung 1 zeigt die Einordnung der jeweiligen Funktionsbündel im Bu-siness Engineering Framework:

224 Barbara Dinter

Strategie-ebene

Strategie-ebene

Software-ebene

Software-ebene

Organisations-ebene

Organisations-ebene

Integrations-ebene

Integrations-ebene

Gestalten* der Organisation• Prozesslandkarte/Prozessmodelle• Aufbauorganisation• Informationslandkarte• Prozess-Services

Gestalten* der Strategie• Geschäftsnetzwerkmodelle• Kundenprozessmodelle• Leistungsmodelle• Zielsystem

Gestalten* der Integration• Applikationslandschaft• Fachliche Services• Geschäftsfunktions-/

Informationsobjektmodelle

Infrastruktur-ebene

Infrastruktur-ebene

Infrastruktur-ebene

Gestalten* von Software• Softwarekomponenten/

Software-Services• Datenmodelle

Gestalten* der IT-Infrastruktur• Plattforminfrastruktur• Netzwerkinfrastruktur

* Gestalten = Prozess der Erst- und Weiterentwicklung

1

2

3

Abb. 1. Gestaltungsebenen der Serviceorientierung im Business Engineering Framework (Winter 2008)

In (Aier u. Winter 2008; Winter 2008) werden die Gestaltungsebenen und -ziele hinsichtlich der verschiedenen Services folgendermaßen charak-terisiert:

Die Services der Software-Architektur (Software-Services) sind tech-nisch implementierte Funktionalitäten, deren Gestaltung sich oft an den Datenobjekten orientiert, die sie erzeugen, verändern oder konsumieren. Gestaltungsziele der Software-Services sind Interoperabilität und Wieder-verwendung. Software-Services sind die Voraussetzung, um auf der Inte-grationsebene möglichst agile Applikationen bauen zu können (Pfeil 1). Die Services der Integrationsarchitektur (fachliche Services) fassen lose gekoppelte, in sich abgeschlossene fachliche Funktionalitäten zusammen. Ihre Gestaltung orientiert sich an Geschäftsprozessen, an grobgranularen, abgeschlossen fachlichen Funktionalitäten oder an Geschäftsobjekten. Fachliche Services werden mit dem Ziel gestaltet, einerseits die fachlichen Strukturen und die IT-Strukturen aufeinander abzustimmen. Andererseits soll Flexibilität garantiert werden, sodass sich Prozessänderungen auf Softwareebene möglichst leicht umsetzen lassen. Fachliche Services sind gleichzeitig die Voraussetzung, um auf der Organisationsebene Prozessän-derungen möglichst einfach unterstützen zu können (Pfeil 2). Die Services


der Prozessarchitektur (Prozess-Services) fassen inhaltlich abgeschlossene Aktivitäten zusammen, die ein wohl definiertes Ergebnis mit betriebswirt-schaftlichem Wert erzeugen. Prozess-Services sollten so gestaltet werden, dass sie effizient und effektiv sind. Sie bilden die Voraussetzung dafür, Änderungen des Geschäftsmodells einfacher umzusetzen (Pfeil 3).

Diese Differenzierung veranschaulicht, dass das häufig in der Praxis an-zutreffende Verständnis, das Services auf technische Services (meist Web-Services) reduziert, zu kurz greift; nicht zuletzt, da damit eine adäquate Adressierung der jeweiligen Gestaltungsziele verloren geht.

2.2 Nutzenpotenziale serviceorientierter Architekturen

Vom serviceorientierten Paradigma werden vielfältige und weitreichende Nutzenpotenziale erwartet, insbesondere solche, die in bestehenden IT-Architekturen als vordringliche Verbesserungsbedarfe erkannt worden sind. Abbildung 2 spiegelt die am häufigsten genannten Vorteile von SOA wider, sie werden im Anschluss erläutert:

Agilität und

Flexibilität

Kosten-einsparung

Komplexi-tätsre-duktion

Investitions-schutz

Out-sourcing-Potenzial

Evolutionäre Erweiter-barkeit

Abb. 2. Nutzenpotenziale serviceorientierter Architekturen

Wiederverwendung: Viele in Software realisierte Geschäftsfunktionalitä-ten werden in zahlreichen Geschäftsprozessen verwendet. Mit Hilfe einer SOA können diese Softwarefunktionalitäten über standardisierte Schnitt-stellen von verschiedenen Prozessen genutzt werden, Mehrfachentwick-lungen werden vermieden. Voraussetzung ist dabei eine geeignete Granu-larität der Services, hier muss ein Kompromiss zwischen hoher Wiederverwendbarkeit (feine Granularität) und handhabbarer Servicegröße (grobe Granularität) gefunden werden.

226 Barbara Dinter

Komplexität: Durch SOA wird die Steuerung der Geschäftsprozesse von der Umsetzung der Funktionalität entkoppelt. Anders als in herkömmli-chen Applikationen werden die Koordinationsmechanismen in die Integra-tionsebene verlagert und damit von den funktionalen Komponenten ge-trennt. Zusätzlich ermöglicht die Standardisierung von Schnittstellen eine Reduktion der Schnittstellenzahl. Wartbarkeit: In „traditionellen“ Applikationslandschaften müssen Ände-rungen an der fachlichen Funktionalität ggf. mehrfach umgesetzt werden. Entsprechendes Versionsmanagement vorausgesetzt, können im Falle einer SOA mehrere Anwendungen gleichzeitig von Weiterentwicklungen der Services profitieren. Da die Funktionalitäten der Services über Schnittstel-len gekapselt sind, kann darunter Software ausgetauscht werden, ohne dass Anpassungen an den nutzenden Komponenten erforderlich sind. Schnelligkeit: SOA ermöglicht es der IT, schneller auf sich ändernde An-forderungen der Business-Seite zu reagieren. Dabei wird sowohl die Agili-tät (d.h. die effiziente Reaktion auf geplante Änderungen) als auch die Fle-xibilität (die Reaktion auf ungeplante Änderungen) gesteigert (Aier u. Schelp 2008). Kosten: Die Wiederverwendung von Komponenten senkt tendenziell die Entwicklungskosten. SOA geht dabei nicht von der Illusion einer komplet-ten Neuplanung einer Applikationslandschaft aus. Vielmehr können beste-hende Applikationen durch Kapselung ihrer Funktionalität in Services für SOA befähigt werden und so Altanwendungen länger und flexibler als bis-her möglich weiter genutzt werden. Investitionsschutz: Die Sicherstellung des Investitionsschutzes wird durch die Kapselung von Legacy-Applikationen bzw. Zerlegung der aktuellen Applikationslandschaft in fachliche Services, die in die serviceorientierte Architektur eingebunden und sukzessive ersetzt bzw. erneuert werden können, erreicht. Evolutionäre Erweiterbarkeit: Die evolutionäre Erweiterbarkeit service-orientierter Architekturen folgt aus dem modularen Aufbau einer SOA und der losen Kopplung der Services, welche die Ergänzung zusätzlicher Dienste ohne größeren Aufwand ermöglichen. Monolithische und gewach-sene Software lässt sich durch die Integration über eine einheitliche SOA-Infrastruktur ablösen. Outsourcing-Potenziale: Outsourcing-Potenziale lassen sich leichter identifizieren, denn aufgrund der Plattformunabhängigkeit, der weitestge-henden Standardisierung und der losen Kopplung von Services können diese auch von Drittanbietern, z. B. in Form von Web-Services, bezogen werden.

Darüber hinaus werden häufig noch weitere Nutzenpotenziale wie bei-spielsweise eine Verkürzung der Time-to-Market, die Reduktion operati-


ver Risiken und die Förderung von Technik- und Herstellerunabhängigkeit genannt. Diese zusätzlichen Ziele lassen sich jedoch in den allermeisten Fällen auf die vorgenannten generischen Nutzeneffekte des serviceorien-tierten Architekturparadigmas zurückführen.

Für eine ausführliche Diskussion serviceorientierter Architekturen sei auf die einschlägige Literatur verwiesen, wie beispielsweise (Krafzig et al. 2005; Oey et al. 2006; Heutschi 2007; Starke u. Tilkov 2007).

3 Einsatz serviceorientierter Architekturen in der Informationslogistik

Wie eingangs erwähnt, sind in den Unternehmen unterschiedliche Aus-gangssituationen anzutreffen. In vielen Fällen ist oder wird SOA (zumin-dest punktuell) im operativen Bereich eingeführt, so dass die IL-Organisationseinheiten, sei es durch die unternehmensweite IT veranlasst oder aus Eigeninteresse, vor der Frage stehen, ob und wie sie das service-orientierte Paradigma auch im dispositiven Umfeld einsetzen werden. Es gibt aber durchaus auch Fälle, in denen die Informationslogistik eine Vor-reiterrolle spielt und etwa zur Umsetzung bestimmter Anwendungsszena-rien (vgl. Abschn. 4) auf SOA zurückgreift.

Trotz der intensiven Diskussion des serviceorientierten Architekturpara-digmas ist bislang allenfalls unzureichend untersucht, welche Implikatio-nen die Einführung einer SOA für die Informationslogistik hat. Bestehende Arbeiten und Literatur adressieren in der Regel ausgewählte Aspekte, hierbei insbesondere bestimmte Anwendungen. Daher wird im Anschluss zunächst eine Systematisierung vorgenommen, die aufzeigt, wo welche Services in einer IL-Architektur denkbar und sinnvoll sind. Aus ihnen las-sen sich dann die in Abschn. 4 vorgestellten Einsatzmöglichkeiten von SOA in der Informationslogistik ableiten.

3.1 Services in der Informationslogistik

Die Informationslogistik kann sowohl als Service Provider als auch als Service Consumer fungieren. Auch lassen sich Funktionalitäten innerhalb der dispositiven Systeme über Services abbilden. Hierbei hat sich mittler-weile hat ein gewisser Konsens herausgebildet, welche Services man in ei-ner IL-Architektur differenzieren kann, wenngleich Klassifizierungskrite-rien, Terminologie und einzelne Servicetypen sich noch unterscheiden (vgl. Gordon et al. 2006; Besemer 2007; Dittmar 2007; Gassman 2007; Martin u. Nussdorfer 2007).

228 Barbara Dinter

Abbildung 3 zeigt die Anordnung der am häufigsten genannten Service-typen in einer generischen und vereinfachten IL-Systemarchitektur, die sich an der Hub and Spoke-Architektur (vgl. auch Kap. 7) orientiert. Die verschiedenen Servicetypen werden im Folgenden kurz vorgestellt.

Infra

stru

ktur

-Ser

vice

s

Abb. 3. Services in der Informationslogistik-Systemarchitektur

3.1.1 Sourcing (oder Backend) Services

In der Vergangenheit wurden operative Quellsysteme „traditionell“, d.h. via herkömmlicher Datenschnittstellen (sei es mit ETL-Tools oder Eigen-entwicklungen) angebunden. Insbesondere, wenn die operativen Systeme bereits serviceorientiert gestaltet sind, bietet sich an, die entsprechenden Zugriffsmöglichkeiten auch zu nutzen. Dies können sowohl Services sein, die extra für diesen Zugriff geschaffen werden (Extraktionsservices) als auch bereits bestehende Services der operativen Applikationen. Stehen die Services über einen Service Bus zur Verfügung, kann dieser ggf. an die In-tegrationsinfrastruktur für das Data Warehouse angebunden werden, so


dass die einzelnen Transaktionen auf dem Bus mitverfolgt und aktuelle Daten abgegriffen werden können (Schelp 2007).

Im Gegensatz zu den durch Batchverarbeitung verursachten Verzöge-rungen (Latenzen) können auf diese Weise ereignisgesteuert Datenbewirt-schaftung und folglich auch die Datenbereitstellung beschleunigt werden, was insbesondere bei zeitkritischen Vorgängen den entscheidenden Faktor ausmachen kann (vgl. auch Abschn. 4.1). Zudem lassen sich historisierte Daten aus dem Data Warehouse mit aktuellen („Real Time“- bzw. „Right Time“-) Daten aus den operativen Systemen transparent integrieren, ohne dass der Endanwender den Zugriff auf verschiedene Quellsysteme realisie-ren würde. Schließlich kann der SOA-Ansatz unter Umständen die Anbin-dung weitere Datenquellen ermöglichen, wenn beispielsweise unstruktu-rierte Daten integriert werden sollen. In der Praxis sind noch technische Restriktionen (wie die Verfügbarkeit der beteiligten Systeme und die Last auf der Businfrastruktur) und logische Herausforderungen (wie die gleich-zeitige Verfügbarkeit aller für die Weiterverarbeitung in den ETL-Prozessen benötigten Daten aus verschiedenen Quellsystemen) zu meistern sowie ökonomische Fragen wie die Kosten, die mit der Protokollierung al-ler Daten verbunden sind (Schelp 2007).

3.1.2 Transformations-Services

Prinzipiell könnte auch die Transformationsfunktionalität innerhalb der Datenbewirtschaftungsprozesse, die üblicherweise einen großen Anteil an Entwicklungskapazitäten bindet, über Services realisiert werden. Ähnlich wie die Funktionsbausteine (Templates) der ETL-Tools stellen die Servi-ces dann Funktionalitäten wie Aggregationen, Filterungen, Umschlüsse-lungen, Formatkonvertierungen oder Joins zur Verfügung. Eine solche komplette Substituierung ist in der Praxis noch kaum anzutreffen, wenn-gleich die führenden ETL-Hersteller zunehmend Web Service-Schnittstel-len anbieten, mit denen Transformationsfunktionen als Web Services zur Verfügung gestellt werden können. In (Wu et al. 2007) wird aufgezeigt, wie ETL-Prozesse durch Services ersetzt werden können. (Gordon et al. 2006) illustriert an einem Beispiel einen möglichen Mehrwert einer sol-chen Vorgehensweise: Fehlen in der Datenbewirtschaftung zunächst Da-tensätze aus einer Quelle (ein häufiges Problem in der Praxis), findet die Verarbeitung zunächst mit einer Art Platzhalter statt und eine entsprechen-de Notifikation wird an das „säumige“ Quellsystem geschickt, das seiner-seits die fehlenden Daten via Services „nachliefert“, sobald sie bereitste-hen.

230 Barbara Dinter

3.1.3 Analytische (oder Frontend) Services

Neben den Sourcing-Services haben die analytischen Services (auch Front-end Services genannt) derzeit die höchste Praxisrelevanz, nicht zuletzt da sie einen wesentlichen Enabler für die so genannte Operationalisierung der BI (bzw. der Informationslogistik) darstellen (vgl. Abschn. 4.2). Via analy-tischer Services können die Produkte der Informationslogistik (oder Teile davon, vgl. auch Abschn. 4 in Kap. 12 und Abschn. 2.4 in Kap. 4) zur Nutzung bereitgestellt werden. Einen Überblick über analytische Services mit Anwendungsbeispielen findet sich u. a. in (Martin 2006; Martin u. Nussdorfer 2007), in denen die Autoren folgende Arten von Services un-terscheiden:

• Kennzahlen • Berichtsservices • Abfrageservices (Ad hoc und OLAP) • Analyseservices (Datenvisualisierung, Data Mining, statistische Werk-

zeuge) • Planung und Simulation • Dashboard-Services (Präsentationssservice zur Veröffentlichung eines

Scorecard-Modells) • Alerting- und Broadcasting-Services • interaktive Analytik (Datenexplorationsumgebung).

Die ebenfalls genannten Ausprägungen Datenintegration und Echtzeit-Analytik adressieren die in Abschn. 4 genannten Anwendungsszenarien. Beispiele für analytische Services könnten etwa Scorings, Kundenwert-segmentierung oder Bonitätsrating sein.

Zahlreiche BI Tools können zumindest weniger komplexe Produkte der Informationslogistik (Kennzahlen, Reports, …), wie sie oben genannt wurden, in der Regel als Web Services zur Verfügung stellen bzw. in Por-tale integrieren. Umgekehrt ermöglichen bereits manche Werkzeuge, dass auf XML-Daten anderer Services zugegriffen und die Daten beispielsweise in einen Report eingearbeitet werden können.

Die Rückführung der Analyseergebnisse in die operativen Systeme lässt das Data Warehouse innerhalb einer SOA aus Sicht der (operativen) Servi-ces als weiteren operativen Service in Erscheinung treten. Hier ist jeweils zu prüfen, ob die verwendeten Systeme einen solchen Closed Loop über-haupt leisten können (ob sie beispielsweise Variantenbildung bei Ände-rungen unterstützen etc.). Zugleich müssen den operativen Repositories die notwendigen Metadaten zur Verfügung gestellt werden, um die analyti-schen Services in gleicher Form in die operative Servicelandschaft einbin-


den zu können, wie es bei den operativen Services der Fall ist (Schelp 2007).

3.1.4 Infrastruktur-Services

Ergänzend zu den Services, die entlang des Datenflusses von den operati-ven Quellen hin zu den Informationskonsumenten anzusiedeln sind, gibt es Querschnittsaufgaben, die ebenfalls mit Hilfe von Services umgesetzt wer-den können. Sie betreffen im Wesentlichen die Infrastrukturthemen, wie sie bereits in Kap. 3, Abschn. 3.1.1 eingeführt wurden, und hierbei insbe-sondere Metadaten- und Stammdatenmanagement, Datenqualitätsmana-gement sowie Datenschutz und Datensicherheit. In jedem dieser Themen-felder ist ein breites Spektrum an Services denkbar, sei es die Generierung von technischen Metadaten oder die Verknüpfung fachlicher und techni-scher Metadaten, die Durchführung von Plausibilitätschecks oder die Un-terstützung des Datenqualitätsreportings durch Messung von Datenquali-tätskennziffern oder Authentifizierungsservices. Letztere Services sind per se anwendungsneutral und damit auch nicht IL-spezifisch, so dass die (un-ternehmens- oder geschäftsbereichsweite) Wiederverwendungsquote eines solchen (generischen) Authentifizierungsservices vergleichsweise hoch sein dürfte. Dies illustriert die Realisierung eines wesentlichen Nutzenpo-tenzials des serviceorientierten Architektur-Paradigmas.

3.1.5 Umsetzung

Welche Services dann technisch umgesetzt werden und auch wie, hängt von den jeweiligen unternehmensspezifischen Anforderungen und techni-schen Rahmenbedingungen ab. Denkbar ist beispielsweise, dass die oben genannten Servicetypen über einen Enterprise Service Bus und das zuge-hörige Service Repository mit den operativen Services verbunden werden und damit durch Rückschreiben von Informationen in die operativen Quel-len so genanntes Closed Loop realisiert werden kann.

Angesichts der in Abschn. 2.1 getroffenen Unterscheidung von Service-typen sollte man sich bei den oben genannten Services durchaus vor Au-gen halten, um welche Art von Service es sich jeweils handelt. Eine kriti-sche Betrachtung der hier identifizierten Services zeigt, dass die Trennung von fachlichen Services und Software-Services durchaus sinnvoll ist. Bei den Infrastruktur-Services, Sourcing Services und Transformations-Services handelt es sich überwiegend nicht um fachliche Services, die fachliche Funktionalität zur Verfügung stellen würden. Vielmehr handelt es sich bei diesen Services um Softwarekomponenten, die fachlich neutrale Funktionalitäten wie z. B. Autorisierung oder Datenbankzugriffe ermögli-

232 Barbara Dinter

chen. Dagegen stellen die analytischen Services fachliche Funktionalitäten in Form von Enterprise Services zur Verfügung, ebenso wie einzelne Transformations-Services, die z. B. anhand von Geschäftsregeln Bewer-tungen berechnen oder Aggregationen vornehmen.

3.2 State of the Art in der unternehmerischen Praxis

Im Sommer 2007 wurde auf einer Anwenderveranstaltung zum Data Warehousing eine Umfrage zum Thema „Serviceorientierte Architekturen in BI-Systemen“ durchgeführt (Bucher et al. 2007). 67 ausgefüllte Frage-bögen gingen in die Auswertung ein. Abbildung 4 verdeutlicht, dass bei den befragten Unternehmen signifikante Bestrebungen bestehen, Services in die BI-Systeme (Informationslogistik) zu integrieren. Organisatorisch wird in zunehmendem Maße gezielt Know How zur Einführung von SOA in BI-Systemen aufgebaut. Dieses Know How soll in dedizierten Projekten zur Einführung von SOA in BI-Systemen verwendet werden und im Rah-men anstehender BI-Projekte zur (zunächst) punktuellen Einführung von SOA beitragen. Zukünftig soll das Service-Angebot in den Bereichen der Frontend Services (analytische Services), der Infrastruktur-Services und der Backend Services (in Abschn. 3.1 als Sourcing Services bezeichnet) verstärkt ausgebaut werden. Die einzelnen Servicetypen werden vergleich-sweise ähnlich in ihrer Relevanz bewertet (Bucher et al. 2007). Auch künf-tig sind in der Gewichtung keine Verschiebungen zu erwarten.

h z

Projekte & Service-Definition Es wird Know How zur Einführung von SOA in BI-Systemen aufgebaut 1,45 2,32

Es gibt dedizierte Projekte zur Einführung von SOA in BI-Systemen 1,20 2,03

Im Rahmen anstehender BI-Projekte wird SOA (punktuell) eingeführt 1,40 2,31

Es wird zwischen fachlichen und technischen Services unterschieden 1,81 2,55

In welchen Bereichen Ihrer BI-Systeme sind Services definiert? Frontend Services 1,55 2,73

Infrastruktur Services 1,71 2,76

Backend Services 1,71 2,64

Ø 1,55 Ø 2,48

niedrig hoch

heute zukünftig

0 1 2 3 4

Abb. 4. Umsetzungsgrad von BI und SOA (Bucher et al. 2007)


Die Umfrage zeigte, dass sich Unternehmen (zumindest zukünftig) mit der Einführung von Services im BI-Umfeld auseinandersetzen. Ähnliche Erkenntnisse lieferte eine Studie von Ventana Research im Oktober 2006. Demnach hielten mehr als 81% der Befragten SOA für BI für wichtig (Ventana Research 2006; Besemer 2007). Knapp 50% der Studienteilneh-mer in den Fachbereichen meinten, dass BI-Services Informationen breiter verfügbar machen würden und dass die Fähigkeit des Business verbessert würde, schneller auf Veränderungen zu reagieren. Umgekehrt vertraten auf IT-Seite ca. 66 % der Befragten die Auffassung, dass BI-Services der IT helfen könnten, die Bedürfnisse des Business besser zu verstehen, während weitere 33% v. a. die leichtere Integration und die niedrigeren Lifecycle Management-Kosten als wesentliche Vorteile betrachten.

Auch in dieser Studie wurden die Servicetypen Frontend und Backend Services (letztere beinhalten dort auch die Transformations- und Infra-struktur-Services) in etwa gleich gewichtet. Bei beiden Servicetypen plan-ten mehr als die Hälfte der befragten Unternehmen eine baldige Umset-zung (Ventana Research 2006; Besemer 2007). Mehrheitlich hielten die Studienteilnehmer den Aufbau von Know How für die vordringlichste Aufgaben (53%), gefolgt von der Überprüfung der BI-Hersteller hinsich-tlich ihrer SOA-Fähigkeiten (49%) und der Identifikation der IT-Ressourcen, die für Migration und Betrieb einer SOA-Umgebung notwen-dig wären (48%). Nur ein Drittel der Unternehmen traut ihrer internen IT das notwendige Know How zu, BI-Services zu implementieren (Everett 2006; Ventana Research 2006).

4 Anwendungsszenarien serviceorientierter Architekturen in der Informationslogistik

Als wesentliche Treiber für die Einführung von SOA in der Informations-logistik werden immer wieder die beiden Anwendungsgebiete Real Time / Active Data Warehousing bzw. Operationalisierung der Informationslogis-tik ins Feld geführt. Diese und weitere Anwendungsszenarien werden im Folgenden kurz vorgestellt.

4.1 Real Time Data Warehousing und Active Data Warehousing

Die Agilität eines Unternehmens und die Nutzung des Faktors Zeit können als wesentliche Beiträge zur Sicherung der Wettbewerbsfähigkeit eines Unternehmens angesehen werden. Der Bedarf nach Beschleunigung von

234 Barbara Dinter

Entscheidungsprozessen trägt der Tatsache Rechnung, dass Maßnahmen umso wirksamer und wertvoller sind, je früher sie ergriffen werden. Wie bereits erwähnt, trägt SOA zur schnelleren Datenbereitstellung für Ent-scheidungsprozesse bei. Somit ist dieser Architekturansatz ein wesentli-cher Enabler für das so genannte Real Time Data Warehousing. Auch wenn im Folgenden der Begriff „Real Time“ verwendet wird, so sei darauf hingewiesen, dass in den meisten Fällen der Ausdruck „Right Time“ tref-fender wäre, denn er bezeichnet eine für eine bestimmte Situation ange-messene Geschwindigkeit (in diesem Fall: der Informationsbereitstellung). In (Gassman 2007) illustrieren Anwendungsbeispiele den kontextabhängi-gen unterschiedlichen Zeitbedarf: Im Wertpapierhandel werden Informa-tionen sofort benötigt, für Analysen im Call Center im Sekundenbereich, für Auftragsbestätigungen im Minutenbereich, etc. Für (Nahezu-)Echtzeit gibt es (noch) vergleichsweise wenige Anwendungsanfälle, insbesondere angesichts technischer Herausforderungen und vergleichsweise hoher Kos-ten. Studien wie (Steria Mummert Consulting 2006) bestätigen diese Beo-bachtung aus der Praxis.

Zur Realisierung von Real Time Data Warehousing wird in der Regel über den Einsatz von EAI (Enterprise Application Integration)-Werkzeugen diskutiert, die dann in Ergänzung zu oder anstelle von ETL-Tools zur Datenbewirtschaftung (insbesondere bei Lösungen mit einem Operational Data Store) Verwendung finden. Eine Referenzarchitektur für ein Real Time Data Warehouse findet sich in Abschn. 3.2.2 des Kap. 7. SOA für die Datenbewirtschaftung (im Kontext Real Time) bedeutet auch einen Paradigmenwechsel vom traditionellen Pull-Prinzip (der ETL-Werkzeuge) hin zum Push-Prinzip. Das hat u. a. auch organisatorische Im-plikationen, wenn etwa sich die Verantwortung für die Datenbereitstellung in die Quellsysteme verlagert.

In (Tho Manh et al. 2007) wird mit ZELESSA eine Infrastruktur vorges-tellt, deren BI Real Time-Architektur mit Hilfe von SOA realisiert wird. Neben „traditionellen“ Analysen auf dem Data Warehouse kann über so genannte Event Streams „Real Time Analytics“ stattfinden. Auch in (Ab-rahiem 2007) wird aufgezeigt, wie SOA beitragen kann, ein (Near) Real Time Data Warehouse aufzubauen. Zur Vertiefung zu Real Time Data Warehousing sei verwiesen auf (Schelp 2006; Abrahiem 2007; Tho Manh et al. 2007).

Ebenfalls zur Beschleunigung von Entscheidungsprozessen dient das Konzept des Active Data Warehousing (auch unter Active BI oder Event-driven BI bekannt). Im Gegensatz zum herkömmlichen Data Warehouse werden hier, sobald bestimmte, zuvor definierte Bedingungen erfüllt sind, relevante Personenkreise automatisch durch das analyseorientierte Infor-mationssystem darüber in Kenntnis gesetzt (Push-Prinzip). Alternativ wer-


den automatisch ebenfalls zuvor spezifizierte Aktionen in der Systemum-gebung angestoßen. Ziel ist die teilweise oder vollständige Automatisie-rung von Routineentscheidungen. Die Notwendigkeit der Ereignissteue-rung im Active Warehousing wird wiederum durch SOA in besonderem Maße unterstützt. Für eine Referenzarchitektur sei ergänzend auf Kap. 7, Abschn. 3.2.1 verwiesen.

4.2 Prozessorientierte Informationslogistik

Das Konzept der prozessorientierten Informationslogistik wird in Kap. 6 ausführlich vorgestellt. Auch in Kap. 1 wird unter dem Begriff „Operatio-nal Intelligence“ ausgeführt, wie analytische Informationen in die Ausfüh-rung operativer Geschäftsprozesse integriert werden können und welche Rolle SOA in diesem Kontext spielt. In (Bucher u. Dinter 2008) werden die Nutzenpotenziale einer solchen Verschmelzung erörtert: Sie reichen von Beschleunigung der Prozessausführung, qualitativer Verbesserung der Prozessleistung über höhere Kosteneffizienz bis hin zu Steigerung der Transparenz und Erhöhung von Flexibilität und Agilität.

Ein einfacher Beispielprozess (ein Kundenanruf im Call Center) soll dies illustrieren (vgl. Abb. 5). Der Agent benötigt für ein optimales Kun-denangebot analytische Informationen, z. B. den Kundenwert (setzt sich z. B. zusammen aus Mahnstufe, durchschnittlichem Rechnungsbetrag der letzten 12 Monate etc.) oder einen Produktvorschlag, der optimal zum Kundenprofil passt. Analytische Services ermöglichen hier eine transpa-rente und zeitnahe Informationsbereitstellung und können ggf. mit den restlichen operativen Services dieses Prozesses „verzahnt“ werden. Die Abläufe werden dokumentiert und sauber strukturiert.

Kunde ruft inCall-Center an

Anrufgrundidentifizieren

Agent unterbreitet optimales Angebot

Nimmt Kunde Angebot an

Auftrags-bearbeitung

nein

Agent hält Ergebnis fest

... ja

Passendes Produkt ermitteln Regeln anwenden Angebot erstellenKundenwert

ermitteln

Service „Ermittle

Kundenwert“

Service „Ermittle

passendes Produkt“

Abb. 5. Beispiel eines Geschäftsprozesses mit Nutzung von analytischen Services

236 Barbara Dinter

Weitere Fallbeispiele für prozessorientierte Informationslogistik finden sich in (Bucher u. Dinter 2008). (Raden 2006) enthält ebenfalls eine Über-sicht.

Die hohe Bedeutung von analytischen Informationen in Geschäftspro-zessen wird durch Studien bestätigt, wie beispielsweise in (Steria Mum-mert Consulting 2006), der zufolge mehr als 70% der Unternehmen das BI-System bereits für das operative Tagesgeschäft nutzen.

Eine weitere Konvergenz von Geschäftsprozessmanagent und Business Intelligence ist im Kontext Corporate Performance Management (CPM) zu beobachten. (Martin u. Nussdorfer 2007) gehen ausführlich auf die Bedeu-tung des Zusammenwachsens von BI und Geschäftsprozessen ein. Mit CPM können Unternehmensziele und Geschäftsprozesse kontinuierlich aufeinander abgestimmt und konsistent gehalten werden. Entsprechend müssen Prozesse geplant, überwacht und gesteuert werden. Laut (Martin u. Nussdorfer 2007) wird dieses CPM mit einer serviceorientierten Architek-tur realisiert. Auch (Dinter u. Bucher 2006) betrachten CPM als einen um-fassenden Ansatz zur Steuerung der Wertschöpfung von Unternehmen. Folglich umfasst CPM neben der strategisch-taktischen Komponente auch eine operative Komponente, durch die die Verbindung hin zu den Ge-schäftsprozessen sowie deren Management und Messung geschaffen wird. Als Business Activity Monitoring (BAM) wird dabei die Echtzeit-Überwachung und Analyse kritischer Prozesskennzahlen bezeichnet, wo-durch eine Entscheidungsunterstützung für das operative Management er-möglicht wird. Ziel ist die Verkürzung der Durchlaufzeiten sowie die Ver-besserung der Effektivität von Geschäftsprozessen. Insbesondere, wenn die zu Grunde liegenden Geschäftsprozesse bereits in einer SOA eingebettet sind, bietet sich an, die für die Analysen relevanten Prozesskennzahlen auch über Services bereitzustellen (Dinter u. Bucher 2006).

4.3 Standardisierung der Nutzung analytischer Informationen

In Abschn. 3.1.3 wurde ausgeführt, welche analytischen Services eine In-formationslogistik-Infrastruktur in ihrer Rolle als Service Provider zur Verfügung stellen kann. Neben den bereits genannten Anwendungsmög-lichkeiten unterstützt die Bereitstellung analytischer Informationen via Services eine Homogenisierung der Informationsversorgung, wie Abb. 6 veranschaulicht.


Zugriff via standardisierter Services

Ausgangssituation

Domäne 1

DWH

Domäne 1

DWH

Domäne 3

DWH

Domäne 3

DWH

Domäne 2

DWH

Domäne 2

DWH

Data Mining PlanungDashboardsReporting

DWH DWHDWH

ServiceData Mining

ServicePlanung

ServiceDashboards

ServiceReporting

Abb. 6. Standardisierter Zugriff auf analytische Informationen durch Services

Historisch gewachsen oder durch Veränderungen in der Unternehmens-struktur bedingt (etwa bei Mergers and Acquisitions) liegen in vielen Un-ternehmen heterogene dispositive Systeme vor. Folglich werden Anwender mit unterschiedlichen Zugangsmöglichkeiten (heterogene Schnittstellen und/oder Werkzeuge) konfrontiert und sind oft nicht in der Lage, zu loka-lisieren, wo sich die für sie relevanten Informationen befinden (bzw. ob sie überhaupt vorliegen). SOA kann hier helfen, für die Informationskonsu-menten einheitliche Zugriffe via Services bereitzustellen. Standardisierte Zugriffe und Transparenz über die zu Grunde liegenden Informationsquel-len helfen beim Auffinden benötigter Informationen und steigern die Nut-zerakzeptanz.

Schliesslich wird damit auch dem Trend Rechnung getragen, analyti-sche Informationen nicht nur einem breiteren Anwenderkreis zugänglich zu machen, sondern diese mit innovativen Mitteln und über unterschiedli-che Kanälen zugreifbar zu machen. Die analytischen Informationen sollen Teil der täglichen Arbeit werden und demzufolge integriert in Unterneh-

238 Barbara Dinter

mensportale, Suchmasken oder über verschiedene Medien zugreifbar sein. Die Bereitstellung via Services unterstützt ein solch breites Spektrum bes-ser als traditionelle Ansätze. Analytische Services tragen damit bei zum Paradigmenwechsel vom Bring- zum Holprinzip hinsichtlich der Informa-tionsversorgung der Unternehmensbereiche.

Weitergehende Informationen zu einer möglichen technischen Umset-zung finden sich u. a. in (Hulford 2006).

5 Zusammenfassung

Im Beitrag wurde nach einer Einführung in das Konzept serviceorientierter Architekturen gezeigt, wo und wie dieses Paradigma in der Informations-logistik eingesetzt werden kann. Mit der Übertragung des SOA-Ansatzes in die Informationslogistik kommt man der Vision eines geschlossenen Handlungskreislaufes zwischen operativen und dispositiven Systemen ei-nen entscheidenden Schritt näher. Wie in Abschn. 4 ausgeführt wurde, fungiert SOA zudem als Enabler für eine Beschleunigung (und ggf. Auto-matisierung) von Entscheidungsprozessen, was den Unternehmen nachhal-tige Wettbewerbsvorteile verschaffen kann.

Zunächst unterscheiden sich die Methoden zur Gestaltung der Services und die technischen Realisierungsmöglichkeiten für SOA allgemein und für SOA in der Informationslogistik nicht allzu sehr. Dennoch sollten im-mer die Spezifika der dispositiven Systeme berücksichtigt werden. In (Schelp 2007) wurde aufgezeigt, dass die vorrangigen Gestaltungsziele in operativen Systemen (im Wesentlichen Agilität) sich unterscheiden von denen in der Informationslogistik, die u. a. die zeitliche Stabilität in der Vordergrund rückt.

Bei der Einführung von SOA stehen die Domänen Operativsysteme und Informationslogistik vor ähnlichen Herausforderungen. Diese sind fachli-cher Natur – hier insbesondere die Schaffung einheitlicher Terminologien, einer notwendigen Voraussetzung für bereichsübergreifende, idealerweise unternehmensweite (Wieder)Verwendung von Services – aber auch techni-scher und organisatorischer Natur. Noch sind SOA-Projekte, insbesondere im Kontext der Informationslogistik, von einer gewissen Unsicherheit ge-prägt. Neben fehlendem Know How in den Unternehmen gibt es auch nur wenige etablierte Best Practices in methodischer (und teilweise auch in technischer) Hinsicht. Der Schritt vom Hypethema hin zu einem Konzept mit tragfähigen und umfassenden Lösungen ist noch nicht zur Gänze voll-zogen.


Folglich bietet sich neben einem gezielten Know How-Aufbau ein itera-tiver Ansatz zur Umsetzung an. Machbarkeitsstudien und Pilotierung wer-den dringend empfohlen, bevor Erfahrungen idealerweise in Projekten mit übersichtlichem und handhabbarem Scope gesammelt werden. Dabei ist insbesondere darauf zu achten, konsequent in allen Projektphasen die Fachbereiche einzubeziehen. Der Aufbau einer serviceorientierten Archi-tektur geht einher mit dem Aufbau passender Organisationsstrukturen. Auf Serviceebene sind Verantwortlichkeiten eindeutig festzulegen, eine klare und gelebte SOA-Governance (Keller 2007; Schelp u. Stutz 2007) stellt einen kritischen Erfolgsfaktor dar. Eine ausführliche Übersicht über Er-folgsfaktoren serviceorientierter Architekturen findet sich in (Durst u. Daum 2007). Hier wird auch die Relevanz der Verankerung von SOA-Initiativen in der Unternehmens- und IT-Strategie betont, die einhergehen muss mit einer entsprechenden Unterstützung durch die Unternehmenslei-tung. Zudem erfordern SOA-Projekte ein starkes Business/IT-Alignment: Gerade wenn solche Initiativen aus der IT heraus gestartet werden, besteht sonst die Gefahr einer zu technischen Perspektive.

Literatur

Abrahiem, R.: A new generation of middleware solutions for a near-real-time data warehousing architecture, in: Proceedings of the 2007 IEEE International Conference on Electro/Information Technology, Chicago 2007.

Aier, S.; Schelp, J.: EAI und SOA - Was bleibt nach dem Hype?, in: Bichler M. et al. (Hrsg.): Proceedings der Multikonferenz Wirtschaftsinformatik 2008 (MKWI 2008), GITO-Verlag, München 2008, S. 1469-1480.

Aier, S.; Winter, R.: Serviceorientierung - Ein Architekturthema, http://www.isis-specials.de/profile_pdf/3u005_ed_soa0108.pdf,

Besemer, D.: Getting Started Now on SOA for BI, in: DM Review (2007) May 2007, S. 26-27.

Bucher, T.; Dinter, B.: Anwendungsfälle der Nutzung analytischer Informationen im operativen Kontext, in: Bichler M. et al. (Hrsg.): Proceedings der Multik-onferenz Wirtschaftsinformatik 2008 (MKWI 2008), GITO-Verlag, München 2008, S. 41-42.

Bucher, T.; Dinter, B.; Lahrmann, G.; Schmaltz, M.; Stroh, F.: Ergebnisdokumen-tation 7. CC EIW Workshop, 2007.

Dinter, B.; Bucher, T.: Business Performance Management, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 23-50.

240 Barbara Dinter

Dittmar, C.: Integration von Real Time Business Intelligence in eine SOA – Auf dem Weg zum Active Business Intelligence, in: Gluchowski P. et al. (Hrsg.): Schlaglichter der Wirtschaftsinformatik, guc, Chemnitz 2007, S. 129-142.

Durst, M.; Daum, M.: Erfolgsfaktoren serviceorientierter Architekturen, in: HMD - Praxis der Wirtschaftsinformatik 253 (2007), S. 18-27.

Everett, D.: Service-Oriented Architecture for Business Intelligence Isn't Well Understood, http://www.dmreview.com/news/1072118-1.html, 29.02.2008.

Gassman, B.: Data Integration for Strategic Business Intelligence and Beyond, Gartner, Stamford 2007.

Gordon, S.; Grigg, R.; Horne, M.; Thurman, S.: Service-Oriented Business Intelli-gence, in: The Architecture Journal (2006) 1.

Heutschi, R.: Serviceorientierte Architektur: Architekturprinzipien und Um-setzung in die Praxis, Springer-Verlag, Berlin, Heidelberg 2007.

Hulford, P.: Why SOA is Important to Your BI Solutions, in: DM Review (2006) 4, S. 34-36.

Keller, W.: SOA-Governance, in: Starke G. et al. (Hrsg.): SOA Expertenwissen, dpunkt, Heidelberg 2007, S. 289-308.

Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA - Service-Oriented Architec-ture Best Practices, Pearson, Upper Saddle River 2005.

Martin, W.: Analytics meets Enterprise SOA, 2006. Martin, W.; Nussdorfer, R.: CPM – Corporate Performance Management, Annecy

2007. Oey, K. J.; Wagner, H.; Rehbach, S.; Bachmann, A.: Mehr als alter Wein in neuen

Schläuchen: Eine einführende Darstellung des Konzepts der serviceorien-tierten Architekturen, in: Aier S. et al. (Hrsg.): Unternehmensarchitekturen und Systemintegration, 2. Aufl., Gito, Berlin 2006, S. 197–220.

Raden, N.: An Analytics Manifesto, 2006. Schelp, J.: Real-Time Warehousing und EAI, in: Chamoni P. et al. (Hrsg.): Analy-

tische Informationssysteme - Business Intelligence-Technologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 425-438.

Schelp, J.: Ansatzpunkte zur Übertragung Serviceorientierter Konzepte auf das Data Warehousing, in: Gluchowski P. et al. (Hrsg.): Schlaglichter der Wirtschaftsinformatik - Festschrift zum 60. Geburtstag von Roland Gabriel, guc, Chemnitz 2007, S. 143-156.

Schelp, J.; Stutz, M.: SOA Governance, in: HMD - Praxis der Wirtschaftsinfor-matik 253 (2007), S. 66-73.

Starke, G.; Tilkov, S. (Hrsg.): SOA-Expertenwissen - Methoden, Konzepte und Praxis serviceorientierter Architekturen, Heidelberg 2007.

Steria Mummert Consulting: Business Intelligence-Studie 2006 - Wie gut sind die BI-Lösungen der Unternehmen im deutschsprachigen Raum?, Steria Mum-mert Consulting AG, Düsseldorf 2006.

Tho Manh, N.; Schiefer, J.; Min Tjoa, A.: ZELESSA: an enabler for real-time sensing, analysing and acting on continuous event streams, in: International Journal of Business Intelligence and Data Mining 2 (2007) 1, S. 105-141.

Ventana Research: Service-Oriented Architecture for Business Intelligence. Trends, Needs and Practices, 2006.


Winter, R.: SOA braucht eine klare Definition, in: Computerwoche 34 (2008) 3, S. 20.

Wu, L.; Barash, G.; Bartolini, C.: A Service-oriented Architecture for Business In-telligence, in: Proceedings of the IEEE International Conference on Service-Oriented Computing and Applications, Newport Beach, CA 2007, S. 279-285.

12 Methode zur Gestaltung einer Leistungs-verrechnung für DWH Competence Center

Mario Klesse


1 Problemstellung und Herausforderungen ....................................... 243 2 Ziele einer Leistungsverrechnung .................................................. 245 3 Elemente einer Leistungsverrechnung ............................................ 246 4 Information als Produkt und Informationsproduktion .................... 247 5 Vorgehensmodell der Methode ...................................................... 257 6 Zusammenfassung und Ausblick .................................................... 269

Literatur .......................................................................................... 271

1 Problemstellung und Herausforderungen

Innerbetriebliche Informationslogistik wird häufig durch Data Warehou-sing-Konzepte realisiert (vgl. Kap. 3). Data Warehousing basiert auf einer weitgehend zentral gemanagten Integrationsinfrastruktur, die entwickelt und betrieben werden muss. In der Praxis wird diese Aufgabe häufig von innerbetrieblichen DWH Competence Centern (DWH-CC) wahrgenom-men (vgl. Kap. 5). Obwohl Data Warehousing in der Unternehmenspraxis mittlerweile einen ähnlich hohen Reifegrad erreicht, wie die operative Applikationslandschaft und deren Betreuung (Chamoni et al. 2004), be-steht das Problem, dass für DWH-CCs serviceorientierte Konzepte, wie bspw. in der ITIL (OCG 2001) beschrieben, nicht vorhanden sind. Wäh-rend in der IT-Unterstützung operativer Prozesse Services definiert, ihre Kosten ermittelt und diese den Fachabteilungen (Leistungsabnehmern) in Rechnung gestellt werden (z. B. OCG 2001; Scheeg 2005), vermag auch heute noch kaum ein DWH-Leistungserbringer zu bestimmen, was die von

244 Mario Klesse

ihm angebotenen Informationsprodukte kosten und in welcher Qualität sie geliefert werden (Chamoni et al. 2004, S. 44f).

Dieser Rückstand ist auf einige besondere konzeptionelle Schwierig-keiten bei der Entwicklung einer Leistungsverrechnung für das Data Ware-housing zurückzuführen. Um Leistungen zu verrechnen, müssen Produkte definiert und Preise für diese ermittelt werden. Allein bei diesen Kernauf-gaben bestehen zwei wesentliche Unterschiede zwischen operativer IT und der IT-Unterstützung von Entscheidungsprozessen: Zum Ersten unter-scheidet sich das „Produkt“ des Data Warehousing erheblich von denen der operativen Welt. Während die operative Anwendungslandschaft in der Regel repetitive Prozesse unterstützt und die dazu bereitzustellenden Funk-tionen im Vordergrund stehen, zentriert sich die dispositive Applikati-onslandschaft im Data Warehousing um Informationen, die in Ent-scheidungsprozessen benötigt werden. Zum Zweiten fällt es schwer, die Kosten von Informationen in ihrem mehrstufigen Produktionsprozess ent-lang der DWH-Architektur zu bestimmen, nicht zu sprechen von der äu-ßerst problematischen Nutzenbestimmung von Informationen (Rehberg 1973, S. 98ff. und 113ff.). Hinzu kommen die Probleme, die daraus resul-tieren, dass ein Grossteil des Data Warehousing auf gemeinsam genutzter Infrastruktur basiert (vgl. Kap. 3). Hierzu zählen nicht nur technische Platt-formen, sondern auch Teile der Software, der Datenbestände und nicht zu-letzt die Leistungen des DWH-CC. Dies führt unvermeidlich zu hohen, meist fixen Gemeinkosten, die sich in der Regel einer streng verur-sachungsgerechten Zuordnung zu Leistungsabnehmern entziehen. Gleiches gilt für alle Arten von Investitionen (z. B. Entwicklung, Plattformausbau etc.) in die weitgehend gemeinsam genutzte DWH-Landschaft. Hier resul-tieren aus der Gemeinkostenproblematik mitunter sogar Investitionsstaus, da Erweiterungen und Optimierungen der Infrastruktur keinem Kunden so recht zuzuordnen sind (Jung u. Winter 2001).

Im Folgenden wird eine Methode (Gutzwiller 1994) vorgestellt, die es DWH-CCs erlaubt, ihre Leistungen zu strukturieren, in Produkte zu bün-deln und in verständlicher Form abzurechnen. Vorraussetzungen für den Einsatz sind neben der Organisation als DWH-CC ein mittlerer bis hoher Reifegrad des Data Warehousing, d.h. die organisatorischen Prozesse im DWH-CC sollten weitgehend definiert sein und das DWH-CC sollte eine weitgehende Eigenverantwortung für seine Kosten haben. In vielen Groß-unternehmen sind diese Voraussetzungen heute gegeben (Klesse 2007, S. 46-52).

Zunächst werden dazu die Ziele und die wesentlichen Bestandteile einer Leistungsverrechnung dargestellt. Anschließend werden mit dem Informa-tionsprodukt und dem Informationsproduktionsmodell zwei wesentliche konzeptionelle Voraussetzungen vorgestellt. Danach wird das Vorgehens-

Leistungsverrechnung für DWH Competence Center 245

modell der entwickelten Methode skizziert. Es umfasst die wesentlichen Schritte, die zur Gestaltung einer DWH-Leistungsverrechnung nötig sind. Die vollständige Methode ist in (Klesse 2007, S. 219-383) dokumentiert. Der Beitrag schließt mit einer Zusammenfassung und einem Ausblick auf Weiterentwicklungsmöglichkeiten.

2 Ziele einer Leistungsverrechnung

Leistungsverrechnung ist kein Selbstzweck, sondern hat immer mehrere Ziele, die allgemein der Wirtschaftlichkeit dienen sollen. Je nachdem, wie die Prioritäten gesetzt werden, ist eine Leistungsverrechnung auch unter-schiedlich auszugestalten (Marzinzik 1998, S. 68). Eine Leistungsverrech-nung folgt jedoch immer drei Primärzielen (Gschwend 1986, S. 71):

Kostenrechnerisches Ziel: Im Mittelpunkt des kostenrechnerischen Ziels steht die objektive und zweckneutrale Wiedergabe des Werts der trans-ferierten Leistung (Gschwend 1986, S. 78-80). Dies ist bspw. von Be-deutung, um Budgets zu planen und zu kontrollieren, um unterneh-merische Entscheidungen zu fundieren oder um Marktleistungen zu kalkulieren.

Lenkungsziel: Durch die Steuerungswirkung von Verrechnungspreisen sollen dezentrale Entscheidungen derart koordiniert werden, dass sich auf Gesamtunternehmensebene optimale Entscheidungen ergeben (Gschwend 1986, S. 71-74). Einerseits soll der Leistungserbringer da-hingehend gesteuert werden, sein Leistungsportfolio hinsichtlich Inhalt, Qualität und Preis am Leistungsabnehmer auszurichten. Anderseits soll der Leistungsabnehmer in seinem Nutzerverhalten dahingehend be-einflusst werden, vorhandene Kapazitäten des Leistungserbringers op-timal auszunutzen.

Erfolgszuweisungsziel: Die einzelnen Unternehmensbereiche sollen ih-ren Anteil am Erfolg zugerechnet bekommen und dadurch zur Leis-tungssteigerung und Effizienzerhöhung motiviert werden (Gschwend 1986, S. 77-77). Beispielsweise soll der DWH-Leistungserbringer dazu motiviert werden, seine Ressourcen optimal auszunutzen. Gleichzeitig soll der Abnehmer zum wirtschaftlichen Einsatz der DWH-Leistungen angehalten werden.

Dabei muss sich auch das Instrument der Leistungsverrechnung selbst in seiner Ausgestaltung dem Wirtschaftlichkeitsziel unterordnen (Fürer 1993, S. 32; Marzinzik 1998, S. 57). Die Berücksichtigung dieser Ziele ist immer

246 Mario Klesse

ein Kompromiss, sie sind daher unternehmensindividuell verschieden zu priorisieren.

3 Elemente einer Leistungsverrechnung

Der Gestaltungsgegenstand einer Leistungsverrechnung lässt sich in zwei Bereiche aufteilen (Abb. 1). Dies ist zum einen die Schnittstelle zum Leis-tungsabnehmer, welche für den Kunden sichtbare Elemente enthält. Dazu zählen folgende Elemente (OCG 2001, S. 33-38, 64-69, 92ff.):

Produkte / Services: Die Produkte bzw. Services stellen jene gebündel-ten Leistungen dar, die dem Abnehmer durch den Leistungserbringer angeboten werden bzw. für diesen erbracht werden. Wichtig für die Wirkung einer Leistungsverrechnung ist, dass diese für den Leistungs-abnehmer verständlich und nutzenstiftend ist. Zudem sollte ihre Qualität beschrieben sein, damit nicht einseitig Kosten optimiert werden.

Abrechnungsmodell: Das Abrechnungsmodell legt die Form und Ausge-staltung der Abrechnung gegenüber dem Leistungsabnehmer fest. Die hierbei in der Praxis häufig angewandten Umlageverfahren erfüllen die Anforderungen an eine Leistungsverrechnung nicht (Britzelmaier 1999, S. 44). Damit eine Leistungsverrechnung die gewünschte Wirkung ent-faltet, muss das Abrechnungsmodell preisbasiert sein. Die Abrech-nungsgrößen, d.h. die Einheiten, die für die Produkte letztlich bepreist werden, sollten sich dabei an den gesetzten Zielen der Verrechnung orientieren.

Preismodell: Das Preismodell legt die Art und Weise der Preisbildung für die Abrechnungseinheiten der Produkte fest. Im unternehmensinter-nen Kontext von DWH-CCs ist die Bildung langfristig kostendeckender Verrechnungspreise in der Regel Grundanforderung. Diese sollten zu-dem auf nachvollziehbare Art und Weise entstehen, da sonst die Ak-zeptanz im innerbetrieblichen Kontext nicht gegeben ist.

Zum anderen sind dies Elemente, die lediglich für den DWH-Leistungs-erbringer sichtbar sind und ihm bei der Planung und Istermittlung von Kosten, Qualität und Mengen seiner Produkte unterstützen. Dazu zählen folgende Elemente (OCG 2001, S. 33-38, 70-75):

Internes Leistungsmodell: Die extern angebotenen Produkte / Services korrespondieren mit internen Leistungen. Diese wiederum setzen sich aus entsprechenden Teil- bzw. Vorleistungen zusammen. Diese Leis-tungen müssen daher erfasst, strukturiert und miteinander in Beziehung gesetzt werden, um Qualität, Wert und Menge von Leistungen planen zu


können und letztlich das kostenrechnerische Wertabbildungsziel zu er-füllen.

Kosten- und Leistungsrechnungssystem: Das Kosten- und Leistungs-rechnungsrechnungssystem (KLR-System) bildet die internen Leistun-gen, Produkte und Abrechnungsgrößen in Form von Kostenarten, Kos-tenstellen und Kostenträgern ab, so dass sich die Kosten der Leistungen bestimmen lassen.

Abb. 1. Gestaltungselemente einer Leistungsverrechnung

4 Information als Produkt und Informationsproduktion

Die Kernfrage „Was ist eigentlich das Produkt eines DWH-CCs?“ bildet den Ausgangspunkt der Gestaltung einer Leistungsverrechnung. Die in der Praxis gängigen Umlageverfahren nach Speicherplatz oder CPU-Sekunden unterstellen, dass dies das Produkt des DWH-Leistungserbringers ist. Das ist aber sicher nicht der Fall. Die Fachabteilungen benötigen zur Unterstüt-zung ihrer Prozesse Informationen, die das DWH-CC mithilfe eines DWH-Informationssystems bereitstellt. Was liegt also näher, als die Information selbst als Produkt zu definieren?

Diese Sichtweise ist im Informationsqualitätsmanagement seit langem akzeptiert (Ballou et al. 1998; Wang et al. 2002) und entspricht dem Para-digma einer serviceorientierten IT, nachdem ein IT-Produkt einen engen Bezug zum Prozess des Leistungsabnehmers aufweisen soll (OCG 2001;

248 Mario Klesse

Scheeg 2005). Übertragen auf das Data Warehousing lässt sich jedes DWH-Produkt als Kombination von Informationsprodukten und Prozess- bzw. Supportleistungen beschreiben.

Definiert man Informationsprodukte als Kernleistung eines DWH-CC, folgt daraus auch der primäre Leistungsprozess – die Informationsproduk-tion (Wang et al. 2002). Dieser Prozess stellt aus Rohdaten über verschie-dene Zwischenstufen qualitätsgesicherte Informationsprodukte her.

Alle anderen Prozesse eines DWH-CCs sind folglich Supportprozesse der Informationsproduktion, d.h. sie liefern entweder Leistungen,

die Voraussetzung für die Informationsproduktion sind (z. B. Entwick-lung),

die die Informationsproduktion unmittelbar unterstützen (z. B. fachli-cher Betrieb),

die die Informationsproduktion tatsächlich ausführen (z. B. technischer Betrieb),

oder die den Kunden bei der Nutzung der Informationsprodukte unters-tützen (z. B. fachlicher Support).

Legt man diese Sichtweise zu Grunde, lassen sich Leistungen und Kosten auch unmittelbar verursachungsgerecht einzelnen Schritten der Informati-onsproduktion zuordnen. Für die Methode wurden daher zwei zentrale Modelle entwickelt. Das erste Modell dient der Beschreibung von Infor-mationsprodukten (Abschn. 4.1). Das zweite Modell formalisiert den In-formationsproduktionsprozess und seine Zulieferprozesse so weit, dass auf dieser Basis die Qualität, Kosten und Leistungen der zur produzierenden Information geplant werden können (Abschn. 4.2).

4.1 Informationsproduktmodell

Das Informationsproduktmodell (IP-Modell) wurde so gestaltet, dass es so-wohl zur Abbildung von Rohdaten, von Zwischenprodukten in der Infor-mationsherstellung („Informationsobjekte“) als auch zur Abbildung der Endprodukte („Informationsprodukte“) geeignet ist. Basis des Modells sind Ansätze aus dem Informationsqualitätsmanagement (Wang u. Strong 1996; Nelson et al. 2005) und dem IT Service Management (OCG 2001; Klesse 2007, S. 206-218). Das Modell unterscheidet zwei Dimensionen und zwei Schichten (Abb. 2).


Abb. 2. Modell eines Informationsprodukts

Die Funktionsdimension eines Informationsprodukts beschreibt das „WAS“ des Informationsprodukts, die Qualitätsdimension das „WIE“. Die Schichten dienen der Abbildung des Umstandes, dass eine Information im-mer an ein Informationssystem gekoppelt ist (Bode 1993, S. 31; Kotkamp 2001, S. 48; Wang et al. 2002, S. 2). Einige Eigenschaften eines Informati-onsprodukts resultieren daher aus der Information selbst (Schicht „Infor-mation“), andere dagegen aus dem Informationssystem, welches diese be-inhaltet oder bereitstellt (Schicht „Informationssystem“). Eine derartige Schichtung bietet damit die Möglichkeit, ausgehend von Anforderungen an ein Informationsprodukt einerseits jene Eigenschaften zu extrahieren, wel-che von den zur Informationsherstellung nötigen Basisdaten gefordert werden müssen und andererseits, welche von den sie herstellenden Infor-mationssystemen benötigt werden.

Die funktionale Dimension umfasst folgende Eigenschaften, die in der Regel zur Entwicklungszeit des Informationsprodukts determiniert werden (Kotkamp 2001, S. 45f.):

Gegenstand: Der Gegenstand beschreibt den eigentlichen Inhalt der In-formation. Er kann beispielsweise durch Datenmodelle oder durch ver-bale Beschreibung umrissen werden.

Struktur: Informationen sind entsprechend ihres Verwendungszwecks unterschiedlich strukturiert. Beispielsweise können Informationen mul-

250 Mario Klesse

tidimensional oder normalisiert strukturiert sein. Die Spezifikation der Struktur erfolgt integriert mit der Beschreibung des Inhalts.

Darstellung: Informationen werden für die Verwendung verschiedent-lich dargestellt. Darstellungsformen sind beispielsweise tabellarische Berichte, Dashboards oder Portfolios.

Funktionalität: Jedes Informationsprodukt kann umfangreiche Funktio-nalität umfassen. Im Falle eines multidimensionalen Informati-onsprodukts erschöpft sich die Funktionalität in OLAP-Funktionen. Dennoch sind auch hochkomplexe Funktionen Bestandteile von Infor-mationsprodukten, wie bspw. Preisbildungsmechanismen.

Distributionsform: Diese Eigenschaft beschreibt, wie Informationen „vertrieben“ werden. Beispiele hierfür sind die zeitinduzierte (Jahresab-schluss) und die ereignisorientierte Verteilung (exception reports) oder die Verteilung auf Abruf (interaktive Analysen).

Speicherung: Informationsprodukte sind immer an ein Medium bzw. an ein Informationssystem gekoppelt. Die Eigenschaft hält daher fest, wo das Informationsprodukt hinterlegt ist.

Zur Beschreibung der Qualitätsdimension dient ein kennzahlenbasiertes Merkmalssystem, das sich an gängigen Ansätzen des Informationsquali-tätsmanagements orientiert (Nelson et al. 2005). Jedes Merkmal lässt sich mit standardisierten Metriken operationalisieren und messen (Ballou et al. 1998):

Richtigkeit: Der Erfüllungsrad hinsichtlich einer Spezifikation, zu dem die Information korrekt, unmissverständlich, aussagekräftig, glaubwür-dig und konsistent ist. Die Spezifikation kann beispielsweise in Form von Geschäftsregeln (Korrektheit), Dublettenprüfungen (Unmissver-ständlichkeit), Integritätsbedingungen (Konsistenz) vorliegen. Die Me-trik kann hierfür darin bestehen, welcher Anteil dieser Bedingungen oder Prüfungen erfolgreich passiert wurde (Helfert 2002, S. 185). Glaubwürdigkeit kann z. B. statistisch geschätzt werden, indem die In-halte des Informationsprodukts mit Referenzinhalten verglichen werden (Helfert 2002, S. 148ff.).

Vollständigkeit: Der Erfüllungsrad, zu dem ein bekannter und spezifi-zierter Informationsbedarf durch das Informationsprodukt gedeckt ist. Hierfür sind zwei grundsätzlich verschiedene Metriken denkbar. Zum einen kann der Abdeckungsgrad zwischen der zur Verfügung gestellten Information und dem bekannten Informationsbedarf gemessen werden (designorientiert). Zum anderen kann gemessen werden, welcher Anteil der Quellinformationen laut Spezifikation korrekt geladen wurde bzw.


wie viele Nullwerte oder unvollständige Datensätze bei der Informati-onsproduktion verarbeitet werden mussten (produktionsorientiert).

Aktualität: Der Erfüllungsrad, zu dem die produzierte Information zeit-aktuell gemäß Spezifikation ist. Als Metrik kann das tatsächliche Alter einer Information zu seiner voraussichtlichen "Haltbarkeitsdauer" ins Verhältnis gesetzt werden (Ballou et al. 1998). Deren Anwendung ver-ursacht jedoch einen erheblichen Aufwand. Da in der Praxis die Ak-tualität häufig nur einen geringeren Anteil zum Nutzen des Informati-onsprodukts beiträgt (Nelson et al. 2005, S. 216), sollte eine einfache Metrik herangezogen werden. Eine solche ist das Verhältnis zeitgerecht geladener Quellen zu der Gesamtzahl der Quellen eines Informations-produkts (Helfert 2002, S. 185).

Zugänglichkeit: Der Erfüllungsrad, zu dem auf ein System und die darin enthaltene Information mit geringem Aufwand zugegriffen werden kann. Als Metrik hierfür bietet sich beispielsweise die gesicherte Be-triebszeit des Zugriffssystems an.

Zuverlässigkeit: Der Erfüllungsgrad, zu dem die spezifizierten Eigen-schaften des Informationsprodukts zur Verfügung stehen. Typische Me-triken sind hier der Anteil der Zeit, zu der das Informationsprodukt tat-sächlich vom Anwender benutzt werden kann, im Verhältnis zur zugesi-cherten Nutzungszeit; die mittlere Häufigkeit zwischen dem Auftreten von Fehlern (sowohl in der Datenproduktion als auch im Datenzugriff) oder die durchschnittliche Dauer der Störungsbehebung.

Antwortzeit: Der Erfüllungsgrad, zu dem das System rechtzeitige Ergeb-nisse auf eine Anfrage nach Informationen oder Verarbeitungsfunktio-nalität liefert. Die entsprechende Metrik ist die Antwortzeit. Bei einfa-chen Berichtsabrufen spielt diese Größe in der Praxis eine geringe Rolle (Nelson et al. 2005, S. 126), so dass hier in der Regel ein möglichst ein-faches Messverfahren verwendet werden sollte.

Flexibilität: Der Erfüllungsgrad, zu dem das System an die verschiede-nen Nutzerbedürfnisse sowie an veränderte Bedingungen anpassbar ist. Als Metrik bietet sich hier z. B. die Reaktionszeit an, mit der auf eine Veränderung an einer operativen Datenquelle reagiert wird.

Das beschriebene Produktmodell lässt sich sowohl zur Beschreibung von quellseitigen und zielseitigen Datenlieferungen als auch zur Beschreibung von statischen Berichten, OLAP-Berichten und beliebigen DWH-Applika-tionen einsetzen (Klesse 2007, S. 218). Abbildung 3 zeigt beispielhaft die Funktionsdimension für ein Informationsprodukt aus dem analytischen CRM, das anhand des beschriebenen Merkmalsrasters spezifiziert ist.

252 Mario Klesse

MD-Bericht:

ZweckEmpfänger

BeschreibungHistorisierung

Inhaltliche Beschreibung FilterGeschäftskunde Kundennummer Gemäss Unternehmensstandard ohne Interne

Unternehmen Voller Name des UnternehmensBranche Branchenzugehörigkeit des UnternehmensAnzahl Mitarbeiter Mitarbeiterzahl des UnternehmensGroessenklasse Grössenklasse des Unternehmens

Periode Monat KalendermonatQuartal KalenderquartalJahr Kalenderjahr

Produkt Produktnummer Unternehmensweite ProduktnummerProduktname Bezeichnung des ProduktsProduktgruppe Produktgruppe Sicht VertriebProduktcluster Produktcluster Sicht Vertrieb

Region Ort Ort (Ebene Postleitzahlen) Sicht VertriebGebiet Vertriebgebiet Sicht VertriebBundesland Bundesland / KantonLand Land / Staat

Inhaltliche Beschreibung / Berechnung BerechnungEinkaufspotenzial (EP) Einkaufspotenzial des Geschäftskunden in

CHF, basierend auf der Grössenklasse und der Mitarbeiterzahl des Unternehmens

EP = Anzahl_Mitarbeiter * Einkaufspotenzial (Groessenklasse)

Fakturierter Betrag (FB) Bisheriger Umsatz mit dem Kunden in CHF FB = SUMME (Fakturierter Betrag)

Share of Wallet (SoW) Anteil des Fakturierten Betrags am Einkaufspotenzial

SoW = FB / EP

Darstellung

Funktionalität

Distribution Bereitstellung: Abfrage/Lieferung: Auf Abruf, bei Bedarf feste Selektion per E-Mail abonnierbar

Speicherung

Periodisch, wöchentlich montags 9:00 Uhr

Informationsgegenstand

24 Monate, rollierend

Kennzahlen

Dimensionen

Zentral

Standard-Funktionen zur Definition abgeleiteter Felder

Marktpotenzialanalyse Geschäftskunden

Tabellarisch und grafisch, Exportierbar in CSV- und PDF-Datei

Allgemeine AngabenVertriebsplanung auf Basis von Marktpotenzialen, produktbezogen für GeschäftskundenVertrieb Geschäftskunden

Standard-Funktionalität multidimensionale Analyse

Kennzahlen Marktpotenzial-analyse

Welches sind die Kunden mit dem grössten Marktpotenzial?

Abb. 3. Produktsteckbrief eines OLAP-Berichts (Funktionsdimension)

4.2 Informationsproduktion

Um den Kernprozess der Leistungserstellung, die Informationsproduktion (IP) zu strukturieren, sowie um die nötigen Input-Leistungsmengen, ihre Qualität und ihre Kosten der Herstellung von Informationsprodukten pla-nen zu können, dient das Informationsproduktionsmodell. Es besteht in Anlehnung an (Wild 1970; Bode 1993; Ballou et al. 1998) aus Produkti-onsgruppen, Produktionsstellen, Informationsobjekten, Plattformleistungen und Prozessleistungen (Abb. 4).


Abb. 4. Metamodell des Informationsproduktionsprozesses

Produktionsgruppen dienen der aggregierten Abbildung des Informations-produktionsprozesses (IPP). Sie grenzen die logischen Produktionsstufen von Informationen gegeneinander ab. Jede logische Komponente des DWH-Informationssystems stellt eine Produktionsgruppe dar. Es werden folgende Produktionsgruppentypen unterschieden:

Quellinformationssysteme dienen zur Abbildung logischer Informations-quellen. Dies können beispielsweise eine CRM-Applikation oder ein ERP-System sein.

DWH-Integrationsinfrastrukturen dienen zur Abbildung von logischen infrastrukturellen Komponenten. In einer strengen Hub and Spoke-Architektur existiert genau eine solche Produktionsgruppe.

DWH-Applikationen dienen der Abbildung von anwendungsspezifi-schen Teilen des DWH-Informationssystems. Ein Beispiel ist ein Data Mart mit Zugriffskomponente für das Kampagnenmanagement oder ei-ne komplexe Lieferschnittstelle für ein Zielsystem.

Innerhalb der Produktionsgruppen übernehmen Produktionsstellen die ei-gentliche Informationsverarbeitung. Hierbei werden folgende Stellentypen unterschieden:

Sourcingstellen stellen die quellseitigen Grenzen des DWH-Informa-tionssystems dar. Sie liefern eine Informationsart, die im Data Ware-house weiterverarbeitet wird.

Verarbeitungsstellen transformieren eine oder mehrere Informationsar-ten zu einer neuen Informationsart.

Permanentspeicherstellen dienen der langfristigen Lagerung von Infor-mationsarten. Input und Output einer solchen Stelle ist ein und dieselbe Informationsart.

254 Mario Klesse

Distributionsstellen stellen die outputseitigen Systemgrenzen des DWH-Informationssystems dar. Sie stellen die Informationsprodukte her, die vom Nutzer des Data Warehouse verwendet werden. Dabei werden zwei Subtypen unterschieden. Abfragestellen dienen dem interaktiven Zugriff auf einen Datenbestand, Lieferstellen führen dagegen eine Datenliefe-rung an andere Systeme durch.

Mit den genannten Modellelementen lässt sich jede DWH-Landschaft ab-bilden. Dabei sind nur so viele Stellen zu bilden, wie es die gewünschte Genauigkeit der anschließenden Rechnungen erfordert. Abbildung 5 zeigt einen mit diesen Modellelementen beispielhaft abgebildeten Informations-produktionsprozess. Dargestellt ist ein DWH-Informationssystem, welches aus zwei Quellsystemen befüllt wird, einer CRM-Applikation und einer ERP-Applikation. Jede Quelle stellt je zwei Informationsarten bereit: Das CRM-System stellt die Informationsarten Vertragsbeschwerden (IV1) und Kundenstammdaten (IK1) zur Verfügung. Das ERP-System stellt Informa-tionen zur Vertragserfüllung (IV2) und Kundenbonitätsdaten zur Verfügung (IK2). Jede dieser Informationsbereitstellungen wird durch je eine Sour-cing-Stelle modelliert. Die Informationsarten werden im Data Warehouse integriert: Aus Partikularsichten über Kunden (IK1, IK2) werden integrierte Kundeninformationen (IK), aus den Einzelinformationen (IV1, IV2) zu Ver-trägen entsteht ein Gesamtbild über die Akzeptanz von Vertragsmodellen. Diese Transformation übernehmen Verarbeitungsstellen (V01, V02). Die Ergebnis-Informationen werden in Permanentspeicherstellen abgelegt (PV, PK). Zwei DWH-Applikationen verarbeiten diese Informationen weiter und speichern sie für Abfragen durch den Benutzer: Die erste Applikation er-möglicht OLAP-Analysen für die Kampagnensteuerung (IPKa). Dazu wer-den Vertrags- und Kundeninformationen werden integriert und es werden Kunden nach ihrer Akzeptanz von Vertragsmodellen segmentiert (IKa). Die zweite Applikation ermöglicht den Abruf von Bonitätsberichten für das Controlling (IPCo). Die integrierten Kundeninformationen werden dazu transformiert, multidimensional aufbereitet und in einer neuen Form (ICo) gespeichert. Auch die Vorgänge innerhalb der Applikationen werden wie-der durch entsprechende Stellen modelliert.


Abb. 5. Beispiel eines Informationsproduktionsmodells

Auf Basis dieses Modells lassen sich bereits Informationsflüsse und In-formationsqualitätseigenschaften planen (Ballou et al. 1998). Um jedoch eine Kosten- und Leistungsplanung vornehmen zu können, sind die zur In-formationsproduktion nötigen nicht-informatorischen Input-Leistungen mit dem Informationsproduktionsmodell zu verknüpfen. Jede Stelle wird dazu mit den Leistungen verknüpft, die sie zur Verarbeitung ihrer Informations-arten benötigt. Dabei werden folgende Inputleistungsarten unterschieden:

Plattformleistungen sind die Leistungen, die von der DWH-Plattform bzw. vom DWH-Plattformzulieferer bereitgestellt werden. Hierunter können Verarbeitungsleistungen, Speicherleistungen und Übertragungs-leistungen subsumiert werden.

Prozessleistungen sind alle Leistungen, die durch das DWH-CC erb-racht werden. Hierunter sind die Prozesse der Entwicklung und des fachlichen Betriebs des DWH-Informationssystems zu subsumieren.

Die Leistungen sind zunächst zu strukturieren und messbar zu machen. Tabelle 1 zeigt für einige Plattform- und Prozessleistungen mögliche Messgrößen.

Anschließend sind die nicht-informatorischen Leistungen den Stellen zu-zuordnen. Diese Zuordnung ist abhängig davon, um welche Leistungsart es sich handelt, auf unterschiedliche Weise vorzunehmen.

256 Mario Klesse

Tabelle 1. Nichtinformatorische Leistungen und Messgrößen

Leistung Messgröße Plattformleistungen Datenhaltung (Speichern) Gigabyte-Tag Verarbeitung Informationsbereitstellung (Batch) CPU-Sekunde oder

Joblaufzeit Verarbeitung Informationsabfrage (Online) CPU-Sekunde oder

Anfragelaufzeit Daten sichern (Backup) Gigabyte-Tag Daten übertragen (Netz) Gigabyte Prozessleistungen (Entwicklung) Ersterschließung von Datenquellen Anzahl Ersterschließungen Erschließung von Daten einer erschlossenen Quelle Anzahl Datenarten / Tabellen Bereitstellen erschlossener DWH-Daten für eine Applikation

Anzahl Datenarten / Lieferdateien

Erstellung von Kennzahlen aus erschlossenen DatenAnzahl Kennzahlen Erstellung statischer Berichten aus erschlossenen Daten

Anzahl Berichte

Prozessleistungen (Fachlicher Betrieb) Prozessunterstützung Inf.-Produktion Anzahl unterstützter

ETL-Prozesse Qualitätssicherung Inf.-Produktion Anzahl Qualitätskontrollen Metadatenpflege Anzahl Metadatenmutationen Referenzdatenpflege Anzahl

Referenzdatenmutationen Fehlerbehebung Anzahl behobener Fehler

„leicht“ Anzahl behobener Fehler „schwer“

Für Plattformleistungen sind den gebildeten Stellen jene Softwarekom-ponenten zuzuordnen, die die Aufgabe der jeweiligen Stelle realisieren. Im Falle von Sourcing-, Verarbeitungs- und Lieferstellen sind dies z. B. dieje-nigen ETL-Programme und temporären Datenstrukturen, die die Informa-tionstransformation realisieren. Im Falle von Permanentspeicherstellen sind dies beispielsweise die Datei- und Datenbereiche, die zur langfristigen Lagerung der jeweiligen Informationsart erforderlich sind. Im Falle von Abfragestellen sind dies z. B. entsprechende Queries. Die Konsumation der Plattformleistungen durch die jeweiligen Stellen kann anschließend mithilfe von Monitoring-Werkzeugen oder aus ETL-Protokollen nähe-rungsweise bestimmt werden. Daraus lassen sich entsprechende durch-schnittlich pro Informationsart und -menge eingesetzte Plattformleis-tungsmengen ermitteln.


Für Prozessleistungen sind entsprechende Mengenzusammenhänge zwi-schen Informationseigenschaften und Prozessleistungsmenge zu formulie-ren. Hierbei ist nach der Art des Prozesses zu differenzieren (Wieding 2000, S. 142-145):

Potenzialorientierte Leistungsbeziehungen: Insbesondere die Leistungs-mengen von Entwicklungsprozessen hängen nicht davon ab, wie viele Informationen einer Art produziert werden müssen, sondern welche In-formationen hergestellt werden sollen. Die Zuordnung der Leistungs-menge zur entsprechenden Stelle erfolgt somit durch die Zuordnung der entwickelten IS-Komponenten bzw. zu den Stellen.

Prozessorientierte Leistungsbeziehungen: Insbesondere die Leistungs-mengen des fachlichen Betriebs hängen von bestimmten Eigenschaften der von einer Stelle produzierten Information ab. Beispielsweise hängt der Aufwand der Qualitätssicherung vom Verhältnis zwischen der be-stehenden und der angestrebten Informationsqualität ab. Diese Zusam-menhänge sind für alle Prozessleistungen zu formulieren.

Sind diese Zusammenhänge für alle Prozess- und Plattformleistungen fest-gestellt, lassen sich die zur Produktion einer Informationsart nötigen Vor-leistungsmengen anhand von Mengen- und Qualitätseigenschaften der be-treffenden Information sowohl feststellen (Istwerte) als auch planen (Planwerte).

5 Vorgehensmodell der Methode

Im Folgenden wird ein Überblick über das Vorgehensmodell der Methode gegeben (Abb. 6). Um die Übersichtlichkeit des Vorgehensmodells zu er-höhen und den Bezug zu den Gestaltungselementen der Leistungsverrech-nung herzustellen, sind die Aktivitäten in Phasen gruppiert. Die einzelnen Aktivitäten werden im Folgenden erläutert (Klesse 2007, S. 243-253). Jede Aktivität erzeugt Entwurfsergebnisse, die hier als Inputs und Outputs der Aktivitäten dargestellt werden.

258 Mario Klesse

Abb. 6. Vorgehensmodell der Methode

5.1 Phase 1: Vorgaben

Die Phase „Vorgaben“ dient dem Treffen grundsätzlicher Entscheidungen, die die Gestaltung der Leistungsverrechnung maßgeblich beeinflussen. Sie besteht aus den Aktivitäten „Szenario analysieren“, „Ziele festlegen“ und „Grundsätzliche Festlegungen treffen“.


Aktivität 1.1: Szenario analysieren Input: (DWH-Governance) Output: Szenario

Diese Aktivität ist nötig, um die Anwendbarkeit der Methode sicherzu-stellen. Im Wesentlichen ist hier anhand einer Checkliste zu prüfen, ob das Szenario „Internes DWH Competence Center“ tatsächlich vorliegt. Ande-renfalls sind ggf. Anpassungen an der Methode vorzunehmen.

Aktivität 1.2: Ziele festlegen Input: (DWH-Governance) Output: Zielsystem (priorisiert)

In dieser Aktivität werden die Ziele bestimmt, die mit der Leistungsver-rechnung erreicht werden sollen. Insbesondere ist zu entscheiden, wie die drei Ziele „Kostenrechnerische Wertabbildung“, „Lenkungsfunktion“ und „Erfolgszuweisungsfunktion“ priorisiert werden. Daraus lassen sich die Prioritäten jeglicher anderer Anforderungen und Ziele ableiten (Technik in Klesse 2007, S. 254ff.).

Aktivität 1.3: Grundsätzliche Festlegungen treffen Input: Zielsystem Output: Grundsätzliche Festlegungen zur Abrechnung und zur Produkt-

bildung

Ziel dieser Aktivität ist es, erste Grundsätze der Abrechnung und der Pro-duktbildung zu wählen. Hinsichtlich der Abrechnung ist festzulegen, an welche Leistungsabnehmer prinzipiell welche Kosten zu verrechnen sind. In der Praxis existieren hierzu unterschiedliche Modelle, aus welchen eines zu wählen ist: Zum einen kann festgelegt werden, dass die Kosten des DWH-Informationssystems vollständig an die Informationsabnehmer zu verrechnen sind. Zum anderen bietet sich die Option, die Kosten der Inte-grationsinfrastruktur an die Datenlieferanten zu verrechnen, während Kos-ten von DWH-Applikationen an die jeweiligen Informationsempfänger verrechnet werden. Letztere Festlegung ist zweckmäßig, wenn im Unter-nehmen eine Bringschuld für Informationen etabliert ist.

Zur Vorbereitung der Produktbildung ist festzulegen, inwieweit welche Leistungen des DWH-CC mit Informationsprodukten gebündelt werden und welche Leistungen prinzipiell separat verrechnet werden. Zielführend sind hier zwei Optionen, aus denen ein Modell zu wählen ist: Die service-orientierte Abrechnung bündelt Entwicklungs- und Betriebsleistungen der DWH-Integrationsinfrastruktur und der DWH-Applikationen in infra-strukturelle und applikatorische Informationsprodukte und rechnet diese

260 Mario Klesse

mit dem Leistungsabnehmern ab. Dies ermöglicht es, Entwicklungskosten an der DWH-Integrationsinfrastruktur nutzungsgerecht zu verteilen. Die produktorientierte Abrechnung geht noch einen Schritt weiter: Hier wer-den alle Leistungen in Informationsprodukte gebündelt. Das heißt, der Kunde sieht lediglich das Informationsprodukt, das er auch nutzt, z. B. ei-nen „Bericht Kampagnencontrolling“ (Technik in Klesse 2007, S. 257ff.).

5.2 Phase 2: Ist-Analyse

Ziel der Phase Ist-Analyse ist, einen Überblick über die in die Leistungs-verrechnung einzubeziehenden Elemente zu erhalten. Entsprechend sind die DWH-Architektur, die an der Leistungserstellung beteiligten Organisa-tionseinheiten sowie die Prozesse des DWH-Leistungserbringers zu erhe-ben. Die anschließende grobe Kostenstrukturanalyse unterstützt die Schwerpunktsetzung bei den nachfolgenden Analyseschritten.

Aktivität 2.1: Organisation der Leistungserbringung erheben Input: -- Output: Leistungserstellungslandkarte

Für das Data Warehousing sind neben dem DWH-Informationssystem die organisatorischen Prozesse der Leistungserbringung notwendig. Erst diese ermöglichen es, Informationsprodukte mit einer gesicherten Qualität anzu-bieten und mit der nötigen Nutzerunterstützung zu versehen. Mit dieser Aktivität wird zunächst die Voraussetzung für die Prozessanalyse geschaf-fen, indem die am Leistungserstellungsprozess beteiligten Organisations-einheiten erfasst werden (Remer 1997). Dazu gehören nicht nur die DWH-Abteilungen im Unternehmen, sondern auch interne und externe Zuliefe-rer, die fest in die Leistungserstellung eingebunden sind. Gleichzeitig wer-den die Leistungen, die zwischen den Organisationseinheiten ausgetauscht werden, grob erfasst (Technik in Klesse 2007, S. 264ff.).

Aktivität 2.2: DWH-Architektur erheben Input: -- Output: DWH-Architektur (logisch und physisch)

Mit dieser Aktivität wird die DWH-Architektur auf logischer Ebene (DWH-Informationssystem) und auf physischer Ebene (DWH-Plattform) erfasst. In diesem Zuge werden auch die Quellen des DWH-Informations-systems identifiziert. Die Architekturanalyse dient als Grundlage der Iden-tifikation von Informationsprodukten sowie zur Vorbereitung der Analyse des Informationsproduktionsprozesses (Technik in Klesse 2007, S. 265ff.).


Aktivität 2.3: Kostenstruktur analysieren Input: -- Output: Kostenstruktur des Data Warehousing

Ziel der Aktivität ist es, die Kostenstruktur der bisher analysierten Ele-mente (Architekturkomponenten, Prozesse) zu erheben, einerseits um im weiteren Verlauf Schwerpunkte setzen zu können, andererseits um die bis-herige Erfassung ggf. zu detaillieren. Verursacht die Leistungserbringung z. B. überwiegend Maschinenkosten, ist eine detaillierte Analyse der Pro-zesse zumindest für die Leistungsverrechnung nicht zielführend. Hingegen ist bei einer personalintensiven Leistungserbringung davon abzuraten, al-lein Messgrößen des automatisierten Prozesses als interne Bezugsgrößen in der Verrechnung heranzuziehen. Auch die Genauigkeit der Abrechnung richtet sich nach dem Kostenvolumen der zu verrechnenden Prozessleis-tungen und Architekturelemente. Beispielsweise erscheint es wenig sinn-voll, eine DWH-Applikation, die nur ca. 1% der Gesamtkosten verursacht, weitergehend in Informationsprodukte zu zergliedern (Technik in Klesse 2007, S. 269ff.).

5.3 Phase 3: Definition der Kundenschnittstelle

Diese Phase dient der Ausgestaltung der Schnittstelle zu den Leistungsab-nehmern. Im Wesentlichen werden die angebotenen Produkte und Service Level Agreements definiert sowie die dazugehörigen Preis- und Abrech-nungsmodelle festgelegt.

Aktivität 3.1: Informationsprodukte identifizieren Input: DWH-Applikationen aus DWH-Architektur, optional fachliche

Metadaten Output: Informationsproduktverzeichnis (Kandidaten)

Ziel dieser Aktivität ist es, auf Basis der erhobenen DWH-Applikationen schrittweise Informationsprodukte zu identifizieren. Ein ggf. bereits eta-bliertes Metadatenmanagement kann als weiterer unterstützender Input für diese Aktivität herangezogen werden. Ergebnis der Aktivität sind Infor-mationsprodukte, die einerseits für den Kunden sinnvoll nutzbare Infor-mationseinheiten darstellen, andererseits ein anhand der Genauigkeitsan-forderungen festgelegtes Mindestkostenvolumen aufweisen. Sie sind der Dreh- und Angelpunkt des weiteren Vorgehens: Zum einen müssen sie an-schließend spezifiziert werden, zum anderen richten sich die nachfolgen-den Detailanalysen der Leistungserstellungsprozesse an ihnen aus (Tech-nik in Klesse 2007, S. 272ff.).

262 Mario Klesse

Aktivität 3.2: Informationsprodukte spezifizieren Input: Informationsproduktverzeichnis, Internes Leistungsmodell Output: Informationsproduktsteckbrief (Spezifikation von Funktion und

Qualität)

Die identifizierten Informationsprodukte werden anschließend hinsichtlich ihrer funktionalen und qualitativen Eigenschaften spezifiziert. Als Grund-lage dient das entwickelte allgemeine Modell des Informationsprodukts (siehe Abschn. 5.3), welches für die identifizierten Produkte operationali-siert und instanziiert wird (Technik in Klesse 2007, S. 278ff.).

Aktivität 3.3: Kundendienstleistungen identifizieren und spezifizieren Input: Informationsproduktverzeichnis, Prozessleistungsverzeichnis

(org. Prozesse) Output: Dienstleistungssteckbrief (Spezifikation von Funktion und Quali-

tät)

Nach der Spezifikation von Informationsprodukten können je nach grund-sätzlicher Festlegung Prozessleistungen verbleiben, die nicht direkt den In-formationsprodukten zuzuordnen sind. Beispielsweise können dies Benut-zersupportleistungen sein, oder die Entwicklung leistungsabnehmerspe-zifischer DWH-Applikationen. Sie sind als (nicht ergebnisorientiert spezifizierbare) Services in den Produktkatalog aufzunehmen. Im Rahmen der Methode wird jedoch angestrebt, dass möglichst wenige derartige Ser-vices entstehen (Technik in Klesse 2007, S. 286ff.).

Aktivität 3.4: Abrechnungsmodell festlegen Input: Zielsystem, Informationsproduktverzeichnis, Kundendienstleis-

tungen Output: Abrechnungsmodell, bestehend aus Leistungsabnehmerverzeich-

nis und Abrechnungsgrößenverzeichnis

Es werden Abrechnungsgrößen für die Produkte festgelegt und die Leis-tungsabnehmer konkretisiert. Es wird dabei angestrebt, dass möglichst we-nige verschiedene Abrechnungsmodelle entstehen und dass sich diese streng an dem entwickelten Zielsystem der Leistungsverrechnung orientie-ren. Da sich Abrechnungsgrößen unmittelbar auf das Verhalten der Nutzer auswirken, sind diese potenziellen Auswirkungen zu analysieren und mit dem Zielsystem der Leistungsverrechnung abzugleichen (Technik in Kles-se 2007, S. 288ff.).


Aktivität 3.5: Preismodell festlegen Input: Zielsystem, Informationsproduktionsmodell Output: Preismodell

Das grundsätzliche Vorgehen der Preisbildung wird festgelegt. Es wird be-stimmt, welche Parameter neben den Kosten bei der Preisbildung berück-sichtigt werden und welche Informationen die Kosten- und Leistungsrech-nung liefern können muss. Diese Festlegungen werden unter Berücksich-tigung des Zielsystems und der bestehenden Engpässe in der Informa-tionsproduktion getroffen. Zur Auswahl stehen kostenorientierte Preis-modelle, die Qualitäts- und Zeitparameter einbeziehen können, um die im Zielsystem definierte Steuerungswirkung zu erzielen (Technik in Klesse 2007, S. 297ff.).

Aktivität 3.6: Produktkatalog erstellen Input: Informationsproduktverzeichnis, Informationsproduktsteckbrief,

Steckbriefe der Kundendienstleistungen, Leistungsabnehmerver-zeichnis

Output: Produktkatalog

Die Informationsprodukte sowie die Kundendienstleistungen werden in ei-nen Produktkatalog eingeordnet. Die Aktivität hat lediglich konsolidieren-den Charakter (Technik in Klesse 2007, S. 307ff.).

Aktivität 3.7: Verträge erstellen Input: Informationsproduktsteckbriefe, Dienstleistungssteckbriefe,

Internes Leistungsmodell, Leistungsabnehmerverzeichnis Output: Service Level Agreements, Operational Level Agreements

Die Informationsprodukte sowie die Kundendienstleistungen werden ab-schließend in Service Level Agreements festgehalten. Diese Aktivität führt die bisherigen Ergebnisse zusammen und nimmt die Vereinbarung kun-denbezogener DWH-Produkte aus den Informationsprodukten und ggf. aus begleitenden Kundendienstleistungen vor. Zudem werden die Leistungs-vereinbarungen mit den Lieferanten für Daten, Plattformen und Imple-mentierungsleistungen vertraglich fixiert (Technik in Klesse 2007, S. 308ff.).

264 Mario Klesse

5.4 Phase 4: Erstellung des Internen Leistungs- und Kostenmodells

Ziel dieser Phase ist es, unter Verwendung der in Abschn. 4.3 skizzierten Modellelemente ein unternehmensspezifisches Modell der DWH-Leis-tungserstellung zu entwickeln, auf dem die Kostenermittlung für die In-formationsprodukte aufbauen kann. Als übergeordneter Hauptprozess dient der Informationsproduktionsprozess (IPP). Für die Analyse werden die Er-gebnisse aus Phase 2 aufgegriffen und hinsichtlich der identifizierten In-formationsprodukte detailliert.

Aktivität 4.1: Informationsproduktionsprozess erheben (IPP Sicht: Infor-mation) Input: Informationsprodukte, Logische DWH-Architektur (Informati-

onsquellen, DWH-Integrationsinfrastruktur, DWH-Applikatio-nen)

Output: Informationsproduktionsmodell – Sicht Information, bestehend aus Informationsproduktionsmatrizen und Stellenverzeichnis

Zunächst wird der Informationsproduktionsprozess in seiner Gesamtheit erfasst. Basis dieser Aktivität ist das in Abschn. 4.3 beschriebene Modell der Informationsproduktion. Für jedes Informationsprodukt wird abgebil-det, wie es über die verschiedenen Produktionsstufen des DWH-Informati-onssystems aus den Quellinformationen hergestellt wird. Die dazu nötigen Datenflüsse werden in Informationsproduktionsmatrizen festgehalten. Sie dienen als Ausgangsbasis für die Bildung von IPP-Stellen sowie ihrer Ver-knüpfung. Die Stellen werden in den nachfolgenden Aktivitäten schritt-weise mit den nicht-informatorischen Leistungen verknüpft (Technik in Klesse 2007, S. 310ff.).

Aktivität 4.2: Plattform-Leistungen erheben und zuordnen (IPP Sicht: Plattform) Input: Informationsproduktionsmodell – Sicht Information,

physische DWH-Architektur bzw. DWH-Plattformarchitektur Output: Informationsproduktionsmodell – Sicht Plattform, bestehend aus

Plattformleistungsverzeichnis und Zuordnungsmechanismus zur Sicht Information via Stellenverzeichnis, ergänzende Beschrei-bung im Plattformsteckbrief

Zunächst werden die Plattform-Leistungen erhoben. Hierfür kann es ggf. nötig sein, mit den Zulieferern zunächst die benötigten Plattformleistungen neu zu strukturieren und ein geeignetes Abrechnungsmodell zu vereinba-


ren. Empfohlen wird die Trennung von Verarbeitungs-, Speicher- und Übertragungsleistung je Plattform bzw. je technischer Ressource (Scheeg 2005, S. 163-168). Anschließend werden die Elemente des DWH-Informationssystems (Tabellen, ETL-Prozesse, etc.) den Stellen des IPP zugeordnet. Mithilfe einer initialen Messung werden für jede gebildete Stelle Ausgangswerte für die Verbräuche der verschiedenen Plattform-leistungsarten ermittelt, die bei der Ausführung der zugeordneten DWH-Informationssystemkomponenten entstehen (Technik in Klesse 2007, S. 321ff.).

Aktivität 4.3: Prozessleistungen ermitteln und zuordnen (IPP Sicht: Orga-nisation) Input: Informationsproduktionsmodell – Sicht Information, Leistungs-

erstellungslandkarte Output: Informationsproduktionsmodell – Sicht Prozess, bestehend aus

Prozessleistungsverzeichnis und Zuordnungsmechanismus zur Sicht Information via Stellenverzeichnis, ergänzende Beschrei-bung im Prozesssteckbrief

Das Vorgehen innerhalb dieser Aktivität orientiert sich somit an etablierten Ansätzen zur Einführung der Prozesskostenrechnung (Remer 1997). Zu-nächst werden die Prozesse der Leistungserbringung erhoben und struktu-riert. Insbesondere werden (organisatorische) Prozessleistungen definiert und messbare Bezugsgrößen für die Prozessleistungen identifiziert. An-schließend werden die Zuordnungsmechanismen für die Leistungen zu den Elementen des Informationsproduktionsprozesses festgelegt. Soweit mög-lich, werden Zusammenhänge zwischen Prozessleistungsbezugsgrößen und Eigenschaften der produzierten Informationen formuliert. Die Ergeb-nisse werden in einem Prozessleistungsverzeichnis und einem Prozess-steckbrief für jeden Prozess festgehalten (Technik in Klesse 2007, S. 335ff.).

Aktivität 4.4: Abbildung in KLR-System vornehmen Input: Abrechnungsmodell, Produktkatalog, Informationsproduktions-

modell Output: Kostenartenplan, Kostenträgerplan, Kostenstellenplan, Kalkulati-

onsschema, Planungsergebnisse der Phase 5

Ziel ist es, ein Kalkulationsschema zu entwickeln, welches die laufende Kalkulation der Informationsprodukte und Kundendienstleistungen er-möglicht. Das erstellte Informationsproduktionsmodell wird dazu in eine Kosten- und Leistungsrechnung abgebildet. Die Abbildung erfolgt vor al-

266 Mario Klesse

lem nach rechentechnischen Gesichtspunkten und berücksichtigt daher auch das entwickelte Abrechnungs- und Preismodell. Abschließend wird eine initiale Planung durchgeführt (Phase 5). Das Vorgehen innerhalb der Aktivität orientiert sich an bestehenden Ansätzen zur Konzeption von IT-Kostenrechnungssystemen (Mai 1996; Britzelmaier 1999). Vereinfacht dargestellt ergibt sich eine direkte Abbildung der IPP-Stellen, der Prozesse und der Plattformen in Form von Kostenstellen und Kostenplätzen, deren Leistungen Informationen, Prozessleistungen und Plattformleistungen dar-stellen (Technik in Klesse 2007, S. 344ff.).

5.5 Phase 5: Planung und Kalkulation

Mit der Phase 4 ist die eigentliche Gestaltung des Verrechnungssystems abgeschlossen. Die entwickelten Artefakte müssen anschließend imple-mentiert und in die Abrechnungs- und Servicemanagement-Prozesse des Unternehmens integriert werden. Diese Aufgaben werden hier nicht weiter ausgeführt, da sie stark von der entwickelten Konzeption und vom unter-nehmensspezifischen Rahmen abhängig sind. Zur Inbetriebnahme sowie für den laufenden Betrieb des Konzepts sind jedoch Prozesse nötig, die es erlauben, die Eigenschaften und Preise der Informationsprodukte zu pla-nen. Diese sind in der Phase 5 zusammengefasst und in die Prozesse des DWH-CC zu integrieren.

Aktivität 5.1: Veränderungen planen Input: IS-Architekturplanung (operativ und dispositiv), Anforderungen

der Leistungsabnehmer Output: Neuprodukte, Produktänderungen, Nutzerstrukturveränderungen,

Infrastrukturmaßnahmen, veränderte Qualitätsanforderungen

Ein DWH-Informationssystem ist regelmäßigen Veränderungen unterwor-fen. Ursachen dafür sind sich ändernde Datenquellen, der Bedarf nach neuen Informationsprodukten oder nach der Veränderung bestehender In-formationsprodukte. Zudem können Erweiterungen der Integrationsinfra-struktur selbst nötig sein, wie bspw. die Einführung oder Erweiterung ei-nes Metadatenmanagementsystems. Die Aktivität dient dazu, die Verände-rungen zu identifizieren, welche potentiell zu Mengen- und Kostenverän-derungen im Informationsproduktionsmodell führen können. Ihr Output orientiert sich am Informationsbedarf aller nachgelagerten Prozesse (De-tails in Klesse 2007, S. 355ff.).


Aktivität 5.2: Informationsmengen planen Input: Fachliche Veränderungen, Neuprodukte, Produktänderungen,

Nutzerstrukturveränderungen Output: Mengen der Informationsarten (Plan), Informationsproduktmen-

gen gemäß Abrechnungsmodell (Plan)

Veränderungen der geschäftlichen Lage des Unternehmens, der Analyse-anforderungen, der Nutzerzahlen oder des Analyseverhaltens der Nutzer führen zu Veränderungen der Informationsmengen, die im Data Warehou-sing verarbeitet werden müssen. Die Aktivität dient der Planung der In-formationsmengen aus fachlicher Sicht. Dies umfasst sowohl die Menge der bereitzustellenden Informationen als auch die Menge der voraussicht-lich abgefragten Informationen. Ziel ist es einerseits, die benötigten Men-genzahlen für das Abrechnungsmodell zu gewinnen, andererseits einen wichtigen Input für die interne Leistungsplanung des DWH-CC zu gene-rieren (Details in Klesse 2007, S. 356ff.).

Aktivität 5.3: Informationsqualität planen Input: Qualitätsmesswerte der IPP-Stellen, Qualitätsanforderungen Output: Qualitätsmetrikwerte der Informationsprodukte (Plan), Qualitäts-

metrikwerte der Quell-Informationsobjektarten (Soll)

Die Qualität der Informationsprodukte ist maßgeblich von der Qualität der Quelldaten abhängig. Um zu ermitteln, inwieweit es realistisch ist, für ein Informationsprodukt die Kundenanforderungen hinsichtlich der Informati-onsqualität zu erfüllen, muss die Informationsqualität geplant werden. Da-zu dient das in Abschn. 5.3 vorgestellte Modell. Grundsätzlich wird für al-le gebildeten Stellen die Informationsqualität der Input- und Outputin-formationen anhand der gebildeten Qualitätsmetriken für Informationspro-dukte gemessen. Durch Extrapolation lassen sich die Auswirkungen ver-änderter Inputqualitäten oder von Qualitätsanforderungen entlang der Informationsproduktionskette planen (Ballou et al. 1998); (Details in Kles-se 2007, S. 359ff.).

Aktivität 5.4: Prozessleistungsmengen Entwicklung planen Input: Anforderungsbeschreibungen der Neuprodukte, Produktänderun-

gen, Infrastrukturmaßnahmen Output: Entwicklungsleistungsmengen (Plan) je Stellen / Produktions-

gruppen des IPP-Modells, bei Neuentwicklungen zusätzlich an-gepasstes IPP-Modell (neue Produktionsgruppen, Stellen, Zuord-nungen von IS-Komponenten)

268 Mario Klesse

Die Einführung neuer Produkte, die Veränderung bestehender Informati-onsprodukte sowie Infrastrukturmaßnahmen erfordern Entwicklungsleis-tungen, die geplant werden müssen. Die Entwicklung erzeugt IS-Kompo-nenten, die dem IPP-Modell zugeordnet werden müssen, um auf dieser Basis die Kostenermittlung von Informationsprodukten zu ermöglichen. Bei Neuentwicklungen muss zusätzlich das IPP-Modell angepasst werden. Diese Aktivität ermittelt die Planaufwände und ordnet diese dem gegebe-nenfalls anzupassenden IPP-Modell zu (Details in Klesse 2007, S. 361ff.).

Aktivität 5.5: Prozessleistungsmengen Betrieb und Support planen Input: Mengen der Informationsprodukte, Veränderungen der Informa-

tionsproduktion Output: Planleistungsmengen Betriebs- und Supportprozesse (Plan), an-

gepasste Einsatzfunktionen im IPP-Modell

Auf Basis der ermittelten Informationsmengen und Veränderungen kann die Veränderung der Prozessleistungsmengen im fachlichen Betrieb und Support geplant werden. Zusätzlich werden Trends aus den Ist-Daten über die Bezugsgrößen- und Ressourcenverbrauchsentwicklung herangezogen. Diese Aktivität führt diese Planzahlen zusammen und ermittelt die Plan-leistungsmengen für Betrieb und Supportprozesse des DWH-CC (Details in Klesse 2007, S. 365ff.).

Aktivität 5.6: Plattformleistungsmengen planen Input: Mengen der Informationsprodukte, Veränderungen der Informa-

tionsproduktion Output: Plattformleistungsmengen (Plan), angepasste Einsatzfunktionen

im IPP-Modell

Auf Basis der ermittelten Informationsmengen und Veränderungen kann die Veränderung des Plattformleistungsbedarfs geplant werden. Die In-formationsmengen allein reichen jedoch für eine Planung nicht aus. Zu-sätzlich sind Messdaten über bestehende Entwicklungen der Plattform-leistungsmengen heranzuziehen, die im Rahmen der Ist-Leistungsmessung (für laufende Abrechnung und Kapazitätsmanagement) gewonnen werden (Hahn et al. 2000). Diese Aktivität führt wiederum beide Planungen zu-sammen und ermittelt die Plattformleistungsmengen für die Informati-onsproduktion (Details in Klesse 2007, S. 367ff.).

Aktivität 5.7: Informationsprodukte kalkulieren Input: Planmengen Informationen, Prozess- und Plattformleistungen Output: Plankosten und Preise der Informationsprodukte


Auf Basis der ermittelten Leistungsmengen sind die Kostenauswirkungen der Veränderungen zu planen. Mithilfe des in Abschn. 4.3 dargestellten Modells können anschließend die Kosten pro Informationsprodukt ermit-telt werden (Klesse 2007, S. 194-203). Anhand des Abrechnungsmodells ergibt sich die Kostenbasis für die "Stückpreise" der Informationsprodukte (Details in Klesse 2007, S. 374ff.).

Aktivität 5.8: Katalog und Verträge anpassen Input: Neuprodukte, Veränderungen, Planmengen, Qualitäten und Prei-

se Output: Aktualisierte Service Level Agreements, Operational Level

Agreements und Produktkatalog

Die bestehenden Service Level Agreements müssen regelmäßig mit den Plan- und Solldaten aktualisiert werden. Neuprodukte müssen in neuen Service Level Agreements festgehalten werden. Die Aktivität gleicht in weiten Teilen der Aktivität "Verträge erstellen" und dient dem Abschluss des Planungsprozesses.


Im Artikel wurde eine Methode vorgestellt, mit dem DWH-CCs eine Leis-tungsverrechnung für die von ihnen angebotenen Produkte konzipieren können.

Die Methode berücksichtigt die häufig unterschiedlichen Zielsetzungen der Leistungsverrechnung eines DWH-CC, indem sie die Zielfindung durch eine eigene Aktivität unterstützt und die ermittelten Ziele konse-quent in den Techniken verfolgt.

Zudem unterstützt sie die Spezifikation von fachlichen, an Informatio-nen ausgerichteten Produkten. Das dazu entwickelte verallgemeinerte Konzept eines Informationsprodukts ist auf analytische Prozesse, abgrenz-bare Informationsarten sowie auf Applikationen anwendbar. Die Methode integriert in den Produkten eine Qualitätssicht. Durch das zu Grunde lie-gende Informationsproduktionsmodell werden Qualitätseigenschaften der Informationsprodukte systematisch planbar. Das Abrechnungsmodell und die Abrechnungsgrößen werden konsequent an den Zielen der Leistungs-verrechnung ausgerichtet und berücksichtigen explizit ihre Wirkung auf die Nutzer. Die Methode bietet dazu mehrere kostenorientierte Preismo-delle zur Auswahl, die die Bildung langfristig kostendeckender Preise er-möglichen. Alle zur Preisbildung benötigten Informationen werden durch das zu Grunde liegende IPP-Modell geliefert. Dieses Modell verfolgt den

270 Mario Klesse

Grundsatz, alle Leistungsflüsse zu erfassen, zu Informationen zuzuordnen und sowohl mengen- als auch qualitätsorientiert zu beschreiben. Eine Be-wertung der Leistungen mit Kosten erfolgt auf Basis der Mengen und Qua-litätssicht. Die Methode beschreibt weiterhin Abbildungsregeln für das Modell in eine Kosten- und Leistungsrechnung. Das KLR-System ist ana-log dem Produktionsmodell am Prozess der Informationsproduktion ausge-richtet. Die strenge Orientierung an Leistungsflüssen innerhalb des Mo-dells und der Methode ermöglicht eine verursachungsgerechte Verrech-nung fixer Gemeinkosten im Sinne des Finalitätsprinzips (Haberstock 1998). Das bedeutet, Leistungen werden jene Kosten zugeordnet, ohne die sie nicht erzeugt werden könnten.

Durch die im Rahmen der Methode realisierte nutzungsorientierte Ver-rechnung von Infrastrukturleistungen wird zudem ein verursachungsrech-ter Lösungsansatz für die Infrastrukturproblematik präsentiert. Dies er-möglicht dem Leistungserbringer eine eigenständige Planung, Entwicklung und Optimierung der Infrastruktur.

Die Methode wurde für interne DWH Competence Center entworfen, die die betriebliche Informationslogistik mit DWH-basierten Informations-systemen unterstützt. Da die Methode darauf basiert, betriebliche Informa-tionsproduktionsprozesse mit allgemeinen Elementen flexibel abzubilden, ist sie prinzipiell ohne Weiteres auch für andere Formen der IT-Unterstüt-zung der Informationslogistik einsetzbar (z. B. Entwicklung und Betrieb von Operational Data Stores oder ähnlichen Systemen). Zur Weiterent-wicklung der vorgestellten Methode bieten sich mehrere Richtungen an. Zum einen kann die Methode auch für andere organisatorische Szenarien als das interne DWH-CC (vgl. Kap. 5) ausgestaltet werden. Vor dem Hin-tergrund einer zunehmenden Verselbständigung von IT-Dienstleistern könnten beispielsweise stärker marktorientierte Preisbildungsmechanismen und Abrechnungsmodelle eingebunden werden. Zum anderen kann das der Methode zu Grunde liegende Modell der Informationsproduktion weiter-entwickelt werden. Beispielsweise wurde der Faktor „Zeit“ bewusst nicht in das Modell aufgenommen, um dessen Komplexität zu reduzieren. Dies schränkt jedoch die Aussagekraft des Modells in der Qualitätssicht ein. Sollte im Rahmen der Diskussion um Informationslogistik-Konzepte, die „(Near) Realtime“ Informationen liefern, der zeitlichen Dimension einer Information eine gestiegene Bedeutung zukommen, ließe sich diese Lücke unter Verwendung der Ansätze von (Ballou et al. 1998) schließen.


Literatur

Ballou, D. P.; Wang, R.; Pazer, H. L.; Tayi, G. K.: Modeling Information Manu-facturing Systems to Determine Information Product Quality, in: Management Science 44 (1998) 4, S. 462-484.

Bode, J.: Betriebliche Produktion von Information, Deutscher Universitäts-Verlag GmbH, Wiesbaden 1993.

Britzelmaier, B.: Informationsverarbeitungs-Controlling - Ein datenorientierter Ansatz, Teubner, Stuttgart, Leipzig 1999.

Chamoni, P.; Gluchowski, P.; Gronwald, H.: Business Intelligence-Studie biMA 2004, Mummert Consulting, Hamburg 2004.

Fürer, P.: Prozesse und EDV-Kostenverrechnung - Die prozessbasierte Ver-rechnungskonzeption für Bankrechenzentren, Diss., Universität St. Gallen, Bamberg 1993.

Gschwend, W.: Die Zielproblematik des Verrechnungspreises - Eine kritische Analyse der verschiedenen Verrechnungspreisfunktionen, Diss., Universität St. Gallen, St. Gallen 1986.

Gutzwiller, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Physica, Heidelberg 1994.

Haberstock, L.: Kostenrechnung I - Einführung, 10. Aufl., Schmidt-Verlag, Berlin 1998.

Hahn, S.; Jackson, M. H. A.; Kabath, B.; Kamel, A.; Meyers, C.; Matias, A. R.; Osterhoudt, M.; Robinson, G.: Capacity Planning for Business Intelligence Applications: Approaches and Methodologies, IBM Redbooks, 2000.

Helfert, M.: Planung und Messung der Datenqualität in Data-Warehouse-Systemen, Diss., Universität St. Gallen, Bamberg 2002.

Jung, R.; Winter, R.: Justification of Data Warehousing Projects, in: Khosrowpour M. (Hrsg.): Managing Information Technology in a Global Economy (Pro-ceedings zur IRMA 2001, Anchorage), IDEA Group Publishing, Hershey u.a. 2001, S. 54-57.

Klesse, M.: Leistungsverrechnung im Data Warehousing - Entwicklung einer Methode, Diss., Universität St. Gallen, St. Gallen 2007.

Kotkamp, S.: Electronic Publishing - Ökonomische Grundlagen des Handels mit Informationsprodukten, Diss., TH Karlsruhe, Karlsruhe 2001.

Mai, J.: Konzeption einer controllinggerechten Kosten- und Leistungsrechnung für Rechenzentren, Peter Lang, Frankfurt/M. et al. 1996.

Marzinzik, C.: Leistungsverrechnung als Instrument eines kostenorientierten In-formationscontrolling - Ein prozesskostengestützter Ansatz zur Steuerung der Wirtschaftlichkeit der warenwirtschaftlichen Informationsverarbeitung von Handelsunternehmen, Verlag Dr. Kovac, Hamburg 1998.

Nelson, R. R.; Todd, P. A.; Wixom, B. H.: Antecedents of Information and Sys-tem Quality: An Empirical Examination Within the Context of Data Ware-housing, in: Journal of Management Information Systems 21 (2005) 4, S. 199-235.

272 Mario Klesse

OCG: IT Infrastructure Library (ITIL) - Service Delivery, Office of Government Commerce, The Stationery Office, 2001.

Rehberg, J.: Wert und Kosten von Informationen, Harri Deutsch, Frankfurt/M. 1973.

Remer, D.: Einführung der Prozesskostenrechnung - Grundlagen, Methodik, Ein-führung und Anwendung der verursachungsgerechten Gemeinkos-tenzurechnung, Schäffer-Poeschel, Stuttgart 1997.

Scheeg, J. M.: Integrierte IT-Kostentabellen als Instrument für eine effiziente IT-Leistungserbringung im Informationsmanagement - Konzeption und prak-tische Umsetzung, Universität St. Gallen, St. Gallen 2005.

Wang, R. Y.; Allen, T.; Harris, W.; Madnick, S.: An Information Product Ap-proach for Total Information Awareness, MIT Sloan School of Management, 2002.

Wang, R. Y.; Strong, D. M.: Beyond Accuracy: What Data Quality Means to Data Consumers, in: Journal of Management of Information Systems 12 (1996) 4, S. 5-33.

Wieding, A.: Leistungsrechnung: Ein prozessorientierter Ansatz, Gabler, Wies-baden 2000.

Wild, J.: Input-, Output- und Prozeßanalyse von Informationssystemen, in: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 22 (1970) 1, S. 50-72.

13 Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse

Robert Konzelmann

Teradata

1 Einleitung ....................................................................................... 2732 Planungsphasen .............................................................................. 2803 TSM Phase: Design ........................................................................ 2984 Zusammenfassung und Ausblick .................................................... 308

Literatur .......................................................................................... 310

1 Einleitung

Die Notwendigkeit von geeigneten Methodologien für die Entwicklung von Informationssystemen ist sicherlich unbestritten. Auch über ihre Wir-kungen und ihr Zusammenspiel mit anderen grundlegenden Erfolgsfakto-ren wie Fachwissen, Situationskenntnisse und Erfahrung wurde schon viel analysiert und geschrieben (vgl. hierzu z. B. Daenzer u. Huber 1992). Je-doch genauso groß wie die Einigkeit betreffend der Notwendigkeit (dem WAS?), ist die Uneinigkeit betreffend der eigentlichen Vorgehensweise (dem WIE?). Dies hat sicherlich auch mit den folgenden, in der Fachwelt etablierten, Grundsätzen einer Methodik zu tun (Daenzer u. Huber 1992):

Eine Methodik…

ist nicht Selbstzweck, sondern muss zur Erarbeitung guter Lösungen dienen.

ist kein Ersatz für Begabung, erworbene Fähigkeiten, Situationskennt-nisse, geistige Auseinandersetzung mit Problemen u. ä., sondern setzt diese voraus bzw. soll sie stimulieren.

soll mit sinnvollem Problemlösungsverhalten verträglich sein.

274 Robert Konzelmann

ist kein Gegensatz zu Intuition und Kreativität, sondern macht diese zur Zielerreichung nutzbar.

bedeutet nicht Rezepte, sondern ist Leitfaden zur Problemlösung, der kreativ und intelligent anzuwenden ist. Der Nutzen der Anwendung er-gibt sich erst aus dem eingebrachten geistigen Potenzial.

ist hinsichtlich des zu treibenden Aufwands auf den zu erwartenden Nutzen auszurichten.

Die Schwierigkeit, die sich aus diesen Prinzipien ergibt, ist das finden der „goldenen Mitte“. Hier zeigt sich in der Praxis, dass das intuitive Vor-gehen dem methodischen oft überproportional vorgezogen wird. Dies auf Grund mangelnden Methodenverständnisses und dem daraus resultieren-dem fehlendem Vertrauen, grober Unterschätzung der zu bewältigenden Problematik und Überschätzung der eigenen Fähigkeiten.

Eine zusätzliche Schwierigkeit besteht darin, die für das jeweilige Prob-lem korrekte Methode zu identifizieren. Zu oft wird daher auf generische Ansätze zurückgegriffen, die die spezifischen Problematiken nur un-genügend berücksichtigen. Dies macht sich insbesondere auch in Projekten zum Aufbau von Data Warehouse-Systemen bemerkbar, die sich in grund-legender Hinsicht von konventionellen Systemen unterscheiden (Strauch u. Winter 2002):

Das Data Warehouse-System stellt einen äußerst aufwändigen Bereich der betrieblichen Informationsverarbeitung dar, der sukzessiv aufgebaut werden muss und nur bei langfristiger und ganzheitlicher Betrachtung nachhaltig wirtschaftlich betrieben werden kann. Im Gegensatz dazu sind traditionelle betriebliche Anwendungssysteme im Normalfall bes-ser isolierbar und müssen auch bei kurzfristiger, isolierter Betrachtung wirtschaftlich sein.

Alle Daten in einem Data Warehouse-System stammen aus den operati-ven Vorsystemen. Ein Data Warehouse-System kann also – im Gegen-satz z. B. zu Anwendungssystemen zur Unterstützung bestimmter Ka-näle oder Geschäftsbereiche (z. B. Call Center, Electronic Commerce) – nicht „auf der grünen Wiese“ entwickelt werden.

Die zukünftigen Benutzer eines Data Warehouse-Systems haben Schwierigkeiten, ihren Bedarf an Informationen, das heißt die Anforde-rungen an das zu entwickelnde System, zu Beginn eines Projekts über-haupt und abschließend zu spezifizieren. Für traditionelle betriebliche Anwendungssysteme ist dies zum Glück nicht der Normalfall.

Der Aufbau von Data Warehouse-Systemen stellt ein funktions- und be-reichsübergreifendes Projekt dar, das nur erfolgreich sein kann, wenn es von genügend hoher Stelle im Unternehmen gefördert wird. Im Gegen-

Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse 275

satz dazu lassen sich Verantwortlichkeiten für bereichs- oder funktions-bezogene betriebliche Anwendungssysteme sehr gut lokalisieren („ap-plication owner“).

Inmon definiert den Unterschied zwischen der Entwicklung von opera-tiven und analytischen Systemen kurz und bündig: „Operational develop-ment is shaped around a development lifecycle that begins with require-ments and ends with code. DSS processing begins with data and ends with requirements.“ (Inmon 1996). Diese eher plakative Aussage ist mit einer gewissen Vorsicht zu genießen, führt sie doch allzu oft zu einem ange-botsorientierten Data Warehouse-Entwicklungsansatz, bei dem die Endbe-nutzer nur wenig Einfluss auf die Systemerstellung haben (Strauch u. Win-ter 2002). Korrekt dagegen ist die Aussage, dass die Informationsbedarfs-analyse einen gewichtiger Beitrag zum Erfolg oder Misserfolg eines jeden Data Warehouse-Systems beisteuert, und daher spezieller Beachtung be-darf. Dazu werden in der Praxis heutzutage meistens die Anforderungen zuerst auf einer hohen Abstraktionsstufe erfasst und anschließend sukzes-sive verfeinert. Dies ermöglicht ein iteratives Vorgehen, bei dem zusam-men mit den Endbenutzern die Anforderungen ausgehend von den Ge-schäftszielen, über die daraus resultierenden Fachanforderungen mit ihren Kenn- und Steuerungsgrößen und der dafür benötigten Analysen der In-formationsbedarf erhoben werden. Das iterative Vorgehen ist aber nicht nur für die Informationsbedarfsanalyse von Wichtigkeit, sondern stellt ein zentrales Konstrukt einer jeden Data Warehouse-Methodologie dar. Damit wird die Komplexität des Gesamtsystems in überschaubare Inkremente aufgebrochen und dadurch die Implementierung von neuen Anforderungen in einem vorhersehbaren und für die Endbenutzer akzeptablen Zeitrahmen ermöglicht. Um diesem hehren Ziel gerecht zu werden, bedarf es neben der iterativen Methodologie, flexibler und skalierbarer Strukturen, die die Wi-derverwendbarkeit schon vorhandener Daten fördern und eine einfache In-tegration neuer Datenobjekte ermöglichen.

Die Teradata Solution Methodology (im weiteren TSM genannt) vereint all diese Anforderungen. Sie verfügt nicht nur über die oben erwähnten Grundkonzepte, sondern beinhaltet auch das Wissen und die Erfahrung aus einer Vielzahl erfolgreicher Data Warehouse-Implementierungen, welche jeweils in die kontinuierliche Weiterentwicklung der Methodologie ein-fließen.

1.1 Überblick Teradata Solution Methodology

Methoden sind planmäßig angewandte, begründete Vorgehensweisen zur Erreichung von festgelegten Zielen (i. a. im Rahmen festgelegter Prinzi-


pien). Zu Methoden gehören eine Notation, systematische Handlungsan-weisungen und Regeln zur Überprüfung der Ergebnisse (Hesse et al. 1992). Zu diesem Zweck definiert TSM in acht Phasen 43 Tätigkeiten, welche auf Aktivitätsebene die zu verwendenden Prozesse, Prozeduren und Techniken zusammen mit den dazugehörigen Rollen und Verantwort-lichkeiten beschreiben (vgl. Abb. 1). Entsprechende Arbeitsvorlagen und Beispiele aus vergangenen Data Warehouse-Projekten ergänzen die Me-thodologie um „Best Practice“ Vorgehen, ermöglichen dadurch die Ein-bindung von vorhandenem Wissen und unterstützen und vereinfachen die Planung, Durchführung und Kontrolle der einzelnen Aktivitäten. Welche der Phasen und Aktivitäten jeweils zur Anwendung kommen, hängt von der zu erstellenden Lösung und der bestehenden Umgebung ab und muss jeweils vor Projektbeginn definiert werden. Diese Selektion kann horizon-tal, über die Tätigkeiten, und / oder vertikal, über die Phasen, erfolgen. So wird zum Beispiel die Strategie-Phase nur zu Beginn einer Enterprise Data Warehouse-Initiative durchlaufen, um dadurch die generellen Einsatzmög-lichkeiten eines solchen Systems zu überprüfen und festzulegen. Andere Beispiele sind Projekte für die Datenqualitätsbereinigung, bei denen selek-tive Aktivitäten aus den Phasen Analyze und Build durchgeführt werden, oder Projekte, die den Betrieb eines Data Warehouse im Fokus haben und sich daher nur auf die Manage-Phase konzentrieren. Obgleich die in TSM definierten Phasen und Aktivitäten über eine logische Reihenfolge verfü-gen, handelt es sich nicht um ein klassisches Wasserfallmodell. Dies be-deutet insbesondere, dass Aktivitäten parallel ausgeführt werden können, und dass sie über einen iterativen Charakter verfügen. Weiter ist die ab-schließende Erstellung eines Objektes (wie zum Beispiel Analysedoku-mente oder Datenmodelle) nicht zwingend an eine einzelne Aktivität ge-bunden, sondern kann sich über mehrere Phasen, Tätigkeiten und Aktivi-täten erstrecken.

Die Phasen Strategy, Research und Analyze bilden die technologieneu-trale Planungsphase und beinhalten unter anderem die Erhebung und Ver-feinerung der Anforderungen und ihrer Informationsbedürfnisse, sowie die Definition der einzelnen Implementierungszyklen, sogenannte Inkremente. Am Ende dieser Phasen steht die logische Architektur.


Technical Expert

Solution Architect

System DBA

Availability SLA

Value Assessment

Hardware-Software Upgrade

User TrainingUser Curriculum

System Relocation

Acceptance Testing

Backup & Recovery

Technical EducationEducation Plan

Data MigrationInitial DataOperational Applications

Operational MentoringTest PlanInfrastructure

& Education

Business Continuity

Production Install

Information Exploitation

Support Management

Custom ComponentData MappingInformation

Sourcing

System PerformanceSystem TestECTL

ApplicationSoftware

InstallationPackage

AdaptationLogical ModelEDW MaturityEnterprise Assessment

Capacity Planning

Components for Testing

Physical Database

Hardware Installation

System Architecture

Application Requirement

Business Value

Opportunity Assessment

ManageIntegrateBuildEquipDesignAnalyzeResearchStrategy

Technical Expert

Solution Architect

System DBA

Availability SLA

Value Assessment

Hardware-Software Upgrade

User TrainingUser Curriculum

System Relocation

Acceptance Testing

Backup & Recovery

Technical EducationEducation Plan

Data MigrationInitial DataOperational Applications

Operational MentoringTest PlanInfrastructure

& Education

Business Continuity

Production Install

Information Exploitation

Support Management

Custom ComponentData MappingInformation

Sourcing

System PerformanceSystem TestECTL

ApplicationSoftware

InstallationPackage

AdaptationLogical ModelEDW MaturityEnterprise Assessment

Capacity Planning

Components for Testing

Physical Database

Hardware Installation

System Architecture


Business Value


ManageIntegrateBuildEquipDesignAnalyzeResearchStrategy

Planning

Implementation

Production

Abb. 1. Teradata Solution Methodology (TSM)

Die Phasen Design, Equip und Build bilden zusammen die technologie-getriebene Implementierungsphase, welche die physische Architektur defi-nieret und die Implementierung ihrer Komponenten steuert. Ein weiterer Schwerpunkt liegt in der Installation und Konfiguration der Systemumge-bungen und der benötigten Software. Um die Integrität der Gesamtlösung jederzeit gewährleisten zu können, hat jede Änderung oder Erweiterung zumindest die System Architecture Aktivitäten innerhalb der Design Phase zu durchlaufen.

Die Phasen Integrate und Manage bilden die Bereitstellungs- und Be-triebsphase, in der die erstellte Lösung getestet, integriert, in die Produk-tion übergeben und gemäß den Anforderungen betrieben wird.

Bevor wir nun in den folgenden Abschnitten aufzeigen, wie mittels TSM ein Data Warehouse-System erfolgreich zu gestalten ist, erscheint es uns als sinnvoll, den Begriff „System“ kurz zu erläutern. Dies insbeson-dere darum, weil in der Praxis leider immer noch viel zu oft ein be-schränktes, die Technologie in den Vordergrund stellendes, Systemver-ständnis existiert.

1.2 Systeme und Architekturen

„Das Wort System steht … für Konnektivität. Wir meinen damit jede An-sammlung miteinander in Beziehung stehender Teile … Was wir als Sys-


tem definieren, ist deshalb ein System, weil es miteinander in Beziehung stehende Teile umfasst und in gewisser Hinsicht ein … Ganzes bildet.“ (Daenzer u. Huber 1992). Jedes System lässt sich unter verschiedenen Ge-sichtspunkten betrachten und beschreiben. Dadurch treten jeweils be-stimmte Eigenschaften (Merkmale von Elementen und ihrer Beziehungen) in den Vordergrund. Einen weiteren wichtigen Aspekt eines Systems defi-niert der IEEE-Standard 1471-2000 für softwareintensive Systeme. Jedes System dient mindestens einem Zweck (dies hat zumindest für Informati-onssysteme seine Gültigkeit), der über die Bedürfnisse der Stakeholder de-finiert wird.

Abb. 2. IEEE-Standard 1471-2000 für softwareintensive Systeme (Schekkerman 2004a)

Die Architektur vereint die unterschiedlichen Sichten (Views) und be-schreibt somit das System. Dabei wird die Architektur als Gesamtarchi-tektur verstanden (vgl. hierzu z. B. Inmon et al. 1997), und definiert sich daher nicht ausschließlich über die Technologie, sondern beinhaltet auch die fachliche Sicht und die Informations- und Datensichten.

Angelehnt an das Integrated Architecture Framework (IAF, vgl. Mulhol-land u. Macaulay 2006) lassen sich sechs Sichten über vier Ebenen für eine Data Warehouse-Systemarchitektur definieren, um daraus die benötigten Sichten zu generieren.

Die erste Ebene definiert den Zweck des Gesamtsystems. Im speziellen geht es um die Ziele die mit dem System zu erreichen sind, die System-grenzen und die einzuhaltenden Rahmenbedingungen.

Die zweite Ebene definiert, was zu tun ist, um diese Ziele zu erreichen. Dabei wird auch das Gesamtsystem in eigenständige Inkremente unter-teilt.


Die dritte Ebene definiert technologieneutral, wie ein spezifisches Inkre-ment umgesetzt wird und beinhaltet die logische Architektur.

Die vierte Ebene definiert anhand der physischen Modelle, der benötig-ten technologischen Komponenten und ihrer Konfiguration die physi-sche Architektur.

Über diese Ebenen werden die Sichten gelegt, die die zu erstellenden Komponenten (Artefakte) und ihre Beziehungen definieren.

Die fachliche Sicht beschreibt alle bestehenden und zu erstellenden fachlich relevanten Komponenten wie Geschäftsziele, Geschäftspro-zesse und Organisationsstrukturen.

Die Informationssicht definiert alle bestehenden und zu erstellenden fachlich relevanten Informationskomponenten wie Kommunikations-modelle, Datenflüsse und Datenmodelle.

Die Informationssystemsicht definiert alle bestehenden und zu erstellen-den Informationssysteme (Eigenentwicklungen und Standardsoftware), die die Geschäftsprozesse unterstützen und die relevanten Informationen beinhalten.

Die Technologiesicht definiert die vorhandene und benötigte Infrastruk-tur.

Die Betriebssicht definiert alle vorhandenen und benötigten Betriebs-komponenten. Sie ist ein interdisziplinärer Bestandteil aller vorherge-henden Sichten.

Die Sicherheitssicht definiert alle vorhandenen und benötigten Sicher-heitskomponenten. Sie ist ein interdisziplinärer Bestandteil aller vorher-gehenden Sichten.

Die Sichten (Views) ergeben sich aus der Gruppierung und Selektion von verschiedenen Artefakten, die zusammen einen Teilaspekt der Ge-samtarchitektur definieren. Die Teradata Solution Methodology verfügt über mehrere solcher vordefinierter Sichten, die für die einzelnen Projekte individuell anpassbar sind. Abbildung 3 zeigt die Views für eine Enterprise Data Warehouse-Architektur, welche in den nächsten Abschnitten näher erläutert wird.


Information System Technology Infrastr. Security GovernanceInformationBusiness


Enterprise Assessment

Business Value

Data Warehouse Maturity

Information Sourcing


Logical Model

Data Mapping

Package Adaption

System Architecture

Custom Components

Test Plan

Abb. 3. Architekturrelevante TSM-Phasen (angelehnt an das Integrated Architec-ture Framework)

Ziel der nachfolgenden Abschnitte ist es, aufzuzeigen, wie mit Hilfe von TSM eine konsistente, erweiterbare und anforderungsgetriebene Data Warehouse-Architektur erstellt werden kann. Dafür werden die vier Pha-sen Strategy, Research, Analyze und Design genauer betrachtet. Während die darin enthaltenen Aktivitäten für die meisten Data Warehouse-Projekte ihre Gültigkeit haben und generell beschrieben werden können, hängt die physische Umsetzung der Architektur und der spätere Betrieb des Data Warehouse-Systems stark von den zu verwendenden einzelnen technischen Komponenten und Werkzeugen, sowie von der Umgebung, in der es be-trieben wird, ab. Die Phasen Equip, Build, Integrate und Manage tragen diesem Umstand Rechnung, und sind daher sehr umfangreich gestaltet. Es wird daher im Rahmen dieses Buches darauf verzichtet, diese im Detail zu beschreiben.

2 Planungsphasen

Das wohl meistzitierte Gespräch zwischen Mensch und Tier in IT-Pro-jektmethodologie-Büchern stammt aus „Alice's Adventures in Wonder-land“ (Carroll 1865) und identifiziert das Problem so mancher Planung:


Das Fehlen einer der drei Komponenten Ist-Situation, Soll-Situation und des Wegs von Ist zu Soll.

„‘Would you tell me, please, which way I ought to go from here?‘ said Alice. ‘That depends a good deal on where you want to get to‘, said the Cat. ‘I don't much care where –‘ said Alice. ‘Then it doesn't matter which way you go‘, said the Cat.“

Diese drei Komponenten sind die Treiber der folgenden technologie-unabhängigen Planungsphasen und decken sich im Wesentlichen mit den von Strauch und Winter definierten Anforderungen für die Informations-bedarfsanalyse (Strauch u. Winter 2002):

Informationslandkarte: Als Ergebnis der Informationsbedarfsanalyse im Data Warehousing wird eine so genannte „Informationslandkarte“ ver-langt, die auf aggregierter Ebene beispielsweise Aussagen darüber macht, aus welchen Quellsystemen welche Daten stammen, welche Or-ganisationseinheiten welche Informationen erhalten, welche Begriffe homonym bzw. synonym verwendet werden etc.

Ist-Zustand der Informationsversorgung: Die Informationsbedarfsana-lyse muss den Ist-Zustand der Informationsversorgung erfassen können. Dies bedingt sowohl die Analyse der bereits angebotenen Informationen wie auch der Datenqualität in den Quellsysteme. Die hiermit erzielten Ergebnisse müssen in die Informationslandkarte einfließen.

Soll-Zustand der Informationsversorgung: Der Soll-Zustand der Infor-mationsversorgung muss auch zukünftige Anforderungen an die In-formationsversorgung mittels Data Warehouse-Systemen umfassen.

Priorisierung: Die durch das Data Warehouse-System bereitzustellen-den Informationen müssen auf Grund von beispielsweise zeitlichen oder finanziellen Restriktionen und ihrer Wichtigkeit für die betriebliche Aufgabenerfüllung beurteilt und priorisiert werden.

Homogenisierung der Begriffe: Die Integration operativer Daten in ei-nem zentralen Data Warehouse bedingt die Vereinheitlichung der darauf aufbauenden Informationen und der entsprechenden Begriffswelt.

Abstimmung mit dem Modellierungsansatz: Die Informationsbedarfs-analyse muss die Objekte des gewählten semantischen Datenmodells (Fachkonzept) berücksichtigen. Dabei werden multidimensionale, se-mantische Datenmodelle bevorzugt.

Dokumentation: Die Informationsbedarfsanalyse liefert wertvolle Meta-daten, die maschinell erfasst werden sollten, um diese im Anschluss an ein Data Warehouse-Projekt nicht mit hohem Aufwand zusammentra-gen zu müssen.


2.1 TSM Phase: Strategy

Gängigen Business Engineering-Ansätzen folgend wird in dieser ersten Phase die strategische Positionierung des Data Warehouse spezifiziert (Winter 2003). Diese definiert insbesondere das „WARUM wird das Sys-tem benötigt“, den Umfang und generell gültige Grundsätze. Allzu oft wird zu wenig Gewicht auf den eigentlichen Sinn und Zweck des Systems gelegt, und zu rasch der Fokus auf die zu erstellende Lösung gelegt. Der Grund dafür liegt oft in der kurzsichtigen Annahme, dass die Entwicklung von anforderungsgetriebenen Data Warehouse-Lösungen zu zeitintensiv sei. Basierend auf unseren Erfahrungen lohnt sich jedoch dieser Aufwand, garantiert doch nur dieser die Akzeptanz und die Verwendung des Systems durch die Endbenutzer (vgl. dazu auch Strauch u. Winter 2002; Gam u. Sa-linesi 2006).

Inmon et al. formulieren diesen Umstand sehr treffend: „If motivations are ignored, the result may be a system which is very efficient in addres-sing the wrong objective.“ (Inmon et al. 1997).

2.1.1 TSM Tätigkeit: Opportunity Assessment

Ziel dieser Aktivitäten ist es, Nutzen und Einsatzmöglichkeiten einer mög-lichen Enterprise Data Warehouse-Lösung zu evaluieren. Dafür wird die Ist-Situation erhoben und mit den Unternehmenszielen verglichen. Even-tuelle Diskrepanzen werden dahin gehend untersucht, ob und in wie weit diese auf fehlende oder ungenügende Informationsversorgung zu-rückzuführen sind. Dabei sollten auch Referenzen aus demselben oder vergleichbaren Geschäftsumfeld herbeigezogen werden, um zu verstehen, wie der Markt diese Themen angeht und wohin er sich in der nähren Zu-kunft bewegt.

Am Ende dieser Aktivitäten steht eine Empfehlung, ob und in welchen Bereichen mit welchen Zielen ein Data Warehouse-System zu erstellen ist.

2.1.2 TSM Tätigkeit: Enterprise Assessment

Ausgehend von den definierten Zielen wird die Machbarkeit einer Data Warehouse-Einführung für alle relevanten Geschäftsbereiche anhand ihrer bestehenden Applikations- und Systemlandschaft, ihrer vorhandenen und benötigten Informationsarchitektur und ihrer Prozesse erhoben und ge-wichtet. Am Ende steht die Data Warehouse-Implementierungsstrategie, die die identifizierten und gewichteten einzelnen Data Warehouse-Initiati-ven beschreibt.


Dazu werden verschiedene Übersichten und erste Modelle erstellt, die im Laufe des Projektes stetig verfeinert werden.

Die Plattformübersicht ist eine erste Ist-Aufnahme aller relevanten Hardware- und Netzwerkkomponenten inklusive ihres Standortes. Zusätz-lich zu dokumentieren sind geplante Systemerweiterungen oder Ablösun-gen und ihr Einfluss auf die bestehende oder die neu zu erstellende Data Warehouse-Umgebung.

Die Applikationsübersicht ist eine erste Ist-Aufnahme aller potenziellen Quellen des zukünftigen Data Warehouse, ihrer Datenstrukturen und Schnittstellen. Zusätzlich zu dokumentieren sind geplante Erweiterungen oder Ablösungen und ihr Einfluss auf die bestehende oder die neu zu er-stellende Data Warehouse-Umgebung.

Die Organisationsübersicht ist ein um die System- und Applikations-verantwortlichen erweitertes Organigramm. Es dient insbesondere dazu, die benötigten Spezialisten frühzeitig zu identifizieren und ihre jeweilige Verfügbarkeit zu dokumentieren.

Das Geschäftsprozessmodell bildet die heutigen und die zukünftigen Prozesse auf einer hohen Abstraktionsstufe ab. Ziel ist die Identifizierung der für das nachfolgend zu erstelllende Informationsmodell benötigten Kernentitäten.

Das Informationsmodell ist ein in der ersten Normalform gehaltenes lo-gisches Data Warehouse-Datenmodell. Dabei wird auch das initiale Data Dictionary erstellt, das die Definitionen der Entitäten und ihrer Beziehun-gen enthält.

2.2 TSM Phase: Research

Basierend auf dem in der Strategy Phase definierten Gesamtumfang wer-den für die einzelnen Geschäftsbereiche die einzelnen Lösungen definiert und priorisiert. Dafür können die folgenden Kenngrößen als Entschei-dungskriterien verwendet werden (Geiger 2007):

Prognostizierter Geschäftsnutzen Datenverfügbarkeit im Unternehmen Komplexität der Lösung

Die nebenstehende Grafik visualisiert diese Kriterien anhand eines Ent-scheidungswürfels. Danach sollten die Projekte im äußeren rechten Quader (hoher Geschäftsnutzen, hohe Datenverfügbarkeit, geringe Komplexität) zuerst angegangen werden, gefolgt von den Projekten mit hohem Ge-schäftsnutzen.


Datenverfügbarkeit

Tief Hoch

GeschäftsnutzenTief

Hoch

Zu priorisierendeLösungen

Abb. 4. Entscheidungswürfel

Ziel der folgenden Aktivitäten ist es, diese Kriterien zu erheben und ihr Wechselspiel aufzuzeigen. Daraus resultiert die Data Warehouse-Gesamt-planung, welche die einzelnen zu erstellenden Lösungen gruppiert, und gemäß dem inkrementellen Vorgehen priorisiert (vgl. Abb. 5).

Inkrement 1 Inkrement 2 Inkrement 3EDW Infrastruktur Integrierte Kundensicht Kundenverhalten Finanzberichte

Ziel und Zweck

Erstellen einer zentralen und skalierbaren Data Warehouse-Infrastrukturfür die Gesamtunter-nehmung

Integrieren und unifizieren der unter-nehmensweiten Kunden-daten, um eine „Single View of the Client“ zu ermöglichen

Durch die Integration von Transaktionsdaten können das Kundenverhalten analysiert und Seg-mente erstellt werden

Das Erstellen aller unternehmensweiten Finanzberichte geschieht über das Data Warehouse

BIO Datenarchitektur, analytische Architektur und Modellierung

Unternehmensweite DatenintegrationDatenqualitätMaster Data Management

KundenbindungZahlungsanalyse

Finanzkennzahl-Reporting

Benötigte Daten

KundenstammdatenProduktdaten

Transaktionsdaten GL-Daten

Haupt-aktivitäten

Aufbau Infrastruktur (Hardware und Software)Aufsetzen der benötigten Prozesse

DatenmodellierungErstellen der Lade-programmeErstellen von BerichtenAufsetzen von Daten-qualitätsprozessen

Erweitern des Datenmodells um TransaktionsdatenErstellen Ladeprogramme für Transaktionsdaten

Erweitern des Datenmodells um FinanzdatenErstellen der LadeprogrammeErstelle der einzelnen Berichte

Zeitrahmen 1 Monat 8 – 10 Monate 4 – 6 Monate 4 – 6 Monate

Abb. 5. Beispiel-Übersicht über eine Data Warehouse-Gesamtplanung


2.2.1 TSM Tätigkeit: Business Value

Um den Geschäftsnutzen einzelner Data Warehouse-Lösungen quantifizie-ren und gewichten zu können, müssen diese erst einmal erhoben und ana-lysiert werden. Dafür hat sich in der Praxis ein vierteiliger Regelkreis be-währt; sogenannte Business Improvement Opportunities1 (BIO). Dabei werden die Geschäftsmöglichkeiten, die sich aus den Geschäftszielen ab-leiten lassen, erhoben, und daraus der Informationsbedarf2 der zur Steue-rung und Kontrolle notwendigen Aktivitäten definiert. Die daraus entste-henden Prozessverbesserungen generieren den Geschäftsnutzen. Die nachfolgende Grafik zeigt einen solchen Regelkreis am vereinfachten Bei-spiel „Erhöhung der Kundenbindung“:

Ziele:• Identifizieren der „wertvollen“ Kunden• Verbessern der Kundenloyalität• Frühes Erkennen von abwanderungswilligen

Kunden, und Einleiten von geeigneten Gegenmaßnahmen

Analysen:• Kundenprofitabilität• Kundenakquisitionskosten• Erfolg der Kundenbindungsmaßnahmen• Kundeloyalität und Zufriedenheit• Veränderungen im Kundenverhalten• Nächstbestes Angebot

Resultate:• Erhöhte Kundenbindung und Loyalität• Erhöhter LTV (durchschnittlich um x%)• Erhöhte Kundenzufriedenheit (Reduktion der

Beschwerden um x%)• Reduzieren der Kundenakquisitionskosten (um

x% für Segment A / y% für Segment B …)

• Vermehrter Up-und Cross-Sell (durchschn. Anzahl Produkte = x)

Aktivitäten:

• Entwickeln von kundenzentrierten Angeboten, um profitable Kunden zu behalten und / oder zurückgewinnen

• Entwickeln von Kundenloyalitäts-Programmen, um die Kundenbindung zu erhöhen

Abb. 6. Business Improvement Opportunity-Beispiel: Erhöhung der Kundenbin-dung

Lassen sich die ersten drei Komponenten durch gezielte Analyse erhe-ben, so ist es doch ungemein anspruchsvoller, die anzustrebenden Resul- 1 Eine Business Improvement Opportunity enthält die Definition einer Geschäfts-

initiative, die einmal umgesetzt einen direkten Geschäftsnutzen erzeugt (o. V. 2006b).

2 Der Informationsbedarf wird definiert als die Art, Menge und Qualität der In-formationen, die eine Person zur Erfüllung ihrer Aufgaben in einer bestimmten Zeit benötigt. Er ist in vielen Fällen nur vage bestimmbar und hängt vor allem von der zu Grunde liegenden Aufgabenstellung, den angestrebten Zielen und den psychologischen Eigenschaften des Entscheidungsträgers ab (Picot et al. 1996, S. 106).


tate und den daraus zu erwartenden Nutzen, zu spezifizieren und quantifi-zieren. Eigene Erfahrungen und Vergleichsdaten aus ähnlichen Projekten und Branchen können hierfür eine erste Basis bieten und damit diesen Pro-zess entscheidend unterstützen. Einen Schritt weiter gehen die Business Impact Models (BIM) von Teradata, die neben Referenzdaten auch über branchen- und lösungsspezifische Berechnungsmodelle verfügen und so nicht nur den Nutzen, sondern auch die zu erwartenden Kosten antizipieren können. Unabhängig vom gewählten Vorgehen resultieren dabei immer Näherungswerte, können doch verlässliche Kostenaussagen erst nach der Analyse zusammen mit der Auswahl der technischen Komponenten und der daraus abzuleitenden Architektur gemacht werden.

Das zweite Selektionskriterium für die Initiativen, die Datenverfügbar-keit, sagt aus, in wie weit die einzelnen Informationsbedarfe durch beste-hende operationelle oder analytische Systeme befriedigt werden können. Dieses lässt sich über Fragestellungen und benötigte Mess- und Kenngrö-ßen (sogenannte Key Performance Indicators, KPIs) erheben. Für die „Er-höhung der Kundenbindung“ könnten diese unter anderem lauten:

Fragestellungen

Wie viele Kunden können nicht bedient werden, wenn x% unserer Ban-komaten während y Stunden nicht verfügbar sind?

Welche Muster im Kundenverhalten deuten auf eine baldige Auflösung der Geschäftsbeziehung hin?

Was ist das typische Kundenprofil pro Produkt?

KPIs

Durchschnittliche Anzahl Transaktionen pro Kundensegment Kundenprofitabilität Kundenfluktationsrate

Fragestellungen und KPIs können dabei Teil mehrerer Business Impro-vement Opportunities sein. Dabei zeigt sich auch einer der Hauptnutzen eines Enterprise Data Warehouse, ermöglicht dieses doch, mittels dersel-ben Daten unterschiedliche Informationsbedürfnisse unternehmensweit, geschäftsbereichsübergreifend zu unterstützen. Daraus lässt sich auch das dritte Selektionskriterium, die Komplexität, ableiten. Diese ist insbeson-dere davon abhängig, wie viele neue Datenobjekte aus unterschiedlichen Datenquellen zu extrahieren, laden und integrieren sind. Dafür ist eine Gruppierung der einzelnen Business Improvement Opportunities anhand ihrer Informationsbedarfe und der daraus abzuleitenden Datenobjekte not-wendig. Um diese Komplexität sinnvoll abbilden und analysieren zu kön-


nen, stellt Teradata ein Visualisierungswerkzeug zu Verfügung, das nach-folgend kurz beschrieben werden soll.

Teradata EDW Roadmap

Die Teradata Enterprise Data Warehouse-Roadmap ist ein Planungswerk-zeug, welches dem Benutzer einerseits ermöglicht, sich eine Übersicht be-züglich des momentanen Nutzens und Informationsgehalts seines Data Warehouse zu verschaffen und anderseits zu analysieren, mit welchem Aufwand welche zusätzlichen BIOs, Fragestellungen und KPIs unterstützt werden können. Die nachfolgende Abbildung zeigt die Gesamtübersicht und die Verknüpfung einer Fragestellung (in der Mitte links) zu einer Bu-siness Improvement Opportunity (oben in der Mitte) und zu den benötigten Datenobjekten (untere Hälfte) und ihren Quellen. Weiter lassen sich auch erkennen, für welche Geschäftsbereiche (oben rechts) diese Fragestellung relevant ist. Darüber hinaus zeigt die EDW Roadmap, in wie weit für die Fragestellungen und KPIs benötigten Daten im DWH vorliegen.

Abb 7: Teradata Enterprise Data Wareouse Roadmap (EDWr, vgl. o. V. 2006b)

Analysen können dabei über den Ist-Zustand durchgeführt werden, wie zum Beispiel “Welche Fragestellungen und KPIs können heute schon durch das Data Warehouse beantwortet werden?“, oder zukünftige Inkre-mente betreffen und damit die Planung und Priorisierung aktiv unterstüt-zen.


Entscheidend für die Qualität der Analysen ist die dem Modell zu Grun-de liegende Datenbasis. Diese besteht einerseits aus den Vergleichsdaten, d. h. der Beschreibung der einzelnen Objekte, ihrer Verknüpfungen und ih-rer relativen Gewichtung zueinander, und anderseits aus der Informatione, welche Daten bereits im Data Warehouse zur Verfügung stehen. Die Ver-gleichsdaten basieren auf den gesammelten Erfahrungen aus bran-chenspezifischen Teradata Data Warehouse-Projekten und können durch das Projekt beliebig verändert oder erweitert werden. So enthält zum Bei-spiel die Roadmap für die Finanzdienstleistungsbranche 29 Business Im-provement Opportunities, 387 Fragestellungen und 161 KPIs mit ihren je-weiligen Abhängigkeiten und Verknüpfungen. Die Datenobjekte basieren auf dem Teradata Financial Services Logical Data Model (TD FS-LDM), welches mit seinen mehr als 1700 Entitäten in der Lage ist, ein Gesamtun-ternehmen umfassend abzubilden.

2.2.2 TSM Tätigkeit: Data Warehouse Maturity Assessment

Im Gegensatz zu den vorhergehenden Aktivitäten, welche neue Anforde-rungen erhoben und gewichteten, fokussiert ein Data Warehouse Maturity Assessment auf das bestehende System. Es ermöglicht die Gegenüberstel-lung der Geschäftsziele mit der momentanen Funktionalität der analyti-schen Plattform und zeigt Schwachstellen auf, die das Erreichen dieser Ziele erschweren oder gar verhindern können. Dafür muss ein Modell verwendet werden, welches die unterschiedlichen Reifestadien betreffend der Prozessführung und -steuerung innerhalb einer Unternehmung mit der einer analytischen Plattform vergleichen kann. Die involvierten Geschäfts-bereiche müssen dabei einzeln bewertet werden, da sich diese in unter-schiedlichen Stadien befinden können.

Eine zusätzliche, insbesondere für die Data Warehouse-Strategie inter-essante Sicht ist der Vergleich gegen den Markbenchmark. Voraussetzung dafür ist die Verwendung eines etablierten Modells, welches über bran-chen- oder lösungsspezifische Vergleichsdaten verfügt. Ein solches ist das Teradata Data Warehouse Maturity Model, welches für jede Reifestufe spezifische Analysebedürfnisse definiert. Diese basieren auf der Annahme, dass die Komplexität der Analysen und ihre Einbindung in die Geschäfts-prozesse mit der jeweiligen Reife der Geschäftsbereiche steigt.


Operate Understand Change Grow Compete Lead

Is ithappening?

Whathappened?

Why did ithappen?

What will happen?

What is happening?

Make it happen!

Business Maturity

Data Warehouse MaturityAbb: 8: Teradata Data Warehouse Maturity Model Bewertungsskala

Operate (Stufe 1) Das Unternehmen befindet sich in der Aufbauphase und hat den Fokus auf die Entwicklung seiner Produkte und Leistungen. Die Analysen werden direkt aus den operationellen Systemen oder aus nicht integrierten Eigenlösungen (z. B. Excel.Lösungen) erstellt. Understand (Stufe 2) Das Unternehmen ist weiterhin im Aufbau, verfügt aber über klar definierte Geschäftsziele und misst sich dagegen. Für die Analyse werden einfache Batchreports aus einer zentralen oder dezentralen Analyseumgebung erstellt. Change (Stufe 3) Das Unternehmen verfügt über eine Geschäftsstrategie, die sich über die Kundenzufriedenheit bezüglich der angebotenen Produkte und Leistungen definiert. Für erweiterte Analysen werden spezifische Data Marts mit OLAP-Fähigkeiten erstellt. Grow (Stufe 4) Das Unternehmen verfügt über alle grundlegenden Pro-zesse. Seine Wachstumsstrategie beinhaltet nun auch externe Faktoren und basiert unter anderem auf Vorhersagen. Technisch und analytisch versierte Benutzer verwenden vermehrt die Daten direkt im Data Warehouse zur Erstellung von Trendanalysenmodellen. Compete (Stufe 5) Um die Geschäftszyklen korrekt zu antizipieren und die Marktstellung langfristig zu behaupten, entwickelt das Unternehmen seine Prozesse, Infrastruktur, Organisation und Kultur stetig weiter. Daten werden täglich, und vermehrt auch untertags, in das Data Warehouse gela-den. Die Analyse basieren auf integrierten und granularen Datensätzen. Lead (Stufe 6) Anhaltende Innovationen bezüglich Produkten, internen Prozessen und des Umgangs mit Informationen steigern nachhaltig die Produktivität der Unternehmung. Das Data Warehouse ist operationalisiert und wird zeitgerecht geladen, um so Geschäftsprozesse direkt zu unterstüt-zen oder anzustoßen.

Das Modell sieht vor, dass man in einem ersten Schritt den Geschäftsbe-reich oder die Geschäftsbereiche mittels Interviews und Dokumentenstu-dien anhand dieser sechs Stufen bewertet. Das Resultat ist ein gewichteter Wert und soll den generellen Trend widerspiegeln. In einem zweiten Schritt wird die analytische Landschaft (Data Warehouse und eventuelle


Data Marts) aus dem Blickwinkel der Planung, der Benutzer, der Daten und des Betriebes betrachtet und gemäß der Skala bewertet.

Die Planungssicht beschäftigt sich mit den Fragen, wie mit Anforderun-gen und ihrer Finanzierung umgegangen wird, wie ihr Nutzen gemessen wird welche architektonischen Vorgaben und Richtlinien bestehen und wie diese umgesetzt werden.

Die Benutzersicht beschäftigt sich mit den Fragen, welche Mitarbeiter wie, wann, wo und mit welchen Mitteln Zugriff auf die Daten erhalten. Auch wird erhoben, wie die Benutzer bezüglich der Verwendung der ana-lytischen Plattform geschult und auf dem Laufenden gehalten werden.

Die Datensicht beschäftigt sich mit den Fragen, wie und wo Daten in-tegriert werden, wo welche Analysen stattfinden und welche Datenmodelle dafür verwendet werden. Ein weiterer Schwerpunkt wird dabei auf die Da-tenqualität und Datensicherheit gelegt.

Die Betriebssicht beschäftigt sich mit den Fragen, wie die durch das Be-laden und durch die Analysen und Berichte generierten Arbeitslasten mi-teinander in Einklang gebracht werden und ihren Einfluss auf die mit den Endbenutzern vereinbarten Service Level Agreements (SLA). Hierzu wird auch die Ausfallsicherheit und die Backup- und Recovery-Fähigkeit des Gesamtsystems untersucht.

Die daraus resultierende Bestandsaufnahme der analytischen Umgebung zeigt die Diskrepanzen zwischen der Ist-Architektur und der von den Ge-schäftszielen abgeleiteten Zielarchitektur auf. Dabei werden zu schlie-ßende Lücken wie auch überdimensionierte Lösungskomponenten be-leuchtet.

2.2.3 TSM Tätigkeit: Information Sourcing

Das Information Sourcing schließt die Arbeiten rund um die kontextuelle Ebene ab. In dieser Tätigkeit werden die fehlenden Informationen bezüg-lich der potenziellen Quellsysteme und der darin erhaltenen Datenelemente auf Entitätsebene erhoben, analysiert und dokumentiert. Als Basis dafür dienen die erhobenen Fragestellungen, KPIs und anderen existierenden Anforderungen (zum Beispiel gesetzliche Auskunftspflichten oder Be-richte). Dabei ist jeweils zu beachten, dass die Daten aus dem System ge-laden werden, dass auch über die Daten-Ownership verfügt. In den meisten Fällen ist dies das System, in dem die Daten ursprünglich generiert wur-den. Alle Bereiche, die einen Einfluss auf die Erstellung der Schnittstellen und das spätere Beladen haben, müssen dokumentiert werden. Dies betrifft insbesondere Informationen betreffend des Betriebssystems, der Daten-bank und Filesystem sowie der Verfügbarkeit des Gesamtsystems und der benötigten Datensätze.


Die nachfolgende Analysephase detailliert die Anforderungen des zu erstellenden Inkrementes, wodurch erste verlässliche Angaben betreffend des Aufwands gemacht werden können.

2.3 TSM Phase: Analyze

Gemäß Strauch und Winter muss eine Methodik für die Informationsana-lyse im Data Warehousing ausgehend vom Informationsbedarf der Benut-zer einen Abgleich mit dem Ist-Zustand der Informationsbereitstellung vornehmen, abzudeckende Informationsbedarfe bewerten, priorisieren und homogenisieren, um schließlich daraus die Datensicht des Data Ware-house-Fachkonzepts abzuleiten (Strauch u. Winter 2002). Wurde dies in der vorhergehenden Phase für das Gesamtsystem auf einer höheren Ab-straktionsstufe durchgeführt, werden diese Ergebnisse nun für das zu im-plementierende Inkrement detailliert.

2.3.1 TSM Tätigkeit: Application Requirements

Eine im Jahr 2000 durch die Standish Group International durchgeführten Studie identifiziert das Fehlen von „firm basic requirements“ als eine der zehn häufigsten Gründe für das Scheitern von IT-Projekten. Das Resultat einer internen Teradata Studie aus dem Jahre 2005 zeigt auf, dass 90% al-ler befragten Projektleiter das Anforderungsmanagement als ihre größte Herausforderung sehen (vgl. Tabelle 1).

Tabelle 1. Teradata Project Methodology (TPM) Umfrageergebnisse 2005

Wichtigste Prozessprioritäten für TPM 5.0 nach Bereich Prozessbereich / TPM Work Stream % Angaben 1. Anforderungsmanagement 90% 2. Risikomanagement 86% 3. Qualitätsmanagement 81% 4. Zeit- und Budgetmanagement 76% 5. Konfigurationsmanagement 62%

Die Schwierigkeiten bei der Anforderungserhebung liegen meist im De-

tail und sind so vielschichtig wie das zu erstellende System. Objektiv las-sen sie sich dennoch meistens auf folgende grundlegende Schwierigkeiten zurückführen.


Die meisten Projekte enthalten Anforderungen von verschiedenen Be-nutzergruppen und Organisationseinheiten, welche sich oft nur schwer miteinander in Einklang bringen lassen.

Dem Projektteam fällt es schwer, die Anforderungen mit dem notwendi-gen Detaillierungsgrad zu erheben. Während die oft begrenzte Verfüg-barkeit der benötigten Spezialisten innerhalb des Unternehmens zu einer oberflächlichen Analyse führt, birgt die Tendenz von vielen Projektmi-tarbeitern, über das absolute Wissen verfügen zu müssen, die Gefahr ei-ner nicht endenden Analysephase. Eine weitere Schwierigkeit kann sich auch aus einer vorgängigen Proof of Concept-Phase ergeben, in der den Endbenutzern schon eine „fertige“ Lösung präsentiert wurde und er da-her den Sinn einer weiteren Analyse nicht mehr einsieht.

Oft fehlt das Verständnis betreffend des Projektziels und der dafür zu erbringenden Leistung. Es ist insbesondere immer wieder in IT-Projek-ten zu beobachten, dass man versucht, die Lösung zu „vergolden“, in-dem man zusätzliche, meistens technische, Anforderungen einbringt, die nicht zur Erreichung der Projektziele notwendig sind.

Endbenutzer sind sich zu Projektbeginn oft unschlüssig, was sie benöti-gen (eher schon können sie definieren, was sie nicht wollen). Endbenut-zer wissen, was sie wollen wen sie es sehen und versuchen daher, neue Anforderungen in späteren Projektphasen einzubringen.

Wie solche Schwierigkeiten anzugehen sind, wurde in unzähligen Me-thodologien und Büchern bereits ausführlich festgehalten (vgl. z. B. Schienmann 2001). Es soll daher nicht Ziel dieses Beitrags sein, diese hier wiederzugeben. Nichtsdestotrotz scheint es uns von Bedeutung, die für uns wichtigsten Grundsätze in Bezug der Anforderungserhebung kurz zu er-läutern.

Die Endbenutzer müssen über den Nutzen und die Wirkung von Anfor-derungen Bescheid wissen und bereit sein, ihr fachliches Wissen an das Projektteam weiterzugeben.

Das Erheben der Anforderungen erfolgt nach einem definierten Prozess mit definierten Endprodukten. Welche Methodologie dabei eingesetzt wird (z. B. Use Cases) ist zweitrangig und hängt von den Rahmenbe-dingungen und den Fähigkeiten der Projektmitarbeiter ab. Eine Anfor-derung besteht immer aus der Motivation, der Ist-Situation, der Soll-Si-tuation und Transformation von Ist zu Soll. Unsicherheiten werden als Annahmen beschrieben, inklusive ihrer Auswirkungen, falls sie sich zu einem späteren Zeitpunkt als inkorrekt erweisen.

Prototyping und grafische Darstellungen helfen den Endbenutzern, ihre Anforderungen zu spezifizieren und zu verifizieren.


Das Projekt muss die Möglichkeit haben, auf sich verändernde Anforde-rungen zu reagieren. Dafür benötigt es zwingend neben den erforderli-chen Detailkenntnissen eine ganzheitliche Sicht auf das zu entwickelnde System und seine Umsysteme.

Gemäß IEEE Software Engineering sind Anforderungen Voraussetzun-gen oder Fähigkeiten, die ein System oder eine Systemkomponente gemäß Vertrag, Standard, Spezifikation oder anderen formellen Dokumenten er-füllen muss, um durch den Auftraggeber akzeptiert und abgenommen zu werden. Daraus lässt sich ableiten, dass Anforderungen eine Zerlegung des Gesamtsystems sind, wobei diese Komponenten in sich abgeschlossene und messbare Einheiten bilden müssen. Gemäß der Teradata Project Me-thodology (o. V. 2006a) sollten Data Warehouse-Anforderungen den fol-genden Kriterien genügen:

Benötigt: Anforderungen beschreiben die von einem Benützer oder Sys-tem benötigten Funktionen und Fähigkeiten um eine bestimmte Aufgabe und ihre Ziele zu erfüllen.

Durchführbar: Anforderungen müssen mittels der vorhandenen techni-schen und monetären Mittel erreichbar sein und müssen sich innerhalb der bekannten Rahmenbedingungen bewegen.

Testbar: Anforderungen müssen so gestellt sein, dass sie mittels eines definierten Verfahrens eindeutig auf ihre korrekte Implementierung ge-testet werden können.

Vollständig: Alle kritischen Anforderungen an ein System müssen defi-niert werden. Als kritische Anforderungen werden solche definiert, die ein System daran hindern, seinen eigentlichen Zweck zu erfüllen, falls sie weggelassen werden.

Elementar: Anforderungen sollen in kleinstmöglicher (elementarer) Form definiert werden.

Einmalig: Jede Anforderung darf nur einmal existieren und muss ein-deutig identifizierbar sein.

Lösungsneutral: Anforderungen enthalten keine Spezifikationen, wie eine Lösung zu implementieren ist. Diese sind in Rahmenbedingungen festzuhalten, gegen die die einzelnen Anforderungen jeweils geprüft werden (siehe Durchführbar).

Nachvollziehbar: Anforderungen müssen nachvollziehbar sein und In-formationen über ihren Ursprung enthalten.

Abhängigkeiten aufzeigen: Abhängigkeiten von oder zu anderen Anfor-derungen müssen definiert und dokumentiert sein. Dies gilt sowohl für funktionale wie auch nichtfunktionale Anforderungen.


Priorisiert: Anforderungen müssen gemäß ihrer Wichtigkeit priorisiert werden.

Vorgehen Zu Beginn einer Anforderungsanalyse steht immer die Defini-tion des Projektumfanges. Dieser ergibt sich aus der Dekomposition der definierten BIOs in einzelne logisch und technisch zusammenhängende Lösungen, die jeweils als eigenständiges Inkrement implementiert werden. Dabei gilt es zu beachten, dass die Durchlaufzeit für die Entwicklung eines Inkrementes relativ kurz sein sollte, um einerseits zeitnah auf neue Anfor-derungen reagieren zu können und anderseits um den Wildwuchs von nicht integrierten „quick and dirty“ Lösungen in den einzelnen Geschäftsberei-chen zu unterbinden.

Ein wichtiger Erfolgsfaktor einer jeden Anforderungsanalyse ist das Verständnis des logischen Aufbaus von Anforderungen und ihren Wech-selwirkungen. So werden in der Praxis leider immer noch viel zu oft allein stehende Teilsichten erhoben, die sich in einer späteren Phase entweder als widersprüchlich oder als lückenhaft erweisen. Die folgenden Aspekte soll-ten unserer Erfahrung nach durch eine Analyse beleuchtet werden:

Fachliche Anforderungen - Fachliche Anforderungen beinhalten alle notwendigen Anforderun-

gen, um die vorgängig definierten Geschäftsprozesse zu unterstützen. Sie stellen im Normalfall die größte Anforderungsgruppe.

- Länderspezifische, gesetzliche und richtliniengetriebene Anforderun-gen sind meisten nicht nur unternehmens- sondern auch standortab-hängig. Diese stehen oft im Widerspruch zu den fachlichen Anforde-rungen und können diese übersteuern.

- Auditbedingte Anforderungen leiten sich aus den oben genannten An-forderungen ab und stellen die Einhaltung und Überprüfbarkeit dieser sicher.

- Besondere Unternehmens- oder Umgebungs-Anforderungen, die durch die Strategie und / oder Architektur getrieben sind. Dies kön-nen unter anderem Anforderungen betreffend der einzusetzenden Technologie, Softwarekompatibilität oder der Zugriffsmethoden sein.

- Betriebs-Anforderungen umfassen alle Spezifikationen und Vorga-ben, die beschreiben, wie eine Datenbank, Applikationen, Schnitt-stellen sowie Soft- und Hardwarekomponenten in die Produktion übernommen und betrieben werden.

Performance-Anforderungen - Performance-Anforderungen für Schnittstellen definieren, in welcher

Zeitspanne Daten zwischen zwei Prozessen oder Applikationen durchgereicht werden müssen.


- Performance-Anforderungen für Prozesse definieren, in welcher Zeit-spanne ein Geschäftsprozess die notwendigen Informationen benötigt. Es ist wichtig, dass Performance-Anforderungen schon zu Begin er-hoben werden. Dies insbesondere aus den zwei folgenden Gründen: Einerseits hat die benötigte Performance einen großen Einfluss auf die Architektur der einzelnen Soft- und Hardware-Komponenten und ihre Integration sowie auf die Kosten eines Data Warehouse. Ande-rerseits sollten so früh wie möglich Performance-Tests durchgeführt werden. Ist dies nicht der Fall, so wird es unter Umständen nicht mehr möglich sein, Performanceprobleme innerhalb der verbleiben-den Zeit und im verbleibenden Budget zu beheben.

Support-Anforderungen beinhalten die Funktionen und Ressourcen, die vom Kunden im späteren Betrieb benötigt werden und über Service Le-vel Agreements (SLAs) definiert werden. Diese während der Imple-mentierung erhobenen Informationen stellen einen ersten Richtwert dar und werden während der Inbetriebnahme nochmals verifiziert. Insbe-sondere, falls die notwendigen Support-Organisationen im Unternehmen noch nicht existieren oder aber der spätere Betrieb und Support ausge-gliedert werden, müssen diese Anforderungen frühzeitig erhoben wer-den.

Sicherheits-Anforderungen für die Daten (Datensicherheit und Daten-schutz) und die Applikationen. Diese lassen sich im Normalfall direkt von den unternehmensweiten Sicherheitskonzepten ableiten.

Schulungs-Anforderungen beschreiben den benötigten Schulungsum-fang und Schulungsmodus für die definierten Benutzergruppen.

Data Warehouse-Erfolgskriterien definieren, anhand welcher Kenngrö-ßen der Erfolg des Systems gemessen wird und sind nicht zu verwech-seln mit den Abnahmekriterien einer Lösung. Die Erfolgskriterien kön-nen monetärer Art sein, wie ROI oder Einsparungen, die durch die Konsolidierung der Systemlandschaft erreicht wurden, oder sich auf die Verwendung und Akzeptanz des Systems und der verfügbaren Informa-tionen innerhalb des Unternehmens beziehen.

Kommende Anforderungen sind all jene, die während der Analyse zur Sprache kamen, die aber nicht Teil des aktuellen Inkrementes sind. Nichtsdestotrotz ist wichtig, diese zu dokumentieren, zu gewichten, und in die Gesamtplanung einfließen zu lassen. Dadurch wird die Anforde-rungsimplementierung transparent und schafft die benötigte Vertrauens-basis zu den Endbenutzern.


2.3.2 TSM Tätigkeit: Logical Model

Ein weiterer wichtiger Teil der Analysephase ist das Erstellen des Logi-schen Datenmodells, welches die Informationsverwaltung aus der fachli-chen Perspektive abbildet und den Kern des Data Warehouse darstellt. Die Schwierigkeit bei der Erstellung eines solchen Modells liegt in der not-wendigen Flexibilität und Erweiterbarkeit. Es muss in der Lage sein, heute bekannte sowie zukünftige Anforderungen und die dafür notwendigen Da-tenobjekte abzudecken respektive zu integrieren, um dadurch die gefor-derte unternehmensweite Informationssicht zu gewährleisten. Dazu wird in einem ersten Schritt ein Subject Area Model erstellt, welches den Infor-mationsbedarf des Gesamtsystems wiedergibt. Ausgehend davon werden in einem zweiten Schritt für das aktuell zu erstellende Inkrement die not-wendigen Entitäten und Attribute definiert und modelliert. Die folgende Hierarchie von Modellen und ihren Abstraktionsstufen hat sich dafür be-währt:

Das Subject Area Model ist die semantische Beschreibung der wichtigs-ten Datenbereiche einer Unternehmung und definiert den Umfang der Informationsarchitektur.

Das Conceptual Model beschreibt die für das Data Warehouse-System relevanten Hauptentitäten und ihre Beziehungen. Es ist eine erste Ver-feinerung des Subject Area Model und beinhaltet allgemein gehaltene und nicht normalisierte Datenstrukturen und Relationen. Dabei werden die Fachbegriffe und die dazugehörigen Geschäftsregeln eindeutig defi-niert und dokumentiert.

Das Key Based Model identifiziert alle benötigten Entitäten und ihre Be-ziehungen. Dafür wird das Conceptual Model weiter verfeinert, um Sub-Entitäten ergänzt und normalisiert. Jede Entität verfügt über die Attri-bute, die es zur eindeutigen Identifizierung seiner Datenelemente benö-tigt.

Das Attributed Model ist das endgültige logische Datenmodell, das über alle relevanten Entitäten und Attribute verfügt. Es beschreibt die inte-grierte, unternehmensweite und technologieneutrale Informationsarchi-tektur und ist die Basis für das später zu entwickelnde physische Da-tenmodell.

Existieren bereits logische Datenmodelle im Unternehmen oder wurde als Teil der Strategiephase ein High Level-Modell erstellt, können diese als Ausgangspunkte verwendet werden. Leider existieren vielerorts nur physi-sche Modelle, die aktuell und dokumentiert sind. Diese sind mit Vorsicht zu genießen, enthalten sie doch oft implementierungs- und technologiespe-


zifische Besonderheiten, die die Geschäftsproblematik nur bedingt wieder-geben und zu falschen Schlüssen führen können.

Ein weiterer Ausgangspunkt sind logische Datenmodelle von Drittan-bieter. So stellt zum Beispiel Teradata für alle Branchen eigene logische Datenmodelle zur Verfügung, die stetig weiterentwickelt werden. Ein sol-ches Modell reduziert den Eigenentwicklungsaufwand massiv, da es Er-fahrungen und Best Practices aus unzähligen branchenspezifischen Enter-prise Data Warehouse-Projekten beinhaltet. Dadurch stellt es ein reifes Fundament dar, welches um die jeweiligen projektspezifischen Anforde-rungen erweitert werden kann.

Basierend auf den erhobenen Fragestellungen werden die Subject Areas, Entitäten und Attribute für das Modell definiert. Besonderes Augenmerk ist hierbei auf die Konstrukte zu richten, die in keinem der vorhandenen Modelle abgebildet sind, da diese von Grund auf neu modelliert werden müssen. Neben den Business Questions gilt es auch, die restlichen rele-vanten fachlichen und insbesondere Sicherheits-Anforderungen zu berück-sichtigen, sofern diese das logische Modell betreffen.

Das logische Modell wird zusammen mit den Endbenutzern anhand der Business Questions hinsichtlich der Vollständigkeit und der Navigation durch das Modell getestet. Ziel sollte es sein, das Modell zu brechen, also relevante Fragestellungen, die nicht durch das Model beantwortet werden können, zu spezifizieren, um dadurch die Grenzen des Modells aufzuzei-gen.

Data Mapping Die logische Datenarchitektur wird durch das Definieren der benötigten Quellsysteme und das Zuordnen ihrer Datenelemente zum logischen Datenmodell komplettiert. Hierfür ist ein tiefes Verständnis der existierenden Systemlandschaft und der Datenflüsse von eminenter Be-deutung. Andernfalls riskiert man, dass diese Aktivität übermäßig viel Zeit beansprucht und ein unbefriedigendes Endresultat liefert.

Jedes Datenelement wir über seine primäre Datenquelle, d. h. von sei-nem Ursprung, geladen. In Fällen, bei denen ein Datenelement sein Ur-sprung in verschiedenen Datenquellen haben kann (zum Beispiel Daten, die während des Tages in Zwischensystemen hochgerechnet und während der Tagesendverarbeitung definitiv berechnet werden, wie dies bei Konto-ständen oft der Fall ist), gilt es klar zu definieren, zu welcher Zeit welche Quelle gültig ist. Ferner müssen die für den Ladeprozess notwendigen Da-tentransformationen erhoben und dokumentiert werden.

Die definierten Datenelemente werden einer Datenqualitätsanalyse un-terzogen, die entweder auf dem gesamten Datenbestand oder auf einer aus-sagekräftigen Stichprobe basiert. Von Vorteil hierbei ist es, wenn man die-se Analyse skriptbasiert (zum Beispiel unter Zuhilfenahme eines Data


Mining-Werkzeuges) durchführt, was einem später ermöglicht, dieselbe Analyse auf neuen Datensätzen wiederkehrend durchzuführen. Basierend auf den Resultaten werden erste Data Cleansing-Anforderungen mit den entsprechenden Data Owners und Data Stewarts sowie den Endbenutzern definiert, die dann in das Extract Transform Cleanse Load (ETCL)-Design einfließen. Ein Fokus sollte hierbei auf die Verwendung von „schlechten“ Daten gelegt werden. Es empfiehlt sich, diese trotz ihrer jeweiligen Män-gel in das Data Warehouse zu laden und nicht zu verwerfen. So können Funktionen wie zum Beispiel die Summe aller verkauften Produkte trotz inkorrekter Datensätze berechenbar bleiben. Voraussetzung dafür ist, dass man sich der Datenqualität und ihrer Auswirkungen bewusst ist, und diese auch an die Endbenutzer kommuniziert.

Die Lade-Anforderungen definieren, wann welche Daten geladen wer-den, und komplettieren die logische Datenarchitektur. Der zeitliche Aspekt beinhaltet dabei zwei Dimensionen: Erstens, bis wann (Tageszeit) neue Daten im Date Warehouse zu laden sind und zweitens wie schnell nach ih-rer Erstellung im Quellsystem die Daten im Data Warehouse vorhanden sein müssen. Hierbei sind die Verfügbarkeit der Quellsysteme und ihrer Schnittstellen sowie mögliche Abhängigkeiten im Erstellen oder bei der Extraktion der Daten zwingend mit einzubeziehen.

3 TSM Phase: Design

Während der Designphase wird die logische Architektur in eine physische, technologiegetriebene Architektur überführt. Dazu müssen vorgängig die notwendigen Soft- und Hardwarekomponenten gemäß den Anforderungen aus der logischen Architektur evaluiert werden. Dabei müssen die einzel-nen Komponenten immer auch bezüglich ihrer Skalierbarkeit hinsichtlich der zu erstellenden Gesamtlösung überprüft werden. Skalierbarkeit ist hierbei nicht, wie oft irrtümlich angenommen, ausschließlich auf die Da-tenmenge beschränkt, sondern betrifft zahlreiche zusätzliche Aspekte, wie:

die Anzahl gleichzeitig zu unterstützender Benutzer die Anzahl gleichzeitig zu unterstützender Abfragen und Abfragetypen das gleichzeitige Beladen und Abfragen derselben Datenbasis das zu analysierende Datenvolumen pro Abfrage die Komplexität der einzelnen Abfragen die zu unterstützenden Datenmodelle

Zusammengefasst betrifft sie all die Dimensionen, die notwendig sind, um die unterschiedlichen Service Level Agreements zu gewährleisten, die


sich aus den jeweiligen Anforderungen aus den zu unterstützenden opera-tiven und analytischen Geschäftsprozesse ergeben.

Das Design der physischen Architektur gliedert sich in vier Teile, deren jeweiliger Aufwand direkt von der einzusetzenden Technologie abhängt.

3.1 TSM Tätigkeit: System Architecture

Die Systemarchitektur stellt den Bauplan des Gesamtsystems dar und um-fasst einen High Level-Design der ETCL (Extraction, Transformation, Cleansing and Loading)-Architektur, der Applikationen, des physischen Datenmodells und der Betriebsprozesse. Die Systemarchitektur dient als Grundlage für alle nachfolgenden Designaktivitäten.

Da das Volumen und die Frequenz der zu verarbeitenden Daten sicher-lich den größten Einfluss auf die Architektur haben, müssen diese, falls nicht schon in der Analysephase abschließend definiert, spätestens zu die-sem Zeitpunkt vollständig erhoben werden. Dabei muss zwischen dem ini-tialen Laden, bei dem zusätzlich historische Daten für den Aufbau des Da-ta Warehouse geladen werden, und dem täglichen Beladen unterschieden werden. Daraus lässt sich eine erste ETCL-Architektur definieren, die den gesamten Ladeprozess, ausgehend vom jeweiligen Quellsystem über mög-liche Zwischenstationen (Staging Area) bis zum Data Warehouse, be-inhaltet. Für jede dieser Ladestrecken beschreibt die Architektur das Transportmedium und Technologie (in Bezug auf Betriebssystem, Hard-ware und Netzwerk).

Am anderen Ende der Architektur steht die Applikationslandschaft. Sie definiert, welche Funktionen wo und mit welcher Technologie wie imple-mentiert werden, welche Benutzer wie darauf zugreifen und die Anbin-dung an das Data Warehouse. Zusätzlich ergänzt sie die erhobenen Daten-volumetriken um die von ihnen benötigten sowie erzeugten Datenflüsse.

Auf Grund dieser Teilarchitekturen und dem in der Analyse entwickel-ten logischen Datenmodell wird nun ein erster Entwurf des physischen Da-tenmodells als Kern des Gesamtsystems erstellt. Insbesondere werden da-bei Architektur-, Datenbank- und Sicherheits-Anforderungen (wie zum Beispiel Schnittstellen und View Layers) zum Modell hinzugefügt. Aggre-gationen sollten zu diesem Zeitpunkt nur erstellt werden, wenn eine doku-mentierte und ausgiebig geprüfte Notwendigkeit dafür besteht. Alle zu-sätzlichen Tabellen und / oder Attribute generieren automatisch Mehrauf-wand bezüglich Implementierung, Test und Wartung und erhöhen dadurch die Komplexität der Lösung.

Als letzte Komponente der Systemarchitektur wird die Betriebssicht ers-tellt. Diese definiert wie und insbesondere, womit die einzelnen Kom-


ponenten und das Gesamtsystem betrieben, verwaltet und überwacht wer-den. Wurden die vorangegangenen Teilarchitekturen mit dem klaren Fokus auf das Enterprise Data Warehouse erstellt, so steht hier die Integration mit der bestehenden Systemumgebung und den bestehenden Prozessen im Vordergrund.

3.2 TSM Tätigkeit: Package Adaption

Die Package Adaption beschäftigt sich mit der Implementierung und Inte-gration von Standardsoftware und betrifft hauptsächlich den Einsatz von ETL- und Business Intelligence-Werkzeugen.

Die meisten heute verfügbaren ETL- und BI-Werkzeuge besitzen eine Vielzahl von Funktionalitäten und Implementierungs- und Verwendungs-möglichkeiten, die sich oft überschneiden (so verfügen zum Beispiel etli-che BI-Applikationen über eigene ETL-Werkzeuge für die Datenextraktion aus dem Data Warehouse). Aus diesem Grund muss zu Beginn für ein je-des dieser Werkzeuge der Verwendungszweck und daraus abgeleitet der Umfang der zu verwendenden Funktionen definiert werden. Neben dem Reifegrad der einzelnen Funktionen und ihrer Prozessdurchgängigkeit ist auch ihre Skalierbarkeit im Sinne der heutigen und zukünftigen Anforde-rungen ein wichtiges Selektionskriterium.

Darauf folgend werden alle erforderlichen Transformationen, Kalkula-tionen, Bereinigungsregeln, Fehlerverwaltung und Kontrollprozesse defi-niert, die benötigt werden, um die Daten von der Quelle in das Data Wa-rehouse und vom Data Warehouse in die analytischen Applikationen zu laden. Oft ist es dabei nicht möglich oder aus Performance- und / oder Wartungsgründen nicht sinnvoll, den jeweiligen Prozess komplett mit dem Werkzeug abzubilden. Hierfür können einzelne Teile aus dem Design he-rausgelöst und als Eigenentwicklung implementiert werden. Der Nachteil dieser dadurch erlangten Flexibilität ist, dass es zu Brüchen im Gesamt-prozess und der Ablaufsteuerung kommen kann. Daher sind hierfür von der Architektur klare Richtlinien zu definieren und periodisch zu überprü-fen, unter welchen Umständen dies geschehen darf. Am Ende dieser Akti-vität existieren für jede Ladestrecke eine Definition der dafür zu verwen-denden Ladewerkzeuge und Funktionen und die Beschreibung (inklusive Begründung) aller Ausnahmen, bei denen Eigenentwicklungen zu verwen-den sind.


3.3 TSM Tätigkeit: Custom Components

Trotz des Einsatzes von Standardsoftware sind Data Warehouse-Systeme keine Standardlösungen. Vielmehr sind sie komplexe Gebilde aus unter-schiedlichen Softwarekomponenten und Werkzeugen, die miteinander in Einklang gebracht werden müssen. Die dafür notwendigen Aktivitäten sind in TSM unter Custom Components zusammengefasst und beinhalten das Design der Lademechanismen, der physischen Datenmodelle sowie der analytischen Applikationen.

3.3.1 Physical Database Design

Kernstück des physischen Datenbankdesigns ist das physische Datenmo-dell, welches mehr oder minder eine 1:1-Abbildung des logischen Daten-modells zuzüglich technischer Komponenten wie Views, Indizes, Schlüs-selattribute und Triggers ist. Alle Abweichungen vom logischen Modell können direkte Auswirkungen auf die Aussagekraft, Integrationsfähigkeit und Flexibilität des Data Warehouse haben und müssen daher klar begrün-det und dokumentiert werden. Benutzersichten und Applikationsschnitt-stellen sind als zusätzliche Schicht (View Layer) über dem Basismodell zu konzipieren.

Neben dem Datenmodell werden alle Komponenten, die für den Betrieb und die Wartung benötigt werden (wie zum Beispiel Datenbankadminis-tration, Backup and Recovery und der Change Control Prozess) spezifi-ziert.

3.3.2 Application Design

Die Art und Weise, wie die analytischen Applikationen entworfen und an-gebunden werden, ist ein kritischer Erfolgfaktor jeder Data Warehouse-Lösung, da sie die Schnittstelle zu den Endbenutzern sind. Sie sind ver-antwortlich dafür, ob und wie ein System benutzt wird. Dementsprechend müssen neben den Anforderungen alle Informationen betreffend wie, von wem und wo die Applikation benutzt werden soll in das Design einfließen. Sie beeinflussen nicht nur die Benutzerführung und Informationspräsenta-tion, sondern auch die Datenhaltung und Verwaltung. Das Design einer Applikation, die von Tausenden Benutzern weltweit gleichzeitig verwen-det wird, unterscheidet sich in den meisten Belangen gegenüber einer App-likation, die für eine Handvoll lokaler Spezialisten konzipiert wird.

Die Anbindung an das Data Warehouse kann aktiv über SQL-Aufrufe, Makros, Stored Procedures oder Triggers erfolgen oder, falls die Applika-tion über eine eigene Datenhaltung verfügt, mittels periodischer Ladepro-


zesse. In der Praxis haben sich dabei Mischlösungen bewährt, bei denen Aggregate in den BI-Lösungen gehalten werden und Basisdaten im Data Warehouse. Wo genau der Schnitt gemacht wird, hängt einerseits von den Anforderungen und anderseits von der Skalierbarkeit der einzelnen Lö-sungskomponenten ab. Ein weiterer Aspekt ist die geforderte Datenver-fügbarkeit, verzögert sich doch diese bei jeder zusätzlich zu ladenden Um-gebung.

Das Applikationsdesign beinhaltet...

die benötigten Daten, Datenflüsse und Schnittstellen, die benötigten Funktionen und ihre Verteilung, die benötigten Datenstrukturen, wie zum Beispiel multidimensionale

Modelle, die Sicherheitsanforderungen und Berechtigungen, wie und von wem Abfragen erstellt und initiiert werden, die Informationspräsentation, die Benutzerführung und die benötigten HW- und SW-Komponenten und ihre Konfiguration.

3.3.3 Design der Extract Transform Cleanse Load (ETCL)-Prozesse

Das Design der ETCL-Prozesse ist sicherlich der aufwändigste und komp-lexeste Arbeitsschritt, gilt es doch für jede Datenstrecke die zu im-plementierenden Funktionen sowie die Abhängigkeiten gegenüber anderen Datenstrecken, Quellsystemen und Geschäftsprozessen zu spezifizieren. Erschwerend kommt dazu, dass zwischen dem initialen und dem periodi-schen Beladen jeweils unterschieden werden muss, was im jeweiligen De-sign zu reflektieren ist. Abbildung 9 zeigt schematisch den Datenfluss vom Quellsystem in das Data Warehouse und in die analytischen Applikatio-nen.


SRCA

SRCB

SRCZ

SourceSystems

LandingZone

StagingArea

EDWTargetTables

Data Marts& Extracts

Abb. 9. Datenflüsse im Data Warehouse

Waren früher solche Prozesse ausschließlich Batchprozesse, die jeweils in der Nacht das Data Warehouse beluden, wird heute vermehrt auch unter-tags oder gar near real time geladen. Dadurch entstehen erhöhte Anforde-rungen an die Verfügbarkeit des Gesamtsystems und dessen Datenbank-objekte, die nun gleichzeitig beladen und gelesen werden, sowie an die Anbindung der Umsysteme, die nun vermehrt lose gekoppelt (z. B. über eine serviceorientierte Architektur) stattzufinden hat. Extraction Das Design der Extraktion bestimmt, wie welche Daten wann wo abgezogen werden und ist primär von den Quellsystemen und ihrer Auslastung abhängig. Dokumentiert werden:

die Quellsysteme und benötigten Benutzer- und Zugriffsrechte, das Extraktionsformat und Extraktgröße, die Extraktionsmethode, der Zeithorizont für die Extraktion, die Landing Area, welche die Daten zwischenspeichert und die Transportmethode, wie die Daten in die Landing Area kommen.

Die darauf basierende Designlogik definiert den Prozess, die Verant-wortlichkeiten und integriert die notwendigen Werkzeuge. Transform Das Design der Transformation definiert, welche Daten wann, wie und wo transformiert werden. Da diese Transformationen oft rechen-intensiv sind und die Prozesse meist zu Randzeiten laufen, in denen die Datenbank nicht ausgelastet ist, wechselt man vermehrt von einer klassi-schen ECTL-Architektur zu einer ELCT basierten Architektur, bei der die Daten erst ins Data Warehouse geladen und dann dort transformiert wer-den. Ausschlaggebend für die Architekturentscheidung sind sicherlich


nicht zuletzt die Performance-Anforderungen und die Skalierbarkeit der verfügbaren Technologie, muss man doch bei einem ELCT-Design in der Lage sein, unterschiedliche Arbeitslasten zur selben Zeit mit derselben Plattform und Konfiguration abzudecken. Cleanse Die Bereinigungsprozesse basieren auf bekannten, durch die Ana-lysephase aufgedeckten Datenqualitätsproblemen. Die zu definierenden Regeln können einfache Bereinigungen auf Attributebene beinhalten oder komplexe Funktionen, wie zum Beispiel die Identifikation vom Dubletten. Das Design beinhaltet neben den Regeln zusätzliche für die Bereinigung benötigte Informationen (wie zum Beispiel Referenztabellen), wo die be-reinigten Daten zu speichern sind und eventuell zusätzliche benötigte Soft- und Hardware. Load Das Schreiben der Daten in das Data Warehouse geschieht über die Ladeprozesse. Hierfür ist ein Mapping vom Quellsystem in die Staging Area und von dort in die Zieltabellen notwendig, welches neben den Ver-bindungen auch die Historisierungskonzepte für die einzelnen Datenob-jekte beinhaltet. Ausgehend von der Architektur, der Beladungsart und der Komplexität der Transformationen kann das Data Warehouse auch direkt, unter Umgehung der Staging Area, beladen werden. Dies gilt insbesondere für Mini Batches und Near Real Time Feeds, bei denen wenige Daten in kurzer Zeit geladen und den Benutzern zur Verfügung gestellt werden müssen.

Zusätzlich sind jeweils die Fehlerverarbeitungen (inklusive des Schwel-lenwerts, bei dem der Prozess zu beenden ist), die Funktionen zur Auf-zeichnung der Datenveränderungen sowie die Spezifikation der Testfälle und der dafür benötigten Testdaten für jeden der oben beschriebenen Teil-prozesse separat zu spezifizieren3.

Abschließend werden die definierten Teilprozesse in den ETCL-Ge-samtprozess eingebunden. Dazu gehören neben der Abbildung aller Ab-hängigkeiten das Design der Prozesssteuerung und die Spezifizierung von Fehler- und Statusmeldungen. Jede Ladestrecke muss dabei über definierte Kontrollpunkte verfügen, die im Falle eines Abbruchs ein kontrolliertes Wiederaufsetzen der Prozesse ermöglichen.

3.4 TSM Tätigkeit: Test Plan

Ein Data Warehouse ist per Definition ein datenzentrisches System. Der ETCL-Prozess stellt dabei den Lebensfluss dar, der das korrekte und zeit-gerechte Beladen des Systems und im Endeffekt seinen Erfolg garantiert.

3 Siehe Testplanung „Unit Test“


Die Überprüfung dieser Prozesse ist daher unabhängig von den Lösungs-spezifischen Anforderungen immer eine Hauptaktivität eines jeden Data Warehouse-Tests. Dabei steht insbesondere die Gültigkeit der Daten und die Performance der Prozesse im Vordergrund. Weitere wichtige Faktoren sind der Betrieb und die Datensicherheit.

3.4.1 Daten-Gültigkeit

Um die Korrektheit der Daten im Data Warehouse zu garantieren, muss der ETCL-Prozess die richtigen Daten zur richtigen Zeit aus den jeweili-gen Quellsystemen extrahieren, die unterschiedlichen Bereinigungen und Transformationen korrekt durchführen und die jeweiligen Datenobjekte entsprechend dem Data Mapping aktualisieren. Um dies zu überprüfen, existieren unterschiedliche Vorgehensmodelle mit ihren jeweiligen Stärken und Schwächen.

1. Die Daten im Data Warehouse werden mit denjenigen in den Quell-systemen verglichen. Üblicherweise vergleicht man dabei die Anzahl der Datensätze und stichprobenartig Datenwerte auf unter-schiedlichen Aggregationsstufen. Dabei ist zu berücksichtigen, dass basierend auf den Transformationsregeln nicht zwingend alle Daten-sätze aus dem Quellsystem in das Data Warehouse geladen werden.

2. Die Daten werden, dem Datenfluss folgend, auf allen Schichten (Lan-ding Area, Staging Area und Data Warehouse) auf ihre Gültigkeit ge-prüft. Dies hat einerseits den Vorteil, dass Fehlerquellen einfacher identifiziert werden können, und anderseits, dass die Anzahl zu veri-fizierender Transformationen und Bereinigungen kleiner und daher einfacher nachzuvollziehen ist, als bei einem durchgehenden Ver-gleich. Das Prüfverfahren ist dasselbe wie beim obigen Vorgehens-modell.

3. Jeder ETCL-Prozess wird individuell und isoliert gegen seine spezifi-schen Anforderungen getestet. Dies ist insofern möglich, da jeder die-ser Prozesse für sich allein existieren kann, und über einen definierten In- und Output verfügt.

Die beiden letzteren genannten Vorgehen stellen sicherlich die umfang-reicheren Tests dar und ermöglichen eine schnelle Lokalisierung der Feh-lerquellen. Auch unterstützen sie ein inkrementelles Testvorgehen, da nicht alle Komponenten benötigt werden. Der Nachteil liegt in dem größe-ren Aufwand, der hierfür betrieben werden muss. Ein kritischer Punkt für alle Modelle ist das Erstellen der Testdaten. Wann immer möglich, und insbesondere für Vorgehen 1 und 2, sollten produktive Daten verwendet werden. Dies ermöglicht den Abgleich der Resultate gegen existierende


Systeme und garantiert die zwingend notwendige inhaltliche Konsistenz der Daten. Dies aber nur, falls der Datenabzug über alle Quellsysteme syn-chron, das heißt zur selben Zeit, erfolgt.

3.4.2 Performance

Die Performance der ETCL-Prozesse ist primär abhängig von der System-umgebung und dem einerseits zu verarbeitenden und anderseits schon im Data Warehouse vorhandenen Datenvolumen. Diese Faktoren werden üb-licherweise in der Testumgebung nur bedingt wiedergegeben, führt man die Tests doch im Normalfall auf einem kleineren System mit reduziertem Datensatz aus. Eine Analyse über der Anzahl verarbeitenden Datensätze pro Ladestrecke und definierter Zeiteinheit kann aber immerhin Tendenzen und mögliche Flaschenhälse aufzeigen.

Eine weitere Möglichkeit sind sogenannte Stresstests, bei denen ver-sucht wird, die Grenzen und die Skalierbarkeit eines Gesamtsystems oder einer ihrer Komponenten aufzuzeigen. Ziel ist es, die Auswirkungen einer Systemüberlastung auf Prozesse und Daten aufzuzeigen, was mögliche Schwachpunkte frühzeitig erkennen lässt.

3.4.3 Test-Phasen

Verschiedene Vorgehensmodelle für das Testen von Software wurden im Rahmen des klassischen Software Engineering in den letzten 20 Jahren entwickelt. Wie für Modelle üblich, basieren sie alle auf einer vereinfach-ten Sicht der Realität und haben ihre Stärken und Schwächen. Eine klassi-sche und bewährte Methode um Tests zu klassifizieren und spezifizieren ist das in Abb. 10 dargestellte V-Modell (Balzert 1998; Nørgaard u. Byrd 2006), welches Tests relativ zur jeweiligen Entwicklungsstufe definiert und einen Modultest, Integrationstest, Systemtest und Abnahmetest vor-sieht. Diese sollten jeweils den aktuellen Gegebenheiten angepasst werden. Solche Anpassungen können zum Beispiel in der Zusammenfassung von einzelnen Testschritten sein, wie dies in einigen Unternehmen beim Sys-tem- und Abnahmetest der Fall ist, oder den Verzicht auf einen Integrati-onstest für Änderungen, bei denen keine neuen Ladestrecken hinzugefügt wurden. Insbesondere aber sollte die Planung iterative und sich überlap-pende Tests vorsehen und nicht stur linear vollzogen werden.


Anforderungsdefinition

Feinentwurf

Modulimplementation

Grobentwurf

Integrationstest

Systemtest

Modultest

Abnahmetest

Abb. 10. V-Modell (Balzert 1998)

Der Modultest-Plan spezifiziert wie, wann, wo und von wem in sich ge-schlossene Programmteile getestet werden. Der Vorteil von solchen Mo-dultests besteht darin, dass sie es erlauben kleine, in sich abgeschlossene Einheiten isoliert zu testen und mögliche Fehler so früh wie möglich zu identifizieren. Die Tests beinhalten insbesondere

die Verifikation der korrekten Implementierung von Data Mappings, Transformationen und Bereinigungen,

den Umgang mit Datenanomalien und Grenzwerten wie zum Beispiel Nullwerten, minimalen und maximalen Werten, „Space“ und fehlenden oder inkorrekten Werten,

Den Umgang mit inkompatiblen Feldtypen wie zum Beispiel Integer und Long, Integer und Char, Datumsformate und Feldgrößen,

Indizes und Schlüsselattribute und die Fehlerbehandlung inklusive Fehlerstatus, Roll-back und Prozesster-

minierung.

Der Integrationstest-Plan spezifiziert wie, wann, wo und von wem Gruppen von Programmteilen in ihrem Zusammenspiel getestet werden. Für die Ablaufsteuerung wird dabei die später zu verwendende Job Control Language (JCL) und / oder die Job Scheduling Software verwendet. Die Tests beinhalten insbesondere:

Die Verifikation von durchgehenden Ladestrecken (End to End Proces-sing).


Die Überprüfung von Ladesequenzen und ihren Abhängigkeiten. Die Fehlerbehandlung inklusive Fehlerstatus, Roll-back und Prozess-

terminierung. Die Messung der benötigten Zeit pro Ladestrecke als erste Hinweise auf

mögliche Performance Probleme.

Der Systemtest-Plan spezifiziert wie, wann, wo und von wem alle rele-vanten Komponenten als Gesamtsystem getestet werden und überprüft, ob alle fachlichen und technischen Anforderungen korrekt umgesetzt wurden. Die Datenbasis sollte hierfür ein aussagekräftiger Auszug aus der Produk-tivumgebung sein. Die Tests beinhalten insbesondere:

Die Verifikation von durchgehenden Ladestrecken für das initiale und periodische Beladen.

Die Integration der Ablaufsteuerung. Die Überprüfung der Daten anhand der definierten Fragestellungen und

Kenn- und Steuergrößen. Die Überprüfung von Performanceanforderungen.

Der Abnahmetest-Plan spezifiziert wie, wann, wo und von wem die Ab-nahme des Gesamtsystems geschieht. Dieser steht unter der Verantwortung des Auftraggebers und kann als Teil des System-Tests definiert werden.

Am Abschluss der Designphase steht die physische Architektur, dir der Definition und Spezifikation des zu implementierenden Systems ent-spricht, und die detaillierte Planung für die Implementierung und Inbe-triebnahme der Lösung inklusive aller Kosten. Die Implementierung und der spätere Betrieb des Systems werden in den anschließenden TSM Pha-sen Equip, Build, Integrate und Manage definiert, welche nicht Bestandteil dieses Kapitels sind. Änderungen an der Architektur, die während der Im-plementierung auf Grund von auftretenden Problemstellungen notwendig werden, müssen jeweils in einer verkürzten Design- und eventuell auch Analysephase erarbeitet, auf ihre Auswirkungen auf die Systemintegrität und die Planung überprüft und freigegeben werden.


Jedes komplexe Ding, welches als ein System zu funktionieren hat, muss als ein System entworfen und geplant werden, um die Integration und Ko-härenz aller Komponenten zu garantieren und um sicherzustellen, dass das System in der Art und Weise funktioniert, wie dies bei seiner Erstellung vorgesehen war (Schekkerman 2004b). Dieser Grundsatz ist eine der Triebfedern der hier vorgestellten Methodologie, welche in einem ersten


Schritt die Bedürfnisse und Abhängigkeiten des Gesamtsystems erhebt und basierend darauf einzelne klar definierte, in sich abgeschlossene und Nut-zen generierende Inkremente definiert, implementiert und in die beste-hende Systemumgebung integriert. Dabei steht die Architektur im Zen-trum, welche die über den Informationsbedarf definierten fachlichen Anforderungen mit der Systemlandschaft in Einklang bringt.

Ein weiterer wichtiger Aspekt einer erfolgreichen Methodologie ist ihre Akzeptanz. Dazu müssen unterschiedliche Ziele erfüllt werden. Während das Unternehmen anhand der Methodologie ein strukturiertes Vorgehen einführen will, um dadurch die Planbarkeit der Projekte zu verbessern und gleichzeitig deren Risiken zu vermindern, benötigt der Projektmitarbeiter eine flexible Struktur, die ihn in seiner täglichen Arbeit unterstützt, keinen Mehraufwand generiert und ihn seines Gestaltungsfreiraums nicht beraubt. Der modulare Aufbau der TSM kommt diesen Anforderungen entgegen. Sie reflektiert ein strukturiertes und mehrfach erprobtes Vorgehen, welches an die jeweilige Situation, deren Anforderungen und Umfeld angepasst werden kann. Die komplette softwareunterstütze Methodologie beinhaltet neben dem eigentlichen Vorgehen Tipps und Tricks zur Ausführung der Aktivitäten, Arbeitsvorlagen und Module zur Berechnung von Aufwands-schätzungen und zur Generierung von Projektplänen und Vertragsentwür-fen. Korrekt eingesetzt, entlasten diese Funktionalitäten die Mitarbeiter von wiederkehrenden Arbeiten und stellt ihnen eine Wissensbasis zur Ver-fügung, die eine effizientere Arbeitsweise ermöglichen. Dadurch entstehen de-facto Standards, die die Qualität der Projekte beständig weiter treiben.

Die Informationstechnologie bewegt sich in einem schnell wandelnden Umfeld. Neue fachliche Anforderungen benötigen in kurzer Zeit neue Lö-sungen, die wiederum in vielen Fällen auf neue Technologien und / oder Produkte aufsetzen. Will eine Methodologie diesen Umstand gebührend berücksichtigen, muss sie entweder auf generische Ansätze zurückgreifen oder sich stetig weiterentwickeln. TSM wurde vor über 15 Jahren von Entwicklern für Entwickler entworfen und reflektiert seitdem die Erfah-rungen aus unzähligen Data Warehouse-Projekten. Neue Erkenntnisse, die durch ein zentrales Knowledge Management gesammelt werden, fließen dabei entweder direkt in die Methodologie ein, oder werden als Arbeits-vorlagen beigelegt. Die nächste größere Erweiterung ist für das Frühjahr 2008 geplant und hat zum Ziel, durch das Bilden von Workstreams die Benutzerfreundlichkeit und die Projektplanung zu verbessern. Dazu wer-den Aktivitäten aus einer oder mehreren Phasen zu logischen Aktivitäten (wie zum Beispiel Datenmodellierung) oder einem Lieferobjekt (wie zum Beispiel Systemarchitektur) gruppiert.


Requirements Gathering & Analysis

Metadata Services

Pro

du

ctio

n R

ollo

ut

Data Integration

Business Intelligence

Quality Assurance

SystemInstall

Data Mapping& Data Quality

Security & Privacy

Sys

tem

Arc

hit

ectu

re

Modeling

Requirements Gathering & Analysis

Metadata Services

Pro

du

ctio

n R

ollo

ut

Data Integration

Business Intelligence

Quality Assurance

SystemInstall

Data Mapping& Data Quality

Security & Privacy

Sys

tem

Arc

hit

ectu

re

Modeling

ManageIntegrateBuildEquipDesignAnalyzeResearchStrategy ManageIntegrateBuildEquipDesignAnalyzeResearchStrategy

Abb 11: Auszug TSM Workstreams

Ein weiterer Vorteil der Workstreams ist ihre Unterstützung der stetigen Weiterentwicklung der Methodologie, können dadurch doch neue Lösun-gen und ihre dafür notwendigen Prozesse einfach abgebildet werden, ohne den Kern der Methodologie zu ändern. Dadurch wird sichergestellt, dass auch in Zukunft mittels TSM erfolgreich unternehmensweite Data Ware-house-Systeme strukturiert aufgebaut, weitergeführt und betrieben werden können.

Literatur

Balzert, H.: Lehrbuch der Software-Technik - Software-Qualitätssicherung, Un-ternehmensmodellierung, Spektrum, Heidelberg 1998.

Carroll, L.: Alice's Adventures in Wonderland, 1865. Daenzer, W.; Huber, F.: Systems Engineering Methodik und Praxis, Verlag In-

dustrielle Organisation, Zürich 1992. Gam, I.; Salinesi, C.: A Requirement Driven Approach for Designing Data Ware-

houses, in: Proceedings of the Twelfth Working Conference on Requirements Engineering, Luxembourg 2006.

Geiger, J.: The Missing Link, in: Teradata Magazine 7 (2007) 1. Hesse, W.; Merbeth, G.; Frölich, R.: Software- Entwicklung. Vorgehensmodelle,

Projektführung, Produktverwaltung, Oldenbourg, 1992. Inmon, W.: Building the Data Warehouse, Wiley, New York 1996. Inmon, W.; Zachman, J.; Geiger, J.: Data Stores, Data Warehousing and the

Zachman Framework, McGraw Hill, New York 1997. Mulholland, A.; Macaulay, A.: Architecture and the Integrated Architecture Fra-

mework, Capgemini, 2006. Nørgaard, N.; Byrd, B.: Data Warehouse Testing Best Practices, Teradata, 2006.


o. V. : Requirements Definition and Management Best Practices Guide, Teradata, 2006a.

o. V. : Teradata Enterprise Data Warehouse Roadmap for Financial Services, Te-radata, 2006b.

Picot, A.; Reichwald, R.; Wigand, R. T.: Die grenzenlose Unternehmung, 2. Aufl. Aufl., Gabler, Wiesbaden 1996.

Schekkerman, J.: Another View at Extended Enterprise Architecture Viewpoints, Capgemini, 2004a.

Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frame-works, 2. Aufl., Trafford, Victoria 2004b.

Schienmann, B.: Kontinuierliches Anforderungsmanagement. Prozesse - Techni-ken - Werkzeuge, Addison-Wesley, 2001.

Strauch, B.; Winter, R.: Vorgehensmodell für die Informationsbedarfsanalyse im Data Warehousing, in: von Maur E. et al. (Hrsg.): Vom Data Warehouse zum Corporate Knowledge Center, Physica, Heidelberg 2002, S. 359-378.

Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: Ös-terle H. et al. (Hrsg.): Business Engineering - Auf dem Weg zum Unterneh-men des Informationszeitalters, 2. Aufl., Springer, Berlin etc. 2003, S. 87-118.

14 Die Informationslogistik bei der Swisscom Mobile

Maximilian Ahrens


Markus Huber, Peter Kühni

Swisscom Mobile AG

1 Einleitung ....................................................................................... 3132 Marktsituation und Unternehmen ................................................... 3143 Swisscom Mobile Unternehmen ..................................................... 3154 Strategische Ausrichtung der Informationslogistik bei der

Swisscom Mobile ........................................................................... 3175 Organisation der Informationslogistik ............................................ 3206 Einführung des neuen DWH ........................................................... 3237 Analyse des DWH der Swisscom Mobile ...................................... 3278 Konsequenzen und Ausblick .......................................................... 329

Literatur .......................................................................................... 330

1 Einleitung

Diese Fallstudie erhebt den Stand der Informationslogistik bei der Swiss-com Mobile. Dabei wurden sowohl die Entwicklung als auch die zukünfti-gen Planungen der Swisscom Mobile analysiert. Das Kapitel gliedert sich wie folgt: Zunächst werden einführend einige grundlegende Informationen zum Mobilfunkmarkt in Europa und der Schweiz gegeben. Anschließend

314 Maximilian Ahrens, Markus Huber, Peter Kühni

soll das Unternehmen Swisscom Mobile vorgestellt werden. Im Kernab-schnitt dieses Textes werden abschließend die Informationslogistik-Organisation und -Architektur der Swisscom Mobile vorgestellt und die wichtigsten Erfolgsfaktoren erläutert.

2 Marktsituation und Unternehmen

In diesem Abschnitt sollen zunächst die Rahmenbedingungen des Mobil-funkmarktes in Europa und der Schweiz gezeigt werden. Dies ist für die Herausforderungen der Informationslogistik interessant, da der Markt einer großen Dynamik einerseits, sowie einer staatlichen Regulierung anderer-seits unterliegt.

2.1 Mobilfunkmarkt in Europa und der Schweiz

Der Mobilfunkmarkt in Europa befindet sich seit der Entwicklung der digi-talen Mobilfunktechnologie in einer starken Wachstumsphase. Nach den Mobilfunktechnologien der ersten Generationen (B- und C-Netz), die nur wenige Abnehmer fanden, wurde durch die Einführung der GSM-Techno-logie in Europa ein Massenmarkt für mobile Kommunikation eröffnet.

Dies führte dazu, dass in den meisten westeuropäischen Märkten um die Jahrtausendwende herum mehr Mobilfunkanschlüsse als konventionelle Festnetzanschlüsse existierten. Im Jahr 2006 betrug so die Marktdurch-dringung im Mobilfunkbereich bereits 103%, d.h. es gibt mittlerweile mehr Mobilfunkanschlüsse als Einwohner.

Mobile subscribers penetrationin EU (2G and 3G)

386.

61

436.

68

478.

39

84.6%

103.2%

95.0%

0

100

200

300

400

500

600

Oct. 2004 Oct. 2005 Oct. 2006

Mill

ion

ofsu

bscr

iber

s

0%

20%

40%

60%

80%

100%

120%

EUpe

netra

tion

rate

EU subscribers EU penetration rate Abb. 1. Entwicklung des Mobilfunkmarktes in der EU (o. V. 2007a)

Die Informationslogistik bei der Swisscom Mobile 315

Die dynamische Entwicklung dieser Märkte sowie eine neue Industrie-politik führten zu einer Privatisierung vieler europäischer Telekommunika-tionskonzerne. Während bis in die 80er Jahre die Telekommunikation vorwiegend als staatliche Aufgabe gesehen wurde, setzte sich die Auffas-sung durch, dass durch eine Privatisierung ein höherer Kundennutzen er-reicht werde könne. Parallel wurden Regulierungsstrategien eingeführt, die eine Öffnung des Marktes ermöglichen sollten. Im europäischen Umfeld führte diese Entwicklung zu einer weiteren Dynamisierung des Marktes und einem Streben der nationalen Unternehmen in die internationalen Märkte.

Auch in der Schweiz wurde eine ähnliche Entwicklung vollzogen, wenn auch nicht im selben Umfang wie in den EU-Ländern. Die Swisscom als Marktführer hatte nach der Marktöffnung im Jahr 1998 im Jahr 2006 noch einen Marktanteil von über 63%, in der EU halten die ehemaligen Mono-polisten jedoch im Durchschnitt nur noch 40% Marktanteil (o. V. 2007a).

Bedingt durch die Attraktivität des Schweizer Marktes sind jedoch eini-ge Wettbewerber in den Markt eingetreten (Jost 2004). Dadurch entsteht eine ähnliche Situation wie in vergleichbaren europäischen Märkten.

Zuletzt haben die Mobilfunkmärkte erneut einen Innovationsschub er-halten durch die vermehrt angebotenen innovativen Services (z.B. Mobile TV und Musikdienste), die vollständig neue Marketing- und Abrech-nungskonzepte benötigen. So müssen Kunden individuell angesprochen werden und nutzungsbasierte Tarife von Datendiensten entwickelt werden.

Es lässt sich also feststellen, dass insbesondere die Dynamik der Märkte die Mobilfunkprovider unter erheblichen Druck setzt. Dabei entsteht diese Dynamik nicht nur durch neue technologische Innovationen, sondern auch durch neue industriepolitische Ansätze.

Die Informationslogistik-Strategien der Unternehmen müssen diesen komplexen Herausforderungen begegnen und dem Mobilfunkprovider die notwendige informatorische Unterstützung für kundengerechte Angebote bereitstellen.

3 Swisscom Mobile Unternehmen

3.1 Überblick

Die Swisscom Mobile AG ist die Mobilfunktochter der Swisscom. Die Swisscom Mobile hat ihren Hauptsitz in Bern und bedient den schweizeri-schen Markt mit unterschiedlichen Mobilfunkdienstleistungen.


Verwaltungsrat

CEO

Swisscom Solutions AG

Swisscom FixnetAG Fastweb S.p.A.

Group Communiucations

Swisscom Beteiligungen

Swisscom IT Services AG

Group Human Ressources

Group Strategy & Business

Development

Swisscom Mobile AG

Group Finance & Controlling

Gruppengesellschaften

Group Headquarters

Abb. 2. Konzernstruktur der Swisscom AG (o. V. 2006)

Die Swisscom Mobile wird im Verbund mit den anderen Business Units der Swisscom (Fixnet, Services, Solutions) als integrierter Informations- und Telekommunikationstechnologie-Konzern geführt. In der Organisation des Konzerns wird dies sehr gut deutlich (vgl. Abb. 2). Es gibt zentrale Einheiten für Business Development und Human Ressources für die ge-samte Gruppe.

Tabelle 1. Kurzporträt der Swisscom Mobile AG (o. V. 2006)

Swisscom Mobile AG

Historie

1998: Gründung der Swisscom AG und Börsengang 2000: > 3 Mio Mobilfunkkunden und Ersteigerung einer UMTS-Lizenz 2002: Einstieg in den Public Wireless LAN-Markt 2004: Präsentation der ersten UMTS Geräte für den Schweizer Markt 2005: Erste Pilotprojekte zum Thema Mobile TV basierend auf dem DVB-H Standard

Firmensitz Bern (CH) Branche Telekommunikation Homepage http://www.swisscom.ch Umsatz 4,02 Mio CHF (2006) Ergebnis 1,41 Mio CHF (2006) Marktanteile 63,4% (2006) Mitarbeiter 2550 (2007) Kunden >5 Mio Subscriber (2007)


3.2 Herausforderung und Wettbewerb

Die Swisscom Mobile steht vor erheblichen Herausforderungen. Wie schon im vorangegangenen Abschnitt dargestellt, entwickelt sich der Mo-bilfunkmarkt sehr dynamisch, weshalb die Unternehmen flexibel auf ak-tuelle Herausforderungen reagieren müssen.

Durch das Marktumfeld besteht nach wie vor ein erheblicher Druck auf die Swisscom Mobile. Der gesättigte Markt mit mehr Mobilfunkanschlüs-sen als Kunden ermöglicht Wachstum der Kundenzahlen nur noch auf Kosten der Wettbewerber, die ihrerseits den Druck auf die Swisscom Mo-bile erhöhen. Zudem geraten die Margen durch EU-Regulierungen unter Druck, die die Preise für das Roaming in ausländische Netze beschränken. Schließlich entsteht Druck durch die Gerätehersteller, die in Konkurrenz zu den Mobilfunkanbietern selber Content-Angebote im Markt zu positio-nieren versuchen.

Der strategische Fokus besteht darin, im zunehmend gesättigten Markt neue Umsatzpotenziale zu erschließen. Dabei werden insbesondere tech-nisch komplexe Produkte oder Lösungen für spezielle Segmente angebo-ten. Im Privatkundensegment sind insbesondere Media-Dienste im Fokus der Wachstumsstrategie. So sollen internetprotokoll-basiertes TV sowie mobiles TV weiter ausgebaut werden.

Die Muttergesellschaft Swisscom (Schweiz) AG setzt hier besonders auf integrierte Angebote in Zusammenarbeit mit verschiedenen Konzernge-sellschaften. Zur Bewältigung dieser komplexen Herausforderungen hat sich die Swisscom entschieden, ihre Divisionsstruktur teilweise aufzulösen und den Mobil- und Festnetzbereich zu fusionieren. Dadurch entsteht eine neue Swisscom, die stärker nach Kundensegmenten aufgestellt ist (o. V. 2007b).

4 Strategische Ausrichtung der Informationslogistik bei der Swisscom Mobile

Zum besseren Verständnis der aktuellen Herausforderungen der Informati-onslogistik bei der Swisscom Mobile soll zunächst kurz die Entwicklung beschrieben werden. Gemeinsam mit den Herausforderungen des Marktes, die in den vorangegangenen Kapiteln beschrieben wurden, entsteht so ein präzises Bild der konkreten Herausforderungen des DWH bei der Swiss-com Mobile.


4.1 Entwicklung der Informationslogistik

Ein zentrales DWH wurde bei der Swisscom Mobile zunächst ab 1997 für die Bedürfnisse des Marketings entwickelt. Dieses DWH wurde 2002 in einem umfangreichen Entwicklungsschritt um Daten zu Finanzen und Controlling erweitert.

Zunächst wurden Topline-Kennzahlen definiert, die von der Finanzab-teilung definiert wurden. Für diese Zahlen hatte die Finanzabteilung die Datenhoheit inne und konnte sie somit in einem System zusammenführen. Dieses System war somit das erste zentrale DWH bei der Swisscom Mobi-le. Das System war allerdings nur aus logischer Sicht eine Einheit, phy-sisch gab es mehrere verknüpfte heterogene Komponenten, welche Ände-rungen und Erweiterungen und gesamtheitliche Auswertungen zeit- und kostenintensiv machten (vgl. Abschn. 4.2).

Nach der Etablierung dieses Systems wurde 2006–2007 ein konsistentes und ganzheitliches System eingeführt (vgl. Abschn. 7). Nach wie vor ver-antwortet jedoch die Finanzabteilung die Business-Steuerung des Systems. Der hauptsächliche Grund für diese Aufstellung liegt in der Annahme, dass in der Finanzabteilung keine Partikularinteressen vorhanden sind, sondern das gesamte Unternehmen ganzheitlich betrachtet wird.

Als Sponsor des DWH tritt innerhalb der Swisscom Mobile die Ge-schäftsführung auf, Sponsor und System Owner ist der CFO.

4.2 Ziele und Leidensdruck der Informationslogistik

Die Marktsituation der Swisscom Mobile zeigte deutlich die Notwendig-keit, mit der Informationslogistik auf sich dynamisch ändernde Herausfor-derungen zu reagieren, um die strategischen Ziele des Unternehmens op-timal zu unterstützen. Es wurde offensichtlich, dass die bestehende, komplexe Informationslogistik-Infrastruktur nicht geeignet war, die sich daraus ergebenden Anforderungen insbesondere an die Flexibilität der Systeme zu erfüllen. Dies zeigte sich in einer Reihe von fachlichen und technischen Problemen:

In der frühen Phase des DWH gab es bedingt durch die unterschiedli-chen Systeme keine konsistenten Finanzkennzahlen, was zu inkonsistenten Analyseergebnissen führte. Insbesondere der Bedarf der Geschäftsführung nach konsistenten und verlässlichen Zahlen führte zu der Zentralisierung des DWH. Zusätzlich war die Senkung der Betriebskosten ein vordringli-ches Ziel. Ausgehend von diesem anfänglichen Beweggrund stiegen die Ansprüche an die quantitative Unterstützung durch die Informationslogis-tik. Insbesondere die Unterstützung bei der Entwicklung und Durchfüh-


rung von erfolgreichen Marketingkampagnen ist ein neu hinzugekomme-nes Ziel. Um dies zu gewährleisten, brauchen Produktmanager hoch spe-zialisierte Informationen, die durch das DWH individuell bereitgestellt werden müssen. Weiterhin sind die Ansprüche durch die zunehmende Pro-duktvielfalt komplexer geworden. Neue und durch Content getriebene Dienste verlangen sehr viel komplexere Analysen, um eine kundenorien-tierte Ausrichtung des Produktportfolios zu ermöglichen.

Ein dritter entscheidender Punkt, welcher auch zu der Einführung des ganzheitlichen Enterprise Data Warehouses im Jahr 2006 führte, war der erhöhte Anspruch an die Datenqualität. Nachdem zunächst nur die wich-tigsten Top-Kennzahlen fundiert erhoben wurden, sollte der gleiche Quali-tätsanspruch auch für die unterliegenden Zahlen gelten. Die bestehende Si-tuation, in der oft vermeintlich gleiche Zahlen aus unterschiedlichen Systemen von einander abwichen, sollte verbessert werden. Dies war nur möglich durch die Einführung eines erweiterten, ganzheitlichen Systems.

Neben diesen fachlichen Anforderungen an eine neue DWH Struktur, gab es auch Treiber aus der Technik, die zur Umsetzung des „New Mosaic (NeMo)“-Projektes führten.

Ein wesentliches Problem im Zusammenhang mit der bestehenden Architektur der DWH-Plattform vor der Neugestaltung war die hohe An-zahl untereinander abhängiger Schichten. Zwei mit einander verzahnte Systeme zur Verwaltung von Transaktionsdaten und Stammdaten führten zu einer Architektur mit insgesamt fünf Datenhaltungsschichten mit gro-ßen Abhängigkeiten untereinander. Dadurch entstanden hohe Latenzzeiten zwischen dem Entstehen der Transaktionsdaten und der Verfügbarkeit der Daten in den Berichten, teils waren nur wöchentliche Ladezyklen möglich. Zudem entstanden erhebliche Probleme, falls Stammdaten nicht zeitgleich mit den Transaktionsdaten verfügbar waren.

Das Datenmodell des Altsystems war gemäß einem Sternschema aufge-baut, was die Flexibilität bei sich ändernden Anforderungen einschränkte. Änderungsanforderungen im Reportsystem führten häufig zu komplexen Änderungen in allen darunter befindlichen Systemen, was den Aufwand für Änderungsprojekte erheblich steigen ließ.

Schließlich fand während der Initialisierung des Projekts eine umfang-reiche Neugestaltung der operativen Liefersysteme des DWH statt. Die daher erforderliche Neugestaltung der ETL-Schicht ließ eine komplette Erneuerung des DWH sinnvoll erscheinen.

Die drei hauptsächlichen Anforderungen an die neue Architektur waren daher, die Latenzzeiten zu reduzieren, die Flexibilität zu erhöhen und die Betriebskosten zu senken. Für die Latenzzeiten wurde die Anforderung de-finiert, alle Daten vortagsaktuell bereit zu halten und in einigen Bereichen für einen noch kürzeren Ladezyklus strukturell bereit zu sein. Zur Steige-


rung der Flexibilität wurden zwei Architekturprinzipien gebildet: die Re-duzierung auf so wenige physische Schichten wie möglich und die Redu-zierung von eigenentwickeltem Code, etwa für Aggregationen und Trans-formationen auf ein Minimum zur Reduktion der Komplexität, insbeson-dere bei Änderungen.

Diese Anforderungen machten eine komplett neue Architektur erforder-lich, die auch von einer organisatorischen Neuausrichtung der Informati-onslogistik begleitet wurde.

5 Organisation der Informationslogistik

Im Rahmen der neuen Ausrichtung des DWH der Swisscom Mobile wurde auch die Organisation der Informationslogistik neu aufgestellt. In diesem Abschnitt sollen die Zuständigkeiten und Rollen der beteiligten Stakehol-der dargestellt werden.

Abbildung 3 gibt einen Überblick über die Stakeholder im Umfeld des DWH bei der Swisscom Mobile.

Frontend-Team

Informations-konsumenten

Backend-Team

Steering Board

Def inition technischer Bedingungen

Kontrolle des DWH-Auftrages

Def inition von Analysen

Kontrolle der technischen Umsetzung

Abb. 3. Stakeholder-Überblick

5.1 Frontend-Team

Das Frontend-Team hat die Kernverantwortung für die Prozesse des DWH.

Die wesentlichen Aufgaben des Frontend-Teams lassen sich in drei Gruppen unterteilen: die Standard-Reportings, die Kampagnen-Analysen und die strategische Entwicklung der nutzerseitigen Aspekte der Informa-


tionslogistik. Wie in Abb. 3 ersichtlich, liegt der Fokus der Verantwortung des Frontend-Teams dabei auf den fachlichen Aspekten der Informations-logistik. Im Rahmen dieser Tätigkeit werden enge Beziehungen zu den Verantwortlichen der Technik und den Produktverantwortlichen gepflegt.

5.2 Informations-Konsumenten

Informations-Konsumenten (z.B. das Produktmanagement oder das Cont-rolling) sind z. B. für die Entwicklung neuer Produkte und Kampagnen auf die Daten und Analysen aus dem DWH angewiesen. Die jeweiligen Fach-spezialisten sind verantwortlich für die Definition der Analysen, die dann durch das Frontend-Team implementiert werden.

5.3 Steering Board

Das Steering Board ist das Kontrollgremium der DWH Aktivitäten. Es bewilligt die strategischen Planungen des Frontend-Teams und achtet auf die Einhaltung des Geschäftsauftrages aller beteiligten Stakeholder. Die Mitglieder des Steering Boards sind zugleich Mitglieder der Geschäftslei-tung der Swisscom Mobile.

5.4 Backend-Team

Das Backend-Team ist verantwortlich für Entwicklung und Betrieb der DWH Backend-Komponenten. Dieses Team verantwortet die technische Bereitstellung der Daten. Die Hauptschwerpunkte des Backend-Teams sind die Steuerung des BI-Projektgeschäfts (Projektleitung, Definition und Weiterentwicklung der DWH Architektur in Abstimmung mit dem Fron-tend-Team und den Enterprise Architekten, Lieferantenmanagement) und die Koordination der Betriebstätigkeiten.

Eine Abbildung der Verantwortlichkeiten auf die (vereinfachte) techni-sche Architektur des DWH ist in Abb. 4 dargestellt. Das Backend-Team verantwortet die datenhaltenden Systeme inklusive des zentralen DWHs. Das Frontend-Team verantwortet die Analysesysteme, während das Pro-duktmanagement lediglich Konsument der Reports ist.


Micro-strategy RS / AS …

NeMo

ERP Billing …

Reports, interaktive

Tools, Cubes

Reports

Bac

kend

-Te

amFr

onte

nd-

Team

Info

rmat

ions

-ko

nsum

ente

n

Abb. 4. Verantwortlichkeiten der DWH-Organisation

5.5 Prozesse der Informationslogistik

Wie bereits beschrieben, existieren drei Kernprozesse im Bereich des Frontend-Teams: Standard-Reports, Kampagnen-Reports und Entwick-lungsprozesse.

Für sämtliche Standard-Reports hat das Frontend-Team die Verantwor-tung für die Definition der Daten und die Korrektheit der Analysen.

Das Backend-Team hat die Aufgabe, die Daten gemäß den Anforderun-gen des Frontend-Teams zu Verfügung zu stellen und die Datenqualität si-cherzustellen. Diese Aufteilung ist durch einen klaren Managementauftrag gesteuert. Das Top-Management akzeptiert nur solche Reports, die durch das Frontend-Team erstellt wurden und deren Daten aus dem DWH stam-men.

Die Kampagnen-Prozesse werden wesentlich flexibler erstellt. Norma-lerweise definieren die Produkteinheiten das Analyseziel und das Fron-tend-Team stellt im Sinne einer Dienstleistung die entsprechenden Analy-


sen zusammen. Historisch bedingt gibt es teilweise auch noch sogenannte Power User mit erweiterten Zugriffsrechten, welche selbstständig Analy-sen anfertigen. Dies ist jedoch in Zukunft nicht mehr angestrebt, da die zu-nehmende Komplexität der vorhandenen Daten hohe Fehlerwahrschein-lichkeiten solcher Analysen mit sich bringt.

Die Entwicklungsprozesse zielen darauf ab, eine konsistente Roadmap für das Thema Informationslogistik zu entwickeln. Diese Roadmap wird im Konsens aller Stakeholder entwickelt. Der übliche Planungshorizont beträgt etwa 3 Jahre, wobei Projekte teilweise im Laufe dieser drei Jahre anders priorisiert werden. Die Roadmap wird durch das Steering Board des DWH überwacht. Die in der Roadmap aufgeführten Einzelprojekte werden jeweils auch durch das Steering Board genehmigt.

6 Einführung des neuen DWH

In diesem Abschnitt wird das Transformationsprojekt und das dabei entwi-ckelte System NeMO detailliert vorgestellt. Dabei werden auch einzelne technische Herausforderungen die zu bestimmten Architekturprinzipien führten detaillierter ausgeführt.

6.1 Projektverlauf

Das Projekt NeMo verlief in vier Phasen von den ersten Ideen bis zur Ab-schaltung der Altsysteme in einem Zeitraum von circa 3 Jahren. Da NeMo als Greenfield-Ansatz unabhängig von den bestehenden Altsystemen um-gesetzt wurde, war insbesondere eine umfangreiche Planungs- und Eva-luierungsphase notwendig, wie in Abb. 5 deutlich wird.

2004 09/2005 03/2006 08/2006

Initiale Kostenschätzung

PilotierungMachbar-keit und Scoping

Implemen-tierung

05/2007

Test und Produktiv-setzung

Abb. 5. Projektphasen NeMo Projekt

Nach einer initialen Kostenschätzung im Jahr 2004 wurde nach einer Phase der Diskussion die Grundsatzentscheidung gefällt, das Projekt inten-siver zu betrachten. Darauf wurde im September 2005 zunächst eine Pilot-implementierung durchgeführt. Nach dem erfolgreichen Abschluss dieser Implementierung wurden von März bis August 2006 detaillierte Machbar-


keitsstudien durchgeführt. Dabei wurden alle potenziell zu erschließenden Datenquellen individuell mit Kostenfaktoren bewertet und teilweise aus dem Projektsope ausgeschlossen. Die komplette Implementierung wurde in der letzten Phase vom August 2006 bis zum Mai 2007 durchgeführt. Nach einer anschließenden Test- und Überführungsphase wurden im Sep-tember 2007 die Altsysteme komplett abgeschaltet.

Sämtliche operative Tätigkeiten des Projektes wurden durch einen ex-ternen Generalunternehmer und weitere Partner durchgeführt, während in-nerhalb der Swisscom Mobile ein Projektsteuerungsteam installiert war. Bei der Auswahl der beteiligten Unternehmen wurde insbesondere Wert darauf gelegt, dass die Unternehmen auch in den folgenden Phasen des Lebenszyklus das Technikteam der Swisscom unterstützen können und dass bestehende Erfahrungen mit den DWH-Systemen in das Projekt ein-fließen können.

6.2 Systemarchitektur

Die in Abschn. 4.2 aufgeführten Anforderungen führten zur Auswahl einer zentralisierten Systemarchitektur. Sämtliche Daten werden in einem zent-ralen Enterprise Data Warehouse gespeichert, das über eine zentrale Sta-ging Area mit Daten beliefert wird (vgl. Abb. 6).

Es wurde versucht möglichst, in der neuen Architektur möglichst weni-ge Data Marts zu benötigen. Lediglich für einige komplexe Analysen aus dem Finanzbereich wurde ein individueller Datamart erstellt, der multidi-mensionale OLAP-Analysen ermöglicht. Das Ziel der Vereinfachung konnte erreicht werden, statt bisher fünf Schichten bestehen im neuen Sys-tem nur noch zwei Datenschichten.


Enterprise Data Warehouse

EDW base data

EDW derived data

EDW aggregation

EDW data mart

Metadata

StagingAreavolatile permanent

Source systems

ReportsReports

Reporting Portal Data Mining

Abb. 6. Systemarchitektur des Enterprise Data Warehouse

In der neuen Systemarchitektur wurden mehrere bestehende Systeme konsolidiert. Aus der alten Systemwelt wurden neben den Teilsystemen des DWH insbesondere das umfangreiche Kernsystem für das Teilnehmer-reporting und das Backend des Contolling-Systems in das NeMo-System integriert. Da das Teilnehmerreporting innerhalb der Swisscom Mobile ei-ne hohe strategische Bedeutung hat, existierten für die Integration dieses Systems sehr hohe Anforderungen an Daten- und Systemqualität, die in der neuen Systemarchitektur erfüllt werden konnten.

Das Datenmodell wurde in der dritten Normalform umgesetzt, um ma-ximale Flexibilität für die Auswertungen zu erreichen. Zum Erreichen der nötigen Verarbeitungsgeschwindigkeit wurde eine massiv parallele Shared Nothing-Architektur gewählt (vgl. Kap. 1).

Neben den Transaktionsdaten führt NeMO ein eigenes Metadaten-Repository. Hier werden insbesondere Log-Daten über die durchgeführten


Ladeprozesse und Datenqualitätsindikatoren geführt. Fachliche Metadaten werden außerhalb des Systems in eigenen Datenbanken geführt.

6.3 Daten im Enterprise Data Warehouse

Die Swisscom Mobile verfolgt einen ganzheitlichen Ansatz der Informati-onslogistik. Dies wurde erreicht, indem eine konsistente Kennzahlenpyra-mide erstellt wurde, wobei die Zahlen auf allen Ebenen durch Werte aus dem zentralen DWH-System hinterlegt sind. Dies ermöglicht eine sehr ho-he Datenqualität, führt jedoch auch zu einem gewissen Verlust an Flexibi-lität des Systems, da die Einführung neuer Datendefinitionen Einfluss auf das gesamte Kennzahlensystem hat. Aus diesem Grund ist die klare Da-tenhoheit in der Hand des BI-Teams von herausragender Bedeutung.

Abbildung 7 zeigt die Entwicklung den Aufbau der Datenstrukturen in der Swisscom Mobile. In der ersten Phase des DWH wurden lediglich die Top-Kennzahlen erhoben und dann wie oben beschrieben weiter nach un-ten bis auf die Basisdaten ausgedehnt. Heute werden umfangreiche Detail-daten im DWH gehalten, täglich werden mehrere Millionen Datensätze ge-laden. Die Basisdaten werden im neuen System nicht nur als Basis für Aggregationen genutzt, zusätzlich basieren auch die meisten Analysen di-rektem Zugriff auf die Basisdaten.

Top-Kennzahlen

Aggregierte Kennzahlen

Basisdaten

Abb. 7. Aufbau der Daten des Swisscom DWH


7 Analyse des DWH der Swisscom Mobile

7.1 Systemarchitektur

Bei der Umsetzung des Enterprise Data Warehouse wählte die Swisscom Mobile eine zentrale DWH-Architektur, die weitgehend ohne Data Marts auskommt. Die zentralisierte Architektur bietet gegenüber anderen Archi-tekturen einige Vorteile (vgl. Kap. 7), die auch im vorliegenden Projekt zu Tage treten.

Die Datenqualität kann im Vergleich zu anderen Lösungen mit gerin-gem Aufwand sichergestellt werden, da zentral gewartete Stammdaten auf demselben Aktualitätsstand für alle Daten vorliegen. Durch die integrierte Architektur können Transformations- und Verarbeitungsschritte vermieden werden, was die Aktualität steigert. Schließlich steigert die Verfügbarkeit von technischen Metadaten die Transparenz der Verarbeitungsprozesse.

Durch die zentrale Verfügbarkeit aller Daten ist die Integration von In-formationen über verschiedenen Prozessschritte und Funktionsbereiche im Unternehmen einfacher möglich als bei separaten, themenbezogenen Teil-systemen. Dies steigert die Flexibilität bei der Umsetzung von Auswertun-gen.

Schließlich ermöglicht die parallele Systemarchitektur hohe, skalierbare Systemleistung bei hoher Verfügbarkeit, da bei Ausfall einzelner System-teile die Last auf redundante Systemkomponenten verteilt werden kann, die zudem zur Skalierung des Systems einfach ergänzt werden können (vgl. Kap. 1).

7.2 Organisation

Die Struktur des DWH der Swisscom Mobile weist einige interessante Ei-genschaften auf, die einer detaillierteren Einordnung bedürfen.

Basierend auf der Analyse in Kap. 5 lassen sich vier unterschiedliche Formen der Organisation der Informationslogistik identifizieren: Business Service Provider, DWH Competence Center, Full Service Provider, DWH Platform Provider (vgl. Abb. 8).


Full Service Provider

Nutzung

DWH-IS

Technik

n=14

50%

60%

70%

Business Service Provider

Nutzung

DWH-IS

Technik

n=10

60%

40%

20%

DWH Competence Center

Nutzung

DWH-IS

Technik

n=29

30%

40%

30%

DWH Platform Provider

Nutzung

DWH-IS

Technik

n=15

30%

50%

60%

Ges

chäf

tsnä

he

Fertigungstiefe DWH-Informationssystem Abb. 8. Leistungserbringertypen (aggregierte Tätigkeitsanteile, vgl. Kap 5)

Die Informationslogistik-Organisation bei der Swisscom Mobile ist in diesem Klassifizierungsschema als Business Service Provider einzustufen. Diese Art der Organisationseinheit erbringt eine hohe Fertigungstiefe im fachlichen Bereich bei geringer Fertigungstiefe im technischen Bereich während der Betriebsphase. Auch in der Aufbauphase war die Fertigungs-tiefe im fachlichen Bereich sehr hoch, hier wurden zusätzlich wesentliche fachliche Aufgaben im Rahmen der Projektumsetzung vom Backend-Team übernommen.

Dies wird insbesondere deutlich, wenn man die Prozesshoheit des Fron-tend-Teams über sämtliche Prozesse betrachtet. Auch die klare Trennung zwischen technischer und inhaltlicher Verantwortlichkeit ist ein Charakte-ristikum einer als Business Service Provider aufgestellten Informationslo-gistik-Organisation.

Jedoch weist der Aufbau des Enterprise DWH einige Besonderheiten auf, wobei zwischen technischen und organisatorischen Aspekten zu tren-nen ist. Organisatorisch ist eine extrem starke Position des Frontend-Teams erkennbar. Die Geschäftsleitung hat für sämtliche Fragestellungen der Informationslogistik die ausschließliche Verantwortung an das Fron-tend-Team delegiert. Die drückt sich zum Beispiel dadurch aus, dass sämt-liche quantitativen Berichte an die Geschäftsleitung durch Daten des Fron-tend-Teams gestützt werden müssen und nicht durch Datenerhebungen in einzelnen Geschäftsbereichen. Weiterhin ist das Steering Board direkt durch Mitglieder der Geschäftsleitung besetzt, was die strategische Bedeu-tung des Themas aus der Sicht der Geschäftsleitung der Swisscom Mobile unterstreicht.


Diese Besonderheiten der Organisation der Informationslogistik haben Vor- und Nachteile, die im Folgenden kurz analysiert werden sollen.

8 Konsequenzen und Ausblick

8.1 Projektergebnisse

Das NeMo-Projekt hat die gesteckten Ziel voll erreicht. Sämtliche Daten können vortagsaktuell dargestellt werden und die neue Architektur hat die Erstellung neuer Reports erheblich vereinfacht. Die so gewonnene Flexibi-lität steigert die Akzeptanz des Systems erheblich. Weiterhin wurde durch die Abschaffung vieler einzelner Data Marts eine wesentlich höhere Da-tenqualität und -konsistenz erreicht. Schließlich konnten die Betriebskos-ten um über 50% gesenkt werden.

Als wesentliche Erfolgsfaktoren für das Umsetzungsprojekt wurden bei Swisscom Mobile insbesondere die Kommunikation der strategischen Be-deutung des NeMo-Projekts identifiziert. Auch die umfangreiche Pla-nungsphase hat den Erfolg des Projektes wesentlich beeinflusst.

8.2 Organisatorische Aspekte

Die Organisation der Informationslogistik in der Swisscom Mobile ist durch eine hohe Effizienz bei gleichzeitig hohen Qualitätsstandards ge-kennzeichnet. In diesem Abschnitt sollen die Erfolgsfaktoren sowie die Herausforderungen der speziellen Organisationsform der Informationslo-gistik bei der Swisscom Mobile kurz analysiert werden.

Die kritischen Erfolgsfaktoren der Informationslogistik werden in der Swisscom Mobile durch regelmäßige Kundenbefragungen des Frontend-Teams identifiziert.

Neben der vom Management geforderten maximalen Datenqualität ist insbesondere schnelle und automatisierte Analyse von aktuellen Daten von Bedeutung. Gerade im dynamischen Telekommunikationsgeschäft ist die Häufigkeit und Reaktionsgeschwindigkeit der BI-Analysen ein entschei-dender Vorteil, der die der Time to Market von neuen Produkten verkürzen kann.

Ein weiterer Erfolgsfaktor ist die Effizienz des DWH. Obwohl in der Swisscom Mobile zurzeit keine interne Kostenverrechnung stattfindet, be-steht ein hoher Kostendruck durch das Topmanagement. Aus dieser Pers-pektive wurde auch Anfangs 2007 die Outsourcing-Entscheidung für das DWH getroffen, welche zu erheblichen Kosteneinsparungen führte.


Die starke Position des BI-Teams führt zwangsweise zu besonderen He-rausforderungen. Ein häufig auftretendes Phänomen bei starker Zentrali-sierung ist die Fokussierung auf interne Abläufe und ein Verlust der Marktorientierung, da keine Konkurrenz um die Kunden existiert. Diesem Phänomen begegnet man in der Swisscom Mobile durch eine enge Zu-sammenarbeit und regelmäßige Kundenbefragungen. Nichtsdestotrotz ist das Frontend-Team mit der ständigen Herausforderung konfrontiert, die Effizienzbemühungen nicht zu Ungunsten der Leistungsvielfalt einzu-schränken.

8.3 Ausblick: Zukünftige Herausforderungen für die Swisscom Mobile

Nach der erfolgreichen Erweiterung der Informationslogistik 2006-2007 steht die Swisscom Mobile bereits wieder vor großen Herausforderungen. Eine umfangreiche Reorganisation der gesamten Swisscom führt zu einer Reintegration der verschiedenen Geschäftssparten. Im Zuge dieser Rein-tegration spielt auch die Integration der Informationslogistik eine große Rolle. Aus diesem Grunde wurden zum Zeitpunkt der Erstellung der Fall-studie unterschiedliche Integrationsszenarien diskutiert.

Neben dieser immensen Herausforderung soll das Portfolio an Standard-Analysen erweitert werden. Die Möglichkeit, einfach standardisierte Re-ports abzurufen, bietet den Produktmanagern einen großen Mehrwert. Die größte Herausforderung besteht dabei in dem Schaffen von verlässlichen Daten. Gerade aus dieser Sicht bleibt die Sicherstellung der hohen Daten-qualität des DWH der Swisscom Mobile ein vordringliches Ziel.

Literatur

Jost, M.: Der Markt für IT Services in der Schweiz, 2003 - 2008, IDC, Frankfurt 2004.

o. V. : Jahresbericht der Swisscom, Swisscom AG, Bern 2006. o. V. : Der Schweizer Fernmeldemarkt im internationalen Vergleich, Bundesamt

für Kommunikation - Abteilung Telecomdienste, Biel 2007a. o. V. : Swisscom in neuem Kleid, Medienmitteilung, Bern 2007b.

Autorenverzeichnis

Maximilian Ahrens Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected]

Tobias Bucher Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], eiw.iwi.unisg.ch

Dr. Barbara Dinter Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], eiw.iwi.unisg.ch

Markus Huber Swisscom (Switzerland) Ltd Waldeggstrasse 51, CH-3097 Bern-Liebefeld [email protected], www.swisscom.ch

Kai Hüner

Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], cdq.iwi.unisg.ch

Dr. Mario Klesse Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], eiw.iwi.unisg.ch

Robert Konzelmann Teradata (Schweiz) GmbH Postfach, CH-8301 Glattzentrum [email protected], www.teradata.com

332 Autorenverzeichnis

Peter Kühni Swisscom (Switzerland) Ltd Waldeggstrasse 51, CH-3097 Bern-Liebefeld [email protected], www.swisscom.ch

Gerrit Lahrmann Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], eiw.iwi.unisg.ch

Dr. Boris Otto Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], cdq.iwi.unisg.ch

Moritz Schmaltz Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], eiw.iwi.unisg.ch

Alexander Schmidt Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], cdq.iwi.unisg.ch

Florian Stroh

Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], eiw.iwi.unisg.ch

Dr. Jochen Töpfer Teradata (Schweiz) GmbH Postfach, CH-8301 Glattzentrum [email protected], www.teradata.com

Tobias Vogel Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], cdq.iwi.unisg.ch

Autorenverzeichnis 333

Hans Wegener Zurich Financial Services Postfach, CH-8085 Zürich [email protected], www.zurich.com

Kristin Wende Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], cdq.iwi.unisg.ch

Prof. Dr. Robert Winter Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen [email protected], www.iwi.unisg.ch

Sachverzeichnis

A

Abrechnungsmodell 246 Active Data Warehouse 4, 9, 15,

145 Active Data Warehousing 234 Active Enterprise Intelligence 4, 15 Aggregation 167, 168 Agilität 35, 166, 226 Aktualität 19, 132, 251, 327 Alignment 4, 39, 55, 165, 166, 167 Analyselatenz 170 analytische Applikation 301 analytische Nutzung 45 Anforderung 293 Anforderungsanalyse 294 Anforderungserhebung 291 Anspruchsgruppe 34 Antwortzeit 251 Architektur 129, 278, 298

serviceorientierte 221 Architekturtyp 138 Attribut 215 Aufgabe 212 Aufgabenstrukturierung 32 Aufgabenverteilung 82

B

Backend-Team 321 Balanced Scorecard 73 Basel II 169 Basisdaten 326 Bereinigungswerkzeug 216 Best Practice 276 Betrachtungseinheit 44, 45

Betriebswirtschaftslehre 31 BI-Strategie 65 Bonitäts-Score 165 Business Activity Monitoring 107,

236 Business Case 168 Business Engineering 30, 31, 33,

36, 41, 207 – Gegenstand des 36 – Modelle des 37 – Vision des 35 Business Engineering-Landkarte 33 Business Impact Assessment 173 Business Impact Model 286 Business Improvement Opportunity

285, 287 Business Intelligence 2, 21, 48 Business Performance Management

107 Business Service Provider 88, 328 BYNET 10

C

Change Management 31, 173 Change the Business 33 Closed Loop 231 Clusteranalyse 84 Common Warehouse Metamodel

194 Competitive Potential Alignment 62 Compliance 169 Corporate Performance

Management 236 Cross-Selling 165

336 Sachverzeichnis

D

Data Dictionary 19 Data Governance 207, 212, 213 Data Governance Council 205 Data Governance-Komitee 213 Data Management Body of

Knowledge 205 Data Mart 324, 327 – Busarchitektur 139 – unabhängige 139 Data Warehouse 3, 8, 47, 77, 78,

158, 274, 318 – Betrieb 81 – Entwicklung 80 – Nutzung 80 – Support 82 Data Warehouse Maturity

Assessment 288 Data Warehouse Maturity Model

288 Data Warehousing 47, 77, 79, 243,

244 Data-Warehousing-Prozess 77 Daten 203 Datenarchitektur 207, 215, 216 Datenfluss 44, 45, 202, 216 Datenhaltungssystem 216 Datenintegration 2, 15, 179 Datenlatenz 170 Datenmanagement 204 Datenmanagementprozess 214 Datenmodell 17, 189, 325 logisches 296 physisches 301 Datenobjekt 215 Datenqualität 21, 130, 132, 168,

201, 202, 203, 319, 327 – Kosten von 209 – Messen von 210 – Nutzen der 210 – Verbesserung 216 – Ziele der 209 Datenqualitätsmanagement 204,

205, 214 – Nutzen des 209

– Systemunterstützung 216 Datenqualitätsproblem 210 Datenqualitätssicherung 79 Datenqualitätsstrategie 207, 208 Datenqualitätsziel 210 Datenquelle 79, 185 Datensteward 213 Decision Support Systems 49 Delivery-Strategie 68 detaildatenbasierte

Massenkalkulationen 165 Dimensionsdaten 168 Distributionsform 250 DWH Competence Center 91, 243 DWH Platform Provider 90 DWH-Applikationen 79 DWH-CC 92, 244 DWH-FSP 86 DWH-Informationssystem 79 DWH-Integrationsinfrastruktur 79 DWH-Leistungserbringer 82 DWH-Leistungserbringertypen 86 DWH-Organisation 77 DWH-PP 90

E

EAI 146 Effektivität 34 Effizienz 34 Einzelhandel 210 empirische Untersuchung 82, 110 Enterprise Data Warehouse 324 Enterprise Data Warehouse-

Roadmap 287 Enterprise Event Management 24 Entkopplung 37 Entkopplungsmechanismus 37 Entscheidung 165 Entscheidungslatenz 170 Entscheidungsprozess 165 Entscheidungsunterstützung 1, 9,

44, 45 Entwicklung 275 Entwicklungsmodus 30 Entwicklungsstrategie 69

Sachverzeichnis 337

Ereignis 24 Erfahrungsdatenbank 110 Erfolgsfaktor 162 Erneuerung 30 eventgesteuerte Aktivität 164 Executive Information Systems 49 Extraction, Transform, Cleanse

Load 298, 302

F

Fachabteilung 82 Fachbegriff 189 fachliches Verständnis 184 Fertigungstiefe 85, 95 Finanzierung 136 Flexibilität 35, 135, 226, 251, 318 Föderierte Architektur 142 Formalziel-Dimension 35 Frontend-Team 320, 328 Führungsgröße 210 Führungsinformationssysteme 49 Führungssystem 207, 210 Full Service Provider 86 Funktion 244, 249 Funktionalität 250

G

Ganzheitlichkeit 31 Gegenstand 249 Gemeinkostenproblematik 244 Geschäftsbegriff 193 Geschäftsbereich 44 Geschäftseinheit 31 Geschäftsmodell 2, 5 Geschäftsnähe 85, 95 Geschäftsnutzen 285 Geschäftspotenzial 8 Geschäftsprozess 5, 159, 214 Geschäftsregel 189 Geschwindigkeit 169 Gestaltung 31 Gestaltungselement 206 Gestaltungsfaktor 113 Gestaltungsmethode 36 Gestaltungsobjekt 36, 37

– Lebenszyklus des 36, 37

H

Homonym 216 Horizontale Informationsintegration

137 Hub and Spoke-Architektur 141

I

IL-Infrastruktur 158 IL-Leitbild 73 IL-Masterplan 74 IL-Projekte 158 IL-Strategie 63 Implementierung 300 Information 45, 79, 203, 244, 247,

249 Informationsbedarf 157, 175, 285,

291 Informationsbedarfsanalyse 281 Informationslandkarte 281 Informationslogistik 41, 44, 54, 59,

77, 78, 101, 102, 103, 107, 157, 243, 317

– Abgrenzung 47 – Aufgaben der 47 – Betrachtungseinheiten der 44 – Nutzen der 158, 160 – prozessorientierte 102, 107, 108,

110, 112, 116, 120, 235 – Synergiepotenziale der 50 – Wertbeiträge der 163 – Ziele der 47, 318 Informationslogistik-Infrastruktur

109 Informationslogistik-Projekte 158 – Bewertung von 160 – Eigenschaften von 158 Informationslogistik-Strategie 59 Informationsmanagement – integriertes 65 Informationsobjekte 248 Informationsprodukt 244, 248 Informationsproduktion 247, 248,

252

338 Sachverzeichnis

Informationsproduktionsmodell 255 Informationsproduktionsprozess

253 Informationsproduktmodell 248 Informationsqualität 130 Informationsversorgung 102, 117,

121, 281 Infrastruktur 51, 54, 171, 244 Infrastrukturcharakter 51, 159 Infrastrukturkosten 171 In-Memory Analytics 147 Innovation 30 Integrationsebene 37 Integrationsgrad 117 Integrationsinfrastruktur 243 Integrationsschicht 223 Internes Leistungsmodell 246 Investitionsschutz 15 Ist-Analyse 260 Ist-Situation 282 IT / Business Alignment 62 IT-Innovation 33 IT-Strategie 60

K

Kalkulation 266 Kausalanalyse 110 Kennzahl 318 Kennzahlen 174, 175, 211 Kennzahlensystem 326 Komplexität 159 Konsistenz 35, 37, 133 Konstruktionslehre 31, 38 Kontext 36 Konzerndatenqualität 204 Kosten 158, 243 Kosten-

und Leistungsrechnungssystem 247

Kosteneffekt 168 Kosteneinsparungen 171 Kostenersparnis 161 Kostenschätzung 175 Kostensenkung 159, 161, 168 Kundenbeziehung 164

Kunden-Lieferanten-Beziehungen 87

Kundenmanagement 202 Kundenorientierung 163 Kundenschnittstelle 261

L

Latenzzeit 169 Leistung 244 Leistungs- und Kostenmodell 264 Leistungserbringer 85 – Typen 85 Leistungserbringertyp 95 Leistungsverrechnung 244, 245,

246, 247 – Elemente der 246 – Ziele der 245 Lieferfähigkeit 171

M

Management Information Systems 49

Management Support Systems 49, 50

Marktöffnung 315 Marktsegmentierung 165 Massively Parallel Processing 10 Merkmals-Modellierung 190 Metadaten 19, 189, 325 Meta-Programmierung 190 Methode 38, 244, 257, 275 Methodenbasierung 31 Mobilfunkmarkt 314 Modell 38, 180, 185 Modellbasierung 31 Modellevolution 180 Modellintegration 180

N

Nutzen – Bewertung von 158, 173

Nutzenbetrachtung 158 Nutzeneffekt 110, 112 Nutzenkategorie 161

Sachverzeichnis 339

Nutzenpotenzial 159, 172 – Bewertung von 174 – Prognose von 175

O

Operational Business Intelligence 108

Operational Data Store 11 Operational Intelligence 4, 7 Optimierung 30 Ordnungsrahmen 205, 206 Organisation 29, 34, 320, 329 Organisationsebene 33 Organisationseinheit 44 Organisationsform 93, 95 – Auswahl der 95 organisatorische Einbettung 172 Outsourcing-Partner 95

P

Parametrisierung 190 Partikularsicht 55 Performance 10 Performanz 134 Personal 136 Personalkosten 171 Pervasive Business Intelligence 15,

21 Planung 266 Planungssystem 60 Plattform 171 Plattformleistungen 255 Politisch-kulturelle Ebene 33 Portfoliostrategie 95 Portfolio-Strategie 69 Preis 244 Preismodell 246 Privatisierung 315 Produkt 244, 246, 247 Produktionsprozess 244 Produktionsstrategie 70 Projektcontrolling 174 Projektkennzahl 175 Projekttyp 36

Prozess 29, 33, 79, 102, 104, 105, 121, 244, 248

Prozesscharakter 51, 53 Prozesslandschaft 121 Prozessleistungen 255 Prozessmanagement 101, 105 Prozessoptimierung 161, 162 Prozessorganisation 101, 103 Prozessorientierung 102, 103, 107

Q

Qualität 249 Quellsystem 290, 297

R

Real Time Data Warehousing 234 Realisierungsform 116, 119 Real-Time Warehousing 146 Referenzdaten 190 Referenzmodell 18 Reifegradmodell 5 Ressourcen 136 Richtigkeit 250 Risikofaktor 54 Risikomanagement 169 Rolle 82, 212

S

Sachziel 35 Sarbanes-Oxley-Act 169 Service 223, 243 Analytischer 230 Applikations- 223 Enterprise 223 Extraktions- 228 fachlicher 224 Frontend 230 Infrastruktur- 231 Prozess- 225 Software- 224 Sourcing 228 Transformations- 229 Service Level Agreement 15 Service Level Alignment 62

340 Sachverzeichnis

Serviceorientierung 2, 222 Shared Nothing-Architektur 10, 14 Shared Resource-Architektur 10 Sicherheit 136 Situationsanalyse 72 Skalierbarkeit 13 Solvency II 169 Sourcing-Strategie 67, 95 Speicherung 250 Sponsor 212 St. Galler Anwenderforum 83 St. Galler Managementmodell 29,

32 Staging Area 324 Stammdaten 191, 214 – Sicht 216 Stammdatenmanagement 217 Standardisierung 30 Steering Board 321, 328 Stelle 44 Strategic Alignment Model 61 Strategic Intelligence 4, 7 Strategie 60, 282 Strategieebene 32 Strategieentwicklung 74 Strategieentwicklungsprozess 71 Strategische Bedeutung 136 strategische Planung 60 Strategische Zielplanung 72 Strategischer Charakter 51, 53 strategischer Wettbewerbsvorteil

161, 162 Strategy Execution Alignment 62 Strategy Map 73 Struktur 249 strukturelles Beschreibungsmerkmal

184 Supportprozess 248 Swisscom Mobile AG 313, 315 Synonym 216 System 79, 277 Systemarchitektur 130, 159, 216,

324, 325, 327 Systemebene 33 Systemqualität 130, 134 Systems Engineering 31

T

Technologiebeobachtung 31 Technology Transformation

Alignment 62 Teradata 173 Teradata Solution Methodology

275, 279 Phasen 277 Test 305 Total Data Quality Management

204 Total Information Quality

Management 205 Total Quality data Management 205 Transparenz 35, 39, 134, 327

U

Umlageverfahren 247 Unternehmen 157 Unternehmensmodell 5, 22 Unternehmenssteuerung 202 Unternehmensstrategie 208 Unternehmung 29, 31

V

Veränderung 30, 31, 34 – Aufgaben der 31, 32 – Ergebnis der 34 – Gegenstand der 36 – Ziel der 34, 35 Veränderungsmethode 36 Veränderungsprojekt 32 Veränderungsprozess 34, 38 – Typen des 38 Veränderungsvorhaben 31, 32, 35 Verantwortlichkeit 212 Verantwortlichkeitsdiagramm 213,

214 Vereinfachung 35 Verfügbarkeit 12, 135 Vernetzungsfähigkeit 30 Vertikale Informationsintegration

137 Verwendungsform 138

Sachverzeichnis 341

Virtuelle Architektur 144 Vision 72 V-Modell 306 Vollständigkeit 133, 250 Vorgabe 258 Vorgehensmodell 119, 257

W

Wertebereich 216 Wertschöpfung 51 Wertschöpfungsnetzwerk 30 Wiederverwendung 187

Wirtschaftlichkeitsbetrachtung 158 Wirtschaftlichkeitsziel 34 Workload 12

Z

Zentralisierte Architektur 141 Zielwert 210 Zielwerte 175 Zugänglichkeit 251 Zuständigkeit 212 Zuständigkeitstyp 213 Zuverlässigkeit 251

Active Enterprise Intelligence: Unternehmensweite Informationslogistik als Basis einer...

Documents

Transcript of Active Enterprise Intelligence: Unternehmensweite Informationslogistik als Basis einer...