Active Enterprise Intelligence: Unternehmensweite Informationslogistik als Basis einer wertorientierten Unternehmenssteuerung

Active Enterprise IntelligenceTM

Jochen Töpfer · Robert Winter Herausgeber

Active Enterprise Intelligence TM

Unternehmensweite Informationslogistik als Basis einer wertorientierten Unternehmenssteuerung

123

Dr. Jochen Töpfer Teradata (Schweiz) GmbH Postfach 8301 Glattzentrum Schweiz [email protected]

Prof. Dr. Robert Winter Universität St. Gallen Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8 9000 St. Gallen Schweiz [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 Nationalbibliothek Die 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 Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Herstellung: le-tex publishing services oHG, Leipzig Einbandgestaltung: WMX Design GmbH, Heidelberg Titelbild: John Knill/Digital Vision/Getty Images Gedruckt auf säurefreiem Papier 987654321 springer.de

Vorwort

Heutige globale Geschäftsmodelle sind alle betriebswirtschaftlichen Funktionsbereiche übergreifend stark arbeitsteilig aufgebaut. Diese innovative Vernetzung der Wertschöpfungsprozesse über Landesgrenzen und Kontinente hinweg erfordert ebensolche Innovationen in der Informationstechnologie. 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ätsverbesserung 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 ermöglicht. Durch die unter den Sammelbegriff Data Warehousing / Business Intelligence zusammengefassten Innovationen wurde es beispielsweise möglich, entscheidungsrelevante Informationen systematisch in der nachgefragten Qualität und der notwendigen Geschwindigkeit bereitzustellen, ohne an die Einschränkungen operativer Systeme gebunden zu sein. Operative Systeme zeichnen sich im Hinblick auf ihre Eignung zur Entscheidungsunterstü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 Informationsversorgung ist zum unverzichtbaren Bestandteil der betrieblichen Informationssystem-Architektur geworden. Mehr denn je erkennen Unternehmen, dass die integrierte, systematische Befriedigung von Informationsbedarfen 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 Informationssystemen und insbesondere zum Data Warehousing als wichtiger Basistechnologie 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 Enterprise Intelligence-Ansatz mit aktuellen Problemfeldern und ganzheitlichen Lösungsansätzen der Informationslogistik verbunden und es werden Hinweise zur Gestaltung der Informationslogistik in fachlicher, organisatorischer 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 integrierten 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 operationale 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 Informationslogistik auf den verschiedenen Ebenen des Business Engineering-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 Überblick ü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 Informationslogistik. Wegener erläutert in seinem Beitrag die Konzepte der Metadaten, Referenzdaten und Stammdaten und ihre Rolle zur Verwirklichung 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 Informationslogistik gelegt werden kann. Klesse stellt seinen Ansatz für eine Leistungsverrechnung 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 beschreiben die Einführung eines Enterprise Data Warehouse bei der Swisscom Mobile. Unser besonderer Dank gilt der NCR Stiftung zur Förderung wissenschaftlicher 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 Wirtschaftsinformatik 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ühler von Teradata (Schweiz) auch stellvertretend für alle weiteren involvierten 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 Konstruktionslehre 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

10

Inhaltsverzeichnis

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 2 3 4 5 6

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

1

Pervasive Business Intelligence – eine Vision

Viele Firmen unternahmen in den letzten 20 Jahren sehr große Anstrengungen, 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 Wettbewerb 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 Informationssysteme zur Entscheidungsunterstützung weiter zu steigern? Grundsätzlich ist eine Unternehmung nur dann langfristig erfolgreich, wenn sie im Rahmen 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 diese Entscheidungen x x x x

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 Unternehmensdaten. 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 Unternehmensinformationen. Nur dann können Entscheidungsprozesse zeitnah und nachvollziehbar unterstützt werden. In der Vergangenheit wurden Daten in erster Linie Funktionen zugeordnet. Dadurch wird die Datenintegration verfehlt. Werden jedoch alle Unternehmensdaten 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 kompliziert, 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 Wettbewerber und auch Führungskräfte sich verändern, gilt es aus Unternehmenssicht, auf dieser Lernkurve stetig voranzukommen und sich an geänderte Rahmenbedingungen anzupassen. Eine konsequente Serviceorientierung ist auch für eine Business Intelligence-Referenzarchitektur zur Unterstützung flexibler Entscheidungsprozesse 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 Transaction Repositories ablegen. Data Integration Services extrahieren, transformieren und laden Transaktionsdaten aus unterschiedlichsten internen

Active Enterprise Intelligence

3

und externen Transaction Repositories und speichern diese als integrierte Unternehmensdaten unter Verwendung eines applikationsneutralen Datenmodells 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 zeitnaher (near real time) Analytik zur Informationsanreicherung der Geschäftsprozesse.

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

Damit bestehende oder neue Analyseplattformen neue Geschäftsanforderungen 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 Applikationen und Systemen Daten auszutauschen, und gemeinsam an einem übergreifenden Geschäftsprozess zu arbeiten. Dies geschieht mittels offenen 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 Benutzern 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

2

Jochen Töpfer

Active Enterprise Intelligence – eine Strategie

Active Enterprise Intelligence (AEI) ist eine Strategie, die zwischen Strategic und Operational Intelligence unterscheidet, diese aber in einer ganzheitlichen Betrachtungsweise wieder zusammenführt. In den letzten Jahren hat sich die klassische Business Intelligence, die eher strategische und taktische Fragestellungen zu beantworten suchte, weiterentwickelt und zunehmend operationale Themenstellungen aufgegriffen (Imhoff 2006). Strategic Intelligence hat einen Fokus auf lang- und mittelfristige Zielstellungen und basiert auf historisierten und zumeist aggregierten Monats-, teilweise auch Tagesdaten. Es werden Entscheidungsprozesse der Unternehmensleitung unterstützt. Operational Intelligence ist direkt in den operationalen Geschäftsprozessen integriert und unterstützt somit jeden Mitarbeiter mit aktueller (intraday) Information. Besonders hervorzuheben sind Informationen, die sowohl die aktuelle Datenlage als auch Analytik aus integrierten, historisierten Detaildaten in Sekundenbruchteilen erfordern. Strategische und operationale Informationssysteme so auf einander abzustimmen (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 Value Business event Data latency

Value lost Analysis latency

Data ready

Intelligence delivered

Decision latency

Action taken Time Action time / Action distance

Abb. 2. Wertverlust bei Verzögerung zwischen einem Geschäftsereignis und folgender 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 folgenden Handlung. Hier ist die Erkenntnis wichtig, dass sowohl für Daten-

Active Enterprise Intelligence

5

aufbereitung, Analyse bzw. Entscheidungsvorbereitung und Entscheidungsfindung sehr unterschiedliche Teilprozesse zu durchlaufen sind, bevor eine Handlung ausgelöst werden kann (Imhoff 2006). Derzeit werden beispielsweise im Bankenmarkt verstärkt Geschäftsprozesse im Rahmen der Kundeninteraktion etabliert, deren analytische Fähigkeiten sowohl eine Aktualisierung der Unternehmensdaten im Minutenbzw. 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 Unternehmensmodelle abgeleitet, welche das Zusammenspiel von Input- und Steuerungsgrößen beschreiben. Zur Steuerung des Unternehmens müssen Entscheidungen an wohl definierten Steuergrößen getroffen werden. Den Entscheidungen ist ein Prozessablauf mit entsprechendem Informationsbedarf und beteiligten Personen zugeordnet. Entscheidungsprozesse haben ihren Ursprung im Geschäftsmodell und werden mit allen genutzten Informationen nachvollziehbar dokumentiert. Informationen werden zielorientiert im Rahmen von Entscheidungsprozessen eingesetzt und in der Struktur und Präsentation gemäß der Sichtweise von Businessanwendern aufbereitet. Informationen sind demnach für Entscheidungsprozesse zielgerichtet eingesetzte 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 hilfreich, das die Reife von Business Intelligence (BI) und Data Warehousing (DW) innerhalb einer Unternehmung in Stufen beschreibt. In der folgenden Darstellung wird die Intelligenz in der Anwendung (Data Sophistication) mit den Anforderungen an das Datenmanagement (Workload Complexity) 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. Schrader 2007). In der Phase Reporting wird auf die Jahre zurückgeblickt, in denen tatsächlich gedrucktes Papier in Batchläufen erzeugt wurde. Die Berichtsinhalte 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 ACTIVATING MAKE it happen!

Workload Complexity

OPERATIONALIZING WHAT IS happening now? PREDICTING WHAT WILL happen? ANALYZING WHY did it happen? REPORTING WHAT happened?

Predictive Models

Automated Linkages Link to Operational Systems

Ad Hoc Analytics Continuous Update/ Short Queries

Ad Hoc, BI Tools Batch Reports

Batch

Event-Based Triggering

Data Sophistication

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 gespeichert 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 Clusteranalyse, Mustererkennung, Segmentierung oder Vorhersage erforderlich. Um jederzeit Auskunft geben zu können, welchen Status die Geschäftsprozesse im Moment haben, benötigt man die Fähigkeit der Phase Operationalizing. Um die Frage „What is happening now?“ beantworten zu können, müssen untertags in kurzen Intervallen die Daten der Geschäftsprozesse für die weiterführende Analyse bereitgestellt werden. Sobald diese aktuellen und integrierten Daten wiederum in der Steuerung der Geschäftsprozesse zum Einsatz kommen, wird diese Anwendung der Phase Activating zugeordnet.

Active Enterprise Intelligence

7

OPERATIONAL INTELLIGENCE ACTIVATING MAKE it happen!

Align

STRATEGIC INTELLIGENCE

OPERATIONALIZING WHAT IS happening now?

PREDICTING WHAT WILL happen?

REPORTING WHAT happened?

ANALYZING WHY did it happen?

Link to Operational Systems

Predictive Models Ad Hoc, BI Tools

Batch Reports

Automated Linkages

Today

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

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

In Abb. 4 wird deutlich, dass in Zukunft die operative Nutzung von Unternehmensdaten unmittelbar in den Geschäftsprozessen einen neuen Wettbewerbsvorteil ermöglicht, wenn sich diese mit der strategischen Ausrichtung im Einklang befindet. Die ersten drei Phasen Reporting, Analyzing und Predicting werden als Strategic Intelligence bezeichnet, während Operationalizing und Activating der Operational Intelligence zugeordnet werden. Active Enterprise Intelligence impliziert somit, dass das Handeln der Benutzer von der Geschä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, sondern als Applikationen und Workflows basierend auf derselben konsistenten Datenbasis – einem ADW. Eine zielführende und effektive Behandlung von Geschäftspotenzialen, Geschäftsmodellen, Entscheidungs- und Planungsprozessen auf Basis eines ADW können das Wachstumstempo eines Unternehmens beschleunigen. Die schrittweise Umsetzung einer Active Enterprise Intelligence-Strategie erfolgt nach einer in Kap. 13 beschriebenen Methodologie.

8

Jochen Töpfer

Tabelle 1. Vergleich Strategic Intelligence / Operational Intelligence Strategic Intelligence Benutzer Zu ladende Daten Antwortzeit

Operational Intelligence

Planer, Analysten, Manager, Konsumenten, Call Center, Finanz, Marketing Verkäufer, Lieferanten, Systeme / Applikationen 10–100 pro Sekunde 100–10'000 pro Sekunde Sekunden bis Stunden

1–5 Sekunden, in Ausnahmefällen einige Minuten UpdateTägliche Batch Loads Innerhalb von Minuten und / oder Frequenz Stunden Zugriff BI Werkzeuge, Excel Dashboards, Portale, Applikationen, Alerts Verfügbarkeit Business Critical – Mission Critical – kurze Nichtverfügbarkeit ist garantierte Hochverfügbarkeit tolerierbar

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

Active Enterprise Intelligence

3

9

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 hilfreich bzw. lösungsorientiert. Das traditionelle Data Warehouse wird typischerweise von Entscheidungsträgern im Marketing, Finanzen und Strategischer Planung eingesetzt (Brobst et al. 2007). Gegenüber der strategischen Entscheidungsunterstützung, 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 treffen „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 strategischer Effekt. Der Wertschöpfungsprozess selbst wird mit relevanten Informationen bedient, dadurch gesteuert und ständig optimiert. Eine Vereinheitlichung 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 Informationsbasis muss diesem Entscheidungsrhythmus angepasst sein. Die Aktualität und Verarbeitungsgeschwindigkeit der Daten von den operativen Basissystemen der Geschäftsprozesse bis hin zu entscheidungsrelevanten Informationen beim Zugriff auf das Data Warehouse muss in der Regel der Geschwindigkeit entsprechen, in der eine Entscheidung getroffen und umgesetzt wird. Diese Anforderungen an ein Data Warehouse werden von einem Active Data Warehouse (ADW) erfüllt. Hier sind explizite Eigenschaften 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 Verlässlichkeit, Skalierbarkeit, Betrieb und Wartung sowie der Investitionsschutz ausführlich erläutert.

10

Jochen Töpfer

3.1 End-to-End-Performance Das Ermöglichen von zeitnahen Zugriffsszenarien ist für einen zielkonformen Einsatz und die Akzeptanz einer ADW-Systemumgebung existentiell. Grundsätzlich unterscheiden sich zwei Architekturvarianten, die Shared Resource- und Shared Nothing-Architektur. Werden im Rahmen einer Parallelisierung von Einzelrechnern Komponenten wie CPU, Arbeitsspeicher, 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 sparen. Diese Zielsetzung ist nur auf Kosten der Performance erreichbar. Eine Shared Nothing-Architektur dagegen ist auf höchstmögliche Rechenleistung und Input/Output-Bandbreite ausgelegt. Diese Zielsetzung kann zu leicht höherem Speicherplatzbedarf führen. Dennoch ist das Verhältnis von Performance zu Kosten wesentlich günstiger als bei einer Shared Resource-Architektur (Burns et al. 2004). Bis zu 1024 Knotenrechner werden über eine vollskalierbare Interconnect-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 Anforderung 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ährend 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.

Active Enterprise Intelligence

11

Dual BYNET Interconnects

SMP Node1

SMP Node2

SMP Node3

SMP Node4

Operating Sys

Operating Sys

Operating Sys

Operating Sys

CPU1

CPU1

CPU1

CPU1

CPU2

Memory

CPU2

Memory

CPU2

Memory

CPU2

Memory

Server Management

Abb. 6. Teradata Shared Nothing-Architektur

3.2 Workload Management Einer der Vorteile eines Active Data Warehouse ist, dass es den Front Line- (taktischen Entscheidungsträgern) sowie den Backoffice-Benutzern (strategischen Entscheidungsträgern) zu jeder Zeit eine dem Informationsbedarf angemessene integrierte Sicht auf die Unternehmensdaten ermöglicht. Bis anhin scheiterte dieser Ansatz aber meistens an den technischen Limitationen, unterschiedliche Abfragen gleichzeitig auf einem gemeinsamen System zeitgerecht zu verarbeiten. Die Lösung schien lange Zeit im Aufbau und Unterhalt von unterschiedlichen Plattformen für einzelne Verarbeitungsschritte 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, jedoch 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 unterschiedlichen Lastprofile („Workloads“) wiederkehrend zu analysieren, entsprechende Verhaltensmuster zu entdecken und darauf basierend Benutzerund / oder Abfragegruppen vorzuschlagen respektive zu definieren. Im Gegensatz 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) dynamisch 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 verwendet. 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 Datenverarbeitungsprozesse sollte stets darauf geachtet werden, dass Komplexität, Abhängigkeiten und manuelle Manipulationen und Interventionen auf ein Minimum reduziert werden.

Active Enterprise Intelligence

13

Dual BYNET Interconnects

Falls dieser Knoten ausfällt,…

X

SMP Node1 AMP

AMP

AMP

…migrieren die AMPs auf die verbleibenden Knoten… SMP Node2 AMP

AMP

AMP

AMP

SMP Node 3 AMP

AMP

AMP

AMP

SMP Node4 AMP

AMP

AMP

AMP

…und die migrierten AMPs könnenw eiterhin über alternative Pfade auf ihre VDISKs zugreifen. Ausfall eines Knotens führt zu 25% Verlust an Systemleistung

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 Mechanismen für den Betrieb bei Ausfall von einzelnen Systemkomponenten integriert sind (vgl. Abb. 7). Dies betrifft Hardwarekomponenten im gleichen 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 reibungslosen 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 Datenvolumens 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 Workload 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 Datenbanksystem. Diese Faktoren multiplizieren die einzelnen Effekte. Eine Verdopplung sowohl der Daten als auch der Anwender kann leicht zu einer Vervierfachung 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-Architektur verknüpft. Damit die Anforderungen der Benutzer an ein Active Data Warehouse in Form von Service Level Agreements verfasst werden können, darf die Parallelisierung der Systemumgebung aus technologischen Gründen nicht mit Bedingungen bzw. Restriktionen verknüpft werden. Um auch große Systemumgebungen und deren Erweiterungen mit hoher Komplexität stets kalkulierbar und damit entscheidungsfähig zu halten, wird eine lineare Skalierbarkeit mit einer Steigung von 1 benötigt. Dies bedeutet, dass das Hinzufügen einer Systemkomponente immer denselben 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 Geschä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 Arbeitsoberflä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 Prozesskosten und das Betriebsrisiko, andererseits wird die Zeit zur Umsetzung neuer Anforderungen stark verkürzt.

Active Enterprise Intelligence

15

3.6 Investitionsschutz Ein langfristiger Investitionsschutz für eine ADW-Umgebung ist von mehreren Faktoren abhängig. Die Anforderungen an die beschriebene Skalierbarkeit werden über mehrere Jahre von den in SLAs zugesicherten Antwortzeiten definiert. Technologisch betrachtet erfordert dies die Koexistenz verschiedener Hardware-Generationen in einer Systemumgebung. Die Kompatibilität von Hardware-Generationen sollte sich an der Langfristigkeit 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 Anwendung einer Active Enterprise Intelligence-Strategie, so wird der Einsatz einer Active Data Warehouse-Technologie unabdingbar. Eine sehr weitgehende Vision rückt mittels einem mehrjährigem strategischen Umsetzungsprogramm in den Mittelpunkt. Ein Active Data Warehouse bedeutet keinerlei technologische Restriktionen bezüglich Datenvolumen oder Komplexität der Workloads. Das bedeutet jedoch auch stark gestiegene Anforderungen an die Integration der Daten aus den diversen Vorsystemen in die zentrale Analysedatenbank. Bewerten wir die Qualität der integrierten Unternehmensdaten, so müssen Kriterien wie Aktualität, Genauigkeit, 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 geladen 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 Benutzerebene jederzeit garantieren und flexibel auf wechselnde Ereignisse reagieren 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 Systemen. Diese können entweder für jede neue Anwendung neu zusammengestellt werden, was einen wiederkehrenden Aufwand mit den dazugehörigen Kosten mit sich bringt, oder aber einmalig zentral integriert und dann den entsprechenden Anwendungen und / oder Prozessen zeitnah zur Verfü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 Integration 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 solchen Nachweis nur schwer erbringen, da die einzelnen Datenflüsse stark variieren und kein einheitliches Verständnis bezüglich der Definition einzelner Werte existiert. Um solchen Anforderungen gerecht zu werden, wird heute schon, und in der Zukunft verstärkt, ein zentrales Metadatenmanagement mit dokumentierten Definitionen bezüglich einzelner Werte, ihrer Distributionswege und Besitzer verwendet (Loftis 2007).

Active Enterprise Intelligence

17

4.1 Datenmodellierung Um eine unternehmensweite, konsistente Entscheidungsfindung zu ermöglichen, müssen die Daten zentral und in einer einheitlichen Struktur gehalten werden. Diese Struktur wird durch ein übergreifendes Datenmodell 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 zukünftigen Funktionsbereiche eines Unternehmens ist eine wichtige Voraussetzung 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, Angestellter, Schuldner, Demographie

Internal Organizations

Niederlassungen, Regionen, Abteilungen, Teams

Events

Ein- und Auszahlung, verspätete Gebühr, Kontostandsabfrage, Adresswechsel, Web-Interaktion, Wertschriftenhandel

Agreements

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

Customer Assets

Kundenvermögen in Form von Immobilien, Finanzinstrumenten, 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 Fragestellung, 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 Referenzmodell entwickelt. Ausschlaggebend ist hier die Verwendung eines Referenzmodells, auch wenn die heutige Nutzung nur Teilbereiche verwendet. 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 Genauigkeit 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 einzelner Systeme möglichst tief zu halten, haben einige Unternehmen deshalb 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 Rechenlast 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

Active Enterprise Intelligence

19

Unterhaltsaufwand sowie erschwerte Nachweisbarkeit bezüglich der Entstehung einzelner Werte. Zukünftige Systeme müssen daher in der Lage sein, granulare Daten effizient zu bewirtschaften und diese den einzelnen Benutzern in jeweils geeigneter Form zur Verfügung zu stellen. 4.2 Metadaten Den Kern eines proaktiven Ansatzes für das Management von Unternehmensdaten bildet das Data Dictionary. Das Data Dictionary stellt einen zentralen Punkt dar, an dem unterschiedliche Abteilungen sowie Fachbenutzer und technische Teams ein gemeinsames Verständnis von Daten festlegen. Damit wird für den Gebrauch und die Anwendung von Datenbeständen Konsistenz geschaffen. Insbesondere die Beschreibung von Datenquellen 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 vergangenheitsorientierte Diskussionen über im Unternehmen präsentierte Informationen 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 ihrem Wettbewerb auf Veränderungen im Markt zu reagieren. Der rechtzeitige Zugriff auf relevante aktionsfähige Daten, um eine schnelle, präzise und unternehmensweite Entscheidungsfindung zu ermöglichen, ist ein Alleinstellungsmerkmal im verschärften Wettbewerb. Um den Wertbeitrag der Datenaktualität zu beurteilen, ist es erforderlich zu verstehen, in welcher Weise Daten Entscheidungsprozesse unterstützen bzw. diese überhaupt 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 Datenaktualität ausreichend. Viel wichtiger als die Aktualität ist hier der Grad der Datenintegration (über Funktionsbereiche) bei gleichzeitiger Aggregation 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 Datenaktualität wie folgt gliedern: Kurzfristige Entscheidungsprozesse mit x x x x

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. x Tagesaktuelle Daten sollten nur dann gefordert werden, wenn eine Entscheidung am folgenden Tag erfolgt. x 4-stündlich aktuelle Daten ermöglichen eine Entscheidung noch am selben Tag. x ¼-stündliche Aktualität ist dann sinnvoll, wenn der Entscheidungsprozess unmittelbar eingeleitet wird und in den nächsten Minuten beendet ist. Um den Wertbeitrag einer ADW-Infrastruktur zu berechnen, die vierbzw. ¼-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 Unternehmensdaten 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 Infrastruktur sollte generell für die Intervalle eines ADW geeignet sein. Gleichzeitig muss betrachtet werden, dass die in operativen Basissystemen anfallenden Prozessdaten den Datenintegrationsprozessen untertags bereitgestellt und damit weiterverarbeitet werden können. Hier gilt es ebenso eine untertägige Verarbeitung zu ermöglichen.

Active Enterprise Intelligence

21

4.4 Qualität Zunehmend sehen Unternehmen integrierte Daten als einen Wettbewerbsvorteil an, der die Zusammenarbeit mit den Kunden und Veränderungsprozesse allgemein verbessern lässt. Soll die Qualität integrierter Unternehmensdaten 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? Gelingt es, die Datenqualität zu verbessern, so bleibt ungewiss, ob die Verbesserung schnell und effektiv genug erfolgt. Die Nachfrage nach Informationsmanagement steigt besonders mit der Zunahme der Benutzerzahl und des Datenvolumens sprunghaft an. Veränderungsprozesse müssen Jahr für Jahr schneller durchgeführt werden. Der erhöhte Veränderungsdruck 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ätsproblem. Das gesamte System ist durch die großen Datenmengen und die Vielzahl an Verarbeitungsprozessen sehr träge. Jeder Fehler in einem Teilprozess (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 einer integrierten Datenmodellierung implizit einen großen Beitrag zur Verbesserung der Datenqualität. Die Aufteilung der Unternehmensdaten in ein ODS und eine Vielzahl von Data Marts meist über unterschiedliche Infrastrukturen hinweg birgt das größte Qualitätsrisiko. Weiterhin eliminiert ein unternehmensweites, einheitliches logisches Datenmodell über alle Unternehmens- und Funktionsbereiche eine Vielzahl von weiteren Fehlerquellen 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 einzelner 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 externe 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 entwickelt werden, unterscheiden sich dann in den Datenstrukturen und Rechenalgorithmen. Dieser Umstand wird sehr häufig ignoriert. Planung bezeichnet den organisatorischen Prozess, um über die Erstellung 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önnen. 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 Unternehmenssteuerung. In den Unternehmen findet neben einer strategischen Planung eine jährliche 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-Berichtswesens 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 aktiv ist. Bei einer Budgetierung werden hingegen die Strukturvorgaben der

Active Enterprise Intelligence

23

operstiven Systeme, die erfolgte Transaktionen des Geschäftsbetriebs dokumentieren, genutzt. Es wird deutlich, dass hier ganz unterschiedliche Herangehensweisen gewählt werden, die erheblichen Einfluss auf die Architektur der unterstützenden Systeme haben. Pervasive Business Intelligence erfordert die Integration beider genannter Herangehensweisen in einem ganzheitlichen Modell. Erst dann werden alle Mitarbeiter eines Unternehmens von der strategischen Unternehmensplanung über das Jahresbudget einer Geschäftseinheit 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 eines Active Data Warehouse unabdingbar. 5.1 Zugriff Der Zugriff auf Daten eines ADW geschieht wann immer ein Benutzer oder eine operative Applikation über verschiedene Lieferungsmechanismen Daten beziehen. Meistens sind dies schnelle, taktische Abfragen basierend auf historischen und / oder aktuellen Daten. Die daraus resultierenden Antworten müssen typischerweise innerhalb von wenigen Sekunden dem jeweils zu unterstützenden Geschäftsprozess, dem Benutzer oder System 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önnen, ohne gleichzeitig die zugesagte Verfügbarkeit für strategische Abfragen zu gefährden, wird ein Active Data Warehouse benötigt. Während die Integration zu den umliegenden Systemen mittels standardisierter Konnektoren in einer nachricht- oder in der Zukunft vermehrt serviceorientierten 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 situationsbezogen bei deren Eintritt. Ein solches Ereignis kann eine einfache Buchung 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 entdeckt, und basierend auf ihrer Dringlichkeit bearbeitet werden. Insbesondere komplexe Ereignisse können selten direkt von der operativen Applikation 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 Informationen für Entscheidungen herangezogen werden, die signifikanten Einfluss auf Umsatz und Profitabilität haben. Beispiele hierfür sind Eventbasiertes 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 viele 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 Zukunft zu einer unternehmensweiten Synchronisation bzw. Zusammenfüh-

Active Enterprise Intelligence

25

rung der EEM-Aktivitäten führen. Zunehmend werden Synergien zwischen verschiedenen fachlichen Bereichen gesucht und berücksichtigt sowie die Prozesse für die Definition von Ereignissen und die Operationalisierung 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 RisikoProfil 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 Bereichen zusammengeführt und strukturiert in einem ADW abgelegt sind. Das Nutzenpotenzial von EEM auf Basis eines ADW sind: x x x x x x

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:

x Kostentransparenz und -controlling durch automatisiertes operatives Credit und Financial Risks Management (z. B. proaktives Erkennung und Initiierung von Folgeaktivitäten), x Optimierung der Kundenbeziehungen durch ein integriertes Communications Framework (z. B. ereignisbasierte, zeitnahe und personalisierte Kundendialoge), x 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 information on each individual customer, react to the information, and find opportunities 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 reduce 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 environment 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 conversion. 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 information every hour or every other hour; finance pulls some data on a daily basis. 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, Overstock.com

Active Enterprise Intelligence

27

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, Teradata 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 Magazine 7 (2007) 3.

2

Business Engineering – Betriebswirtschaftliche Konstruktionslehre und ihre Anwendung in der Informationslogistik

Robert Winter Universität St. Gallen

1 2 3 4 5 6

Change the Business vs. Run the Business....................................... 29 Aufgabenstrukturierung der Veränderung ........................................ 31 Ziele und Ergebnisse der Veränderung ............................................ 34 Gegenstand der Veränderung ........................................................... 36 Grundlegende Veränderungsprozess-Szenarien ............................... 38 Business Engineering für Betriebsprozesse ...................................... 41 Literatur ............................................................................................ 41

1

Change the Business vs. Run the Business

Das Unternehmensmodell des neuen St. Galler Managementmodells versteht Organisationen als komplexe soziale Systeme, die unter den verschiedensten Blickwinkeln verstanden und gestaltet werden müssen. Einige dieser Blickwinkel sind einfach verständlich. So ist z. B. naheliegend, dass Anspruchsgruppen wie Kapitalgeber, Kunden, Mitarbeitende, Öffentlichkeit, Staat, Lieferanten und Mitbewerber sich jeweils für spezifische Aspekte von „Unternehmen“ interessieren (z. B. Ertrag, Risiko, gesellschaftlicher Nutzen, ökologische Nachhaltigkeit). Auch die Sicht auf die „Unternehmung“ als System vernetzter Management-, Geschäfts- und Unterstützungsprozesse ist naheliegend. Hinsichtlich anderer Blickwinkel wie z. B. der Interaktionsthemen „Ressourcen“, „Normen / Werte“ und „Anliegen / 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 interessant, nämlich der so genannte Entwicklungsmodus. Als grundlegende Entwicklungsmodi 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 grundsätzlich anders gestalten, je nachdem, ob bestehende Strukturen und Prozesse optimiert werden oder ob die grundlegende Erneuerung von Strukturen und Prozessen im Mittelpunkt der Betrachtung steht. Die Unterscheidung von Optimierung und Erneuerung findet sich in der Wirtschaftspraxis auch im Begriffspaar „Run the Business“ vs. „Change the Business“. Während die meisten Methoden der betriebswirtschaftlichen Funktionallehren (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 „betriebswirtschaftliche 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 Kommunikationstechnologie: Kapazität und Leistungsfähigkeit in der Chip- und Speichertechnologie 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 Automatisierung, 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 Organisation 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 Compliance-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 Informationszeitalter ist kundenseitig durch Wertschöpfungsnetzwerke geprägt, die Kundenprozesse ganzheitlich unterstützen (Kagermann u. Österle 2006). Andererseits ist es produktionsseitig auf industrielle Strukturen angewiesen, die Effizienz durch Arbeitsteilung und Standardisierung erreichen.

Business Engineering

31

Vernetzungsfähigkeit ist aber nicht allein durch Daten-Schnittstellen, interorganisationale Prozesse, eine Netzwerkstrategie und Kooperationsbereitschaft der Mitarbeitenden realisierbar. Erst ein ganzheitliches Vernetzungskonzept ist erfolgversprechend, in dem Strategie, Prozesse und Informationssysteme 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. allein Technologie-orientiertes) Vorgehen. Um komplexe Zusammenhänge systematisch abzubilden, die verschiedensten Perspektiven miteinander zu verknüpfen, mit den unterschiedlichen Anspruchsgruppen zu kommunizieren, arbeitsteilig vorzugehen und genügend Planungs- / Steuerungssicherheit zu erreichen, bedarf es eines systematischen und gleichwohl ganzheitlichen 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 Konstruktionslehre für Veränderungsvorhaben. Dazu werden Modell- und Methodenkomponenten 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 Informationsflüsse und -nutzung (Martin 1989) begonnen hat. Allerdings ist der Gegenstand 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 Unternehmensmodells macht deutlich, dass die Gestaltung aller wichtigen Aspekte einer Unternehmung oder selbst einer einzelnen Geschäftseinheit nicht simultan erfolgen kann. Deshalb ist es wichtig, eine sinnvolle Strukturierung 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 x die Umgestaltung oder der radikale Neuentwurf von Kern-, Unterstützungs- und / oder Führungsprozessen, x die Überführung monolithischer Geschäftsmodelle in vernetzte Geschäftsmodelle, x die Umstellung von hierarchischer auf marktliche Koordination (Verselbständigung von Funktionalbereichen), x die Aus- oder Einlagerung von Teilprozessen oder Aufgaben zwischen Unternehmen oder Verwaltungen (Out- / Insourcing), x die Integration oder Aufspaltung von Organisationen, x der systematische Aufbau und die systematische Nutzung von Informationen (z. B. integriertes Kundenwissen), x die Herstellung von Orts-, Zeit- und Kanalunabhängigkeit von Produkten / Leistungen, x die Nutzung elektronischer Vertriebs- und Zugangskanäle für Produkte / Leistungen, x die Nutzung elektronischer Marktplätze für Beschaffung, Handel und Vertrieb, x die Digitalisierung und Integration von Medien oder x die Standardisierung / Konsolidierung von IT-Infrastrukturen oder Softwarekomponenten. Die hohe Zahl gescheiterter Veränderungsprojekte hat zu vielen Untersuchungen geführt, die immer wieder mangelnde Veränderungswilligkeit und / oder mangelnde Veränderungsfähigkeit bei Betroffenen und Beteiligten 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 Unternehmenskultur, der Unternehmensführung, den Machtverhältnissen und Ansprüchen, der Motivation und dem Verhalten der Betroffenen bzw. Beteiligten zusammenhängen. In Anlehnung an die Ordnungsmomente des St. Galler Managementmodells lassen sich in erster Näherung die verschiedenen Aufgaben in der Veränderung den folgenden Betrachtungsebenen zuordnen: x Strategieebene: Hier werden für die betrachtete Einheit (Unternehmen oder Geschäftseinheit) die Positionierung im Wettbewerb und hinsicht-

Business Engineering

33

lich Kompetenzen, die daraus folgende Positionierung in Wertschöpfungsnetzwerken, das Produkt- / Leistungsprogramm und das Zielsystem betrachtet. Diese Gestaltungsfragen lassen sich auch als WAS-Fragen bezeichnen. x 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 betrachtet. Diese Gestaltungsfragen lassen sich auch als WIE-Fragen bezeichnen, da sie die Umsetzung der strategischen Festlegungen behandeln. x Systemebene: Hier werden für die betrachtete Einheit Applikationen, Softwarekomponenten, Datenstrukturen sowie Hardware- und Vernetzungskomponenten betrachtet. Diese Gestaltungsfragen lassen sich auch als WOMIT-Fragen bezeichnen, da sie die Unterstützung der Organisation durch Anwendungssysteme behandeln. Zur weiteren Differenzierung von Modellen und Methoden kann die Systemebene in Unterebenen zerlegt werden, z. B. für IT-Infrastruktur, Software / Daten und Integration. x Politisch-kulturelle Ebene: Hier werden für die betrachtete Einheit Organisationskultur, Führung, Macht, Motivation und Verhalten betrachtet. Diese Gestaltungsfragen lassen sich auch als WARUM-Fragen bezeichnen, weil es hier um die Ursachen und Hintergründe für die Unterstützung oder Verhinderung von Veränderungen geht. „Change the Business“ wird im Business Engineering als Prozess verstanden, durch den, ausgelöst und ermöglicht durch bestimmte „Enabler“, Veränderungen auf allen genannten Ebenen konsistent geplant und umgesetzt 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 verdeutlichen, umfasst in Abb. 1 der als „Transformation“ bezeichnete Planungsund Umsetzungs-Prozessteil alle Betrachtungsebenen.

34

Robert Winter

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

Strategie (Vernetzung, Ziele, Positionierung)

Transformation Organisation (Prozesse, Strukturen, Information)

Führung Verhalten Macht

System (Integration, Software, IT-Infrastruktur)

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änderungen 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 spezifizierten 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änderungsvorhaben dienen dazu, die Wirtschaftlichkeit zu erhöhen oder andere Ziele bestimmter Anspruchsgruppen besser zu erfüllen.

Business Engineering

35

Um Sachziele wie geringere Kosten, höhere Erträge, höhere Geschwindigkeit, bessere Qualität und / oder höhere Flexibilität zu erreichen, verfolgen Veränderungsvorhaben verschiedene Formalziele: x Werden Strategien, Organisationen und / oder Systeme flexibler gestaltet, lassen sie sich schneller, besser oder mit geringeren Kosten an bekannte, antizipierbare Veränderungen anpassen. Werden Strategien, Organisationen und / oder Systeme agiler gestaltet, darf erwartet werden, dass sie sich schneller, besser oder mit geringeren Kosten an unbekannte, zukünftige Veränderungen anpassen lassen. x Durch Vereinfachung lassen sich bestimmte Ergebnisse mit geringerem Aufwand erzielen. Durch Optimierung lassen sich mit bestimmten Aufwänden bessere Ergebnisse erzielen. x Sind Strategien, Organisationen, Systeme und / oder Führung, Verhalten, 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. x Grundlage für die systematische Veränderung von Strategien, Organisationen, Systemen und / oder politisch-kultureller Faktoren ist Transparenz. Nur Strukturen und Prozesse, die transparent sind, können analysiert, 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. Konsistente Strukturen und Prozesse sind eine wichtige Grundlage für systematische Vereinfachung bzw. Optimierung. Einfache bzw. optimierte Strukturen und Prozesse sind eine wichtige Grundlage für die systematische Herstellung bzw. Aufrechterhaltung von Flexibilität bzw. Agilität. Daneben gibt es verschiedene Unter-Formalziele, welche die Erreichung der Ober-Formalziele Transparenz, Konsistenz, Vereinfachung / Optimierung 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 liefert auch Hinweise für deren (generische) Ergebnisse: Die Vision des Business Engineering sind generell offene, lose gekoppelte, aus wiederverwendbaren Komponenten bestehende Strukturen und Prozesse. Die „Geschä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 Aufgabenstrukturierung von rein betriebswirtschaftlich orientierten Aufgaben (Strategiebildung, Organisationsgestaltung) bis zu stark IT-bezogenen Aufgaben (Software- und IT-Infrastrukturgestaltung) reicht, müssen die Gestaltungsobjekte 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, Organisationsebene, Systemebene, politisch-kulturelle Ebene, siehe Abschn. 2) werden Gestaltungsobjekte auf Strategie-, Organisations- und Systemebene 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 jeweils 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 jeweiligen Kontext entsprechen. Auf diese Szenarien wird in Abschn. 5 näher eingegangen. Im Normalfall unterscheidet sich der Lebenszyklus der Gestaltungsobjekte auf Strategie- und Organisationsebene vom Lebenszyklus der Gestaltungsobjekte 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 grundsätzliche Architektur der Systemebene und bestimmte Software- und Infrastrukturkomponenten 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 unterschiedlicher Frequenzen wird durch Abb. 2 illustriert.

Business Engineering

Strategieebene

Organisationsebene

37

1-2 Jahre

3-6 Monate

Softwareebene Infrastrukturebene

6-10 Jahre

Abb. 2. Unterschiedliche Lebenszyklen auf Strategie-, Organisations- und Systemebene

Da es aufgrund der unterschiedlichen Lebenszyklen der Gestaltungsobjekte auf den fachlichen Ebenen einerseits und der Systemebene andererseits nicht möglich ist, die Konsistenz des Gesamtsystems durch vollständige Propagation aller Änderungen aufrecht zu erhalten, ist ein Entkopplungsmechanismus notwendig. In Analogie zur Dreiebenenarchitektur von Datenbanken wird dazu eine spezielle Architekturebene, die „Integrationsebene“ vorgeschlagen. Ähnlich der konzeptionellen Ebene in der Datenbankarchitektur, die die („interne“) Ebene der Datenspeicherung von der („externen“) Ebene der Datennutzung entkoppelt, entkoppelt die Integrationsebene die sich schnell ändernden fachlichen Ebenen von den deutlich stabileren Systemebenen. Als Konsequenz sind die Gestaltungsobjekte der Integrationsebene weder allein fachlicher Natur noch allein IT-bezogen. Sie repräsentieren logische 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 verschiedenen Architekturebenen werden in Abb. 3 aufgezählt. Ein Modell repräsentiert dabei einen Zusammenhang zwischen verschiedenen Gestaltungsobjekten. So werden z. B. Zusammenhänge zwischen Geschäftseinheiten,

38

Robert Winter Gestaltung der Strategie • • • •

Strategieebene

Geschäftsnetzwerkmodelle Kundenprozessmodelle Leistungsmodelle Zielsystem

Gestaltung der Organisation

Organisationsebene

• • • •

Prozesslandkarte Prozessmodelle Aufbauorganisation Informationslandkarte

Gestaltung der Integration

Integrationsebene Softwareebene

• • •

Gestaltung von Software • •

Infrastrukturebene

Applikationslandschaft Fachliche Services Geschäftsfunktions-/ Informationsobjektemodelle

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, Zusammenhänge zwischen Organisationseinheiten, Rollen und Stellen im Aufbauorganisations-Modell oder Zusammenhänge zwischen Datenstrukturen im Datenmodell abgebildet. „Gestaltung“ in Abb. 3 umfasst nicht nur den Erstentwurf, sondern auch die Weiterentwicklung der entsprechenden Modelle.

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:

Business Engineering

39

1. Fachlich getriebene Veränderungen durchlaufen die Gestaltungsebenen 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 entsprechenden Anpassungen der Applikationen und möglicherweise sogar der Infrastruktur. Begleitet werden solche Veränderungsvorhaben auf allen Ebenen durch geeignete Maßnahmen im Bereich „Führung, Verhalten, Macht“. 2. Innovationen der Informations- und Kommunikationstechnik ermöglichen 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 Abrechnungsapplikationen möglich. Elektronische Marktplätze bzw. Einkaufs- / Verkaufsplattformen sind Beispiele für Geschäftsinnovationen 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 Integrationsebene so umgestaltet werden muss, dass veränderte Prozesse (oder Organisationsstrukturen) mit bestehenden (oder nur leicht angepassten) IT-Lösungen arbeiten können oder dass Veränderungen auf IT-Ebene (z. B. Ersatz von Standardsoftware) durch Umgestaltung der Integrationsebene nur begrenzte Anpassungen der Organisation erfordern. 3b. Eine Variante des Alignment-Szenarios ergibt sich aus der Notwendigkeit, Strukturen auf allen Beschreibungsebenen nicht nur „vertikal“, 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, Fachbereiche 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 Services (auf Integrationsebene) möglich, Prozesse (auf Organisationsebene) 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 illustriert. Strategieebene

Organisationsebene

Integrationsebene Softwareebene

Fachlich getriebene Projekte (Top-down) Technisch getriebene Projekte (Bottom-up) AlignmentProjekte Vereinfachungs-/FlexibilisierungsProjekte (SOA)

Infrastrukturebene

Abb. 4. Veränderungsprozess-Szenarien

Je feiner die Differenzierung von Veränderungsprojekt-Szenarien erfolgt, 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 zwischen (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.

Business Engineering

6

41

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 projektartigen 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änken, sondern sollten auch die Gestaltung des Dauerbetriebs unterstützen. Die Mehrzahl der bisher publizierten Business Engineering-Methoden fokussiert allerdings auf die Gestaltung von Veränderungen. Mit dem Verständnis der Informationslogistik als langfristig angelegte, auf die Realisierung 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: Georgakopoulos 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 Managementlehre, 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 Medieninformationen, Frankfurt am Main 2006. Martin, J.: Information Engineering. Vol. 1: Introduction, Prentice-Hall, Englewood 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.): Business Engineering - Auf dem Weg zum Unternehmen des Informationszeitalters, 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. 33106. Winter, R.: Architektur braucht Management, in: Wirtschaftsinformatik 46 (2004) 4, S. 317-319. Winter, R.: Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage 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 Universität St. Gallen

1 2 3 4

Einleitung ......................................................................................... 43 Das St. Galler Konzept der Informationslogistik ............................. 44 Spezifika und Herausforderungen der Informationslogistik............. 51 Zusammenfassung und Ausblick ...................................................... 56 Literatur ............................................................................................ 56

1

Einleitung

Viele Untersuchungen belegen den unverändert hohen Stellenwert von Business Intelligence und Data Warehousing im Unternehmen (z. B. Sommer 2007). Mittlerweile sind analytische Informationssysteme zum unverzichtbaren Bestandteil der Applikationslandschaft eines Unternehmens geworden und nehmen einen erheblichen Teil des IT-Budgets in Anspruch. Allerdings stellt sich heutzutage den Unternehmen nicht mehr primär das Problem des initialen Aufbaus analytischer Systeme; Vielmehr stehen Fragestellungen 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 Umfeld 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 Schwerpunktsetzung zu verdeutlichen (Business Intelligence und Data Warehousing sind historisch IT-Konzepte), wird im Folgenden der Begriff der Informationslogistik eingeführt. Er wird in Abschn. 2 definiert und gegenüber verwandten Begriffen abgegrenzt. In Abschn. 3 werden die Charakteristika 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, Durchführung und Kontrolle der Gesamtheit der Datenflüsse verstanden, die über eine Betrachtungseinheit hinausgehen, sowie die Speicherung und Aufbereitung dieser Daten. Dabei werden nur solche Datenflüsse zur Informationslogistik gezä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 handelnde 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 Informationslogistik 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 Aufbereitung dieser bereichsübergreifenden Daten, soweit sie zur Unterstützung 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 Outsourcing von Geschäftsprozessen oder Teilprozessen erforderlich werden (Picot 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 Betrachtungseinheit ihre Quelle und ihren Endpunkt haben, sind daher auf dieser Betrachtungsebene nicht Teil der Informationslogistik. Bei Wahl einer anderen Betrachtungsebene können solche Datenflüsse aber durchaus Teil der Informationslogistik sein: So sind bei Betrachtung von Unternehmensbereichen die Datenflüsse innerhalb eines Unternehmensbereichs nicht Teil der Informationslogistik – bei Betrachtung der Abteilungen innerhalb dieses Unternehmensbereiches sind abteilungsübergreifende, jedoch bereichsinterne 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 Betrachtungseinheit-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 hellgrau eingefärbten Datenflüsse usw. Analytische Nutzung heißt, dass Informationen zur Unterstützung von Entscheidungen genutzt werden. Eine Entscheidung ist dabei die (im Kontext 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 wiederum ergeben sich aus Daten, wenn sie von „einer Person in einem bestimmten 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 tatsächlichen Nutzung feststeht (Klesse 2007, S. 20). Die Informationslogistik hat dabei das Ziel, Informationen zur Unterstützung sämtlicher Arten von Entscheidungen im Unternehmen zur Verfügung zu stellen. Einerseits werden Entscheidungen auf den verschiedenen Hierarchieebenen des Unternehmens (strategische Entscheidungsfindung, Managementkontrolle und operative Kontrolle), andererseits auch

46

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

Stelle A

Stelle B Abteilung A

Abteilung B

Unternehmensbereich A Unternehmen A

Unternehmensbereich B Unternehmen B

Informationslogistikrelevante Datenflüsse

Abb. 1. Informationslogistik auf verschiedenen Ebenen der Organisation

Entscheidungen von unterschiedlichem Strukturiertheitsgrad (unstrukturiert, 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 Prozesstypen beschränkt. Vielmehr kann die Informationslogistik dispositive und operative Prozesse beliefern. Eine dispositive Nutzung der Informationslogistik 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 Absatzinformationen zur Unterstützung der Preisfindung in Absatzprozessen. Informationslogistik befasst sich also mit allen Arten der Informationsbereitstellung mit Entscheidungsbezug. Rein operativen Zwecken dienende Datenflüsse zur Prozessabwicklung ohne Entscheidungskonsequenz, wie z. B. der Fluss von Bestelldaten aus der Auftragserfassung an die Kommissionierung, gehören nicht zur Informationslogistik, auch wenn sie Organisationseinheiten übergreifen. Ebenso wenig zählen die Systeme zur Realisierung solcher Datenflüsse, wie z. B. Integrationsinfrastruktur mit rein operativem Zweck, zur Informationslogistik.

Das St. Galler Konzept der Informationslogistik

47

2.3 Aufgaben und Ziel der Informationslogistik Die Hauptfunktionen der Informationslogistik ergeben sich aus der Definition des Logistikbegriffs. Analog zur Definition der Logistik als Planung, Steuerung, Durchführung und Kontrolle von Material- und Datenflü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 Informationslogistik die Planung, Steuerung, Durchführung und Kontrolle von Datenflüssen. Hierzu werden Ziele und Leistungen sowie Organisationsstrukturen und Prozesse definiert (Vgl. Kap. 2). Für die Implementierung der Datenflüsse sind die Speicherung und Aufbereitung von Daten erforderlich. Diese werden mit Hilfe von entsprechenden Informationssystemen (z. B. Data Warehouses) realisiert. Ziel der Informationslogistik ist damit, dass relevante Informationen in geeigneter Qualität zur Befriedigung der Informationsbedarfe in einer Betrachtungseinheit bereitgestellt werden, auch wenn die dafür benötigten Daten in einer anderen Betrachtungseinheit entstehen. Damit trägt die Informationslogistik wesentlich zur Realisierung von Synergien bei. 2.4 Abgrenzung 2.4.1

Data Warehousing

Ausgehend von William Inmons ursprünglicher Definition des Data Warehouse (DWH) als „a subject-oriented, integrated, non-volatile, and timevariant 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 Informationslogistik angenähert. Unter Data Warehousing wird die Gesamtheit von Prozessen und Systemen zum Betrieb und Nutzung eines DWH-Informationssystems 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 Warehouse erweitert von einer reinen Managementunterstützung (wie bei Inmon) 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-Informationssystem, (wie z. B. bei Chamoni u. Gluchowski 2006; Kemper et al. 2006) hinaus weitere relevante Dimensionen des Data Warehousing, wie

48

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

z. B. Organisation oder Strategie, betrachtet, wie dies im Sinne des Business Engineering erforderlich wäre (vgl. Kap. 2). Weiterhin steht beim Data Warehousing meist die integrierte Speicherung in einer zentralen Datenbank im Vordergrund, wie sie sich in zahlreichen 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, Steuerung und Kontrolle von Datenflüssen abzielt. Damit lassen sich drei zentrale Unterschiede zwischen Data Warehousing und Informationslogistik erkennen: x Einerseits hat die Informationslogistik im Gegensatz zum Data Warehousing einen umfassenderen Fokus, der nicht nur das Informationssystem in den Vordergrund stellt, sondern die Gesamtheit von Strategie, Organisation und Informationssystem betrachtet. x Zweitens fokussiert das Data Warehousing auf die Schaffung einer integrierten Datenbasis, während die Informationslogistik auf die Realisierung von Informationsflüssen zur Befriedigung von Informationsbedarfen abzielt. x Zum dritten ist der Fokus des Data Warehousing in der Regel unternehmensintern, während die Informationslogistik auch unternehmensübergreifende 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 - today these tools collectively fall into a category called ‘Business Intelligence.‘“(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, erweiterte Auffassungen, die unter BI die Gesamtheit der analytischen Systeme und der speisenden Datenbanken bzw. Data Warehouses verstehen (Gluchowski 2001, S. 6; Negash 2004, S. 178). Andererseits finden sich auch ganzheitliche Ansätze, die BI als Gesamtheit von Systemen und Prozessen

Das St. Galler Konzept der Informationslogistik

49

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 somit leicht von der Informationslogistik abgrenzen – die Informationslogistik hat einen wesentlich umfassenderen und ganzheitlicheren Fokus. Je weiter das Verständnis von BI jedoch gefasst wird, desto mehr verschwimmt die Grenze zur Informationslogistik. Hauptsächliches Abgrenzungskriterium der Informationslogistik ist wieder der Schwerpunkt auf Datenflüssen. Zudem umfasst keine der Definitionen von BI auch unternehmensübergreifende Datenflüsse – BI ist nicht unternehmensübergreifend, wenngleich auch unternehmensexterne Datenquellen genutzt werden können. 2.4.3

Management Support Systems

Der Begriff Management Support Systems (deutsch Führungsunterstützungssysteme 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 moderner 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 basieren, 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 verwendet. DSS sind Systeme, die basierend auf Datenanalysemodellen und Datenbanken das mittlere Management interaktiv beim Treffen von semistrukturierten, 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-

50

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

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 Kommunikationsfunktionen (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 Informationslogistik. Sie umfassen verschiedene Klassen analytischer Informationssysteme, die Teil der Informationslogistik sind. In der Literatur zu MSS zeigt sich deutlich der historische Kontext – einerseits ist die Integration von Daten aus verschiedenen Quellen, wie sie im DWH angestrebt wird, kaum Ziel von MSS, andererseits haben MSS einen begrenzten Fokus 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 Gruppenleistung 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 Organisationseinheiten 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ärkten 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 Schaffung von funktionsspezifischen Informationssystemen in der Frühzeit der elektronischen Datenverarbeitung führten dazu, dass Informationen im Unternehmen vielfach verteilt und fragmentiert gespeichert werden (Holten 1999, S. 29ff.). Das Ziel der Informationslogistik, die effektive und effiziente Befriedigung von Informationsbedarfen, ist daher oftmals nicht betrachtungseinheitsintern möglich, sondern nur unter Nutzung extern bezogener Informationen (Klesse u. von Maur 2003, S. 32f.). Die Quelle der In-

Das St. Galler Konzept der Informationslogistik

51

formationen kann dabei innerhalb oder außerhalb der Unternehmung gen. Wird die Existenz von Synergien unterstellt, ist zwar die Gesamtwertschöpfung höher als die Summe der Wertschöpfungen der einzelnen Betrachtungseinheiten. Dies heißt aber nicht, dass es aus Sicht jeder einzelnen Betrachtungseinheit „lokal“ sinnvoll ist, „ihre“ Daten in die Informationslogistik einzubringen. Synergievorteile und Beteiligungskosten sind unter den Betrachtungseinheiten möglicherweise ungleichmäßig verteilt. So kann es z. B. vorkommen, dass bestimmte Einheiten mit hohem Aufwand hohe (Stamm-)Datenqualität erzeugen, von denen andere Einheiten ohne eigenen Aufwand profitieren. Ein ganzheitliches Konzept zur Gestaltung 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 folgenden 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 Organisationseinheiten übergreifendes Konzept auch nahe legt, solche unterstü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 übergreifenden Charakter der Informationslogistik die verschiedensten Bereiche des Data Warehousing und verwandter Systeme betreffen und in der Regel nicht auf einzelne Domänen oder Projekte beschränkt sind. Die Infrastruktur ist unerlässlich für eine erfolgreiche Informationslogistik, in vielen Fällen ermöglicht sie erst eine sinnvolle Nutzung der in den analytischen Systemen gespeicherten Daten.

52

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

Infrastruktur stellt die notwendigen organisatorischen und technischen Voraussetzungen für Informationssysteme bereit. Sie ist nutzungsoffen, wiederverwendbar und wird in Form standardisierter, zuverlässiger Dienste bereitgestellt, die aufeinander aufbauen und von mehreren Infrastrukturanwendungen 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 Systembetrieb 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 Infrastruktur 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 Zusammenspiel der Infrastrukturkomponenten, sondern auch der Zugriff der fachlichen Applikationen auf die Infrastruktur geregelt werden. Die folgenden Ausführungen beziehen sich auf die Strategie- und Organisationsaspekte von Infrastruktur, nicht auf Infrastruktur im Sinne von Hardware und Software. In der Informationslogistik können folgende Themenbereiche identifiziert 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 Leistungsverrechnung) x Projekt- und Anforderungsmanagement x x x x x x

Alle genannten Themenbereiche sind nicht nur für die Informationslogistik relevant, sondern müssen auch im unternehmensweiten Informationsmanagement, und damit insbesondere auch in den operativen Systemen, adressiert werden. Folglich gilt es im Kontext der Informationslogistik zu entscheiden, ob unternehmensweite Standards und Lösungen aufge-

Das St. Galler Konzept der Informationslogistik

53

baut bzw. etwaige in den operativen Systemen bereits angewandte Konzepte genutzt werden sollen. Eine isolierte Betrachtungsweise und der separate 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 Systemen 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 vorliegenden Buch in eigenen Kapiteln adressiert. 3.1.2

Strategischer Charakter

Als „strategisch“ werden solche Entscheidungen bezeichnet, die gesamthafte Zusammenhänge betreffen und langfristigen Charakter haben (Anthony 1965). Entsprechend ihrer Definition ist Informationslogistik betrachtungseinheit-übergreifend, und die Nutzeffekte von Informationslogistik treten typischerweise eher langfristig ein. Deshalb hat Informationslogistik 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 Wirtschaftlichkeitsentscheidungen in Betracht ziehen, dass Informationslogistik-Investitionen 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 beschränkt sich bewusst nicht auf die ehemals datenzentrierte Sichtweise im Data Warehousing. Vielmehr adressiert dieses Verständnis auch Anwendungen, bei denen Techniken und Verfahren der Datenanalyse und der Informationsbereitstellung 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 Prozesse. Das Konzept der sogenannten prozessorientierten Business Intelligence wird in Kap. 6 näher vorgestellt.

54

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

3.2 Herausforderungen und Lösungsansätze Die Besonderheiten der Informationslogistik führen zu speziellen Herausforderungen bei der Umsetzung im Unternehmen. Dabei ist eine Diskrepanz zu beobachten: Auf der einen Seite genießen die Themen hohe Aufmerksamkeit und werden als sehr relevant eingestuft. Auf der anderen Seite ist die Praxis geprägt von isolierten, lokalen Lösungen und kurzfristig angelegten Initiativen. Folglich hat die Umsetzung von Infrastrukturmaßnahmen wie die meisten bereichs- oder themenübergreifenden Initiativen einige Herausforderungen zu meistern. 3.2.1

Risikofaktoren

Zu den Risikofaktoren gehören die Projektgröße und die Komplexität solcher Vorhaben. Je weiter das mögliche Einsatzgebiet von Infrastrukturthemen 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. Diese Hürden bilden einen Tradeoff zum Bestreben, zur Schaffung von Synergien 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 etwa die Zerlegung des Vorhabens in Teilprojekte und Module, die sequentiell umgesetzt werden können. Dabei sollte insbesondere auf mögliche 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 Einblick und Verständnis für die Komplexität hervorgerufen werden oder angesichts von Budget- oder Ressourcenrestriktionen nicht realisierbar sind. Trotz anzustrebender Komplexitätsreduzierung sollte nicht außer Acht gelassen werden, dass die einzelnen Infrastrukturthemen nicht völlig unabhängig voneinander anzusehen sind. So weisen zum Beispiel Metadaten-, Stammdaten- und Datenqualitätsmanagement zahlreiche Berührungspunkte und Schnittstellen auf, weshalb die jeweiligen Aktivitäten aufeinander 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-

Das St. Galler Konzept der Informationslogistik

55

zelnen Nutzergruppen. Auch ist der Nutzen der Infrastruktur nicht einfach zu quantifizieren – es ist offensichtlich, dass die Infrastruktur für die Anwendungen in der Informationslogistik Nutzen bringt, nicht jedoch, inwieweit sie zum geschaffenen Wert beiträgt. Oft fehlt das Bewusstsein im Unternehmen, dass die oben genannten Infrastrukturthemen wie andere Infrastrukturmaßnahmen im Unternehmen auch (etwa bei Investitionen in Hardware) behandelt werden sollten, wo trotz fehlenden oder unvollständigen Nachweises der Wirtschaftlichkeit entsprechende Investitionen getätigt werden. Dennoch sollten nach Möglichkeit den Nutzen untermauernde (wenn auch nicht notwendigerweise quantifizierbare) Anwendungsfä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 nachgewiesen wird. Eng mit dieser Problematik verbunden ist die Herausforderung, Infrastrukturprojekte mit Unterstützung des (oberen) Managements durchzuführen. Angesichts der vergleichsweise hohen Aufwände in der Umsetzung 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 Infrastruktur durchgeführt, die jedoch als halbfertige oder insuläre Lösungen nicht ihr volles Nutzenpotenzial realisieren können. Ein großer Risikofaktor für Infrastrukturprojekte liegt daher in der Partikularsicht der beteiligten Organisationseinheiten. Diese sind bestrebt, in erster Linie lokale Optima zu erreichen, d. h. ihre eigenen Ziele mit minimalem Aufwand umzusetzen. Dies führt beispielsweise zu Präferenzen für bestimmte Werkzeuge oder Anbieter sowie zur Nichtbeachtung existierender Infrastrukturlösungen in benachbarten Bereichen. Solchen Entwicklungen muss mit übergreifendem Ressourcenmanagement und mit klarer Kommunikation der Vorteile von übergreifender Informationslogistik-Infrastruktur entgegengewirkt werden. 3.2.4

Architektur-Alignment

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

56

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

tung der Informationslogistik dieselben Maßstäbe angelegt wie in der operativen 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 Informationslogistik, 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 Gesamtarchitektur umfasst nicht nur einzelne Projektschwerpunkte, sondern komplette Wertschöpfungsketten mit ihren Prozessen. Diese Betrachtung ermöglicht es, Redundanzen zu vermeiden und Synergiepotenziale zu erkennen.

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 Techniques - 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, Anwendung, 2. Aufl., dpunkt, Heidelberg 2004. Bichler, K.; Schröter, N.: Praxisorientierte Logistik, 3. Aufl., Kohlhammer, Stuttgart 2004.

Das St. Galler Konzept der Informationslogistik

57

Bleicher, K.: Organisation: Strategien, Strukturen, Kulturen, 2. Aufl., Gabler, Wiesbaden 1991. Bucher, T.; Dinter, B.: Process Orientation of Information Logistics - An Empirical 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 Foundations, 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 Einsatzbereiche, in: HMD - Praxis der Wirtschaftsinformatik 222 (2001), S. 5-15. Gluchowski, P.; Kemper, H.-G.: Quo Vadis Business Intelligence?, in: BISpektrum 1 (2006) 1, S. 12-19. Gorry, A.; Scott Morton, M.: A Framework for Management Information Systems, 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 Universitä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, Wiesbaden 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 Medieninformationen, Frankfurt 2006. Kemper, H.-G.; Mehanna, W.; Unger, C.: Business Intelligence - Grundlagen und praktische Anwendungen. Eine Einführung in die IT-basierte Managementunterstützung, 2. Aufl., Vieweg, 2006. Klesse, M.: Leistungsverrechnung im Data Warehousing – Entwicklung einer Methode, 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.

58

Robert Winter, Moritz Schmaltz, Barbara Dinter, Tobias Bucher

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 Informationssysteme, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Business 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 Information Systems 13 (2004), S. 177-195. O'Brien, J.: Management Information Systems - Managing Information Technology in the Networked Enterprise, 3. Aufl., Irwin, Chicago 1996. Picot, A.; Reichwald, R.; Wigand, R.: Die grenzenlose Unternehmung: Information, 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 Infrastructure, 2007, Gartner, Stamford 2007. Strauch, B.; Winter, R.: Stichwort "Business Intelligence", in: Bellmann M. et al. (Hrsg.): Praxishandbuch Wissensmanagement - Strategien, Methoden, Fallbeispiele, Symposion, Düsseldorf 2002, S. 439-448. Stumpf, S.: Wann man von Synergie in Gruppen sprechen kann: Eine Begriffsanalyse, 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 Management, Springer, Berlin etc. 2003, S. 3-23. Wöhe, G.: Einführung in die Allgemeine Betriebswirtschaftslehre, 18. Aufl., Vahlen, München 1993.

4

Strategie der Informationslogistik

Barbara Dinter, Robert Winter Universität St. Gallen

1 2 3 4

1

Strategiebegriff in der Informationslogistik ..................................... 59 Produktsicht auf die IL-Strategie: die IL-Teilstrategien ................... 65 Prozesssicht auf die IL-Strategie: der IL-Strategieentwicklungsprozess ......................................................................... 71 Zusammenfassung ............................................................................ 74 Literatur ............................................................................................ 75

Strategiebegriff in der Informationslogistik

1.1 Motivation und Grundlagen Der Informationslogistik (IL) wird als wesentliches Unterstützungsinstrumentarium und als Enabler für fachliche Innovationen ein hoher Stellenwert 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 Funktionalbereiche) im Unternehmen und daraus historisch gewachsene, intransparente 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 Anforderungen genügen, sondern sollte auch für künftige Anforderungen tragfähig sein. Die IL-Strategie hat sich zudem verschiedenen internen und externen Veränderungen anzupassen. Diese können strategischer Natur sein wie z. B. zunehmender Kostendruck oder zusätzliche Compliance Anforderungen, 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 zahlreiche 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 Planung „ein informationsverarbeitender Prozess zur Abstimmung von Anforderungen 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 WegZiel-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 Strategiearten (Bea u. Haas 2001, S. 164). Dort wird auch die häufig zitierte Differenzierung der Strategiearten anhand der Ebenen des Planungssystems in Unternehmensebene, Geschäftsbereichsebene und Ebene der Funktionen eingeführt (Bea u. Haas 2001, S. 164). Auch zur wechselseitigen Positionierung zwischen IT- und Unternehmensstrategie 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 sollen“ (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-Strategieentwicklung vor. Das Kapitel ist wie folgt aufgebaut: Im verbleibenden Abschn. 1 wird schrittweise zum Begriffsverständnis der IL-Strategie hingeführt. Abschnitt 2 zeigt auf, wie Teilstrategien der Informationslogistik abgeleitet werden können. Diese so genannte Produktsicht auf die ILStrategie 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 Handlungsweise 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 Zusammenfassung (Abschn. 4). 1.2 Alignment von Unternehmens- und IT-Strategie Die bisherigen Ausführungen machen deutlich, dass sowohl der allgemeine Strategiebegriff wie auch der Strategiebegriff im Kontext IT / IS auf x langfristig wirksame, x grundlegende (d. h. Grundlagen für andere Gestaltungsprozesse schaffende) und x ganzheitliche (d. h. die gesamte Betrachtungseinheit umfassende und damit automatisch aggregierte) Festlegungen abstellen. Als typische Festlegungen auf Strategieebene werden im Business Engineering (siehe Kap. 2) die Positionierung im Wettbewerb und hinsichtlich Kompetenzen die daraus folgende Positionierung in Wertschöpfungsnetzwerken, 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 vertikalen Achse eines Koordinatensystems interpretiert, dessen horizontale Achse die Abschnitte „Fachseite“ und „IT“ bilden, entsteht das Grundgerüst des von Henderson und Venkatraman 1993 vorgeschlagenen „Strategic 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 Quadranten die IT-Prozesse und -Infrastrukturen.

62

Barbara Dinter, Robert Winter Fachliche Strategie

IT-Strategie

Betätigungsfelder

Technologiebereich

Spezifische Kompetenzen

Steuerung/ Kontrolle

SystemKompetenzen

Administrative Infrastruktur

Prozesse

ITSteuerung

Architekturen

Fertigkeiten

Prozesse

Fertigkeiten

Fachliche Prozesse und Infrastrukturen

IT-Prozesse und Infrastrukturen

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 Alignment“) (Henderson u. Venkatraman 1993): 1. Strategy Execution Alignment bezeichnet die Ausrichtung der IT-Prozesse und -Infrastruktur auf die fachlichen Prozesse (und Infrastruktur), wobei diese an der fachlichen Strategie ausgerichtet sind. Entsprechende 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 Abstimmungsprozesse 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. Entsprechende Abstimmungsprozesse lassen sich unter dem Stichwort „IT als Enabler“ zusammenfassen.

Strategie der Informationslogistik

63

4. Service Level Alignment bezeichnet die Ausrichtung der fachlichen Prozesse und Infrastruktur an den IT-Prozessen (bzw. der IT-Infrastruktur), wobei diese an der fachlichen Strategie ausgerichtet ist. Entsprechende Abstimmungsprozesse lassen sich unter dem Stichwort „IT als Automatisierungsinstrument“ zusammenfassen. Die folgende Abb. 2 illustriert zusammenfassend die genannten Abstimmungsprozesse: 3 Fachliche Strategie

3

2

1

Fachliche Prozesse und Inf rastrukturen

IT-Strategie

2

4

1 4

IT-Prozesse und Inf rastrukturen

1. Strategy Execution Alignment 2. Technology Transf ormation 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 Gestaltungen auf der einen Seite und prozess- bzw. infrastrukturbezogenen Gestaltungen auf der anderen Seite macht deutlich, dass ein methodengestü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-Strategiegestaltung komplexe Wechselwirkungen nicht nur mit fachlicher Strategiegestaltung und IT-Prozess- bzw. IT-Infrastrukturgestaltung aufweist, sondern auch mit anderen Informationsmanagement-Aufgabenkomplexen wie z. B. Architekturmanagement, Projektportfolio-Management oder IT-Governance. 1.3 IL-Strategie Eine Strategie zur Gestaltung der Informationslogistik kann als Teildisziplin der IT-Strategie angesehen werden. Sie muss sich daher den gleichen

64

Barbara Dinter, Robert Winter

Anforderungen stellen und eine – wie oben erwähnt – langfristig wirksame, 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 Positionierungssicht als Spezifikation aggregierter, umfassender und langfristiger Ziele verstehen. Eingangs wurde im Zuge der allgemeinen Strategiedefinition bereits die Umsetzungssicht auf die Strategie vorgestellt (Strategie als die Maßnahmen zur langfristigen Sicherung des Erfolgs eines Unternehmens). Ü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 Unternehmensbereiche. Dies schließt auch die unternehmensübergreifende Nutzung 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 Produktsicht bezeichnen. Auf der anderen Seite sollte auch die Strategieentwicklung, 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 beschrieben. Als Ausgangsbasis hierfür dient das Modell des integrierten Informationsmanagements (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 Unternehmensstrategie 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 Unternehmensziele in Form von Kennzahlen bereitstellt bzw. per definitionem alle entscheidungsrelevanten und -unterstützenden Informationen zur Steuerung des Unternehmens auf den verschiedenen Ebenen (Unternehmensebene, Geschäftsbereichsebene und Ebene der Funktionen) liefert. Gleichzeitig fungiert sie aber auch als Enabler für die Unternehmensstrategie, wenn sie in ihrer ganzen Bandbreite umgesetzt wird (vgl. Kap. 8). So lassen 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 Infrastrukturcharakter der IL (vgl. Kap. 3, Abschn. 3) wurde bereits herausgearbeitet, dass

Strategie der Informationslogistik

65

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 „BIStrategie“ adressiert. Wie bereits in Kap. 3, Abschn. 2.4.2 ausgeführt wurde, verschwimmen die Grenzen zwischen den Begriffen „Informationslogistik“ und „Business Intelligence“ je nachdem, wie weit der letztere Terminus gefasst wird. Jedoch lässt sich beobachten, dass zwei wesentliche Eigenschaften der Informationslogistik, nämlich die übergreifende Bereitstellung und Nutzung von analytischen Informationen sowie die Berücksichtigung auch unternehmensübergreifender Datenflüsse, in BIStrategien nicht oder kaum berücksichtigt wird. Im Gegenteil, häufig werden 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. Beratungshäuser erschließen die Aufgabenstellung häufig über eine (mehr oder weniger) systematische Herleitung von Teilstrategien, dann meist in Anlehnung 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 Strategieentwicklungsprozess und reichern die einzelnen Phasen mit Vorschlägen zur praktischen 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 Topdown-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 Komponentensicht des IL-Strategieverständnisses (vgl. Abschnitt 1.3) einzunehmen und die strategischen Fragestellungen in Teilstrategien zu adressieren.

66

Barbara Dinter, Robert Winter

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 bereits zahlreiche Arbeiten zur Herleitung und Ausgestaltung solcher ITTeilstrategien (Earl 1989; Heinrich 2002). Speziell für BI-Strategien (vgl. vorheriger Abschnitt) konnte sich bisher noch kein gemeinsames Verständnis etablieren, welche Teilstrategien ihr zuzurechnen seien. In der unternehmerischen Praxis orientiert sich die Definition zugehöriger Teilstrategien häufig an den Teilstrategien der IT-Strategie oder an Teilaspekten des Datenmanagements (wie Metadatenmanagement, Datenqualitätsmanagement, Datenarchitektur etc.). Im Folgenden werden die Teilstrategien aus dem Modell des integrierten Informationsmanagements (Zarnekow et al. 2005) auf die Spezifika der Informationslogistik übertragen. Das Modell beschreibt die zentralen Managementprozesse eines ITLeistungserbringers, die zur Herstellung und Nutzung von IT-Produkten erforderlich sind (Zarnekow et al. 2005, S. 66). Es basiert auf einer Adaption des SCOR (Supply Chain Operations Reference)-Modells (Supply Chain Council 2006). Übertragen auf den Kontext des Informationsmanagements werden dann IT-Leistungserbringer und Leistungsabnehmer in einer Supply Chain zur Erstellung von IT-Leistungen (Zarnekow et al. 2005) unterschieden. Leistungsabnehmer sind typischerweise Geschäftsbereiche des Unternehmens, die Leistungserbringung erfolgt durch einen ITDienstleister – der wiederum die Rolle des Leistungsabnehmers eines internen oder externen Lieferanten einnehmen kann. Der Source-Prozess des Leistungsabnehmers umfasst alle zum Management der Lieferantenbeziehungen erforderlichen Aufgaben, der Deliver-Prozess des Leistungserbringers die zum Management der Kundenbeziehungen. Im dazwischen liegenden Make-Prozess des Leistungserbringers sind alle Aufgaben zum Management der IT-Leistungserstellung zusammengefasst. Der übergeordnete 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 Organisationseinheiten häufig im Spannungsfeld zwischen zu beziehenden ITDienstleistungen, der eigenen „Produktion“ von IT-Leistungen bzw. der Schnittstelle hin zu Leistungsabnehmern (i. d. R. die Fachbereiche) positioniert. In Kap. 5 wird auf die unterschiedlichen Typen von Leistungserbringern in der Informationslogistik näher eingegangen. Die dort vorgestellten Studienergebnisse bestätigen eine Abnahme der Fertigungstiefe, indem standardisierbare Leistungen extern oder unternehmensintern an andere ITBereiche vergeben werden.

Strategie der Informationslogistik

67

Im Modell des integrierten Informationsmanagements werden Teilstrategien unterschieden, sie decken alle relevanten Phasen der IT-Leistungserstellung ab (vgl. Abb. 3). Lieferantenmanagement Sourcing-Strategie • Alignment mit Unternehmens- und IT-Strategie • Lieferantenmanagement • Auswahl SourcingStrategie; Dimensionen: • Intern / Extern • Total / Selektiv • Single / Multiple • Offshore /Nearshore • Komponenten • Utility (RZ) • Software (SSW) • Lösungen (ASP) • Prozesse (BPO)

Programmmanagement

Entwicklungsmanagement

Produktionsmanagement

Portfoliostrategie • Identifikation von Leistungssegmenten • Bewertung und Positionierung von Leistungssegmenten Entwicklungsstrategie

Produktionsstrategie

• Definition der strategischen Rahmenbedingungen für Entwicklung und Produktion • Gestaltung der Anwendungs- u. Systemarchitektur • Rahmenbedingungen für Werkzeuge Organisation der Entwicklung • Vorgehensmodelle • Entwicklungsprinzipien • Methoden, Werkzeuge

Kundenmanagement Delivery-Strategie • Strategische Positionierung in Markt und Wettbewerb • Strategische Ausrichtung des Angebotsportfolios • Preisstrategie • Kommunikationsstrategie • Distributionsstrategie

Organisation des Betriebs • Plattformstrategie • Standortstrategie • Designprinzipien

Abb. 3. Teilstrategien im Modell des integrierten Informationsmanagements (Zarnekow 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 Prozesse 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öglichkeiten. Hierzu sei nochmals auf Kap. 5 verwiesen, wo anhand der Fertigungstiefe 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 hinsichtlich der Make or Buy-Strategie. Abbildung 3 zeigt die Dimensionen zur Kategorisierung von Sourcing-Strategien.

68

Barbara Dinter, Robert Winter

2.3 Delivery-Strategie (Deliver) Die Delivery-Strategie adressiert die Schnittstelle des Leistungserbringers zum Leistungsabnehmer, d. h. alle Aufgaben, die zur Gestaltung der Beziehung des Leistungserbringers zum Absatzmarkt seiner IT-Produkte, also zu den Leistungsabnehmern, erforderlich sind. Hauptaufgabe des Deliver-Prozesses ist es, die Bedürfnisse der Leistungsabnehmer in interne Anforderungen an die IT-Leistungserstellung zu transformieren. Im Kontext 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 Fragestellungen: x Strategische Positionierung im Markt und Wettbewerb: Es gilt, zum einen festzulegen, ob die IL-Produkte am externen Markt angeboten werden sollen (beispielsweise in Form von Reports), aber auch Fragestellungen wie die der Delegationsform des IL-Leistungserbringers (Cost / Profit / Investment Center, vgl. Klesse 2007) müssen geklärt werden. x Strategische Ausrichtung des Angebotsportfolios: Das Portfolio an ILLeistungen sollte möglichst optimal an der Kundennachfrage ausgerichtet 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) vorherrschen muss bzw. dass der IL-Leistungserbringer selbst fachliches Know How im Team hat. x Preisstrategie: Die Bepreisung der IL-Leistungen hängt insbesondere ab von Budgets und vom gewählten Finanzierungs- und Verrechnungsmodell, das es ebenfalls festzulegen gilt. Zur Problematik und möglichen Lösungsansätzen sei auf Kap. 12 verwiesen. x Kommunikationsstrategie: Hier werden die Kommunikationsziele und Zielgruppen des IL-Leistungserbringers festgelegt. Der Anspruch der Informationslogistik, bereichsübergreifendes Denken und Datenaustausch zu fördern, zielt in eine ähnliche Richtung, dass nämlich mit geeigneter Kommunikation oder „Marketing“ die Leistungen der IL weitflächig im Unternehmen bekannt gemacht werden. x Distributionsstrategie: Damit werden die Rahmenbedingungen festgelegt, wie und über welche Wege die IL-Leistungen für die Kunden verfügbar gemacht werden. Dies betrifft auch die Grundsatzentscheidung, ob die Produkte im Push- oder Pull-Modus zum Kunden gelangen. Letzteres Prinzip wird zunehmend von den Fachbereichen nachgefragt, wenn sie nämlich autonom, zeitnah und selbstbestimmt analytische In-

Strategie der Informationslogistik

69

formationen beziehen möchten („Selbstbedienung“ anstelle von Abhängigkeiten von der IT). 2.4 Portfolio-Strategie (Make) Die Portfolio-Strategie definiert die Strategie für das IL-Leistungsprogramm (die Summe aller IL-Leistungen des Leistungserbringers). Folgende Fragestellungen gilt es zu beantworten: x Identifikation von Leistungssegmenten: Die Portfolio-Strategie muss auf Dauer ertragskräftige Leistungssegmente identifizieren. Hierzu sollten insbesondere auch die Anforderungen aus der fachlichen Strategie berücksichtigt werden, um Angebot und Nachfrage an IL-Leistungen bestmöglich zur Deckung zu bringen. x 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 positionieren oder anderseits sich als Service Integrator für das gesamte Spektrum 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 Sichtweise 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 adressieren v.a. diese Teilstrategie und entlehnen sie der IT-Strategie. Die Funktionalität der IT-Leistungen wird maßgeblich durch die Anwendungssysteme, d.h. durch die Entwicklung, bestimmt. Die Entwicklungsstrategie betrifft zum einen systemarchitektonische Aspekte, zum anderen Entwicklungsprinzipien und Vorgaben für die Werkzeugunterstützung. Dazu werden folgende Fragestellungen adressiert: x Organisation der Entwicklung: Die Ansprüche der Informationslogistik müssen auch in der Organisationsgestaltung reflektiert werden. Kapi-

70

Barbara Dinter, Robert Winter

tel 5 geht näher auf mögliche Aufbauorganisationen ein. Auch die Ablauforganisation für die Entwicklung gilt es hier festzulegen. x Festlegung der Entwicklungsprinzipien und Standards: Bereichsübergreifende verbindliche Standards und Vorgehensweisen ermöglichen die (schrittweise) Umstellung von Insellösungen im Unternehmen hin zu einer umfassenden homogenen Informationslogistik und fördern den Datenaustausch zwischen Organisationseinheiten. Ebenso erfordert der Infrastrukturcharakter der Informationslogistik (vgl. Kapitel 3) solche Richtlinien und macht die Abstimmung mit der unternehmensweiten IT sinnvoll. x Rahmenbedingungen für Entwicklungswerkzeuge und -sprachen: In eine ä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 Kaufsoftware realisiert wird. x Strategische Ausrichtung des Anwendungs-Portfolios: Hiermit soll sichergestellt werden, dass die Gestaltung und Anordnung der Anwendungssyteme 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: x Organisation der Produktion: Die bei der Entwicklungsstrategie bereits angesprochene Aufbau- und Ablauforganisation muss auch die Anforderungen des Betriebs der Informationslogistik beachten. x Designprinzipien und Standards: Hier gelten ähnliche Aussagen wie zur Entwicklungsstrategie; es gilt, u. a. Vorgaben für Produktionsinfrastruktur festzulegen (Skalierbarkeit, Fehlertoleranz, etc.). x Strategische Ausrichtung der Systemarchitektur: Damit wird die Produktionsinfrastruktur und deren Architektur langfristig gestaltet. x Rahmenbedingungen für Werkzeuge: Dies betrifft im Wesentlichen Werkzeuge für die Steuerung und Überwachung der Produktion. Hinsichtlich der Auslagerung von Betriebsaufgaben macht die Produktionsstrategie auch Vorgaben für die Sourcing-Strategie, nämlich, ob diese prinzipiell sinnvoll ist.

Strategie der Informationslogistik

71

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 erbracht werden (Zarnekow et al. 2005, S. 65). Auch zu den restlichen Teilstrategien gibt es Interdependenzen, die oben zum Teil schon angesprochen 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 Umkehrschluss, dass die restlichen Teilstrategien (Source- / Deliver- / Portfolio-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 Informationslogistik.

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 Allgemeinen (bzw. für Unternehmensstrategien) gibt es zahlreiche Vorgehensmodelle zur Strategieentwicklung (wie Ansoff 1965; Mintzberg 1987; Müller-Stewens u. Lechner 2003; Dubs et al. 2004), als auch für die Erarbeitung 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 hohem Aggregationsniveau ähneln sich die verschiedenen Vorgehensmodelle stark und enthalten in der Regel die Hauptphasen Analyse, Design bzw. Planung, Umsetzung und Controlling, wenngleich Reihenfolge oder Zusammenfassung von Teilschritten variieren können. Zu jeder Phase lassen sich jeweils Aufgaben (Teilschritte) und unterstützende Techniken definieren (z. B. bei Bea u. Haas 2001, S. 65ff.). Basierend auf der Konsolidierung der oben zitierten Ansätze zum Strategieentwicklungsprozess und unter Berücksichtigung der Charakteristika

72

Barbara Dinter, Robert Winter

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 umfassenden Ist-Analyse den Grundstein: Heinrich zieht den treffenden Vergleich, 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 Dimensionen 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. Gluchowski 2004; Steria Mummert Consulting AG 2006); alternativ oder ergä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 gewachsener, 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 Dimensionen 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 Zielhierarchie 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 betont (Müller-Stewens u. Lechner 2003).

Strategie der Informationslogistik

73

diesem Fall für die Informationslogistk) bereits verfeinert. Das IL-Leitbild sollte demzufolge bereits Orientierungshilfe für die Ausgestaltung der Informationslogistik bieten bzw. das Selbstverständnis der Informationslogistik im Unternehmen reflektieren. Laut Heinrich soll das Leitbild (prägnante) Aussagen zu Ziel- und Zweckorientierung, Kunden- und Mitarbeiterorientierung, 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 Informationen 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 Zielhierarchie, die neben den erwähnten Ebenen Vision und (Unternehmens)Leitbild noch unterscheidet in Unternehmens-, Geschäftsbereichsund Funktionsbereichsziele (mit zunehmender Konkretisierung). Je nach Situation lässt sich diese Unterteilung für die Herleitung der Ziele der Informationslogistik 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 hinsichtlich 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 konform 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ätzlich noch Abhängigkeiten zwischen den Zielen in einer so genannten Strategy Map (Kaplan u. Norton 1992) erfasst werden. 3.3 Strategieentwicklung Die einzelnen Aktivitäten dieser Phase lassen sich gut von Heinrichs Vorgehensweise bei der Entwicklung einer IT-Strategie (Heinrich 2002, S. 109ff.) auf die Informationslogistik übertragen: x Generieren alternativer IL-Strategien

74

Barbara Dinter, Robert Winter

x Evaluieren (beispielsweise mithilfe der Nutzwertanalyse und unter Beachtung der jeweiligen Risiken) und Bestimmen der optimalen ILStrategie x Abstimmen mit der Unternehmensstrategie x Ableiten von Teilstrategien. Im strategischen Management werden zahlreiche Strategiearten unterschieden (wie etwa bei Bea u. Haas 2001, S. 164), deren Übertragung auf die Informationslogistik jedoch nur bedingt sinnvoll ist, da die angewandten 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 Auflistung der Inhalte einer IT-Strategie (Heinrich 2002, S. 113) als Checkliste verwenden. Hat man sich für eine Strategie (bzw. der Repräsentation in Teilstrategien), entschieden, gilt es in einem nächsten Schritt, zugehörige Maßnahmen 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 einen 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 eingegangen, da sie sehr situationsabhängig auszugestalten sind. Insgesamt sollte der oben vorgestellte Strategieentwicklungsprozess für die Informationslogistik als ein iteratives Vorhaben betrachtet wird, das wiederholt durchlaufen 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 Strategie mit einem langfristigen und umfassenden Blickwinkel verfehlt. Bisher

Strategie der Informationslogistik

75

sind noch kaum systematische und umfassende Vorgehensweisen zur Gestaltung 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 strategischen Nachteile eine unzureichende Informationsversorgung im Unternehmen mit sich bringen kann. Dabei ist eine IL-Strategie keinesfalls statisch, sondern analog zur Unternehmensstrategie kontinuierlich Veränderungen 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) sichergestellt werden. Wolf weist darauf hin, dass eine sorgfältige Abstimmung von Strategie und Organisationsstruktur von unvermindert hoher Relevanz 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, Stuttgart 2001. Chamoni, P.; Gluchowski, P.: Integrationstrends bei Business-IntelligenceSystemen - Empirische Untersuchung auf Basis des Business Intelligence Maturity Model, in: Wirtschaftsinformatik 46 (2004) 2, S. 119-128. Dubs, R.; Euler, D.; Rüegg-Stürm, J.; Wyss, C.: Einführung in die Managementlehre, 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 Implementierungsansätze, 3. Aufl., Haupt, Bern et al. 2002. Kaplan, R. S.; Norton, D. P.: The Balanced Scorecard - Measures that Drive Performance, in: Harvard Business Review 70 (1992) 1, S. 71-79.

76

Barbara Dinter, Robert Winter

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 Management 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 IntelligenceTechnologien 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äfferPoeschel, 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 Universität St. Gallen

1 2 3 4 5

Einleitung ......................................................................................... 77 Das Data Warehouse-Konzept.......................................................... 78 DWH-Leistungserbringertypen in der Praxis ................................... 82 Auswahl der geeigneten Organisationsform ..................................... 95 Zusammenfassung und Ausblick ...................................................... 96 Literatur ............................................................................................ 97

1

Einleitung

Seit seiner Etablierung in den späten 1980ern ist Data Warehousing in vielen Unternehmen ein integraler Bestandteil der Informationslogistik (Winter 2000, vgl. auch Kap. 3). In der Vergangenheit konzentrierte sich die Forschung hauptsächlich auf Aspekte der Entwicklung und Einführung eines Data Warehouse (DWH) (Meyer 2000, S. VII). Die nachhaltige organisatorische Implementierung des Data-Warehousing-Prozesses rückt dagegen erst seit kurzem in den Fokus der Betrachtungen. Bisherige Arbeiten zum Thema DWH-Organisation konzentrieren sich vorrangig auf strukturelle Aspekte der Organisation, wie z. B. Projektmanagement, Entwicklungsmethoden, 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 Rollenmodelle vorgestellt, die für das Data Warehousing langfristig organisatorisch 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 Gestaltungsvorschlä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 Outsourcing 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 Warehousing implementiert oder gewachsen sind, in die sich derartige Gestaltungsvorschläge einpassen lassen müssen. Kern der DWH-Organisation ist häufig 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 DWHLeistungserbringer bezeichnet. Über die Positionierung einer solchen Einheit existieren jedoch bisher kaum gesicherte Erkenntnisse. Dies verhindert die Entwicklung speziell auf existierende Organisationsformen ausgerichteter 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 Organisationseinheit mit Fachabteilungen, internen und externen IT-Dienstleistern untersucht wird. Basis ist eine empirische Studie mit 96 Unternehmen, die Data Warehousing betreiben. Für die strukturierte Erfassung der Positionierung 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 DWHLeistungserbringern (Abschn. 3). In Abschn. 4 wird die Auswahl der geeigneten 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 Organisationseinheiten hinaus (vgl. Kap. 3). Das Data Warehouse ist in vielen Unternehmen das zentrale Informationssystem zur Umsetzung der Informationslogistik. Innerhalb der Informationslogistik erfüllt das Data Warehouse die Funktion einer zentralen Integrationsinfrastruktur, die die Bereitstellung 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 organisatorische und strategische Aspekte legt und der auch unternehmensübergreifende 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 einer 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 zentrale Komponenten, wie Systeme zur Datenqualitätssicherung, für das Metadatenmanagement und zur Administration. Sie versorgt die DWHApplikationen mit vereinheitlichten, qualitätsgesicherten Daten. Die DWH-Applikationen stellen den verwendungsspezifischen Teil des DWHInformationssystems dar. In vielen Fällen enthalten sie für den jeweiligen Analysezweck speziell aufbereitete Daten (Data Marts) und stellen Analysefunktionalitä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 jedoch nicht Bestandteil des DWH-Informationssystems sind. DWHInformationssysteme laufen auf physischen DWH-Plattformen, welche Basisdienste zur Speicherung, Verarbeitung und Übertragung von Daten anbieten (technische Architektur). 2.3 Der Prozess Data Warehousing Unter Data Warehousing wird die Gesamtheit von Prozessen und Systemen zum Betrieb und Nutzung eines DWH-Informationssystems verstanden (Jung u. Winter 2000; Klesse 2007). Die Prozesse umfassen die analytische Nutzung sowie Entwicklung, Betrieb und Support des DWHInformationssystems (Wang et al. 1998; Winter 2000; Bauer u. Günzel 2004). Für die Zwecke der nachfolgenden Analysen werden diese Hauptprozesse wie folgt detailliert (vgl. Abb. 1).

80

Mario Klesse, Moritz Schmaltz

Nutzung: Das Data Warehouse kann auf verschiedene Art und Weise genutzt werden. Ergebnis der Nutzung sind aufbereitete Informationen, die direkt in Führungs- und Geschäftsprozesse einfließen können. Damit ergeben sich folgende Teilprozesse der Nutzung: x Durchführen von Standardauswertungen: Hierunter werden Abrufe vorgefertigter Berichte und eng eingegrenzte multidimensionale Analysen subsumiert. Standardanalysen sind durch einen breiten Empfängerkreis und geringe Parametrisierbarkeit gekennzeichnet. x Durchführen von Sonderanalysen: Diese Nutzungsform ist durch einen 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 erforderlich. x 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 Teilprozesse: x Entwicklung von DWH-Applikationen: Dies umfasst die Erstellung und Pflege von Anwendungen und Data Marts von der Anforderungsanalyse bis zur Übergabe an den Betrieb. x Entwicklung der DWH-Integrationsinfrastruktur: Dies umfasst die Erstellung und Pflege der DWH-Integrationsinfrastruktur von der Anforderungsanalyse bis zur Übergabe an den Betrieb. x Auswahl, Einrichtung und Konfiguration von DWH-Plattformen: Das Pendant zur Entwicklung auf Informationssystemebene ist auf Ebene der technischen Architektur die Einrichtung und Konfiguration von DWH-Plattformen.

Organisationsformen für die Informationslogistik

81

Nutzung Durchführen von Standardauswertungen

DWHApplikationen/ Data Marts

DWH-Plattform (Hardware, DBMS, etc.)

Legende:

Entwicklung der DWH-Integrationsinfrastruktur

Auswahl und Einrichten der DWH-Plattform

Komponente

Produktion

Entwicklung der DWHApplikationen

Entwicklung

DWHIntegrationsinfrastruktur

Durchführen von Sonderanalysen

Durchführen von informationskonsumierenden Prozessen

Fachlicher Betrieb der DWHApplikationen

Fachlicher Support der DWHApplikationen

Fachlicher Betrieb der DWH-Integrationsinfrastruktur

Fachlicher Support der DWH-Integrationsinfrastruktur

Technischer Betrieb der DWH-Plattform

Technischer Support der DWHPlattform

Prozess

komponentenspezifischer Prozess

Abb. 1. Prozesse im Data Warehousing

Betrieb: Analog zur Entwicklung kann auch der Betrieb komponentenorientiert in Teilbetriebsprozesse zerlegt werden: x 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-Integrationsinfrastruktur in die DWH-Applikationen unterstützen. x Fachlicher Betrieb der DWH-Integrationsinfrastruktur: Unter dem fachlichen Betrieb der DWH-Integrationsinfrastruktur sind alle Tätigkeiten subsumiert, die der Unterstützung der Informationsintegration dienen. x 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 bezeichnet.

82

Mario Klesse, Moritz Schmaltz

Support: Für den Support des DWH-Informationssystems lassen sich entlang der DWH-Architektur nachfolgend aufgeführte Teilprozesse unterscheiden: x Fachlicher Support der DWH-Applikationen: Der fachliche Support der DWH-Applikationen adressiert vorwiegend die Endbenutzer des Informationssystems. x Fachlicher Support der DWH-Integrationsinfrastruktur: Der fachliche Support der DWH-Integrationsinfrastruktur bedient vorrangig deren direkte Datenabnehmer. x Technischer Support der DWH-Plattform: Der technische Support der DWH-Plattform bedient vor allem die Abnehmer der Plattformleistungen.

3

DWH-Leistungserbringertypen in der Praxis

3.1 Untersuchungsdesign Die zuvor beschriebenen Teilprozesse zerlegen den Data-WarehousingProzess entlang der orthogonalen Dimensionen Funktion und Komponente: Zum einen wird eine Zerlegung in Entwicklung, Betrieb, Support und Nutzung vorgenommen, zum anderen eine Zerlegung entlang der Komponenten DWH-Plattform, DWH-Integrationsinfrastruktur und DWH-Applikationen. Diese Teilprozesse können durch verschiedene Rollen im Unternehmen im unterschiedlichen Maße wahrgenommen werden. Grob unterschieden werden im Folgenden der DWH-Leistungserbringer, Fachabteilungen, die interne IT des betreffenden Unternehmens sowie externe Dienstleister, die in den Prozess eingebunden sind. Für die empirische Untersuchung wurde darauf aufbauend ein Fragebogen entwickelt, welcher die Tätigkeitsverteilung der vier Rollen an den zwölf Teilprozessen erfasst. Der Tätigkeitsanteil jeder Rolle am entsprechenden Teilprozess kann darin prozentual angegeben werden. Die Bezugsbasis bildet der anfallende Gesamtaufwand im jeweiligen Teilprozess. Auf Basis der erhobenen Tätigkeitsanteile sollte eine explorative Analyse Klarheit darüber verschaffen, ob (1) die Aufgabenverteilung vorrangig nach dem Objekt- oder dem Funktionsprinzip festgelegt wird und (2) verschiedene Typen von DWH-Leistungserbringern hinsichtlich der Aufgabenverteilung existieren. Eine qualitative Untersuchung typischer Vertreter der identifizierten DWH-Leistungserbringertypen sollte anschließend aufzeigen, wie derartige Organisationsformen in der Praxis implementiert sind, und einen wei-

Organisationsformen für die Informationslogistik

83

tergehenden Einblick in Vor- und Nachteile der jeweiligen Organisationsform 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 Testpersonen aus der Praxis geprüft und auf der Veranstaltung kurz erläutert. An dem Forum zum Thema „Data Warehousing, Customer Relationship Management 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ücklaufquote von ca. 61%. Bei den Befragten handelt es sich um Mitarbeiter aus Unternehmen der Schweiz, Deutschlands und Österreichs, wobei Großunternehmen, insbesondere 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 beschä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-Organisationseinheit, 23% mehrere. Damit kann die Zentralisierung von DWH-Know-how in einer speziellen Organisationseinheit als gängige Praxis angesehen werden, die von fast 90% der befragten Unternehmen praktiziert wird. Die DWH-Organisationseinheit umfasst in ca. der Hälfte der Fälle bis zu 19 Mitarbeiter. Mehrere Einheiten werden häufig dann unterhalten, 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 vorhanden waren. Insgesamt wurden 68 Datensätze in die Analyse aufgenommen.

84

Mario Klesse, Moritz Schmaltz

3.3 Auswertung Die Auswertung der Daten zeigte, dass sich die abgefragten Teilprozesse des Data Warehousing zu drei Faktoren zusammenfassen lassen:1 x Tätigkeitsanteil an der DWH-Informationssystembetreuung: Der erste Faktor fasst die Tätigkeitsanteile der Entwicklung, des fachlichen Betriebs und des fachlichen Supports von DWH-Integrationsinfrastruktur und der DWH-Applikationen zusammen. x Tätigkeitsanteil an der DWH-Plattformbetreuung: Der zweite Faktor beinhaltet im Wesentlichen die Auswahl, Einrichtung und Konfiguration sowie den technischen Betrieb und Support der DWH-Plattform. x 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 Sonderauswertungen. 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-Leistungserbringer danach unterscheiden, welche Tätigkeitsanteile sie an der DWHInformationssystembetreuung, 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 Entwicklung, dem Betrieb und dem Support von DWH-Integrationsinfrastruktur und DWH-Applikationen verdeutlicht die Ursache hierfür: Die Tätigkeitsanteile aller genannten Teilprozesse weisen starke, signifikante Korrelationen auf. Das bedeutet, dass DWH-Leistungserbringer im Regelfall die Verantwortung für Entwicklung, Betrieb und Support beider Teilkomponenten 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 Messvariablen auf die 3 beschriebenen Faktoren.

Organisationsformen für die Informationslogistik

85

identifizieren.2 Dabei wurden 4 Cluster gebildet, die die Basis der folgenden 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 beispielhaften Unternehmen erhoben. 3.4 Typen von DWH-Leistungserbringern Die untersuchten Leistungserbringer lassen sich demzufolge in vier verschiedene 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 Koordinatensystem mit den Dimensionen „Geschäftsnähe“ und „Fertigungstiefe“ einordnen (vgl. Abb. 2). Die Geschäftsnähe ist durch den Tätigkeitsanteil im Nutzungsprozess determiniert. Je mehr Aufgaben die DWHAbteilung im Nutzungsprozess wahrnimmt, desto fachnäher ist sie ausgerichtet. 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 verwendet. Dabei handelt es sich um ein partitionierendes Verfahren, welches die Clusteranzahl als Eingabewert benötigt. Als Distanzmaß diente die euklidische Distanz. 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 entstehen. 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 dieser 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 bewirkt. Ellbows traten im vorliegenden Datensatz bei 2, 4 und 7 Clustern auf. Da die Lösung mit 2 Clustern keine ausreichende Differenzierung der Leistungserbringer ergibt und bei der 7-Cluster-Lösung einzelne Cluster zu klein sind, wurde eine Clusterzahl von 4 als optimale Lösung ausgewählt.

86

Mario Klesse, Moritz Schmaltz

Abb. 2. DWH-Leistungserbringertypen

In den folgenden Abschnitten sind die einzelnen Leistungserbringertypen jeweils im Detail mit beispielhaften Kunden-Lieferantenbeziehungen dargestellt. In der Praxis sind selbstverständlich auch Mischformen zwischen den Typen anzutreffen, die hier dargestellten Ausprägungen sind lediglich als typische Beispiele zu betrachten. 3.4.1

Full Service Provider (DWH-FSP)

Dieser Typ Leistungserbringer ist relativ stark in den Nutzungsprozess involviert: 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 Leistungsspektrum des DWH-FSP im Nutzungsbereich umfasst typischerweise die Bereitstellung vordefinierter, standardisierter Analysen sowie die Durchführung von kundenspezifischen Reports und individuellen Sonderanalysen. 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 Analyseergebnissen unterstützt. Dennoch wird das bereitgestellte DWHInformationssystem auch selbständig von Fachabteilungen genutzt.

Organisationsformen für die Informationslogistik

87

DWH-Leistungserbringer DWH Full Service Provider (DWH-FSP) Planung/Entwicklung der DWH-Plattform Konfiguration der DWH-Plattform Wartung der DWH-Platform Betrieb der DWH Plattform Betrieb der Plattform Routinebetrieb von Ladeprozessen Support der DWH Platform Lösung technischer Probleme

DWH-Plattform Erweiterungen der DWHServices

Planung/Entwicklung des DWH-IS Projektmanagement Produkt- und Architekturmanagement Entwicklung von DWH-Applikationen und Erweiterungen der Integrationsinfrastruktur Betrieb des DWH-IS Problembehebung Datenqualitätsmanagement Referenzdatenmanagement Metadatenmanagement Support des DWH-IS Benutzeradministration Endbenutzerunterstützung Durchführen von Sonderanalysen DWH-Informationssystem

Betrieb der DWH-Services

Lieferung von Analyseergebnissen

Leistungsabnehmer Fachabteilungen Nutzung des DWH Durchführung von Geschäfts- und Führungsprozessen Durchführung von Standardauswertungen

Legende:

...

Komponente, betreut durch Einheit Komponente, verantwortet durch Einheit

Abb. 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 zwischen dem DWH-Leistungserbringer (d. h. dem DWH-FSP) und dem Leistungsabnehmer (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 umfangreiches Wissen über DWH-Plattformen, über DWH-Informationssysteme als auch über verschiedene Auswertungsmethoden im Data Warehousing.

88

Mario Klesse, Moritz Schmaltz

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 ITAbteilungen bzw. für Nutzerorganisationen, denen eigene Kompetenzen und Ressourcen für das Data Warehousing fehlen und bei denen gleichzeitig nur ein geringer Bedarf nach stark individualisierten Auswertungen besteht. Herausforderungen ergeben sich für den Full Service Provider vor allem im Management der Datenquellen, wenn diese nicht von der gleichen Organisation gemanagt werden, der der DWH-Leistungserbringer unterstellt ist. 3.4.2

Business Service Provider (DWH-BSP)

Dieser Typ Leistungserbringer ist sehr stark in den Nutzungsprozess involviert oder führt ihn selbst durch (Aufgabenanteil 60%). Das Leistungsangebot umfasst die Bereitstellung von Standardauswertungen und die Erstellung 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, wobei 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 arbeitet 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 fachliche Seite, während die Leistungsabnehmer selber nicht direkt die analytischen Systeme nutzen. Diese Organisationsform scheint vor allem dann geeignet, wenn häufig stark verschiedene Analysen angefordert werden, die erhebliches methodisches Know-how benötigen (z. B. Kundensegmentierung mittels Data Mining). 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.

Organisationsformen für die Informationslogistik Externe Service Provider Dienstleister Implementierung Implementierung spezifizierter DWHSoftwaremodule

Dienstleister Plattformen Betrieb der DWHPlattform Routinebetrieb der Ladeprozesse

DWH-Plattform

89

DWH-Leistungserbringer DWH Business Service Provider (DWH-BSP) Implementierte DWH- Entwicklung DWH-IS Planung DWH-IS SoftwareFachkonzeption von Projektmanagement module DWH-Applikationen DWH-Programm- u. u. Erweiterungen an Architekturmanader Integrationsinfragement struktur Nutzung DWH Betrieb DWH-IS Durchführung von Problembehebung StandardBetreute Datenqualitätsmgmt. auswertungen DWHStammdatenmgmt. Durchführung von Plattform Sonderanalysen Metadatenmgmt. Support DWH-IS Unterstützung der Fachanwender im DWH-BSP DWH-IS

Analyseaufträge

DWH-IS Reports, Marktanalysen, Kundenprofile, etc.

Leistungsabnehmer Fachabteilung Nutzung DWH Durchführung von Geschäfts- und Führungsprozessen Keine direkte Nutzung des DWH-Informationssystems

Legende:

...

Komponente, betreut durch Einheit Komponente, verantwortet durch Einheit

Abb. 4. Kunden-Lieferanten-Beziehungen eines Business Service Providers

Die Organisationsform eignet sich damit wie das DWH-CC bei begrenzten 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

90

Mario Klesse, Moritz Schmaltz

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 Service Provider der Fokus auf dem DWH-Informationssystem (Aufgabenanteil 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 Datenqualitätssicherung, Metadatenpflege, Referenzdatenpflege, Nutzeradministration 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 Fachbereichen übernehmen die Erstellung von Standardreports und Sonderanalysen, 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 übernimmt hier nur den Routinebetrieb. Die Planung und Implementierung erfolgt 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 Koordination des Data Warehousing im Unternehmen (vgl. auch Abschn. 3.4.4), sondern zusätzlich die Entwicklung und Anpassung einer speziellen 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 Dezentralisierung der Nutzungsprozesse bietet sich insbesondere dann an, wenn Analysen weniger methodisches Wissen als vielmehr fachliches Wissen benötigen, 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 Dateninhalte des Data Warehouse nur ungenau kennen. Damit besteht die Gefahr, dass sich langfristig die Datenqualität verschlechtert und dass das Verständnis für die fachlichen Anforderungen der Nutzer sinkt.

Organisationsformen für die Informationslogistik Service Provider

DWH-Leistungserbringer

IT-Betriebsabteilung Betrieb der DWHPlattform Routinebetrieb und Überwachung von Ladeprozessen

DWH-Plattform

91

DWH Platform Provider (DWH-PP) Konfigurierte DWH-Plattform

Planung/Entwicklung des DWH Projektmanagement DWH-Programm- & Architekturmanagement Implementierte Entwicklung von DWH-Applikationen und DWH-SoftwareDWH-Erweiterungen Module Planung/Entwicklung der DWH-Plattform Konfiguration der DWH-Plattform Wartung der DWH-Plattform Betrieb des DWH Problembehebung Datenqualitätsmanagement DWH-PlattformReferenzdatenmanagement Betrieb Metadatenmanagement DWH-IS Support des DWH Benutzeradministration DWH-Plattform Endbenutzerbetreuung Erweiterung der DWH-Services

Betrieb der DWH-Services

Leistungsabnehmer Fachabteilungen Nutzung des DWH Durchführung von Führungs- und Geschäftsprozessen Durchführung von Standardauswertungen Durchführung von Sonderauswertungen durch „Power User“ DWH-Applikationen

Legende:

...

Komponente, betreut durch Einheit Komponente, verantwortet durch Einheit

Abb. 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-

92

Mario Klesse, Moritz Schmaltz

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 Architekturmanagement für die DWH-Landschaft, Anforderungsmanagement für die DWH-Systeme, Projektmanagement für die Umsetzung von Anforderungen, Fachkonzeption sowie Test und Abnahme von neuen DWH-Applikationen sowie der dazu nötigen Komponenten der DWH-Integrationsinfrastruktur, fachlichen Betrieb des DWH-Informationssystems, insbesondere die Qualitätssicherung von Daten und Analysefunktionen, Referenzdatenpflege 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 Sonderanalysen spezielles Know-how benötigt wird. Die Kernkompetenz eines DWH-CC ist die Begleitung und Koordinierung des gesamten DWH-Prozesses mit zahlreichen Zulieferern. Wichtig ist dabei vor allem, dass für jede zugelieferte Leistungsart genügend Kompetenzen im DWH-CC vorhanden bleiben, um Leistungsmengen planen und die Qualität der zugelieferten Leistungen beurteilen zu können. Herausforderungen ergeben sich vor allem in der Zusammenführung aller Teilleistungen zu hochqualitativen Informationsprodukten für die Informationskonsumenten. Diese Organisationsform wird mitunter als „optimal“ für das Data Warehousing dargestellt (Strange u. Dresner 2002b). Ihr Vorteil liegt vor allem darin, dass mit einer verhältnismäßig geringen Anzahl von internen Mitarbeitern die Ziele des Data Warehousing verfolgt werden können. Die Teile der Kernprozesse, die Kenntnisse über den Inhalt des Data Warehousing benötigen, wie z. B. fachliche Planung und Entwicklung, Datenqualitätssicherung, Metadatenmanagement und Endbenutzerbetreuung 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 Wissen benötigt wird und zahlreiche, verschiedene Fachbereiche bedient werden. Gleichzeitig sollten die Nutzerkreise in den betreffenden Fachbereichen groß genug sein, um dort den Aufbau von Analysekompetenz unter Wirtschaftlichkeitsgesichtspunkten rechtfertigen zu können.

Organisationsformen für die Informationslogistik Externe Zulieferer Dienstleister Implementierung

93

DWH-Leistungserbringer DWH Competence Center (DWH-CC)

Implementierung spezifizierter DWHSoftware-Module

Implementierte SoftwareModule

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

Betreute DWH-Plattform

DWH-Plattform

Fachl. Planung/Entwicklung des DWH-IS Projekt- und Lieferantenmanagement DWH-Programm- und Architekturmanagement Fachkonzeption von DWH-Applikationen und nötigen Erweiterungen der DWHIntegationsinfrastruktur Fachl. Betrieb des DWH-IS Problembehebung Datenqualitätsmanagement Referenzdatenmanagement Metadatenmanagement Fachlicher Support des DWH-IS Endbenutzeradministration Endbenutzersupport Erstellen von „Quick Solutions“ DWH-Informationssystem Erweiterung der DWH-Services

Betrieb der DWH-Services

Leistungsabnehmer Fachabteilungen Nutzung des DWH Nutzung in Führungs- und Geschäftsprozessen Standardauswertungen Sonderanalysen, durchgeführt durch speziell ausgebildete Endbenutzereinheiten Legende:

...

Komponente, betreut durch Einheit Komponente, verantwortet durch Einheit

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

3.5 Zusammenfassung Tabelle 2 fasst die Einsatzszenarien sowie die beschriebenen Herausforderungen der verschiedenen Organisationsformen zusammen. Es wird deutlich, dass die verschiedenen DWH-Leistungserbringertypen sowohl für un-

94

Mario Klesse, Moritz Schmaltz

terschiedliche Einsatzszenarien geeignet sind als auch unterschiedliche Herausforderungen angehen müssen. Tabelle 2. Einsatzszenarien und Herausforderungen für die DWH-Leistungserbringertypen DWH-FSP Einsatzszenarien Organisatori- Eigenständiger sche Dienstleister Zuordnung Erforderliche gering Nutzerkompetenz Analysemethoden Analysepro- standardisierbar zesse (fach- (sonst nicht lich Anwen- handhabbar) dung)

DWH-BSP

DWH-PP

DWH-CC

Geschäftsbereichsleitung

IT-Führung

IT-Führung

gering

hoch

hoch

standardisierbar individuell – individuell, je (benötigt genach organisato- schulte Nutzer) rischer Zuordnung mittel mittel-hoch

Vorhandene hoch DWHKompetenzen, IS-Ebene Vorhandene hoch gering mittel-hoch DWH-Kompetenzen, Plattformen Herausforderungen Nutzerunter- Aufbau und Er- Aufbau und Er- Förderung des stützung und halt fachlicher halt fachlicher End User DWHKenntnisse über Kenntnisse über Computing / Support unterstützte Pro- unterstützte Pro- Schulung der zesse und Ana- zesse und Ana- Nutzer lysemethoden lysemethoden DWHStandardisieExakte, umsetz- Verständnis der Entwicklung rung von bare Formulie- fachlichen Applikationen rung von Anfor- Anforderungen derungen für die Umsetzung, Vermeidung unkoordinierter DWH-Landschaften

individuell (benötigt geschulte Nutzer) mittel

gering

Förderung des End User Computing / Schulung der Nutzer Verständnis der fachlichen Anforderungen, Koordination der Implementierungszulieferer, Bedarfsplanung

Organisationsformen für die Informationslogistik

95

DWH-FSP DWH-BSP DWH-PP DWH-CC DWH-Betrieb Abstimmung der Abstimmung der Abstimmung der Abstimmung der Zulieferer von Zulieferer von Zulieferer von Zulieferer von extern gelager- Daten und Platt- Daten, Daten, Impleten Daten formleistungen, Datenqualität mentierungsKapazitätsund Plattformbedarfsplanung leistungen, Kapazitätsbedarfsplanung, Datenqualität DWHTechnologiema- Grundlegendes TechnologieGrundlegendes Plattformnagement, Ka- Verständnis der management, Verständnis der entwicklung / pazitätsplanung Technologien Kapazitätspla- Technologien -betrieb behalten nung behalten

4

Auswahl der geeigneten Organisationsform

Die Auswahl der geeigneten Organisationsform für die Informationslogistik hängt im Wesentlichen von der gewählten IT-Strategie und von der Organisation des Unternehmens ab. Von den in Kap. 4 dargestellten Teilstrategien für die Informationslogistik haben insbesondere die Sourcing-Strategie und die Portfoliostrategie Einfluss auf die Wahl der Organisationsform und damit den geeignetsten Leistungserbringertypen. Die in diesem Beitrag vorgestellten Organisationsformen unterscheiden sich in den Dimensionen Geschäftsnähe und Fertigungstiefe DWH-Informationssystem (vgl. Abb. 2). Dabei beeinflussen die in der Sourcing-Strategie festgelegten Sourcing-Ziele die Wahl der Organisationsform in der Dimension Fertigungstiefe: Falls eine geringe Fertigungstiefe angestrebt wird, empfehlen sich die Organisationsformen DWH Competence Center und DWH Business Service Provider, anderenfalls sind der DWH Full Service Provider bzw. der DWH Platform Provider 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 bieten sie die Möglichkeit zur Differenzierung und zur Schaffung von langfristigen Wettbewerbsvorteilen. Daher kann es sinnvoll sein, die technologische Seite der Informationslogistik nicht mehr im Unternehmen bereitzustellen, sondern von einem Outsourcing-Partner extern zu beziehen (Quinn u. Hilmer 1994).

96

Mario Klesse, Moritz Schmaltz

Analog beeinflusst die Portfolio-Strategie die Wahl der Organisationsform in der Dimension Geschäftsnähe: Falls das Produktportfolio einen großen Anteil an fachnahen analytischen Dienstleistungen wie Sonderanalysen 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 Leistungsabnehmern (d. h. in den Fachabteilungen) liegt, das DWH Competence Center bzw. der DWH Platform Provider die sinnvollste Organisationsform. 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 Verankerung der Informationslogistik auf Konzernebene im Rahmen einer zentralen IT-Funktion. Allerdings ist gerade in großen, divisionalisierten Unternehmen in der Praxis oft eine Vielzahl von lokal gewachsenen, dezentralisierten IL-Initiativen anzutreffen, deren Zentralisierung weder organisatorisch noch wirtschaftlich sinnvoll scheint. In solchen Konstellationen ist denkbar, dass mehrere der beschriebenen Leistungserbringertypen 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 erzielen, als auch eine effiziente Informationssystementwicklung und ein wirtschaftlicher fachlicher Betrieb des Data Warehouse sicherstellen (Burton et al. 2006). Diese Konstellation wird durch die Entwicklung unterstützt, dass in Anwenderunternehmen Kompetenzzentren und Infrastrukturservices in organisatorischen Einheiten gebündelt werden, die sich zunehmend spezialisieren (Weill u. Vitale 2002).

5

Zusammenfassung und Ausblick

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 Leistungserbringertypen identifiziert werden, die sich hinsichtlich ihres Involvierungsgrads 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-

Organisationsformen für die Informationslogistik

97

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 DWHAbteilung auf Basis von vorhandenen DWH-Kompetenzen und der angestrebten Unterstützung des Nutzungsprozesses vorzunehmen. Vor dem Hintergrund der zunehmenden Industrialisierung von IT-Services (Zarnekow et al. 2005) kann beispielsweise die Empfehlung ausgesprochen werden, dass im Kontext von Anwenderunternehmen neu zu etablierende DWH-Leistungserbringer bewusst mit einer geringen Fertigungstiefe aufgestellt werden. Die Existenz von zwei DWH-Leistungserbringertypen mit bereits stark reduzierter Fertigungstiefe zeigt deutlich die praktische Umsetzbarkeit einer Konstellation, bei der fachliche DWH-Kompetenzen intern im Unternehmen gebündelt werden, während standardisierbare Leistungen wie der Unterhalt einer DWH-Plattform oder die Implementierung von fachlich spezifizierten IS-Komponenten extern vergeben werden. Angebote von vorkonfigurierten DWH-Plattformen von Herstellern wie IBM, Teradata und Netezza erleichtern diesen Schritt. Auch die Implementierung von DWH-Komponenten wird bereits heute durch zahlreiche Beratungsunternehmen 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 DataWarehouse-Systeme, Universität St. Gallen, Bamberg 2003. Bauer, A.; Günzel, H.: Data Warehouse Systeme - Architektur, Entwicklung, Anwendung, 2. Aufl., dpunkt, Heidelberg 2004. 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 Darstellung zur unscharfen Klassifikation gemischter Daten, Schulz-Kirchner, Frankfurt 1986. Devlin, B.: Data Warehouse: From Architecture to Implementation, Addison Wesley, 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.

98

Mario Klesse, Moritz Schmaltz

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 Organizations: 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 Intelligence 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 Methode, 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 Warehousing, 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 Architecture, 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 Warehouse 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.

Organisationsformen für die Informationslogistik

99

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 Universität St. Gallen

1 2 3 4 5 6 7

1

Einleitung ....................................................................................... 101 Begriffliche Grundlagen ................................................................. 103 Grundannahmen der prozessorientierten Informationslogistik....... 108 Nutzeneffekte der prozessorientierten Informationslogistik........... 110 Ausgestaltung der prozessorientierten Informationslogistik .......... 112 Vorgehensmodell für die Einführung der prozessorientierten Informationslogistik ....................................................................... 119 Fazit und Ausblick .......................................................................... 123 Literatur .......................................................................................... 124

Einleitung

Es gilt heute sowohl in der Wissenschaft als auch in der Praxis als nahezu unbestritten, dass die prozessorientierte Organisation und das prozessorientierte Management signifikante Beiträge zur Steigerung der Effektivität und Effizienz unternehmerischen Handelns leisten können. Prozessorganisation 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 Mitarbeitenden eines Unternehmens eine in deutlich stärkerem Maß selbstbestimmte und verantwortungsvolle Arbeitsgestaltung ermöglichen (Gaitanides 2004). Zahlreiche Autoren stimmen darin überein, dass für die mit der

102

Tobias Bucher

Prozessausführung betrauten Mitarbeitenden eines Unternehmens zur Umsetzung der genannten Ziele während der Prozessausführung uneingeschränkte Zugriffsmöglichkeiten auf alle relevanten Informationsquellen und auf geeignete Analysewerkzeuge zur Verfügung gestellt werden müssen (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 erkennen, die Informationslogistik auf die Unterstützung ausgewählter betrieblicher Prozesse – insbesondere auch operativer Prozesse – hin auszurichten. Die heute existierenden analyseorientierten und entscheidungsunterstützenden Konzepte richten sich überwiegend an Fach- und Führungskräfte. Informationslogistik versetzt diese Personen bspw. in die Lage, sich mittels standardisierter periodischer Berichte über Finanzkennzahlen zu informieren, sich mit Hilfe verschiedener Visualisierungstechniken einen Überblick über die wichtigsten Kennzahlen zu verschaffen, große Datenbestände systematisch und hinsichtlich verschiedener Dimensionen auszuwerten oder diese gar automatisiert nach Mustern durchsuchen zu lassen. 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 gliedert: 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. Abschließend werden zwei Blickrichtungen auf die Integration von Prozessorientierung und Informationslogistik kurz dargestellt und voneinander abgegrenzt. 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, Gestaltungsfaktoren und Realisierungsformen der prozessorientierten Informationslogistik zu identifizieren. In Abschn. 6 wird ein Vorgehensmodell für die Einführung des Konzepts in der Praxis dargestellt, welches im Rahmen eines Expertenworkshops erarbeitet wurde. Abschnitt 7 fasst die wesentlichen Aussagen dieses Artikels zusammen und gibt einen Ausblick auf weitere Forschungsaktivitäten im Kontext der prozessorientierten Informationslogistik.

Prozessorientierte Organisation und Informationslogistik

2

103

Begriffliche Grundlagen

Der Darlegung des Begriffsverständnisses der Informationslogistik ist in diesem Sammelband breiter Raum gewidmet (vgl. Kap. 1). Der vorliegende Artikel verfolgt das Ziel, die Prozessorientierung der Informationslogistik zu beleuchten. Dementsprechend werden im Folgenden die begrifflichen Grundlagen zur Prozessorganisation (Abschn. 2.1) und zum Paradigma des prozessorientierten Managements (Abschn. 2.2) gelegt. Sodann 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 beschrieben, um schnell und flexibel auf Veränderungen innerhalb eines Unternehmens sowie der sozialen, ökonomischen und/oder technischen Rahmenbedingungen reagieren zu können (Osterloh u. Frost 1998; RüeggStürm 2003; Becker u. Kahn 2005; Schmelzer u. Sesselmann 2006). Gaitanides unterscheidet zwischen drei erkenntnistheoretischen Perspektiven der Prozessorganisation (Gaitanides 2004): x Praxeologische Perspektive: Ausgangspunkt der praxeologischen Perspektive der Prozessorganisation sind Aufbau- und Ablauforganisation eines Unternehmens. Während diese bei klassischer, funktionsorientierter Organisationsgestaltung eng miteinander verwoben sind und die Arbeitsabläufe in hohem Maß durch eine bereits vorgegebene Aufbauorganisation bedingt werden, hat prozessorientierte Organisationsgestaltung zum Ziel, Arbeitsabläufe zunächst unabhängig von der Aufbauorganisation 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 Aufbauorganisation“) (Gaitanides 2007). x Ö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 effizienten Abwicklung von Tauschgeschäften unter bestimmten institutionellen Arrangements und versucht zu erklären, welche Organisationsform für welche Art von Austauschbeziehungen die erwarteten Transaktionskosten minimiert (Fritz 2006). Übertragen auf die unternehmensinterne 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 dezentraler, dem Objektprinzip folgender Organisation (marktbasierte, produkt- oder kundenorientierte Differenzierung) andererseits miteinander vereint. Drei Eigenschaften von Transaktionen bestimmen deren Kosten: 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 unternehmensinternen Leistungsaustauschs (Gaitanides 2004). x Konstruktivistische Perspektive: Als konstruktivistische Perspektive der Prozessorganisation bezeichnet Gaitanides den Umstand, dass die Prozessorganisation keine „objektive Realität“ darstellt, sondern vielmehr ein „soziales Konstrukt“ (Gaitanides 2007, S. 99), welches für die Mitarbeitenden eines Unternehmens erst durch sicht- und erfahrbare Elemente wie bspw. veränderte Abläufe, veränderte Verantwortlichkeiten und Zuständigkeiten sowie zusätzliche, übergeordnete Aufgaben des Prozessmanagements verständlich und begreifbar wird: „Prozessorganisation ist in diesem Sinne nicht ein an einer Rezeptur oder einem Referenzmodell 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 Aktivitäten oder Aufgaben beschreiben, welche darauf abzielen, unter Einbeziehung von Eingangsobjekten (Inputs, Ressourcen) eine spezifische Leistung (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 funktionsorientierten 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 (Harrington 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 Gruppen wertschöpfender Prozesse unterschieden, nämlich zwischen primären

Prozessorientierte Organisation und Informationslogistik

105

Aktivitäten einerseits und unterstützenden Aktivitäten andererseits (Porter 2004). Auf dieser Unterscheidung aufbauend differenzieren bspw. Gaitanides 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; Becker u. Kahn 2005). In Erweiterung dessen unterscheidet das neue St. Galler 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ützungsprozessen im Wesentlichen den von Porter begründeten und etablierten Definitionen entspricht, werden Managementprozesse explizit als neue Kategorie 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 Umstä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 „Prozessmanagement“ 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 prozessorientierte Organisationsgestaltung, die Erneuerung oder Verbesserung bestehender Prozesse sowie gesamthaft die Gestaltung, Einführung, Lenkung und Fortentwicklung von Prozessen unter diesem Begriff subsumiert werden. 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): x 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ätsablauffolgen zur Erreichung festgelegter Ziele zu definieren, zu gestalten

106

Tobias Bucher

und zu modellieren. Besonderes Augenmerk ist in diesem Zusammenhang auch auf das Zusammenwirken aller betrieblichen Prozesse sowie auf wechselseitige Abhängigkeiten zu richten. x Phase B: „Implementierung und Ausführung von Prozessen“. Die Prozessimplementierung im Rahmen der zweiten Phase schließt die Einrichtung 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. x Phase C: „Überwachung und Steuerung von Prozessen“. Unabhängig vom Automatisierungsgrad der betrieblichen Prozesse ist eine zeitnahe Überwachung der Prozessausführung sinnvoll, um bei Planabweichungen oder Prozessfehlern unmittelbar korrigierend eingreifen zu können. Neben diesem Aspekt können die im Rahmen der dritten Phase des Prozessmanagements ermittelten Prozesskennzahlen auch zur Unterstützung unternehmerischer Entscheidungen herangezogen werden oder als Gestaltungs- und Entscheidungsgrundlage im Rahmen der kontinuierlichen Prozessverbesserung dienen. x Phase D: „Weiterentwicklung von Prozessen“. Für ein Unternehmen führt bereits das erstmalige Durchlaufen der ersten drei Phasen des Prozessmanagements zu weitreichenden Veränderungen. Gleichwohl darf die beständige Weiterentwicklung der Prozesse und der Prozesslandschaft keinesfalls vernachlässigt werden. Das Prozessmanagement muss als kontinuierlicher Ansatz begriffen werden, wobei die einzelnen Phasen in iterativen Zyklen zu durchlaufen sind. In diesem Zusammenhang sei noch einmal betont, dass die vorgenannten 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 kontinuierliche 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.

Prozessorientierte Organisation und Informationslogistik

107

Zum einen existieren zahlreiche Beiträge, die die Unterstützung der Ausführung von betrieblichen Prozessen durch die Einbettung analytischer, entscheidungsunterstützender Informationen in den Kontext der Prozessausführung adressieren. Die praktische Relevanz und die potenziellen Nutzeneffekte dieses als prozessorientierte Informationslogistik bezeichneten Konzepts wurden in zahlreichen Arbeiten aufgezeigt und beschrieben (Inmon 2000; Gile et al. 2004; Imhoff 2005; Gile et al. 2006; Bucher 2007a; Bucher u. Dinter 2008b,2008a). Prozessorientierte Informationslogistik betrifft primär die Prozessmanagement-Phase B („Implementierung und Ausführung von Prozessen“). Die Phasen A („Identifikation, Definition und Modellierung von Prozessen“) bzw. D („Weiterentwicklung von Prozessen) sind betroffen, wenn Fragestellungen der Einfü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 Prozessorientierung und Informationslogistik ebenfalls diskutiert wird (Gluchowski u. Kemper 2006; Oehler 2006). Derartige Konzepte, die in der Wissenschaft und der Praxis unter Schlagworten wie bspw. „Business Activity Monitoring“ (Adams 2002) oder „Business Performance Management“ (Dinter u. Bucher 2006) erörtert werden, sind vom Konzept der prozessorientierten 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 Prozessfehler, Störungen im Prozessablauf oder sich verändernde Rahmenbedingungen zu reagieren. Zum anderen lassen sich aus der integrierten Analyse aktueller und historisierter Prozesskennzahlen Ansatzpunkte für Maßnahmen zur Leistungssteigerung ableiten. Ebenso wie bei der prozessorientierten 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 stehen. Phase B („Implementierung und Ausführung von Prozessen“) ist hingegen nicht betroffen. Abbildung 1 zeigt die im vorangegangenen Abschnitt erläuterten Phasen des Prozessmanagements und verdeutlicht, welcher bzw. welchen der beiden vorstehend beschriebenen Blickrichtungen auf die Integration von

108

Tobias Bucher

prozessorientierter Organisation und Informationslogistik in welchen Phase Bedeutung zukommt. Phase A: Identifikation, Definition und Modellierung

9 Identifikation der kritischen Geschäftsprozesse/Kernprozesse 9 Modellierung der Prozesse unter Berücksichtigung spezifischer Charakteristika der Entwicklungssituation 9 Abstimmung, Modifikation und Verbesserung der Prozessmodelle

Phase B: Implementierung und Ausführung

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

Phase C: Überwachung und Steuerung

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

Phase D: Weiterentwicklung

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

Prozessorientierte Informationslogistik (Einführung) Überwachung und Analyse der Prozessausführung (Einführung)

Prozessorientierte Informationslogistik (Betrieb)

Überwachung und Analyse der Prozessausführung (Betrieb)

Prozessorientierte Informationslogistik (Fortentwicklung) Überwachung und Analyse der Prozessausführung (Fortentwicklung)

Abb. 1. Phasen des Prozessmanagements und Unterscheidung zweier Blickrichtungen auf die Integration von Prozessorientierung und Informationslogistik

3

Grundannahmen der prozessorientierten Informationslogistik

Dem Artikel liegt folgendes Verständnis des Begriffs der prozessorientierten Informationslogistik zugrunde: „Prozessorientierte Informationslogistik“ bezeichnet als Sammelbegriff all diejenigen Funktionalitäten zur Datenanalyse und zur Informationsbereitstellung, die in einen betrieblichen Prozess eingebettet 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-

Prozessorientierte Organisation und Informationslogistik

109

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öpfende Geschäftstätigkeit eines Unternehmens durch Informationsbereitstellung 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 entsprechend 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 Kontext in Echtzeit bzw. in Nahe-Echtzeit bereitzustellen (Watson 2005; Azvine et al. 2006; Davis 2006; Gassman et al. 2006). Ansätze zur Datenintegration in Echtzeit bzw. in Nahe-Echtzeit zielen darauf ab, die sog. Latenzzeit zwischen dem Auftreten eines Ereignisses und der Entscheidungsfindung 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, Betrugserkennung und Risikomanagement genannt (Inmon 2000). Es steht außer Frage, dass prozessorientierte Informationslogistik auf einer zentralen, integrierten Informationsschicht – der sog. Informationslogistik-Infrastruktur – aufsetzen muss. Diese Informationslogistik-Infrastruktur stellt die technische Basis für die Befriedigung der analytischen Informationsbedarfe im Rahmen der Prozessausführung dar. Eine ausführliche Darstellung und Diskussion verschiedener Systemarchitekturen für die Informationslogistik findet sich in Kap. 7. Wie im einleitenden Kapitel bemerkt, kann durch die systematische, bereichsübergreifende Zusammenführung und Nutzung von Informationen nachhaltig Mehrwert in einem Unternehmen geschaffen werden. Da bei der prozessorientierten Informationslogistik die Unterstützung von Entscheidungen 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 entscheidungsrelevanter Informationen sofort nach ihrer Entstehung von zentraler 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 Informationsbasis, 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 Entscheidungsdatenbank kann ihrerseits wiederum Teil der integrierten Informationsschicht sein, die die Grundlage für prozessorientierte Informationslogistik darstellt.

4

Nutzeneffekte der prozessorientierten Informationslogistik

Durch die Unterstützung der Ausführung operativer Prozesse mit Hilfe einer integrierten Bereitstellung entscheidungsrelevanter Informationen lassen sich sowohl unternehmensinterne als auch unternehmensexterne Nutzeneffekte 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 Prozessleistung sowie Effizienzgewinne in der Ressourcennutzung. Unternehmensexterne Nutzeneffekte umfassen z. B. die Steigerung der Kundenzufriedenheit 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 positive Abhängigkeiten zwischen den latenten Variablen „prozessorientierte Informationslogistik“, „unternehmensinterne Nutzeneffekte“ und „unternehmensexterne Nutzeneffekte“ zu prüfen. Die latenten Variablen sind nicht direkt beobachtbar, sondern müssen über Messmodelle erhoben wer1

Die Stichprobe umfasst 43 mittelständische und große Unternehmen aus verschiedenen Branchen. Die Befragung wurde im Dezember 2006 im Rahmen des 21. St. Galler Anwenderforums durchgeführt. An dieser Konferenz nahmen etwa 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.

Prozessorientierte Organisation und Informationslogistik

111

den. Das Messmodell der latenten Variable „prozessorientierte Informationslogistik“ wird durch die vier Indikatorvariablen „Verfügbarkeit analytischer Informationen zum Zeitpunkt der Prozessausführung“, „Zusammenfallen 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 beiden latenten Variablen „unternehmensinterne Nutzeneffekte“ und „unternehmensexterne Nutzeneffekte“ werden durch die eingangs in diesem Abschnitt genannten Indikatorvariablen determiniert. Abbildung 2 zeigt das beschriebene Kausalmodell zur Erklärung der Nutzeneffekte der prozessorientierten Informationslogistik. Die Analyse des Kausalmodells zeigt, dass alle durch gerichtete Pfeile dargestellten Kausalbeziehungen zwischen den Variablen positive Pfadkoeffzienten 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 innerhalb als auch außerhalb des Unternehmens ihre Wirkung entfalten. Außerdem werden die unternehmensexternen Nutzeneffekte der prozessorientierten Informationslogistik durch die innerhalb des Unternehmens auftretenden 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 „unternehmensinterne Nutzeneffekte“ sowie „unternehmensexterne Nutzeneffekte“ sind bei einem Signifikanzniveau von Į = 0,05 signifikant. Alle anderen Pfadkoeffizienten sind sogar bei einem Niveau von Į = 0,01 signifikant. Die erklärten Varianzanteile betragen 16,9% für die latente Variable „unternehmensinterne 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

į1

Tobias Bucher Verfügbarkeit analytischer Informationen zum Zeitpunkt der Prozessausführung 0.30

0.55

0.40

Hohe Priorität des Themas bei der Unternehmensleitung

į3

0.63

0.62

0.81

0.38

ȗ1

Hohe Priorität des Themas bei der Unternehmens-IT

Unternehmensinterne Nutzeneffekte

İ2

Unternehmensexterne Nutzeneffekte

0.53

ȗ2

0.72

Reduktion von Durchlaufzeiten

0.87

0.85

0.75

Qualitative Verbesserung der Prozessleistung

0.92

Effizienzgewinne in der Ressourcennutzung

0.66 0.43

Steigerung der Kundenzufriedenheit

İ4

Steigerung der Kundenprofitabilität

İ5

Verbesserung der Leistungen für externe Prozesskunden

İ6

0.72

0.89

0.85

İ3

į4

0.48

0.17

İ1

į2

0.65

Prozessorientierte Informationslogistik

0.41

Zusammenfallen von Prozessausführung und Informationszugriff

0.79

0.76

0.59

Abb. 2. Kausalmodell zur Erklärung der Nutzeneffekte prozessorientierter Informationslogistik (Bucher u. Dinter 2008b)

5

Ausgestaltung der prozessorientierten Informationslogistik

Die prozessorientierte Informationslogistik stellt ein vergleichsweise breites Themenfeld dar. Dementsprechend steht zu vermuten, dass verschiedene Unternehmen sich dem Thema mit unterschiedlichen Herangehensweisen und Zielstellungen nähern. Im Folgenden soll ein Überblick über die die unternehmensindividuelle Ausgestaltung der prozessorientierten Informationslogistik hauptsächlich beeinflussenden Faktoren gegeben werden (Abschn. 5.1). Die aus diesen Faktoren resultierenden Realisierungsvarianten der prozessorientierten Informationslogistik werden in Abschn. 5.2 dargestellt. Die Ergebnisse entstammen einer explorativen

Prozessorientierte Organisation und Informationslogistik

113

statistischen Analyse (vgl. Bucher u. Dinter 2008b) und werden im vorliegenden Artikel in verkürzter Form präsentiert.3 5.1 Gestaltungsfaktoren Im Kontext einer explorativen Analyse haben Bucher/Dinter vier Gestaltungsfaktoren der prozessorientierten Informationslogistik identifiziert (Bucher u. Dinter 2008b).4 Diese Gestaltungsfaktoren fassen einzelne Gestaltungselemente (im Folgenden als „Variable“ bezeichnet) zusammen, die die Ausgestaltung der prozessorientierten Informationslogistik in einem Unternehmen beschreiben. Mit Hilfe der vier nachfolgend dargestellten Gestaltungsfaktoren ist es deshalb möglich, die Herangehensweise bzw. den Entwicklungsstand eines Unternehmens in Bezug auf das Themenfeld der prozessorientierten Informationslogistik auf stark verdichtetem Niveau zu charakterisieren: x Gestaltungsfaktor 1: „Entwicklungsstand der Informationsversorgung“. Der erste Faktor wird durch sieben Variablen gebildet, deren gemeinsame Grundlage in Fragestellungen der Qualität und Reife der Informationsversorgung 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 dementsprechend primär technische Fragestellungen zusammen. Der Entwicklungsstand der Informationsversorgung in einem Unternehmen ist als umso höher zu bezeichnen, je größer der durchschnittliche Zielerreichungsbzw. Erfüllungsgrad der sieben Variablen ebendieses Gestaltungsfaktors ist.

3

4

Der der explorativen Analyse zugrunde liegende Datensatz entspricht dem in Abschn. 4 beschriebenen Datensatz. Zusätzliche Informationen zur Charakterisierung der Stichprobe finden sich in (Bucher u. Dinter 2008b). Zum Zweck der Extraktion von Gestaltungsfaktoren wurde eine Faktorenanalyse (Hauptkomponentenanalyse) durchgeführt. Aus 14 Variablen wurden vier Faktoren extrahiert (Kaiser-Kriterium, Eigenwerte größer eins). Das KaiserMeyer-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 Zusammenfassung der verwendeten Methodik findet sich bspw. bei Backhaus et al. (Backhaus 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ührung 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 entstehen bei der Informationsinterpretation/Maßnahmenumsetzung. Variable 1.3 Die bereitgestellten Informationen weisen eine für die Unterstützung 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 Informationen 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.

x Gestaltungsfaktor 2: „Integrationsgrad analytischer Informationen in Prozesse“. Der zweite Faktor wird durch drei Variablen gebildet, die im Wesentlichen den Integrationsgrad von Prozessausführung und Informationsbereitstellung 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 Informationsbereitstellung umso höher, je größer der durchschnittliche Zielerreichungsbzw. Erfüllungsgrad der drei vorherrschenden Variablen dieses Gestaltungsfaktors ist. Insbesondere die Variable 2.2, der zufolge der Integrationsgrad zunimmt, wenn Prozessabläufe in Abhängigkeit von analytischen Informationen angepasst werden können, stellt ein charakterisierendes Merkmal der prozessorientierten Informationslogistik dar.

Prozessorientierte Organisation und Informationslogistik

115

Tabelle 2. Variablen des zweiten Gestaltungsfaktors Gestaltungsfaktor 2: „Integrationsgrad analytischer Informationen in Prozesse“ Variable 2.1 Analytische Informationen werden zeitlich synchron zur Prozessausführung bereitgestellt sowie in den Prozesskontext/Workflow eingebettet präsentiert. Variable 2.2 Die Ablauffolge der Aktivitäten eines Prozesses wird in Abhängigkeit von analytischen Informationen, die im Prozesskontext zur Verfügung gestellt werden, einzelfallbasiert verändert/angepasst. Variable 2.3 Analytische Informationen werden von einem dedizierten Analystenteam aufbereitet und vorselektiert. Nur derart aufbereitete Informationen werden im Prozesskontext bereitgestellt.

x 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 einfacher Instrumente zum Zweck der Datenanalyse und der Informationsbereitstellung. Hierzu zählt insbesondere die Verwendung von standardisieren Berichten, die entweder über eigenständige Reporting-Applikationen oder eingebunden in die Benutzeroberfläche des für die Prozessausführung verwendeten Anwendungssystems bereitgestellt werden. Der Einsatz- bzw. Nutzungsgrad ist umso höher, je größer der durchschnittliche 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.

x Gestaltungsfaktor 4: „Einsatz-/Nutzungsgrad erweiterter Instrumente für die Datenanalyse und die Informationsbereitstellung“. Der vierte Gestaltungsfaktor wird ebenfalls durch zwei Variablen begründet, die ihrerseits den Einsatz- bzw. Nutzungsgrad erweiterter Instrumente zum Zweck der Datenanalyse und der Informationsbereitstellung widerspiegeln (vgl. Tabelle 4). Zu diesen Instrumenten zählen sowohl Ad-hoc-

116

Tobias Bucher

Abfragen als auch der Gebrauch von Anwendungssystemen, die benutzerdefinierte, mathematisch-statistische Analyse- und Simulationsmöglichkeiten bereitstellen. Wie auch bei den anderen Gestaltungsfaktoren ist der Einsatz- bzw. Nutzungsgrad umso höher, je größer der durchschnittliche 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 Prozesskontext 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 Informationsbereitstellung. Verschiedene Autoren betonen, dass die erwähnten einfachen und erweiterten Instrumente ein Kontinuum von Analyse- und Präsentationstechniken darstellen (Chamoni u. Gluchowski 2004; Jones 2004). Unternehmen können dementsprechend sowohl bezüglich 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 Gestaltungsfaktoren haben Bucher/Dinter darüber hinaus – ebenfalls im Kontext der bereits genannten explorativen Analyse – vier disjunkte Realisierungsformen der prozessorientierten Informationslogistik ermittelt (Bucher u. Dinter 2008b).5 Diese Realisierungsformen ergeben sich aus wiederkeh5

Für die Identifikation der Realisierungsformen wurde eine hierarchische Clusteranalyse auf Grundlage der mittels der Regressionsmethode berechneten Faktorenwerte der vier Gestaltungsfaktoren durchgeführt. Für die Fusionierung der Cluster wurde der Ward-Algorithmus verwendet, als Distanzmaß kam die quadrierte Euklidische Distanz zum Einsatz. Das Dendrogramm, das den Fusionierungsalgorithmus graphisch darstellt, legt die Bildung von fünf Clustern als mutmaßlich optimale Lösung des Clustering-Problems nahe. Der fünfte Cluster

Prozessorientierte Organisation und Informationslogistik

117

renden Mustern in den Gestaltungsfaktoren, die bei den in die Untersuchung einbezogenen Unternehmen zu beobachten sind. Die Unterschiede zwischen den vier Realisierungsformen bestehen primär hinsichtlich der Ausprägungen der beiden Gestaltungsfaktoren 1 und 2 („Entwicklungsstand der Informationsversorgung“ und „Integrationsgrad analytischer Informationen 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“): x Realisierungsform 1: „Ausgereifte prozessorientierte Informationslogistik“. Die erste Realisierungsform weist sowohl hinsichtlich des Entwicklungsstands 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 Informationsbereitstellung zum Einsatz kommen. Diese Realisierungsform weist folglich einen hohen Reifegrad der prozessorientierten Informationslogistik auf. Sowohl informationstechnische Fragestellungen im Zusammenhang mit der Datenaufbereitung und der Informationsbereitstellung als auch fachlich-organisatorische Probleme der Integration von analytischen Informationen in den Kontext der Prozessausführung sind in dieser Realisierungsform betrachtet und gelöst worden. x Realisierungsform 2: „Informationstechnisch getriebener Ansatz zur Etablierung der prozessorientierten Informationslogistik“. Die zweite Realisierungsform ist durch hohe Werte bezüglich des Entwicklungsstands der Informationsversorgung einerseits und niedrige Werte bezü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 getriebenen Ansatzes werden fachlich-organisatorische Fragestellungen der Einbettung analytischer Informationen in Prozesse nur mit untergeordneter Priorität adressiert. Dementsprechend weist diese Realisierungsumfasst nur zwei Unternehmen, wobei diese beiden Beobachtungen als Ausreißer zu charakterisieren sind. Dementsprechend werden in diesem Artikel nur vier Realisierungsformen der prozessorientierten Informationslogistik unterschieden. 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 Informationslogistik auf. x Realisierungsform 3: „Fachlich-organisatorisch getriebener Ansatz zur Etablierung der prozessorientierten Informationslogistik unter Berücksichtigung einfacher Instrumente für Datenanalyse und Informationsbereitstellung“. 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 Informationen in Prozesse und niedrige Werte bezüglich des Entwicklungsstands der Informationsversorgung auf. Damit kann auch diesen beiden Gestaltungsfaktoren eine mittlere Reife der prozessorientierten Informationslogistik attestiert werden, wobei der Fokus auf der Betrachtung fachlich-organisatorischer Fragestellungen liegt. Informationstechnische Belange werden erst in zweiter Linie adressiert. Zusätzlich unterscheiden sich die beiden Realisierungsformen 3 und 4 hinsichtlich ihrer Herangehensweisen bezüglich der Datenanalyse und der Informationsbereitstellung. Unternehmen, die gemäß der explorativen Untersuchung der dritten Realisierungsform zuzurechnen sind, setzten hierfür sowohl einfache wie auch erweiterte Instrumente ein. x Realisierungsform 4: „Fachlich-organisatorisch getriebener Ansatz zur Etablierung der prozessorientierten Informationslogistik unter Berücksichtigung erweiterter Instrumente für Datenanalyse und Informationsbereitstellung“. Im Unterschied zur dritten Realisierungsform setzen Unternehmen, die dieser vierten Realisierungsform zuzurechnen sind, ausschließlich erweiterte Instrumente für Datenanalyse und Informationsbereitstellung ein, d. h. Ad-hoc-Abfragen sowie mathematisch-statistische Analysen und Simulationsmöglichkeiten. Abgesehen von diesem Unterschied entsprechen sich die Charakterisierungen der dritten und der vierten Realisierungsform der prozessorientierten Informationslogistik. Aus den Ergebnissen der explorativen Untersuchung lässt sich die Hypothese ableiten, dass zumindest zwei unterschiedliche Entwicklungspfade bestehen, auf welchen Unternehmen eine hohe Reife der prozessorientierten 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 Entwicklungsstand der Informationsversorgung zu erreichen. In fachlich-organisatorischer 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-

Prozessorientierte Organisation und Informationslogistik

119

Hoch

Realisierungsform 2

Niedrig

Entwicklungsstand der Informationsversorgung

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 Realisierungsformen 3 und 4 repräsentieren hingegen die fachlich-organisatorisch getriebene Herangehensweise. Ob ein Unternehmen in einem einzigen Schritt von einem geringen zu einem hohen Reifegrad der prozessorientierten Informationslogistik gelangen kann, d. h. beide Handlungsfelder 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 Informationslogistik. Realisierungsform 1

Mittlere Reife

Hohe Reife

der prozessorientierten Informationslogistik

der prozessorientierten Informationslogistik

Geringe Reife der prozessorientierten Informationslogistik

Mittlere Reife der prozessorientierten Informationslogistik Realisierungsform 3

Niedrig

Realisierungsform 4

Hoch

Integrationsgrad analytischer Informationen in Prozesse

Abb. 3. Realisierungsformen, Reifegrade und Entwicklungslinien der prozessorientierten 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, Energieversorgung und Maschinenbau teilnahmen, wurde ein Vorgehensmodell zur Einführung der prozessorientierten Informationslogistik erarbeitet. Als Grundlage für die gemeinsame Arbeit wurden die beteiligten Experten in das in

120

Tobias Bucher

diesem Artikel skizzierte Verständnis der prozessorientierten Informationslogistik, deren Anwendungsfälle und Nutzenpotenziale sowie Gestaltungsfaktoren und Realisierungsformen eingeführt. Weiterhin lag ein Aktivitä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 sowie 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 Informationslogistik (Bucher 2007b)

Im Folgenden werden die einzelnen Phasen des Vorgehensmodells diskutiert (Bucher 2007b): x Phase I: „Projektinitialisierung“. Die erste Phase umfasst die beiden Aktivitäten A01 („Business Case erstellen“) und A02 („Projektteam aufsetzen“). 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-kulturellen Voraussetzungen für die Einführung der prozessorientierten Informationslogistik im Unternehmen bereits geschaffen sind, indem die Relevanz des Themas aufgezeigt, Nutzenpotenziale kommuniziert und Unterstützung für das Projekt mobilisiert wurden.

Prozessorientierte Organisation und Informationslogistik

121

x Phase II: „Ist-Analyse Informationsversorgung“. Die zweite Phase umfasst lediglich die Aktivität A03 („Ist-Zustand der Informationsversorgung bestimmen“). Diese Aktivität kann nebenläufig zu den Phasen III, IV und V („Ist-Analyse Prozesse“, „Soll-Entwurf Prozesse“ und „SollEntwurf Informationsversorgung“) durchgeführt werden und umfasst die Aufnahme und Analyse des derzeitigen Zustands der Informationsversorgung. Die Ergebnisse der Analyse werden in Form einer Informationslandkarte dokumentiert, welche wiederum einen wesentlichen Input für die Phase VI („Konsolidierung“) darstellt. x Phase III: „Ist-Analyse Prozesse“. Die dritte Phase umfasst die beiden Aktivitäten A04 („Ist-Prozesslandschaft analysieren“) und A05 („Prozesse identifizieren“). Zunächst werden die bestehenden Prozesse und deren wechselseitige Abhängigkeiten untersucht sowie dokumentiert. Die Prozesslandkarte des Unternehmens bzw. des untersuchten Unternehmens-/Geschäftsbereichs stellt einen wesentlichen Output der ersten Aktivität dieser Phase dar. Darauf aufbauend sind in einem Bewertungsund Priorisierungsschritt diejenigen Prozesse auszuwählen, die im weiteren Projektverlauf mit dem Ziel umgestaltet werden sollen, prozessinhärente operative Entscheidungen durch eine integrierte Bereitstellung relevanter analytischer Informationen zu unterstützen. x Phase IV: „Soll-Entwurf Prozesse“. Die vierte Phase umfasst die zwei Aktivitäten A06 („Prozesse und Rahmenbedingungen verstehen / analysieren“) und A07 („Prozessvision entwickeln“). Ziel der Aktivitäten dieser 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 Prozessabläufe mit ein. x Phase V: „Soll-Entwurf Informationsversorgung“. Die fünfte Phase umfasst die drei Aktivitäten A08 („Informationsbedarf ermitteln“), A09 („Informationen homogenisieren und abstimmen“) sowie A10 („Quellsysteme bestimmen / analysieren“). Aufbauend auf der in der vorangehenden Phase entwickelten Prozessvision sind sodann diejenigen Informationen zu identifizieren, die für die Entscheidungsunterstützung im Rahmen der Prozessausführung wesentlich sind. Weiterhin sind Berechnungs-, Darstellungs- und Entscheidungsregeln zu definieren, Terminologien zu harmonisieren, die Informationsbedarfe in fachlicher wie technischer Hinsicht abzustimmen sowie die zugrunde liegenden Quelldaten und Quellsysteme festzulegen.

122

Tobias Bucher

x Phase VI: „Konsolidierung“. Die sechste Phase umfasst ausschließlich die Aktivität A11. Diese Aktivität führt die beiden nebenläufigen Aktivitätsablauffolgen „Ist-Analyse Informationsversorgung“ (Phase II) sowie „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 (Informationslandkarte, Prozesslandkarte, Prozessentwürfe sowie Spezifikationen der Informationsbedarfe für die prozessinhärente Entscheidungsunterstützung) als Input für die anschließende Veränderungsphase konsolidiert. x 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 Voraussetzungen für Informationsversorgung schaffen“) und A15 („Umgestaltete Prozesse implementieren“). Aufbauend auf den konsolidierten Ergebnissen 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 Prozessgestaltung bestimmt werden kann (d. h. sofern unter den betroffenen Stakeholdern keine Einigung über die Prozessgestaltung und die informatorische Unterstützung erzielt werden kann), sind die Anforderungen bzw. Rahmenbedingungen entsprechend anzupassen bzw. neu zu formulieren. Anschließend ist die Aktivitätenfolge A07 bis A12 abermals zu durchlaufen. Auf Grundlage eines definitiven Zielszenarios sind sodann die Soll-Prozesse und die erforderliche Soll-Informationsversorgung (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 Informationslogistik deckt somit Fragestellungen aus den Bereichen der Identifikation, Definition und Modellierung von Prozessen (Prozessmanagement-Phase A, vgl. Abschn. 2.2) sowie der Implementierung und Ausführung von Prozessen (Prozessmanagement-Phase B) ab. Bei wiederholter Anwendung werden implizit auch Aspekte der Weiterentwicklung von Prozessen (Prozessmanagement-Phase D) adressiert. Fragestellungen im Zusammenhang mit der Überwachung und Steuerung von Prozessen (Prozessmanagement-Phase C) werden hingegen nicht thematisiert.

Prozessorientierte Organisation und Informationslogistik

7

123

Fazit und Ausblick

Im diesem Artikel wurden mit der prozessorientierten Informationslogistik einerseits und der Überwachung und Analyse der Prozessausführung andererseits zwei unterschiedliche Blickrichtungen auf die Integration von Prozessorganisation und Informationslogistik aufgezeigt sowie anhand der jeweils betroffenen Phasen des Prozessmanagements voneinander abgegrenzt. Prozessorientierte Informationslogistik adressiert die Unterstützung der Ausführung von betrieblichen Prozessen durch die Einbettung analytischer, 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 dieses Artikels ausgeschlossen. Im weiteren Verlauf des Artikels wurden sodann die Grundannahmen, die potenziellen Nutzeneffekte, die in der unternehmerischen Praxis beobachtbare Ausgestaltung der prozessorientierten Informationslogistik sowie ein mögliches Vorgehensmodell für die Einführung des Konzepts dargestellt. Aus den aktuellen wissenschaftlichen Veröffentlichungen zum Themenfeld der prozessorientierten Informationslogistik sowie aus Rückmeldungen und Interessensbekundungen seitens der Praxis wird deutlich, dass das Themenfeld derzeit noch hohes Forschungs- und Entwicklungspotenzial aufweist. Der vorliegende Artikel stellt eine Zusammenfassung verschiedener 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 Unternehmen 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 integrierte 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, welche 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 Management 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 Analysemethoden - 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 Organisationsgestaltung, Springer, Berlin 2005, S. 3-16. Bruckner, R.; List, B.; Schiefer, J.: Striving Toward Near Real-Time Data Integration 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 Arbeitsbericht, 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 Wirtschaftsinformatik, 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 Wirtschaftsinformatik 2008 (MKWI 2008), 2008a. Bucher, T.; Dinter, B.: Process Orientation of Information Logistics - An Empirical Analysis to Assess Benefits, Design Factors, and Realization Approaches, in: IEEE Computer Society (Hrsg.): Proceedings of the 41th Hawaii International Conference on System Sciences (HICSS-41), 2008b. Bucher, T.; Winter, R.: Classification of Business Process Management Approaches - An Exploratory Analysis, in: BIT - Banking and Information Technology 7 (2006) 3, S. 9-20.

Prozessorientierte Organisation und Informationslogistik

125

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ätsverlag Karlsruhe, Karlsruhe 2007, S. 695-712. Byrne, B.: Structural Equation Modeling with AMOS – Basic Concepts, Applications, and Programming, Lawrence Erlbaum Associates, Mahwah 2001. Chamoni, P.; Gluchowski, P.: Integrationstrends bei Business-IntelligenceSystemen - Empirische Untersuchung auf Basis des Business Intelligence Maturity 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 Management, 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.; Gluchowski P. (Hrsg.): Analytische Informationssysteme - Business IntelligenceTechnologien und -Anwendungen, Springer, Berlin et al. 2006, S. 23-50. Ericson, J.: Process or Data-Centric, http://www.bireview.com/bnews/26003061.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ünchen 2007. Gassman, B.: Management Update - BAM Enhances Operationally Focused Business Intelligence, Research Report ID G00121953, Gartner, Stamford 2004. Gassman, B.; Schlegel, K.; Beyer, M.: Survey Shows BI Users Want Fresher Data, 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: BISpektrum 1 (2006) 1, S. 12-19. Hammer, M.: The Agenda - What Every Business Must Do to Dominate the Decade, Crown Business, New York 2001.

126

Tobias Bucher

Hammer, M.; Champy, J.: Reengineering the Corporation - A Manifest for Business 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 Intelligence 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 Warehouse 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 Society (Hrsg.): Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS-40), IEEE Computer Society, Los Alamitos 2007. Oehler, K.: Corporate Performance Management mit Business Intelligence Werkzeugen, Hanser, München 2006. Osterloh, M.; Frost, J.: Prozessmanagement als Kernkompetenz, Gabler, Wiesbaden 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 Performance, Free Press, New York 2004. Rüegg-Stürm, J.: Das neue St. Galler Management-Modell - Grundkategorien einer 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ünchen 2006. Watson, H.: Real Time - The Next Generation of Decision-Support Data Management, 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.

Prozessorientierte Organisation und Informationslogistik

127

Williamson, O.: The Economics of Organization - The Transaction Cost Approach, 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  2  3  4  5 

Einleitung ....................................................................................... 129  Anforderungsrahmen und Einflussfaktoren .................................... 130  Architekturtypen der Informationslogistik ..................................... 138  Bewertung von Systemarchitekturen .............................................. 148  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 Betrachtungseinheit hinausgehen, sowie der Speicherung und Aufbereitung dieser Daten“ (vgl. Kap. 1). Kernpunkt unseres Verständnisses der IL ist die Betrachtung von übergreifenden Datenflüssen zur analytischen Nutzung dieser Daten. Das Ziel der Informationslogistik ist also die Bereitstellung relevanter Informationen in geeigneter Qualität zur effektiven und effizienten Befriedigung von Informationsbedarfen, die im Rahmen der unternehmerischen Entscheidungsfindung entstehen. Als technische Basis für die Befriedigung der analytischen Informationsbedarfe dienen hierbei Systeme 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 Informationssysteme aus dem Data Warehouse (DWH)-Umfeld sowie deren Architekturen, die sich allgemein als Anordnung von Komponenten, deren Beziehungen zueinander sowie deren Gestaltungsregeln definieren (IEEE 2000),

130

Gerrit Lahrmann, Florian Stroh

untersucht und hinsichtlich ihrer Eignung in der Informationslogistik bewertet. Dieser Beitrag ist wie folgt aufgebaut: In Abschn. 2 werden Anforderungen und Einflussfaktoren hinsichtlich der Auswahl von Systemarchitekturen der Informationslogistik vorgestellt. Abschn. 3 beschreibt relevante 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 detailliert betrachtet. Zentrale Bereiche im Kontext einer Untersuchung relevanter Systemarchitekturen 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 Literatur zumeist als mehrdimensionales Konzept betrachtet (Wand u. Wang 1996). Themen wie Aktualität, Vollständigkeit, Konsistenz oder Transparenz 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 Systemarchitektur selbst, deren unterschiedliche Erfüllungsgrade wiederum Auswirkungen 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 Sicherheit 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 (Ariyachandra u. Watson 2005; Jung 2006; Wilhelmi 2006) In diesem Buch Ariyachandra u. verwendeter Watson 2005 Begriff Strategische Strategische AusrichBedeutung tung, Wichtigkeit Ressourcen Ressourcenbeschränkungen Auswertung Umfang nicht routianalytischer nierter Datenanalysen Daten Horizontale Kooperation zwischen Informationsin- Organisationseinheiten tegration Vertikale Informationsintegration Verwendungsform

Jung 2006 Relevanz -/-

Wilhelmi 2006 -/Budgetumfang

Periodizität

Auswertungssysteme

Horizontale Informationsintegration

Bedürfnis nach Geschäftsbereich übergreifenden Auswertungen Managementunterstützung

-/-

Granularität

-/-

Verwendungsform (create, read, update, delete)

-/-

In der Literatur zur Informationslogistik werden (zusätzlich zu den bereits vorgestellten Anforderungen) noch weitere Einflussfaktoren auf eine Architekturauswahl genannt (Ariyachandra u. Watson 2005; Jung 2006; Wilhelmi 2006). Deshalb wurde der Anforderungsrahmen um weitere Aspekte ergänzt, die zwar nicht zwingend als klassische Anforderungen zu sehen sind (wie z. B. „Verwendungsform“), dennoch aber erheblichen Einfluss auf die Architekturwahl haben können. Da die o. g. Autoren teilweise unterschiedliche Begrifflichkeiten benutzen, findet in Tabelle 1 ein terminologischer Abgleich statt. Die dort abgeleiteten Begriffe werden im Weiteren 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 einer Architekturbewertung in Abschn. 4 hergestellt.

132

Gerrit Lahrmann, Florian Stroh

Systemqualität

Datenqualität „

Aktualität

„

Performanz

„

Vollständigkeit

„

Flexibilität

„

Konsistenz

„

Verfügbarkeit

„

Transparenz

„

Sicherheit

Weitere Einflussfaktoren „

Strategische Bedeutung

„

Horizontale Informationsintegration

„

Ressourcen

„

Vertikale Informationsintegration

„

Verwendungsform

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 Datenqualitä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 Datenaktualisierungsintervalle im Data Warehouse sind z. B. die monatliche, tägliche oder stündliche Aktualisierung. Die zur Verfügung gestellten analytischen Informationen können jedoch niemals aktueller als die operative Datenbezugsbasis sein. „Real-Time Business Intelligence“ bietet die gleichen Funktionalitäten wie herkömmliche Business Intelligence, der Datenbezug erfolgt jedoch aus den operativen Systemen ohne zeitliche Verzögerung (Azvine et al. 2005). Die Forderungen nach „Real-Time Analytics“ oder auch „Real-Time Business Intelligence“ sind dabei bei weitem nicht

Informationslogistik-Systemarchitekturen

133

neu (Brobst u. Venkatesa 1999), jedoch immer noch aktuell (Bitterer et al. 2007). Betriebswirtschaftlich macht die Forderung nach der kostenintensiven Bereitstellung von Real-Time Business Intelligence nur dann Sinn, wenn auch die Entscheidungen, die auf den in Echtzeit bereitgestellten 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 Sachverhalt 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 verstanden, alle relevanten Zustände und Entitäten innerhalb eines Informationssystems abzubilden (Wand u. Wang 1996; Bauer u. Günzel 2004, S. 44). Dies setzt voraus, dass Daten nicht mehr nur einzeln, sondern - zur besseren Interpretierbarkeit - als Kombinationen betrachtet werden. Genauso kann bspw. die Datenbereitstellung aus sämtlichen Unternehmensbereichen 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 Zeitreihenanalysen ü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 Konsistenz der Repräsentation der Daten sowie der Konsistenz der physischen Repräsentation der Daten (Wand u. Wang 1996) unterschieden. Die Konsistenz der Datenwerte findet jedoch in der Literatur mit die höchste Beachtung (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, logische 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 einheitlichen Stammdaten (u. a. Kundendaten als gemeinsame Datenbasis für das gesamte Unternehmen).

134 2.1.4

Gerrit Lahrmann, Florian Stroh Transparenz

Die Transparenz der durch die analytischen Systeme zur Verfügung gestellten Daten ist eine weitere Dimension der Datenqualität. Die Transparenz beinhaltet die intrinsischen Qualitätsmerkmale Glaubwürdigkeit und Reputation (vgl. Pipino et al. 2002, S. 214). Die Glaubwürdigkeit ist Gegenstand einer subjektiven Einschätzung durch die Fachanwender und wird direkt durch die Reputation, eine aus Erfahrung resultierende Einflussgröße, beeinflusst (Jung 2006, S. 115). In analytischen Informationssystemen werden Daten oftmals hochverdichtet betrachtet, so dass die ursprünglichen Datenquellen nicht mehr direkt erkennbar sind. Der Fachanwender benötigt also noch weitere Daten, um den Ursprung eines Datensatzes sowie seine Zusammensetzung zurückverfolgen und damit die Glaubwürdigkeit der Daten beurteilen zu können. Diese zusätzlichen Daten 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 Systemqualität zuordnen lassen, diskutiert. 2.2.1

Performanz

Unter dem Stichwort Performanz werden fachliche Anforderungen zusammengefasst, die die Antwortzeit auf Informationsanfragen von Endanwendern 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 gesamten 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änderung des Nutzungsverhaltens der analytischen Systeme gewährleisten zu können, muss eine Systemarchitektur skalierbar ausgelegt sein. Dies bedeutet 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-

Informationslogistik-Systemarchitekturen

135

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 gesamtheitlichen Betrachtung der Datenflüsse (vgl. Kap. 1) erfordert, dass sämtliche verfügbaren Datenquellen als Teil einer Systemarchitektur der Informationslogistik 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 werden und zwischen diesen vermitteln (Schelp 2006, S. 432). Generell wird eine möglichst geringe Anzahl von Systemschnittstellen als hilfreich angesehen, um die Wartbarkeit eines Systems zu verbessern und damit die Flexibilitä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 Intelligence 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 beispielsweise Schätzungen, dass 70 Prozent aller Unternehmen bis 2010 mit einem Ausfall eines operativen Systems zu rechnen haben, der auf ein analytisches System zurückzuführen ist und womöglich eine Unterbrechung eines operativen Prozesses zur Folge hat (Beyer et al. 2007). Derartige Annahmen beschleunigen Bemühungen, entsprechende Managementmechanismen, 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).

136 2.2.4

Gerrit Lahrmann, Florian Stroh 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 Vertraulichkeit, 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 Organisationen Zugriff gewährt, die dafür berechtigt sind. Nur wenn auf Grund der Aufgaben eines Fachanwenders ein bestimmter Informationsbedarf besteht, 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 erfolgen 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 Einflussfaktoren ergänzen die in den vorhergehenden Abschnitten beschriebenen Anforderungen an die Daten- und Systemqualität. 2.3.1

Strategische Bedeutung

Die Frage nach der strategischen Bedeutung eines Systems zur Informationslogistik im Unternehmen ist nicht als klassische Anforderung zu verstehen, 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 Unterstützung des Managements, das die Notwendigkeit einer unternehmensweiten Informationslogistik erkannt hat oder der Integrationsgrad der Informationsversorgung in die Geschäftsprozesse (vgl. Kap. 6) beeinflussen 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-

Informationslogistik-Systemarchitekturen

137

zyklus eines Systems zur Umsetzung einer Informationslogistik im Unternehmen kann in die vier Phasen Erstentwicklung, Wartung, Betrieb sowie Außerbetriebnahme unterteilt werden (Herrmann 2006). Auch in (Ariyachandra u. Watson 2005) wird bei der Betrachtung ausgewählter Architekturtypen von einer Einteilung in unterschiedlichen Phasen ausgegangen. Ferner bestehen zwischen den Architekturtypen z. T. erhebliche Unterschiede 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 Festlegung auf den Architekturtyp spielen. 2.3.3

Horizontale Informationsintegration

Aus dem Anspruch der Informationslogistik, Informationen bereichsübergreifend zur Verfügung zu stellen, resultiert die Anforderung nach horizontal und vertikal durchgängiger Befriedigung von Informationsbedarfen (vgl. Picot et al. 2001, S. 181). Einen horizontal durchgängigen Informationsfluss stellt z. B. der Informationsaustausch entlang der Wertschöpfungskette zwischen der Einkaufs- und der Produktionsabteilung innerhalb eines Unternehmens dar (Jung 2006, S. 30). Neben dem Informationsaustausch unternehmensinterner Betrachtungseinheiten findet hierbei ebenfalls die Kommunikation mit unternehmensexternen Einheiten Beachtung. 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 Informationsaustauschs zwischen strategischer, taktischer und operativer Ebene innerhalb eines Unternehmens oder einer Konzernstruktur (Gorry u. Scott Morton 1971, S. 33; Jung 2006). Die Rolle des Aggregationsgrades der Informationen ist in diesem Zusammenhang von wesentlicher Bedeutung. Im Sinne der Informationslogistik zeichnet sich beispielsweise eine vertikal durchgängige Befriedigung von Informationsbedarfen durch die Versorgung 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 operativer Ebene durch einen hohen Detailgrad sowie eine hohe Nutzungsfrequenz gekennzeichnet. Ein weiteres Unterscheidungsmerkmal der einzelnen Ebenen im Kontext der vertikalen Informationsintegration ist der Strukturierungsgrad der Entscheidungen, die auf den analytischen Daten basieren. Auf strategischer Ebene sind überwiegend unstrukturierte, auf

138

Gerrit Lahrmann, Florian Stroh

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 bereits vorab verdichteter Daten, ohne dass die Datenbasis basierend auf den zuvor analysierten Daten verändert wird. Systeme, die eine aktive analytische Komponente besitzen, werden als Active Data Warehouse bezeichnet. Ein Active Data Warehouse ermöglicht die ereignisgesteuerte, automatisierte Entscheidungsfindung bei standardisierten Entscheidungsaufgaben und bei den routinemäßigen Elementen von semi-routinemäßigen Entscheidungsaufgaben. 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-Entscheidungs-Ansatz realisiert. In Abhängigkeit vom Ergebnis der Datenanalyse wird ggf. eine Aktion im operativen System ausgelöst (vgl. Thalhammer et al. 2001, S. 242). Ein Active Data Warehouse ist nicht für alle Entscheidungssituationen geeignet. Insbesondere gut strukturierte Problemstellungen aus dem operativen und taktischen Bereich können automatisiert verarbeitet werden. Schwach strukturierte strategische Entscheidungen 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 beschrieben. 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 Informationslogistik vorgestellt. Die dargestellten Architekturbeispiele generalisieren jeweils eine Vielzahl in der Realität auftretender Architekturen und stellen insofern idealtypische Architekturmodelle dar. In der Literatur

Informationslogistik-Systemarchitekturen

139

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 Organisationseinheiten unabhängig voneinander entwickelte Analysemöglichkeiten, beispielsweise in Form von Data Marts, auf. Sie erfüllen die relativ homogenen 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 Architektur mit unabhängigen Data Marts liegen darin, dass einzelne Unternehmensbereiche schrittweise bei Bedarf mit passenden Informationen versorgt 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 erstellen, so gelangt man schnell an die Grenzen dieser Architektur: Die Daten sind in einer siloartigen Struktur abgelegt, Datendefinitionen sind inkonsistent und die Benutzung von unterschiedlichen Dimensionen und Fakten erschwert eine übergreifende Analyse. Quellsystem

Data Mart

SalesAnalysen

Data Mart

FinanzAnalysen

Data Mart

HRAnalysen

1

ETL

Quellsystem 2

Quellsystem 3

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 Architekturtypen wird bei der Data Mart-Busarchitektur auf eine zentrale Daten-

140

Gerrit Lahrmann, Florian Stroh

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 Differenzierungsmerkmale dieser Architektur liegen in der dimensionalen Datenmodellierung mit übereinstimmenden Dimensionsdaten, deren Konsistenz 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 Filialtabellen) aufgebaut. Um Dateninkonsistenzen und Redundanzen zu vermeiden, werden zwischen den einzelnen Data Marts übereinstimmende Dimensionsdaten ausgetauscht und verwendet. Beispielsweise sollen semantisch 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 machen 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)

Informationslogistik-Systemarchitekturen 3.1.3

141

Zentralisierte Architektur

Eine zentralisierte Architektur zeichnet sich dadurch aus, dass sämtliche Datenzugriffe über ein zentrales Data Warehouse (DWH) erfolgen (Ariyachandra 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 Metadaten 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 redundanten 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 vorzufinden (z. B. durch Views), so dass die zentralisierte Architektur einer logischen Implementierung der Hub and Spoke-Architektur entspricht (Ariyachandra 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 Information 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 ETLProzess nutzt die Metadaten aus einem zentralen Repository, um das zentrale DWH mit konsolidierten und bereinigten Daten aus den Quellsystemen zu befüllen. Die Anzahl der Schnittstellen zu den Quellsystemen kann

142

Gerrit Lahrmann, Florian Stroh

Abb. 5. Hub and Spoke-Architektur

durch den zentralen Zugriff auf ein Minimum reduziert werden und es finden 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 analysiert werden. Die Data Marts können auf unterschiedlichen Technologien wie z. B. relationalen Datenbanken, persistente OLAP-Cubes oder In-Memory Analysen 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 Performanz 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 diese Data Warehouses und Data Marts ein föderiertes Data WarehouseSystem (vgl. Hackney 2000).

Informationslogistik-Systemarchitekturen

143

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 Metadatenmanagement für die wichtigsten Unternehmensdaten kann zur Konsistenzsicherung 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 Geschäftsregelwerk bereiten. Bei föderierten Systemen können Probleme bei Konnektivität und Datendurchsatz auftreten, da Daten über unterschiedlichste Systeme ausgetauscht werden müssen.

144 3.1.6

Gerrit Lahrmann, Florian Stroh 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 Datenmaterial 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 Systemen. Daher ist die Anbindung heterogener Quellsysteme sehr aufwändig und mehrere Quellsysteme können kaum integriert betrachtet werden. Ferner werden die operativen Systeme durch den direkten Abfragezugriff sehr stark belastet. Um die Analyse von historischem Datenmaterial zu ermöglichen, müssten sämtliche Daten in den Quellsystemen vorgehalten werden. Auf Grund der oben genannten Nachteile (keine Integration, keine Historisierung, Belastung der operativen Systeme) und der geringen Verbreitung 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

Informationslogistik-Systemarchitekturen

145

3.2 Erweiterungsformen Im Folgenden werden Erweiterungen zu den zuvor beschriebenen Systemarchitekturen 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 Warehouse um die Fähigkeit, basierend auf einem automatisierten Analyseprozess Entscheidungen automatisch zu fällen und auf Grund dieser Entscheidungen 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 Intelligence, 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 Basisarchitektur eine der zuvor vorgestellten, wie z.B. eine zentralisierte DWHArchitektur, sein kann, beinhaltet ein ADWH ein (passives) Data Warehouse, aus dem Ad-hoc Anfragen beantwortet werden können. Bei Auftreten von vordefinierten Ereignissen (z. B. bei Überschreiten eines Schwellwertes) erkennt und verarbeitet ein Event-Manager diese und löst basierend auf Regeln Aktionen aus. Analysten können auf die Regelbasis mittels unterschiedlichster Tools zugreifen, um Analyseregeln und Ereignisse etc. zu definieren oder zu modifizieren.

Abb. 8. Konzeptionelle Architektur eines Active Data Warehouse (in Anlehnung an Thalhammer et al. 2001)

146

Gerrit Lahrmann, Florian Stroh Daten-Analysen ETL

Data Mart

Quellsystem 1

Batch

Daten-Analysen Zentrales DWH

Quellsystem 2

Data Mart

Feed Quellsystem 3

Alerts, etc. Rule Engine

Abb. 9. Beispiel eines (Near-)Real-Time-DWH auf Basis einer Hub and SpokeArchitektur 3.2.2

Real-Time Warehousing

Aus dem Anspruch, möglichst aktuelle Daten für analytische Systeme bereitzuhalten, 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 Datenlade- und Datenanalysebereich weiterhin Verzögerungen bei der Entscheidungsfindung auftreten, wird der Begriff „Real-Time“ teilweise relativiert und als „Right-Time“-Warehousing aufgefasst (Schelp 2006, S. 426). Die folgenden Aspekte sind insbesondere im Aufbau einer echtzeitorientierten 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 Datenströme („Feeds“) aus den Quellsystemen, die höchst mögliche Datenaktualitä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 Inkonsistenzen zwischen Real-Time- und Nicht-Real-Time-Daten können RealTime-Daten beispielsweise in separaten Fakttabellen geladen werden, die entweder die gleiche oder eine andere Struktur wie die Nicht-Real-TimeFakttabellen vorweisen. Dem Risiko falscher Abfrageergebnisse kann ferner mit speziellen Nutzungsvorgaben 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 dennoch auch komplexe Abfragen mit Real-Time-Inhalten zu ermöglichen,

Informationslogistik-Systemarchitekturen

147

können Snapshots der Real-Time-Daten verwendet werden. Darüber hinaus sind die fachlichen Benutzer über die Potenziale und die Risiken zu informieren, die durch den Einbezug von Real-Time-Daten im Data Warehouse entstehen. Durch die hohe Aktualität der Daten ergeben sich im Bereich der Datenanalyse der Informationslogistik neue Möglichkeiten. So sollte in Erwä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 Daten können automatisch in regelbasierten Systemen (Rule Engines) verarbeitet werden. Beim Überschreiten gewisser vordefinierter Grenzwerte können entsprechende Alerts zur Weiterleitung an Nutzer bzw. weitere Informationssysteme 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 Antwortzeit 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 Probleme auf (Schlegel et al. 2006, S. 2): • Die Erstellung der Data Marts ist Ressourcen intensiv, es werden Personal- 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 Weiterentwicklung 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 Erweiterungsform in diesem Kapitel betrachtet. Anstatt eine voraggregierte Zwischenschicht zu erstellen, werden sämtliche Daten in den Speicher geladen und Berechnungen werden zur Abfragezeit durchgeführt. Endanwender können detaillierte Daten einfacher erkunden. Virtuelle Data Marts basieren auf ähnlichen Prinzipien, aufgrund

148

Gerrit Lahrmann, Florian Stroh

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 weltweit 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 Abfrageperformanz 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 Bewertungsergebnisse zusammenfassend dar. Architektur-Anforderungs-Konstellationen, 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-

Informationslogistik-Systemarchitekturen

149

sprechende Häkchen vermerkt. Die hier vorgestellten Bewertungen orientieren sich nur an den Architekturbeschreibungen in Abschn. 3.1. Bei Ergänzung um entsprechende Komponenten oder Mechanismen kann die entsprechende Architektur einzelne Anforderungen in erhöhtem Maße erfüllen. Die unterschiedlichen Ausprägungen der Erfüllungsgrade einer Architektur in Bezug auf die entsprechende Anforderung werden durch die folgenden 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. Der Architekturtyp erfüllt die Anforderung bzw. entspricht dem Einflussfaktor in einigen Teilen. Eine Empfehlung für diesen Bereich kann nicht explizit gegeben werden. Der Architekturtyp erfüllt die Anforderung bzw. entspricht dem 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.

150

Gerrit Lahrmann, Florian Stroh

Tabelle 2. Bewertungsübersicht der untersuchten Architekturtypen und Erweiterungen

Datenqualität

Aktualität Vollständigkeit Konsistenz

Systemqualität

Transparenz Performanz Flexibilität Verfügbarkeit Sicherheit

Weitere Einflussfaktoren

Ressourcenbedarf Eignungsgrad horizontale Informationsintegration Eignungsgrad vertikale Informationsintegration Lese- & Schreibzugriff

9. In Memory Analytics

8. Real Time DWH

7. Active DWH

6. Virtuelle Architektur

Erweiterungen 5. Föderiert

4. Hub and Spoke

3. Zentralisiert

2. Data Mart Bus

1. Unabhängige Data Marts

Architekturen

Informationslogistik-Systemarchitekturen

151

Aktualität: Ladezyklen zwischen Quellsystemen und möglichen Datenintegrationsebenen 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 beispielsweise 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-Architekturen 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 bescheinigt (Ariyachandra u. Watson 2005, S. 39). Des Weiteren wird vereinzelt 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 Verbesserung der Vollständigkeit beitragen. In Bezug auf die Historisierung von Daten ergeben sich bei Architekturen mit einer Datenintegrationsebene entsprechende Vorteile. Konsistenz: In einer Studie wird der zentralisierte Ansatz sowie die Hub and Spoke-Architektur als führend bei der erreichbaren Konsistenz betrachtet, alle anderen Typen – insbesondere unabhängige Data Marts als „Informationssilos“ – schneiden hier schlechter ab (Ariyachandra u. Watson 2005). Gründe hierfür liegen u. a. in einem zentralen Metadatenmanagement. 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 Metadatenmanagement 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 entsprechende Lastverteilungsmechanismen oder die Verwendung denormalisier-

152

Gerrit Lahrmann, Florian Stroh

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 werden, 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ügbarkeit aus). Flexibilität: Hinsichtlich hoher Flexibilität der Architektur, wichtig beispielsweise bei Integration neuer Quellsysteme oder Verwendung der Daten für weitere Informationssysteme, sind unabhängige Data Marts (isolierte „Datensilos“) und föderierte Systeme auf Grund ihrer Heterogenität als kritisch zu erachten. Generell ist die Anzahl zu verwaltender bzw. anzupassender 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 Ausfallsicherheit) 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 hohen Verfügbarkeit in weniger starkem Maße, massiv parallele Architekturen können hierbei jedoch zu einen weitreichenden Erhöhung der Verfügbarkeit beitragen. Da bei einer Hub and Spoke-Architektur nicht direkt auf die integrierte Datenbasis, sondern auf Data Marts zugegriffen wird, können 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 einzelnen 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 jedoch zu beachten, dass sich die soeben vorgenommene Bewertung nur auf die Architekturtypen per se sowie deren grundlegenden Aufbau konzentriert hat. Durch technische Detaillösungen können bei allen Typen Verbesserungen hinsichtlich ihrer Verfügbarkeit erzielt werden. Sicherheit: Die Verwendung entsprechender Sichten („Views“) kann als weiterer Vorteil von Data Mart-Komponenten verstanden werden. Hierdurch ist der Zugriff auf eine Integrationsebene, die alle Daten enthält,

Informationslogistik-Systemarchitekturen

153

eingeschränkt. Dies kann zu einer erhöhten Sicherheit im Betrieb der Systeme beitragen (siehe auch Abschn. 2.2.4). Somit erhalten Architekturen, die auf Data Marts zurückgreifen, eine tendenziell bessere Bewertung hinsichtlich ihrer Sicherheit. Bei Verwendung einer Bus-Architektur muss jedoch 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 entsprechend niedriger bewertet. Die aufwändige Administration von föderierten Systemen, die teilweise aus äußerst heterogenen Systemen bestehen, erschwert ein effektives Sicherheitsmanagement. Ressourcenbedarf: An dieser Stelle wird der Grad des Ressourceneinsatzes während der Einführung und beim Betrieb und der Wartung des jeweiligen Systems betrachtet. Ressourcenschonende Architekturen wie beispielsweise unabhängige Data Marts werden entsprechend positiv bewertet. 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 Ressourcenbedarf 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 Datenintegrationsebene der Architekturtypen drei und vier oder die gemeinsame Verwendung von Stammdaten bei Data Mart Bus-Architekturen erscheint die Verwendung dieser Architekturen zur Schaffung einer horizontalen Informationsintegration, wie in Abschn. 2.3.3 beschrieben, als vorteilhaft (Ariyachandra u. Watson 2005, S. 42). Im Kontext einer ganzheitlichen Informationslogistik, bei der nicht nur einzelne Unternehmen, sondern auch Unternehmensnetzwerke betrachtet werden, ist das Problem der durchgängigen horizontalen Informationsintegration als durch die vorgestellten Architekturen noch nicht vollständig beherrschbar anzusehen. Vertikale Informationsintegration: Eine vertikale Informationsintegration kann durch Architekturtypen mit Data Marts, die nur für die regionale Subjektorientierung bzw. einen Ausschnitt (einer Ebene) des Unternehmens 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 sehen einen rein lesenden Zugriff auf die Daten der operativen Systeme vor. Durch Active DWH-Komponenten kann dieses Verhalten erweitert und

154

Gerrit Lahrmann, Florian Stroh

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 Auswahl einer bestimmten Architektur geben lässt, zeigen bestimmte Architekturen in bestimmten Situationen deutliche Vorteile auf. Oftmals wirken sich situative Faktoren auf die Auswahl einer Architektur aus oder schränken die zur Auswahl stehenden Architekturtypen ein. Einzelne Architekturtypen 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 Informationslogistik des gesamten Unternehmens (oder auch Unternehmensnetzwerks) zu schaffen. Für die Etablierung einer nachhaltigen Systemarchitektur der Informationslogistik sind fachliche und organisatorische Aspekte 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 Selection 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. Bauer, A.; Günzel, H.: Data Warehouse Systeme - Architektur, Entwicklung, Anwendung, 2. Aufl., dpunkt, Heidelberg 2004. Beyer, M.; Friedman, T.; Feinberg, D.: Mission-Critical Data Warehouses Demand 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 Cycle for Business Intelligence and Performance Management, 2007, Gartner, Stamford 2007.

Informationslogistik-Systemarchitekturen

155

Bold, M.; Hoffmann, M.; Scheer, A.-W.: Datenmodellierung für das Data Warehouse, 139, Scheer, August-Wilhelm, Saarbrücken 1997. Brändli, P.; Mügeli, T.; Maier, D.; Winter, M.; Klesse, M.; Herrmann, C.: Customer 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. 620. 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, Addison-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. Gorry, A.; Scott Morton, M.: A Framework for Management Information Systems, in: Sloan Management Review 13 (1971) 1, S. 55-70. Graham, D.: Enabling the Agile Enterprise with Active Data Warehousing, Teradata 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 Intensive 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, Wiesbaden 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.

156

Gerrit Lahrmann, Florian Stroh

Krallmann, H.; Frank, H.; Gronau, N. (Hrsg.): Systemanalyse im Unternehmen – Vorgehensmodelle, Modellierungsverfahren und Gestaltungsoptionen, 4. Auflage. 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 - Information, Organisation und Management, 4. Aufl., Gabler, Wiesbaden 2001. Pipino, L.; Lee, Y. W.; Wang, R. Y.: Data Quality Assessment, in: Communications of the ACM 45 (2002) 4, S. 211-218. Schelp, J.: Real-Time Warehousing und EAI, in: Chamoni P. et al. (Hrsg.): Analytische 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: complementing OLAP with analysis rules, in: Data & Knowledge Engineering 39 (2001), S. 241-269. Wand, Y.; Wang, R. Y.: Anchoring data quality dimensions in ontological foundations, in: Communications of the ACM 39 (1996) 11, S. 86-95. Wilhelmi, C.: Erfolgsfaktoren für die Informationslogistik, BE HSG/EIW/02, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2006.

8

Nutzenpotenziale unternehmensweiter Informationslogistik

Moritz Schmaltz Universität St. Gallen

Jochen Töpfer Teradata

1 2 3 4 5 6 7

Einleitung ....................................................................................... 157 Eigenschaften von Informationslogistik-Projekten ........................ 158 Nutzendimensionen der Informationslogistik................................. 160 Wertbeiträge der Informationslogistik............................................ 163 Kostensenkung durch Informationslogistik .................................... 168 Organisatorische Einbettung........................................................... 172 Methodenbeispiel zur Bewertung der Informationslogistik ........... 173 Literatur .......................................................................................... 176

1

Einleitung

Die Informationslogistik (IL) hat zum Ziel, betrachtungseinheit-übergreifend 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 Unternehmens 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 bestehenden IL-Infrastruktur bzw. der darauf aufsetzenden analytischen Anwendungen zum Ziel haben. Getrieben aus der Praxis wurden daher erhebliche Anstrengungen unternommen, 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 Beitrag zeigt die unterschiedlichen Nutzenpotenziale der IL auf und gibt Hinweise auf Möglichkeiten zur Quantifizierung. Für eine Wirtschaftlichkeitsbetrachtung ist neben der Nutzenbetrachtung auch eine Betrachtung der Kosten erforderlich. Die Kosten von ILProjekten 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 beachtet werden müssen (Frie u. Wellmann 2000, S. 28; Winter u. Jung 2000, S. 32). Die bekannten Methoden zur Schätzung von SoftwareprojektKosten lassen sich – bei entsprechender Modularisierung der IL-Projekte – auch auf die IL anwenden (Watson et al. 2001, S. 51). Daher wird an dieser Stelle auf die Kostenschätzung und die anschließende Berechnung eines 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 beeinflussen, erläutert sowie die Anwendbarkeit etablierter Methoden zur Nutzenschä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 Verankerung von IT-Projekten zur Realisierung der Nutzenpotenziale wird in Abschn. 6 erörtert. In Abschn. 7 wird beispielhaft eine Methode zur Bewertung 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 Eigenschaften kurz dargestellt und in Abschn. 2.2 wird ihr Einfluss auf die Anwendbarkeit 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 erwirtschaftet 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öglicht sie aber auch eine Verbesserung der Informationsversorgung von Entscheidungsprozessen und neue, informationsgetriebene Geschäftsmodelle (vgl. Abschn. 4.4). Diese indirekte Wirkung in einer Vielzahl von Geschäftsprozessen, u. U. über mehrere Stufen hinweg, erschwert die Beurteilung 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 Einfü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 Zusammenhang mit den beeinflussten Geschäftsprozessen steht. Bei Basiskomponenten wie z. B. DWHs kann hingegen nur ein indirekter Zusammenhang 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äftsprozesse erforderlich, außerdem ist der Erfolg u. a. von den Mitarbeitern, Produkten und externen Faktoren abhängig. Dies erschwert eine Beurteilung des Einflusses von IL, da die Isolation des Einflusses und damit die Zurechnung nicht einfach ist (Huber 1999, S. 113). 2.1.2

Komplexität

Die IL ist auf hochgradig komplexe, mehrstufige Systemarchitekturen angewiesen. Komponenten zur Extraktion und Aufbereitung der Daten, Speicherungsschichten und darauf aufbauende analytische Applikationen bilden ein komplexes Gesamtsystem (vgl. Kap. 7). Diese Systemarchitekturen entstehen in der Regel nicht auf einmal, da auf Grund der sonst nicht handhabbaren Komplexität ein inkrementelles Vorgehen beim Aufbau der Systeme erforderlich ist (Bauer u. Günzel 2004, S. 368 ff.). Hinzu kommt, dass oftmals bestehende Subsysteme weiterentwickelt und an sich

160

Moritz Schmaltz, Jochen Töpfer

ä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. Projektphasen kaum möglich ist. Mit fortschreitendem Reifegrad der IL-Architektur ist davon auszugehen, dass neue Entwicklungen in erster Linie im Bereich der analytischen Applikationen stattfinden. Hier wird die Beurteilung einfacher, da einerseits eine geringere Zahl von infrastrukturnahen Systemkomponenten tangiert wird und andererseits analytische Applikationen oft nur eine beschränkte Zahl von Geschäftsprozessen beeinflussen, wodurch die Komplexitä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 Nutzenschätzung einen eindimensionalen Wert für den Nettonutzen des Projekts zu prognostizieren, der dann z. B. zum Vergleich mit alternativen Investitionsszenarien 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 ILProjekten liegt dabei in der Bezifferung des Nutzens, dessen Quantifizierung 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 Hauptschwierigkeit bei der Anwendung von Bewertungsmethoden ist also nicht die Durchführung der Methoden selbst, sondern die Gewinnung von realistischen Eingabegrößen für diese Methoden. In den folgenden Abschnitten werden die verschiedenen Arten von Nutzenpotenzialen und deren Bewertbarkeit beschrieben. Abschn. 7 gibt anhand eines Methodenbeispiels Hinweise auf praktisch anwendbare Möglichkeiten 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

Nutzenpotenziale unternehmensweiter Informationslogistik

161

sind drei Klassen von Nutzeneffekten der IL erkennbar, die sich in der Direktheit ihrer Wirkung unterscheiden. Die Klasseneinteilung ist nicht immer scharf trennbar, manche Autoren sprechen daher von einem Kontinuum der Nutzeneffekte (s. Tabelle 1, Watson et al. 2001, S. 51). Diese Klassen entsprechen den Einsatzmöglichkeiten von Informationssystemen (Nagel 1990; Stickel 2001). Einerseits können Informationssysteme substitutiv eingesetzt werden, um manuelle Tätigkeiten zu automatisieren. 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 unterstützen. Diese inkrementellen Innovationen ermöglichen Nutzenpotenziale im Bereich der Prozessoptimierung. Die potenziell weitreichendsten Änderungen bringt der strategische Einsatz von Informationssystemen mit sich. Dieser ermöglicht radikale Innovationen, die zu strategischen Wettbewerbsvorteilen 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 Nutzeneffekte. Sie entstehen z. B. durch die Konsolidierung mehrerer analytischer Systeme in einem DWH oder durch die gesteigerte Produktivität von Analysten. In der Regel ist die Wirkung der Kosteneffekte gut einzelnen Prozessen zuzuordnen – häufig direkt im IT-Bereich – und auf eine geringe Anzahl von Prozessen begrenzt. Durch die direkte Kostenwirkung lassen 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 Prozessoptimierung Wettbewerbsvorteile

Kostenersparnis

Einflussbereich global

lokal

Wirkung

indirekt

direkt

Messbarkeit

entscheidbar

kalkulierbar

rechenbar

162

Moritz Schmaltz, Jochen Töpfer

Prozessoptimierungen umfassen all jene Prozessverbesserungen, die durch optimierte Informationsversorgung ermöglicht werden. Diese Verbesserungen können sowohl operative Prozesse wie auch Managementprozesse betreffen (Williams u. Williams 2003, S. 32). Hierzu zählen z. B. die gezieltere Selektion von Kunden für Marketing-Maßnahmen oder die genauere 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 Transaktion beim Vertrieb. Eine Bewertung des Nutzens ist nur noch eingeschränkt möglich, die Kalkulation ist mit zunehmenden Unsicherheiten behaftet. Strategische Wettbewerbsvorteile schließlich sind von Natur aus weniger konkret als die vorgenannten Nutzenkategorien. Sie ergeben sich z. B. aus komplett neuen Geschäftsmodellen, die nur durch integrierte Informationslogistik 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üssen, die teils sehr indirekt und über mehrere Stufen der Wertschöpfungskette hinweg zu Stande kommen. Diese Nutzeneffekte sind nicht quantifizierbar, 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 werden. Für Prozesse im Unternehmen identifiziert Österle die vier allgemeingültigen Erfolgsfaktoren Zeit (Geschwindigkeit und Termintreue der Prozessausführung), Qualität (Erfüllen der Kundenbedürfnisse), Kosten (effiziente 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 unterschiedlichem Umfang bei. Während Kostensenkungspotenziale in erster Linie auf den Erfolgsfaktor Kosten wirken, haben die Nutzenpotenziale aus dem Bereich Prozessoptimierung und strategische Wettbewerbsvorteile auch Auswirkungen auf die Erfolgsfaktoren Zeit, Qualität und Flexibilität. Die Zuordnung erfolgt dabei nach dem überwiegend beeinflussten Erfolgsfaktor, eine trennscharfe Abgrenzung ist nicht immer möglich.

Nutzenpotenziale unternehmensweiter Informationslogistik

163

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 vielfacher Weise zur Entstehung von Synergien bei, die ohne integrierende Systeme und Prozesse nur mit erheblichem Mehraufwand zu erzielen wären (siehe Kap. 3). Die Beiträge der einzelnen Nutzenpotenziale zu den Erfolgsfaktoren sind in Tabelle 2 dargestellt. Die strategischen Wettbewerbsvorteile sind dabei als Sonderfall zu betrachten, da sie nicht durch Optimierung 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 einzelnen dargestellt. Abschnitt 4.6 zeigt mögliche Probleme bei mangelnder Informationsversorgung auf. Tabelle 2. Beiträge der Nutzenpotenziale Erfolgsfaktor

Zeit

Qualität

Kosten

Flexibilität

Kundenorientierung durch ganzheitliche Informationsversorgung Nutzen durch eventgesteuerte Aktivitäten Nutzen durch detaildatenbasierte Massenkalkulationen Alignment strategischer und operativer Entscheidungsprozesse durch integrierte Informationslogistik

4.1 Kundenorientierung durch ganzheitliche Informationsversorgung Aktuelle Entwicklungen im Marketing – hin zu zunehmend informationsgetriebenen Marketingkonzeptionen – lassen der IL für die Optimierung der Marktbearbeitung eine stark steigende Bedeutung zukommen. Um eine Kundenbeziehung optimal zu monetarisieren, ist es erforderlich, eine langfristige, intensive und stabile Beziehung zum Kunden aufzu-

164

Moritz Schmaltz, Jochen Töpfer

bauen. Je länger eine Kundenbeziehung dauert, desto höher wird der kumulierte 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 kundenbezogene Gewinnsteigerungen realisieren (Reichheld u. Sasser 1990, S. 110), da einerseits Akquisitionskosten sinken und sich andererseits positive Wirkungen durch steigende Kauffrequenz, Cross-Buying, Weiterempfehlung 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 verhindern. 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 gesammelten 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 analysieren. Diese Vorgänge sollten im Idealfall automatisiert ablaufen und ohne menschlichen Eingriff einen Prozess anstoßen, der die Reaktion des Unternehmens umsetzt. Hier ist eine Nutzenbeurteilung einfach, solange die Maßnahmen einem bestimmten auslösenden Analyseprozess und den dazugehörigen Applikationen zuzuordnen sind.

Nutzenpotenziale unternehmensweiter Informationslogistik

165

4.3 Nutzen durch detaildatenbasierte Massenkalkulationen Um den Mitteleinsatz im Marketing optimal zu steuern, ist eine Segmentierung der Kunden in Gruppen mit unterschiedlichen Bedürfnissen und unterschiedlichen Profitaussichten unerlässlich. Um eine genaue Zuordnung des Kunden zu einzelnen Segmenten zu ermöglichen, sind integrierte Daten aus sämtlichen Kundenkontaktkanälen erforderlich. Zusätzlich können 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 verschiedene Reaktionsmöglichkeiten: Individualisierte Preisgestaltung hilft, die individuelle Preisbereitschaft des Kunden optimal auszunutzen. Integrierte Informationen ermöglichen dabei eine globale Koordination der Preisstrategien und zeitnahes Reagieren 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öpfen, 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 Konsequenzen 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 individuellen Kunden die notwendigen Aggregationen in angemessener Zeit vorzunehmen. Während die Effektivität von Pricing-Mechanismen und individualisierten Angeboten ohne weiteres quantifizierbar ist, lässt sich der Nutzen von Bonitäts-Scores u. U. weniger einfach berechnen. Dennoch bieten Kennzahlen zu Zahlungsausfällen hinreichend Ansatzpunkte für eine belastbare Nutzenschätzung. 4.4 Alignment strategischer und operativer Entscheidungsprozesse durch integrierte Informationslogistik Entscheidungsprozesse im Unternehmen laufen auf unterschiedlichen Ebenen ab – strategische Entscheidungen durch das Topmanagement beeinflussen taktische Entscheidungen des mittleren Managements, die wie-

166

Moritz Schmaltz, Jochen Töpfer

derum die operativen Entscheidungen auf unteren Hierarchieebenen beeinflussen (Gorry u. Scott Morton 1971). Wo eine integrierte IL fehlt, müssen Entscheidungen auf diesen Ebenen auf unterschiedlichen Datengrundlagen 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 eingeschätzt werden kann. Nur mit integrierter IL ist es möglich, die strategischen Entscheidungen durchgehend auf operative Handlungsanweisungen herunterzubrechen. Dabei stellen integrierte Informationen sicher, dass Alignment zwischen den Entscheidungen hergestellt wird, indem alle Entscheidungen auf denselben Daten basieren. Zudem können den taktischen und operativen Entscheidungsträgern ohne großen Aufwand die für sie relevanten Teile der strategischen Analysen zugänglich gemacht werden. Über Drill-Down-Funktionalitäten können zudem detailliertere Daten verfügbar gemacht werden, als sie im Normalfall für strategische Entscheidungen 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 gespeist werden, sind hierzu nicht in der Lage. 4.5 Informationsgetriebene Geschäftsmodelle Integrierte und schnell verfügbare Unternehmensinformationen verschaffen 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 Neugeschä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 werden. 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 aller relevanten Unternehmensinformationen inklusive erforderlicher Analytik. Dasjenige Unternehmen gewinnt, dem es gelingt den Kunden zur richtigen Zeit mit für ihn relevanten Produkten und Dienstleistungen zu überzeugen. So kommt die Zeit ins Spiel.

Nutzenpotenziale unternehmensweiter Informationslogistik

167

So erfasst die RBC Financial Group Canada (RBC) täglich Millionen von Transaktionen und verarbeitet diese Detaildaten u. a. für Kundensegmentierungen (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 richtigen Zeit adressiert werden kann. Als Ergebnis dieses Vorgehens x wuchs der Umsatz pro Marketingbudgeteinheit zweistellig, x 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 %, x führte eine gezielte Marketing-Kampagne zu einer Steigerung der Einlagen 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 versorgen, kann in einem Opportunitätsvergleich auf die Probleme mangelnder Informationsintegration hingewiesen werden. Ist eine detaildatenbasierte und ganzheitliche Kundensicht nicht vorhanden, kann lediglich mit aggregierten Daten gearbeitet werden. Eine Aggregation 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 Erfahrung. Die Möglichkeit, mit dem Kunden ein Geschäft zu tätigen, verstreicht ungenutzt. Das fehlende Alignment von strategischen und operativen Entscheidungsprozessen ist insbesondere für global tätige Unternehmen mit Risiken 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, Geschäftsmodelle und Unternehmensstrategien ist jedoch jederzeit sicherzu-

168

Moritz Schmaltz, Jochen Töpfer

stellen, dass Strategie und Umsetzung aufeinander abgestimmt sind, wenigstens 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. Dennoch sollte ein ausgewogener Business Case nicht allein auf die Kosteneffekte abstellen, sondern muss immer auch die Nutzenpotenziale berücksichtigen, 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 Kosteneffekte treten im Bereich der Informationslogistik selber auf. Zu ihnen zählen 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 insbesondere die indirekten Kosteneffekte neben den Kosten auch andere Erfolgsfaktoren 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 Entscheidungsunterstützung genutzt werden, sind Inkonsistenzen unausweichlich, selbst da, wo verschiedene Quellen eigentlich dieselben Daten zu liefern vorgeben. Diese Diskrepanzen können unterschiedliche Gründe haben. Einerseits ändern sich die Dimensionsdaten von DWH-Datenmodellen. Wo diese nicht zentral verwaltet werden, können Unterschiede in den Dimensionen 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 unterschiedliche Stichtage der verschiedenen Systeme zu den Differenzen beitragen. Diese Diskrepanzen führen zu erheblichen Reibungsverlusten in den Entscheidungsprozessen, wenn vor der Sachdiskussion erst zeitaufwändige Abstimmungsprozesse notwendig werden. Eine zentrale „Single Version

Nutzenpotenziale unternehmensweiter Informationslogistik

169

of the Truth“ führt zu organisationsweit konsistenten, glaubwürdigen Daten. Eine zentrale IL erleichtert das Management der Datenqualität erheblich, da Fehlerquellen nur noch einmalig identifiziert und beseitigt werden müssen. Wo in dezentralen Systemen mehrere ETL-Prozesse für unterschiedliche Zielsysteme dieselben Daten aus den operativen Systemen extrahieren, 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 Kontrollvorschriften wie z. B. dem Sarbanes-Oxley-Act (SOX), Basel II oder Solvency II konfrontiert. Diese Vorschriften erfordern seitens der Unternehmen 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 erforderlich, 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 Unternehmenssteuerung (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 Informationen (Hackathorn 2003). Insbesondere bei taktischen und operativen Entscheidungen besteht vielfach nur ein kurzes Zeitfenster, in dem die Entscheidung 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.

170

Moritz Schmaltz, Jochen Töpfer

Die Latenzzeit lässt sich in drei Teile einteilen: Datenlatenz, Analyselatenz und Entscheidungslatenz, die jeweils durch eine entsprechende Gestaltung 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 geschäftlichen Transaktion (bzw. bei externen Datenquellen aus einem externen 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-NutzenRelation unumgänglich. Die Analyselatenz bezeichnet die Zeit, die vom Eintreffen der Daten bis zur Bereitstellung der Analyseergebnisse für den Entscheidungsträger vergeht. 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 unakzeptabel lang sein. Wenn Daten erst aus unterschiedlichen Systemen zusammengetragen 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 werden 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 Bereitstehen 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 Entscheidungsprozesse 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 Entscheidung unterstützen, indem mit Hilfe von Geschäftsregeln und Schwellenwerten bestimmte Entscheidungen automatisch gefällt werden oder automatisiert den inhaltlich kompetenten und organisatorisch befugten Entscheidungsträgern zugeleitet werden.

Nutzenpotenziale unternehmensweiter Informationslogistik

171

5.4 Lieferfähigkeit Eine dienstleistungsorientierte IT-Organisation muss in der Lage sein, kurzfristig auf geänderte Anforderungen aus den Fachabteilungen zu reagieren. Dezentrale IL erfordert ein vielfaches Duplizieren von Systemkomponenten und Prozessen, insbesondere in den unteren Schichten der Systemarchitektur und bei Basisdiensten wie Metadatenmanagement, Authentifizierung, Datenqualität etc. Eine vereinheitlichte Applikationsplattform für die IL kann diese Komponenten zentral zur Verfügung stellen und damit die Entwicklungsprozesse der IL entscheidend beschleunigen. Dabei sinken nicht nur Kosten und Zeitbedarf, auch die Qualität der Lösungen kann gesteigert werden. Allerdings sind zur Durchsetzung zentraler Lösungen effektive GovernanceProzesse erforderlich, um lokale „Quick and Dirty“-Lösungen zu verhindern, die später nicht in die Gesamtarchitektur eingebunden werden können 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 redundante Infrastruktur Kosteneinsparungen sowohl im Bereich von Sachkosten 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 geringeren Anzahl von physischen Servern betrieben werden, was die Hardwarekosten senkt. Andererseits können durch vereinheitlichte Softwareplattformen, z. B. für ETL-Systeme und Frontend-Applikationen, Lizenzkosten eingespart werden. Falls kostenintensive Altsysteme abgelöst werden können, ist das Sparpotenzial besonders hoch. Zusätzlich können bei einer zentralisierten Plattform Infrastrukturkomponenten 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ö-

172

Moritz Schmaltz, Jochen Töpfer

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 Datenintegration 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 werden. 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 sicherstellt, 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 Geschäftsprozesse nicht ohne Nutzung des Systems ausgeführt werden, sobald 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 ausgeführt werden. Die tatsächliche Nutzung des Systems muss hier möglicherweise durch flankierende organisatorische Maßnahmen gefördert werden. Während diese Erkenntnis vorderhand trivial scheint, ist dies doch ein Aspekt, der in der Praxis vielfach zu Problemen führt, weshalb die Wichtigkeit 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. Kraemer 2006). Tatsächlich ist die frühere DWH-Literatur vielfach sehr technologiezentriert 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

Nutzenpotenziale unternehmensweiter Informationslogistik

173

Geschäftsnutzen zu den wichtigsten Erfolgsfaktoren von DWH-Projekten zählt (Hwang u. Xu 2005). Die erfolgreiche Umsetzung umfassender IL-Projekte erfordert daher intensive Zusammenarbeit zwischen der IT-Abteilung und den Fachabteilungen 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 sichtbar gemacht und die Basis für weitergehende, auf dem Erreichten aufbauende Veränderungen geschaffen werden (Kotter 1995, S. 61). Hierzu empfiehlt sich die Definition von Kennzahlen für die zu ändernden Prozesse. Falls diese schon vor Beginn des Projekts mit den Prozessverantwortlichen auf der Fachseite festgelegt und im Projektverlauf regelmäß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 umzusetzen (Daddah 2005). Langfristiges Ziel der IL ist es, die Verwendung von integrierten Informationen 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 realistisch. 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 Applikationen die Vorteilhaftigkeit des Gesamtsystems nachzuweisen (Watson et al. 2004). Ziel dieses Vorgehens ist weniger die Genauigkeit des ermittelten Endwerts als vielmehr die Möglichkeit, die postulierten Nutzenpotenziale so zu kalkulieren, dass sie auch von Management und Fachabteilungen 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

174

Moritz Schmaltz, Jochen Töpfer

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 Umsetzung des Projekts. Die Methode dient der Bewertung von IL-Projekten sowohl vor dem Projektstart als auch ex post, soweit im Vorfeld hinreichend genaue Vergleichszahlen erhoben wurden. Die Methode zielt dabei nicht primär auf eine möglichst genaue Bewertung des Gesamtnutzens, sondern vielmehr auf eine nachvollziehbare Bezifferung von Nutzenpotenzialen und auf die Schaffung einer Basis von Kennzahlen für das laufende Projektcontrolling ab. Durch die enge Anbindung an die Fachabteilungen wird sichergestellt, dass einerseits die Schätzung 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 Potenzialbeurteilung werden, um den Analyseaufwand in vertretbarem Rahmen zu halten, einzelne Geschäftsprozesse ausgewählt, die im Folgenden auf ihre Nutzenpotenziale untersucht werden. Diese Auswahl erfolgt anhand der Geschäftsstrategie sowie anhand von technologischen und finanziellen Überlegungen. Aus der Geschäftsstrategie werden Prozesse abgeleitet, die für die Entwicklung des Unternehmens besondere Bedeutung haben, oder die besonderem Konkurrenzdruck ausgesetzt sind. Technologische Überlegungen zeigen Prozesse auf, die unzureichend von der IT unterstützt werden oder die nicht hinreichend flexibel sind. Anhand finanzieller Kennzahlen werden Prozesse ausgewählt, deren Rendite unzureichend ist, oder die z. B. unregelmäßigen Cash-Flow generieren. Schließlich können auch weitere Ü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 sollen in dieser Phase Geschäftsprozesse ausgewählt werden, deren Optimierungspotenzial 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 untersuchten Prozesse. Es wird analysiert, was die Ziele des Geschäftsprozesses

Nutzenpotenziale unternehmensweiter Informationslogistik

175

sind und anhand welcher konkreter, messbarer Kennzahlen (z. B. Konversionsraten von Werbekampagnen) der Erfolg gemessen wird. Diese Kennzahlen dienen später der Erfolgskontrolle für die einzelnen Prozesse. Der andere Schwerpunkt der Interviews liegt im Bereich der Informationsbedarfe. Detailliert werden die benötigten Datenobjekte, ihre Granularität, Aktualität und Verlässlichkeit erfasst. Dazu werden die genutzten ITSysteme 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 Applikationen ausgewählt, anhand derer die Berechnung der Projektkennzahlen erfolgt. Diese Auswahl wird primär von strategischen Überlegungen beeinflusst. Zusätzlich wird sichergestellt, dass die Teilprojekte keine widersprüchlichen Ziele haben und möglichst in anderen Kontexten wiederverwendbar sind. Kostenschätzung: Anhand von Erfahrungen aus bestehenden Projekten werden die Kosten für die Umsetzung der ausgewählten Initiativen geschätzt. Dabei werden neben Hardware- und Softwarekosten auch Kosten für Customizing und Implementierung sowie Schulung und Kommunikation berücksichtigt. Prognose der Nutzenpotenziale: Anhand der im zweiten Schritt erhobenen Metriken und Verbesserungspotenziale werden für die betrachteten Geschäftsprozesse konkrete Verbesserungspotenziale und Zielwerte definiert. Dabei werden einerseits Sollwerte für die zuvor definierten Kennzahlen festgelegt, andererseits werden auch der zusätzlich zu erwirtschaftende 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 einen Konsens mit der Fachseite über erreichbare Zielwerte zu erzielen. Damit wird sichergestellt, dass die später für die Zielerreichung verantwortlichen 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 Nutzeneffekte und die geschätzten Kosten werden dann konsolidiert und mit Verfahren der finanziellen Investitionsrechnung (Blohm et al. 2006, S. 41 ff.) in einwertige Kennzahlen wie Kapitalwert (Net Present Value), Kapitalrendite (Return on Investment) oder Amortisationszeitraum (Payback Period) überführt (Nagel 1990, S. 59 ff.; Kütz 2005, S. 148 ff.). Diese haben

176

Moritz Schmaltz, Jochen Töpfer

den Vorteil, dass sie in der Praxis weit verbreitet sind und daher gut verstanden werden (Blohm et al. 2006, S. 44 ff.). Zudem sind die Ergebnisse mit den Kennzahlen konkurrierender Investitionen auch außerhalb des ITBereichs 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ätzlich wird ein Prozess zur Überwachung der Kennzahlen geschaffen, damit der Fortschritt des Projekts kontinuierlich überprüft werden kann, und damit Fehlentwicklungen frühzeitig erkannt und korrigiert werden können. Die Business Impact Assessment-Methode hat nicht das Ziel, einen mathematisch korrekten Beweis für den Gesamtnutzen von IL-Projekten zu führen. Daher wird auch auf die Anwendung von fortschrittlichen, mehrdimensionalen oder nichtmonetären Bewertungsverfahren (Nagel 1990, S. 71 ff.; Kütz 2005, S. 259 ff.; Tallon u. Kraemer 2006, S. 1001 ff.) verzichtet. Vielmehr ist es Ziel der Methode, neben einem Nachweis der Vorteilhaftigkeit 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 Bauer, A.; Günzel, H.: Data Warehouse Systeme - Architektur, Entwicklung, Anwendung, 2. Aufl., dpunkt, Heidelberg 2004. 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 Approach 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, Methoden, Visionen, Springer, Berlin et al. 2000. Gorry, A.; Scott Morton, M.: A Framework for Management Information Systems, in: Sloan Management Review 13 (1971) 1, S. 55-70.

Nutzenpotenziale unternehmensweiter Informationslogistik

177

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: Business 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 Business Review 73 (1995) 2, S. 59-67. Kütz, M.: IT-Controlling für die Praxis - Konzeption und Methoden, dpunkt, Heidelberg 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 Performance, 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-Technologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 425-438. Schmaltz, M.; Dinter, B.: Wartung von Dimensionsdaten in verteilten Data Warehouse-Systemen, in: Schelp J.; Winter R. e.a. (Hrsg.): DW2006 - Integration, Informationslogistik und Architektur, Gesellschaft für Informatik, Friedrichshafen 2006, S. 83-106. Smith, H. A.; McKeen, J. D.: Developments in practice VII: Developing and delivering the IT value proposition, in: Communications Of The Association For Information Systems 11 (2003), S. 438-450.

178

Moritz Schmaltz, Jochen Töpfer

Sommer, D.: Spending Preferences for Business Intelligence and Information Infrastructure, 2007, Gartner, 2007. Stickel, E.: Informationsmanagement, Oldenburg Wissenschaftsverlag GmbH, München 2001. Tallon, P. P.; Kraemer, K. L.: The development and application of a processoriented "thermometer" of IT business value, in: Communications Of The Association For Information Systems 17 (2006), S. 995-1027. Watson, H. J.; Abraham, D. L.; Chen, D.; Preston, D.; Thomas, D.: Data Warehousing ROI: Justifying and Assessing a Data Warehouse, in: Business Intelligence 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 & Management 39 (2002) 6, S. 491-502. Whittemore, B.: The Business Intelligence ROI Challenge: Putting It All Together, in: Business Intelligence Journal 8 (2003) 1, S. 4-10. Williams, S.; Williams, N.: The Business Value of Business Intelligence, in: Business 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 2 3 4

1

Einleitung ....................................................................................... 179 Modelle und der Prozess von Integration und Evolution ............... 183 Die Rolle von Meta-, Stamm- und Referenzdaten in der Entwicklung und Pflege integrativer Systeme ................................ 193 Zusammenfassung .......................................................................... 197 Literatur .......................................................................................... 198

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öpfungskette spielen (z. B. in der Finanzindustrie), wo strikte regulatorische Anforderungen über die Nachverfolgbarkeit von Ereignissen und Entscheidungen 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 substanzielles 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 expliziertes, 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 Modellen 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 Modellevolution 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 verschiedenen 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 Softwareprodukt 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 potenziell eine neue Version des Produkts erstellt werden muss. Wenn man davon absieht, dass Änderungen üblicherweise und – so muss betont werden – sinnvollerweise gruppiert werden, so bleibt doch der Sachverhalt bestehen, dass Veränderungen immer durch den gleichen (nämlich den Entwicklungs-) Prozess geschleust werden. Ein DWH oder ODS integriert Daten aus vielen verschiedenen Bereichen 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 gleichen 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 beobachtendes Phänomen, die Organisation passt die Adoption von Veränderungen an die Möglichkeiten des Entwicklungsprozesses an, indem Veränderungen 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: x 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. x 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 Datenmodellen niederschlagen. x 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 gewähren ihren Markt-, Geschäfts- und Rechtseinheiten gewisse Autonomie bei der Gestaltung des Betriebs. Dadurch wird die oben beschriebene Situation noch einmal verschärft: die sozusagen „natürlich“ bei der Integration auftretende Variabilität wird noch verstärkt, indem sich Veränderungen unabhängig voneinander und ohne wechselseitige Koordination ereignen. Mit anderen Worten: Ein DWH oder ODS kann unter solchen Umständen nicht sinnvoll betrieben werden, ohne eine entsprechende Logistik im Rücken zu wissen, die Daten zuverlässig, systematisch und zu sachgerechten 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 nehmen; dabei wird deutlich werden, dass die Wechselwirkungen zwischen Geschäfts-, Management- und Unterstützungsprozessen wichtig sind. Weiter 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 einzusetzen. 1.2 Die terminologische Herausforderung Die Bedeutung der Begriffe „Metadaten“, „Referenzdaten“ und „Stammdaten“ hat schon mehrfach zu Diskussionen Anlass gegeben. Auch ist die semantische Abtrennung immer wieder Ursache für Verwirrung. Eine häufig anzutreffende Meinung ist beispielsweise, dass Stammdaten sich durch ihre Eigenschaft sich nur langsam zu ändern von Bewegungsdaten unterscheiden (Schmaltz u. Dinter 2006). Was das konkret bedeutet, also etwa x wie schnell oder langsam solche Änderungen sich an einem Datum ereignen dürfen, damit man es als Stammdatum klassifizieren muss, x ob Bewegungsdaten und Stammdaten disjunkte Mengen sind und x welche Auswirkungen all das auf den Umgang mit diesen Daten hat, wird nicht weiter ausgeführt. Referenzdaten werden ebenso unklar definiert; 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 systematischen Umgang. Metadaten zuletzt werden meist als Daten über Daten definiert (Poole et al. 2002), ohne dass näher angegeben wird, welche Implikationen 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 anderen Autoren angebracht, z. B. von (Tannenbaum 2002), die die Limitierung des Begriffs Metadaten auf Daten über Daten als „misconception“ bezeichnet. Allerdings ist in der letzten Zeit (z. B. von Auth 2003; Melchert 2006) darauf hingewiesen worden, dass die Rolleneigenschaften von Metadaten in den Vordergrund zu rücken sind, um zu einem vertieften

Metadaten, Referenzdaten, Stammdaten

183

Verständnis zu gelangen; auch wurde schon früher die beschreibungssprachliche 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 zentrale 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änderung 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 Begriffe. Abschnitt 3 beschäftigt sich mit den praktischen Konsequenzen und beschreibt verschiedene industrietypische Situationen, in denen diese Daten zum Einsatz kommen. Insbesondere werden die Möglichkeiten und Grenzen diskutiert, auch in Bezug auf die Nutzung internationaler Standards wie des Common Warehouse Metamodel (CWM). In Abschn. 4 wird eine Zusammenfassung der Erkenntnisse vorgenommen und auf weitere Möglichkeiten für Forschung und Praxis hingewiesen.

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 Prozessperspektive neue Erkenntnisse bei der Betrachtung des Managements von Metadaten bringen. Wir beziehen uns hier auf das neue St. Galler Management-Modell (Rüegg-Strüm 2003), das drei Kategorien von Prozessen (Geschäfts-, Unterstützungs- und Managementprozesse) vorsieht. Im Zusammenhang von Datenintegration und -evolution interpretieren wir diese Dreiteilung wie folgt:

184

Hans Wegener

x Der Geschäftsprozess ist die Bereitstellung eines die Daten des Unternehmens integrierenden Systems (DWH, ODS). Dies kann mehr oder minder direkt im Sinne des klassischen Entwicklungsprozesses interpretiert 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. x In diesem Kontext dienen als Unterstützungsprozesse alle Maßnahmen, die dazu geeignet sind, den Geschäftsprozess zu beschleunigen. Insbesondere sollen hier diejenigen Beiträge betrachtet werden, die einer schnelleren und Kosten sparenden Integration und Evolution dienlich sind. x Die Managementprozesse zuletzt versuchen, die Erreichung strategischer Ziele im Geschäftsprozess sicherzustellen. Sie sollen im Zusammenhang 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 Kernaufgabe (Integration und Evolution) und unterstützend wirkenden Aufgaben (Vereinfachung von Evolution und Integration) unterschieden. Diese Aufteilung ermöglicht es, genauer zu definieren, welche unterstützenden Ziele erreicht werden müssen, um im Sinne einer umfassenden Informationslogistik Vereinfachungen zu erreichen. Dies sind insbesondere: x Beschleunigung des fachlichen Verständnisses: Zu Beginn jeder Integration muss sichergestellt werden, dass die zu integrierenden Dateninhalte aus fachlicher Sicht kompatibel sind. Insbesondere beinhaltet dies das Studium der Systemdokumentation, der Geschäftsterminologie und ähnlicher Dokumente. Beschleunigung entsteht unter anderem, wenn gleiche oder übertragbare Standards verwendet werden, wie dies im Sinne standardisierter Fachsprachen bereits gefordert wurde (Turowski 2002). Ein Glossar unterstützt verschiedene Ziele von Daten-Wiederverwendung wie z. B. Abstraktion, Selektion, Integration und Spezialisierung (Krueger 1992). x Effiziente Nutzung existierender struktureller Beschreibungsmerkmale: Nachdem ein fachliches Verständnis erarbeitet wurde, muss die Integration 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

Metadaten, Referenzdaten, Stammdaten

185

z. B. durch Transformation und Abbildung, effizient im integrierenden System nutzbar zu machen. Dies ist vor allem ein Problem der Werkzeugintegration, wie sie im Detail von (Poole et al. 2002) beschrieben ist. x 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 Systeme ü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 (vereinfachtes) Abbild des realen Gegenstandsbereichs, stellen also in einem gewissen Sinn wieder verwendbaren fachlichen Konsens dar; insofern unterstützen sie die Aneignung des fachlichen Verständnisses. Sie können auch automatisiert in eine andere Struktur überführt werden und damit (effizient) 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 Informationslogistik zur Wahl stehen, wird im Nachfolgenden ein etwas ausführlicheres Beispiel gegeben. Es ist der Versicherungsindustrie entlehnt; in abgewandelter Form ist eine Übertragung auf andere Industrien möglich. Es ist durchaus üblich, von einer stabilen Menge von Währungen auszugehen, 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. Konsequenterweise 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ährungskursen ausgehen und sie fest im System zu codieren. Vielmehr werden separate, 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änderungen 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 kontinuierlicher Basis werden die aktuellen Wechselkurse von der führenden Quelle übernommen. Dieser Vorgang findet wegen der hohen Änderungsfrequenz automatisch statt. Die kostspieligen Umstellungen im Rahmen der Einführung des Euro sind Zeugnis für die zuweilen unvorhersehbaren Folgen der oben erwähnten Annahmen. (Wobei hinzugefügt werden muss, dass die Umstellungskosten 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 Informationslogistik, 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 stabile Schnittstelle aufgebaut. 4. Im Weiteren widmet sich der Entwicklungsprozess nur noch der Erstellung und Pflege von stabilen Modellaspekten, der Unterstützungsprozess 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 werden. 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 ausgelagert 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 Entwicklungsprozesses wird im Systementwurf nur auf diese Schnittstelle Bezug genommen. Während des Betriebs werden im Rahmen des Unterstützungsprozesses 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 angenommen, dass die Liste weitgehend unveränderlich ist. Daher ist es mög-

Metadaten, Referenzdaten, Stammdaten

187

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ährungsliste 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 Abschnitt benutzt die obigen Überlegungen und gelangt so zu einer Klassifizierung 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 Wechselkurse 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

Metadaten

Referenzdaten

Stammdaten

Abb. 1: Venn-Diagramm der Klassifizierung von Referenz-, Stamm- und Metadaten. Die Darstellung gruppiert Mengen (als Ellipsen) innerhalb ihrer Obermenge. (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 Management des Lebenszyklus der Daten im Vordergrund steht. Währungen haben 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 unter 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 ändert sich durch die Veränderungen auch nicht das fachliche Modell. Ein drittes Kriterium ist, ob die Daten zur Automation eingesetzt werden oder sich eher an einen menschlichen Nutzer wenden. Geschäftsterminologie ist dem letzten Fall zuzuordnen, während beispielsweise Datenmodelle 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 betrachtet werden. Im Rahmen dieses Prozesses wird ein Datenmodell verwendet, das auf Datenelemente Bezug nimmt. Der Lebenszyklus dieser Elemente wird entweder innerhalb oder außerhalb des zu erstellenden Systems kontrolliert. Beispielsweise kann ein System Währungen verwenden, aber ob eine bestimmte Währung als gültig erachtet wird und wann, ist eine 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 Modell, das Systeme beschreibt. Beispiel: Ein geographisches Informationssystem 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 x System: Wohin sollen die Daten geliefert werden? x 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 Bedeutung, sicherzustellen, dass die Aktualisierung quer über die gesamte Systemlandschaft stattfindet.

Metadaten, Referenzdaten, Stammdaten 2.3.1

189

Metadaten

Metadaten sind Daten, die unter Nutzung ihres Lebenszyklus in einem den Entwicklungs- bzw. Betriebsprozess unterstützenden Prozess dazu verwendet werden, Anpassungsleistungen an dort entstandenen 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 teilweise in anderen Prozessen wieder verwendet, sondern oft einzig in einem bestimmten Unterstützungsprozess genutzt. Zuletzt fokussiert man bei Metadaten auf die Anpassung einer Gruppe von (strukturell gleichförmigen) Produkten, nicht auf ein einzelnes Produkt. Im obigen Beispiel der Länderliste 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 Daten in die Kategorie Metadaten: x Fachbegriffe: Die Beschreibung der fachlichen Bedeutung von Modellelementen wird quer über verschiedene Produkte hinweg geteilt. Ändert sich an dieser Bedeutung etwas, können die korrespondierenden Anpassungen quer über die Produkte gleichförmig vorgenommen werden (z. B. indem sich eine geänderte Berechnungsformel in einem geänderten ETL-Datenfluss widerspiegelt). Die Anpassung findet hierbei manuell statt. x 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 Entwicklungsprozesses ereignenden Veränderungen am Modell automatisch zwischen den verschiedenen Werkzeugen (z. B. ETL, Datenmodellierung, Reporting) ausgetauscht werden können. x Geschäftsregeln: Die Regeln können von verschiedenen Produkten genutzt werden, um Änderungen in den fachlichen Anforderungen umzusetzen. 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. Generative 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 Systematisierung und (idealerweise auch) Automatisierung im Unterstützungsprozess zugänglich macht. Andererseits basiert die Nutzung auf dem Lebenszyklus 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 Abbildungsregeln 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 damit 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 Metadaten, 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: x Parametrisierung: Hierunter werden einfache Konfigurationsdaten verstanden, die nur eine Anpassung gegenüber simplen Veränderungen erlauben, z. B. eine Liste von Optionen. x Merkmals-Modellierung: Sie erlaubt die Kombination mehrerer verschiedener Merkmale zu einem durch Regeln bestimmten Ganzen, z. B. konditionale Ausdrücke wie bei der Modellierung verschiedener Sichten auf das Hauptbuch. x Meta-Programmierung: Dies ist die höchste, komplexeste Stufe, bei der die volle algorithmische Komplexität genutzt werden kann, z. B. Programmiersprachen.

Metadaten, Referenzdaten, Stammdaten

191

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 einzubettenden Kontext. Mithin werden sie an verschiedenen Orten in der Datenarchitektur (wieder)verwendet. Sie werden zur Automation benutzt: Es ist z. B. nicht unüblich, die Logik eines Systems in Abhängigkeit von selektierten 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 Unterschied 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 benutzt, aber nur für die Übernahme simpler Veränderungen. Diese Beschränkung ist aber praktischer, nicht formaler Natur. Durch die Einfachheit können die Daten an verschiedenen Stellen in der Datenarchitektur benutzt werden, ohne dass dafür im Interesse der Konsistenz für jede dieser 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 x x x x x

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 verwendet werden, um automatisiert Veränderungen im fachlichen Umfeld 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 externen 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 beschriebenen Art ermöglichen. Beispiele für Stammdaten, die weder Referenz- noch Metadaten wären unter anderem: x Wechselkurse x Zinssätze x 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 Referenz-, Stamm- und Metadaten

Nutzung für automatische Adoption von Veränderungen Fokus auf Wiederverwendung Nutzt den Lebenszyklus Bevorzugter Zeitpunkt der Nutzung Gegenstandsbereich

Stammdaten (ohne Metadaten (ohne Metadaten) Referenzdaten) Ja Teilweise

Referenzdaten

Ja

Selten

Ja

Nein

Ja

Ja

Betrieb

Entwicklung, Betrieb Technik, Fachlichkeit

Betrieb

Fachlichkeit

Ja

Fachlichkeit

2.4 Konsequenzen für die Informationslogistik Was bedeutet nun die oben beschriebene Semantik von Meta-, Referenzund Stammdaten für die Informationslogistik? Zunächst einmal ermöglicht sie eine differenziertere Betrachtung im Hinblick auf den jeweiligen Nut-

Metadaten, Referenzdaten, Stammdaten

193

zungszweck. Im Rahmen der Datenintegration und -evolution bietet sich dem Betreiber von DWHs und ODSs somit folgendes Bild: x Bei der Integration sind im Rahmen des Entwicklungsprozesses vor allem die technischen und fachlichen Metadaten von Interesse, um einerseits effizient arbeiten zu können bzw. sich andererseits ein schnelles Verständnis der Integrationsproblematik zu verschaffen. x Wiederverwendung beschleunigt vor allem bei Referenz- und Stammdaten einerseits die Übernahme von Veränderungen, führt aber andererseits auch zu einer Integration der Veränderungsprozesse, die hier vor allem unterstützender Natur sind. x Evolution kann mit verschiedenen Mitteln (Vergegenständlichung, Isolation) unterstützt werden; je einfacher dabei die dem Veränderungsprozess zu Grunde liegende Modellwelt, desto weniger werden Lebenszyklusmodelle gebraucht, was die Daten nutzenden Systeme unter anderem weniger abhängig voneinander macht. Insgesamt ist also eine dem Problem angemessene Auswahl der Datenklasse notwendig; die daraus entstehenden Konsequenzen für die Prozesslandschaft 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 womö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“), Referenzdaten („reference data“) und Metadaten unterschieden, die allerdings in

194

Hans Wegener

diesem Fall nicht dediziert ausgewiesen wurden, da es sich um Geschäftsterminologie und Daten für die Merkmals-Modellierung handelt. Stammdaten enthalten Referenzdaten, aber auch so genannte Kalkulationsparameter (z. B. Wechselkurse und Zinssätze). Referenzdaten beinhalten die Schlüssel von Aufzählungsattributen (z. B. Kunden, Verträge, Währungen, Risikoarten oder Länder) sowie auch die dazu gehörigen Attributwerte. Stamm- und Referenzdaten werden im Rahmen der Architekturprozesse unterschiedlich behandelt: Für die Referenzdaten werden Standardquellen definiert, die die offiziell sanktionierten Werte für ein Attribut enthalten. Für den architekturellen Review eines Systems gibt es eine genau festgelegte Definition für die Kompatibilität mit den Standardquellen; sie zielt darauf ab, dass alle Modellelemente so, wie sie in der Quelle definiert sind, auch in den abnehmenden Systemen wieder zu finden 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 fachsprachliche Kompatibilität zu prüfen. 3.2 Physische vs. logische Ebene in der Werkzeugintegration Modelle haben bei der Werkzeugintegration eine herausragende Bedeutung. Das Common Warehouse Metamodel (Poole et al. 2002) verspricht hier einen entscheidenden Fortschritt, indem es das Metamodell standardisiert und so eine nahtlose Integration der verschiedenen Werkzeuge erlaubt. Das CWM adressiert dabei Bereiche wie Datenstrukturen, Transformations- und Ableitungsregeln, Ladeprozesse, Datenquellen und -formate 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 physischen und logischen Stufe. Diese verschiedenen Betrachtungsperspektiven führen zunächst einmal zu verschiedenen Granularitätsstufen beim Metamodell (technische vs. fachliche Sicht) und dann zu Problemen bei der Integration der Metadaten. Beispielsweise war im Rahmen eines Projekts bei einer Bank geplant, die Datenmodelle über Metadaten mit Geschäftsterminologie zu verbinden, um so den Benutzern eine gezielte Suche nach Dateninhalten zu ermöglichen („Data Shopping“). Das Metamodell war an das CWM angelehnt worden, aber es stellte sich unter anderem heraus, dass das CWM nicht allen Benutzergruppen gerecht wird: Hoch spezialisierte Data Miner

Metadaten, Referenzdaten, Stammdaten

195

benutzten direkt das physische Datenmodell, um SQL-Anfragen zu formulieren, 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 Begriffen, 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 benutzt wurde, um unter anderem Dimensionsdaten für die Systeme zu modellieren und sie unmittelbar dorthin zu verteilen. Da aber natürliche Sprache mehrgestaltig ist, kam es dazu, dass ein Begriff wie „Country“ zum einen als „Type of Location“, also als Dimensionswert benutzt wurde, andererseits auch als Attribut Verwendung fand. Die resultierende Komplexitä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 Prozess. 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-ModellIntegration eine ungeheuer komplexe Herausforderung darstellt, die sowohl von den verfügbaren Werkzeugen als auch Metamodellen nicht wirksam unterstützt wird. Tatsächlich belassen es dann viele Projekte auch bei eher lose gekoppelten (Meta)Modellwelten und die gewünschten Effizienz- 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 Alleinstellungsmerkmale 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 zurückgegriffen werden muss. Bei der oben genannten Bank wurde das dort eingesetzte ETL-Werkzeug in eine größere System- und Prozesslandschaft eingebettet. Unter anderem sollten die Abbildungsregeln und -jobs nach so genannten „Projekten“ 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 organisatorischen 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 wieder die Art und den Zeitpunkt der Bereitstellung von Metadaten einschränken. Ob sie vor Auslieferung des fertigen Produkts oder danach gesammelt 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 Akzeptanz für Metadaten. 3.4 Den Kompromiss zwischen Bürokratie und Anarchie finden Die Beschleunigung der Entwicklung und Pflege integrativ wirkender Systeme 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 Datenintegration, machte aber den Erstellungs- und Pflegeprozess für die Referenzdaten unheimlich aufwändig, bürokratisch und letzten Endes für einige in der Organisation unannehmbar. Eine zumindest bei Referenz- und insbesondere bei Dimensionsattributen oft anzutreffende Alternative ist die „gemeinsam geteilte Wahrheit“,

Metadaten, Referenzdaten, Stammdaten

197

bei der lediglich eine Untermenge der Attributwerte von allen Systemen, Organisationen und Lokationen geteilt wird. Gerne gibt bei Konzernstrukturen die Zentrale die Untermenge vor (z. B. die obersten drei Ebenen der „Line of Business“) und dezentrale Einheiten sind frei, diese zu ergänzen und dafür bei der Datenlieferung an die Zentrale eine sachgerechte Abbildung vorzunehmen. Das gestaltet sich allerdings bei komplex zusammengesetzten Daten wie Kunden- oder Produktstruturen schwieriger, da nicht eindeutig klar sein muss, wie zentrale und dezentrale Eigenschaften 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 Unternehmen auseinandersetzen müssen. Durch die unterschiedlichen regulatorischen 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 garantieren.

4

Zusammenfassung

Dieser Beitrag hat die Unterschiede zwischen Stamm-, Referenz- und Metadaten herausgearbeitet. Alle haben zum Ziel, die Umsetzung von Veränderungen zu verbessern; sie benutzen aber unterschiedliche Mittel, um verschiedenen 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 Beitrag 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 Unterstützungsprozessen mit dem Geschäftsprozess unter Nutzung des Lebenszyklus der Daten. Stammdaten (insoweit Referenz- und Metadaten nicht darunter fallen) hingegen sind eine gesondert zu behandelnde Kategorie.

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 mangelnden Methodenstandardisierung, die damit einhergehen müsste. Aber es ist auch eine mittelbare Folge der mangelnden Kompatibilität der Werkzeuge. Es erscheint zweifelhaft, ob dieser Zustand in der nächsten Zeit bereinigt werden kann. Zusammenfassend bilden Stamm-, Referenz- und Metadaten das Rückgrat 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 DataWarehouse-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 Francisco 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. 132183. 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 Financial 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 ObjectOriented 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 Warehouse-Systemen, in: Schelp J. et al. (Hrsg.): Proceedings der DW2006 - Inte-

Metadaten, Referenzdaten, Stammdaten

199

gration, Informationslogistik und Architektur, Gesellschaft für Informatik, Friedrichshafen 2006, S. 83-106. Strahringer, S.: Metamodellierung als Instrument des Methodenvergleichs, Dissertation, 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: Memorandum des Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwendungssysteme, Universität Augsburg, Augsburg 2002.

10 Unternehmensweites Datenqualitätsmanagement: Ordnungsrahmen und Anwendungsbeispiele

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel Universität St. Gallen

1 2 3 4 5

Datenqualität als Grundlage der Informationslogistik .................... 201 Stand der Wissenschaft und Praxis ................................................. 203 Ordnungsrahmen für Datenqualitätsmanagement .......................... 205 DQM-Gestaltungselemente ............................................................ 208 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 Kundenservice. Beides führt dazu, dass Entscheidungen im Unternehmen in immer kürzeren Abständen und auf Grundlage einer wachsenden Menge an Informationen getroffen werden müssen. In diesem Kontext verfolgt die Informationslogistik das Ziel, Informationen zur Unterstützung sämtlicher Arten von Entscheidungen im Unternehmen 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

x Kundenmanagement: Zur Steigerung der Kundenzufriedenheit und zur Verbesserung des Kundenservice müssen sämtliche Daten, die im Unternehmen zu einem Kunden existieren, verfügbar sein. In der Praxis erfordert das häufig die Bereitstellung von Daten aus unterschiedlichen Informationssystemen, z. B. aus Systemen für das Customer Relationship Management (CRM) und aus Data Warehouse-Systemen. Voraussetzung für diese Kundendatenintegration ist eine hohe Datenqualität in den beteiligten Systemen. x Unternehmenssteuerung: Entscheidungs- und Führungsprozesse in Unternehmen sind durch wachsende Mengen an Informationen, kurze Entscheidungszyklen und steigende Komplexität der Entscheidungsbereiche 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. x Behördliche und gesetzliche Auflagen: Die Zahl an Vorgaben und Richtlinien, die Unternehmen zu beachten haben, steigt kontinuierlich. Um der damit verbundenen Nachweispflicht nachkommen zu können, müssen Unternehmen die erforderlichen Daten bereitstellen können. x Unternehmensvernetzung: In viele Branchen sinkt die Fertigungstiefe einzelner Unternehmen, was zu einer verstärkten Vernetzung und zu einem 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öpfungsketten 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. Geschäftsbereichen (s. auch Kap. 3). Denn Probleme mangelhafter Datenqualität treten in unterschiedlichen Organisationseinheiten auf, beispielsweise im Einkauf, wenn auf Grund inkonsistenter Lieferantenstammdaten Einkaufsvolumina nicht gebündelt werden können, oder bei der Produkteinfü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 erforderlich, verbessert, wenn die Daten zur Entscheidungsfindung bereitgestellt werden, und nicht bei ihrer Entstehung bzw. Pflege. Im Gegensatz

Unternehmensweites Datenqualitätsmanagement

203

zu reaktiven Maßnahmen der Datenqualitätsverbesserung zielt das präventive Datenqualitätsmanagement (DQM) darauf ab, die Datenqualität bereits bei der Entstehung der Daten in den Geschäftsprozessen sicherzustellen (Eppler u. Helfert 2004). DQM bezeichnet in diesem Zusammenhang das qualitätsorientierte Management der Daten; es umfasst die Erzeugung, Verarbeitung, Speicherung, Pflege und Darstellung hochqualitativer Daten. Unternehmensweites DQM ist eine Querschnittsfunktion und betrifft sämtliche Geschäftsbereiche 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 Entwicklung 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 anschließend in Abschn. 3 die Anforderungen an Aufbau und Inhalt des Ordnungsrahmens skizziert werden. Die einzelnen Elemente des Ordnungsrahmens werden in Abschn. 4 vorgestellt und mit Beispielen verdeutlicht. Der Beitrag schließt mit einer kurzen Zusammenfassung und einem Ausblick 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ührungen zu Grunde, ohne jedoch dabei die o. a. strategische Dimension zu vernachlässigen. Daten sind somit die Basis für Informationen, die wiederum 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ä-

204

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

higkeit, den Anforderungen für die Verwendung in einer bestimmten Situation 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ätsdimensionen zusammensetzt (Wang u. Strong 1996). Beispiele für derartige Datenqualitätsdimensionen sind Aktualität, Konsistenz, Vollständigkeit, Relevanz und Genauigkeit. Darüber hinaus ist die Sicherstellung von Datenqualität eine unternehmensweite 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 Ausrichtung und dezentralen Organisationsformen vor Herausforderungen. Derartige Unternehmen erzeugen und vertreiben unterschiedliche Produkte in mehr oder weniger autonom agierenden Geschäftsbereichen und in mehreren 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, unterschiedlichen fachlichen Anforderungen einzelner Geschäftsbereiche und länderspezifischen gesetzlichen Vorgaben entwickelt hat. Datenqualitätsprobleme treten dabei auf, wenn Daten aus unterschiedlichen Systemen und über verschiedene Geschäftsbereiche und Länder hinweg zusammengefü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 unternehmensweites DQM etablieren möchten. 2.2 Datenqualitätsmanagement (DQM) Datenmanagement umfasst die Definition einer Datenarchitektur, unternehmensweite Datenmodelle und Datenmodellierungsstandards, die Verwaltung der Daten und der Datenpflegeprozesse sowie die Informationssysteme 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 herausgebildet. Zu den wichtigsten gehören: x Total Data Quality Management (TDQM): Das TDQM-Programm wurde 1991 am MIT entwickelt und zielte darauf ab, DQM als Managementaufgabe zu etablieren und eine fundierte wissenschaftliche Basis

Unternehmensweites Datenqualitätsmanagement

205

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 Unternehmen. TDQM umfasst deshalb die Analyse der Kundenbedürfnisse an Daten, das Management des Datenproduktionsprozesses, den Lebenszyklus 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 unterschiedlichen 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). x 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 Kundenzufriedenheit durch Datenqualitätsverbesserungen. x 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 etablieren, ein einheitliches Verständnis über Datenmanagementfunktionen zu schaffen sowie Leitfäden und „Best Practices“ für die Umsetzung bereitzustellen. 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 Governance 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 Datenqualität herrschen manuelle Aktivitäten vor, es finden kaum präventive Maßnahmen statt, sondern es wird erst reagiert, wenn Datenqualitätsprobleme

206

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

aufgetreten sind und es gibt kaum eine klare Regelung der Verantwortlichkeit 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 zugehörigen Aufgaben sowie im Fehlen praktischer Werkzeuge zur Umsetzung (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 Anforderungen erfüllen: x Berücksichtigung nicht allein informationstechnischer, sondern auch organisatorisch-betriebswirtschaftlicher Aufgaben des DQM: DQM ist nicht ausschließlich eine Teilaufgabe des Managements der Informationstechnologie im Unternehmen. Die strategische Bedeutung hochqualitativer Daten sowie die fachliche Hoheit über Daten im Unternehmen erfordern eine Kopplung mit den betriebswirtschaftlichen Zielen im Unternehmen und eine organisatorische Verankerung, die auch die Fachseite einschließt (PwC 2004). x Unternehmensweite Anwendbarkeit, insbesondere über mehrere Geschäftsbereiche hinweg: DQM ist eine Querschnittsfunktion. Bestehende Ansätze (siehe Abschn. 2.2) fokussieren jedoch häufig einen einzelnen 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-Ansätze (siehe Absch. 2.2) können die folgenden sechs Gestaltungselemente für den Ordnungsrahmen abgeleitet werden: x x x x x x

Datenqualitätsstrategie Führungssystem Data Governance Datenmanagement-Prozesse Datenarchitektur und Datenhaltung Systemunterstützung Die Gestaltungselemente werden in Abschn. 4 im Einzelnen erläutert.

Unternehmensweites Datenqualitätsmanagement

207

3.3 Aufbau Dem Aufbau des Ordnungsrahmens liegt der Ansatz des Business Engineering zu Grunde (vgl. Kap. 2), um der Forderung nach betriebswirtschaftlich-organisatorischer Verankerung des Gestaltungsbereichs sowie der Anwendbarkeit über einzelne Organisationseinheiten hinweg Rechnung zu tragen. Grundsätzlich bestimmt die Unternehmensstrategie die Architektur der Geschäftsprozesse, die wiederum durch Informationstechnologie unterstützt werden (Davenport 1993; Hammer u. Champy 1993). Für die Gestaltung 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 Gestaltungselemente 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 Unternehmenszielen leisten soll. Das Führungssystem steuert die Umsetzung der Datenqualitätsstrategie und verbindet die Ebenen „Strategie“ und „Organisation“. Die Organisationsebene umfasst einerseits die so genannte Data Governance, 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. unternehmensweit gültige Warengruppenschlüssel einerseits und länderspezifische Gewichtseinheiten andererseits) einzelne Datenobjekte besitzen und nach welchen Regeln die Daten erfasst und gepflegt werden. Die Systemunterstützung umfasst zudem einerseits die Architektur der Informationssysteme, in denen die Daten gehalten werden sowie andererseits Vorgaben für Werkzeuge zur Erhöhung der Datenqualität, z. B. zur Datenbereinigung. Im folgenden Abschnitt werden die Gestaltungselemente des Ordnungsrahmens genauer erläutert und anhand von Beispielen illustriert.

208

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

Strategie Datenqualitätsstrategie

Führungssystem

Organisation

Data Governance

Systeme

DatenmanagementProzesse

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 Unternehmensstrategie auszurichten. Das umfasst i. d. R. die folgenden vier Aufgaben:

Unternehmensweites Datenqualitätsmanagement

x x x x

209

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 Detaillierungen. 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: x Bereitstellung einer zentralen und konsistenten Datenbasis zur analytischen Nutzung („Single Point of Truth“) für den Finanz- und Produktplanungsprozess eines Chemieunternehmens x Steigerung der Transparenz über Materialstammdaten als Voraussetzung für die Geschäftsprozessharmonisierung bei einem Konsumgüterhersteller x Konsolidierung der Lieferantenstammdaten für die Informationslogistik im Zentraleinkauf eines Automobilzulieferers x Steigerung der Flexibilität bei der Bereitstellung von Kundenstammdaten in einem Telekommunikationsunternehmen x Etablierung klarer Verantwortlichkeiten für Produktstammdaten bei einem 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). Fachliche Nutzenpotentiale

Datenqualitätskosten

Kosten schlechter Datenqualität

Kosten der Qualitätsverbesserung und -sicherung

Strategisch

Operativ

Direkte Kosten

Präventionskosten

Wettbewerbsvorteile

Verkürzte Prozessdurchlaufzeiten

Indirekte Kosten

Bereinigungskosten

Kundenzufriedenheit

…

Entdeckungskosten

…

Abb. 2. Kosten und Nutzen des DQM

210

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

Direkte Kosten schlechter Datenqualität fallen z. B an, wenn im Berichtswesen unterschiedliche Systeme verschiedene Werte für den gleichen Sachverhalt liefern (unternehmensweites Einkaufsvolumen bei einem Lieferanten o. ä.) und die Informationen verifiziert werden müssen. Zu indirekten 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 Datenqualität in einzelnen Datenbeständen verbessert wird. Unter Entdeckungskosten 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 zwischen so genannten strategischen Potenzialen, die i. d. R. nicht messbar sind und quantifizierbaren Nutzenpotenzialen. Zu letzteren zählen z. B. reduzierte Transportkosten durch genauere Gewichtsangaben bei Produkten und reduzierte Wartungskosten auf Grund der Verfügbarkeit von Anlagenstammdaten. 4.2 Führungssystem Das Führungssystem hat im DQM die Aufgabe, die Datenqualität zu messen, und bildet damit die Grundlage zur kontinuierlichen Verbesserung der Datenqualität im Unternehmen. In der Praxis haben sich einige Erfolgsfaktoren für die Etablierung von Führungssystemen herausgebildet: x Identifikation betriebswirtschaftlicher Führungsgrößen auf Basis der Anforderungen der Nutzer der Daten bzw. der aus ihnen resultierenden Informationen. x Festlegung von Zielwerten für die Führungsgrößen in Abstimmung mit den beteiligten Rollen (z. B. Prozess- und Systemverantwortliche). x Verankerung dieser Datenqualitätsziele in den Zielsystemen der beteiligten Organisationseinheiten und der beteiligten Mitarbeiter. x Festlegung von Maßnahmen im Falle von Abweichungen von Zielwerten. x Sicherstellung der Messbarkeit der Führungsgrößen. Die Gestaltung von Führungssystemen soll anhand eines Beispiels veranschaulicht werden. In Tabelle 1 ist das Führungssystem der Karstadt Warenhaus GmbH dargestellt (Schemm u. Otto 2007). Datenqualitätsprobleme ä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-

Unternehmensweites Datenqualitätsmanagement

211

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 Formatwechsel Wert (Absolutwert der For- Filiale, matwechsel) / Verbrauch Abteilung * 100 Pseudo-Bepo Wert (Wert Pseudo-Bepo) / Filiale, Wert Bepo Gesamt * 100 Abteilung Minusbestand Anzahl (Anzahl Bepo ohne Be- Filiale, stand) / (Anzahl Bepo Abteilung Gesamt) * 100 Inventurbestand Wert (Inventurbestand ohne Filiale, ohne BestellpoBepo) / Inventurbestand Abteilung sitionen * 100 EK-Differenzen Anzahl (Anzahl fehlerhafte Re- Abteilung po) / (Anzahl Repo Gesamt) * 100 Rechnungen oh- Anzahl (Anzahl Rechnungen Filiale, ne Auftrag ohne Auftrag) / (Anzahl Abteilung Rechnungen Gesamt) * 100 Fehlerlisten Anzahl (Absolutwert der Menge Filiale, mit Fehlern) / (Absolut- Abteilung wert der Gesamtmenge) * 100 StapfWert Wert der nachträglichen Filiale, Korrekturen Ergebniskorrekturen Abteilung

Periodizität Monatlich Monatlich Monatlich Jährlich Monatlich Monatlich

Monatlich

Monatlich

Karstadt definierte zwei Kennzahlen zur Messung dieses Problembereichs: x Im Fall eines so genannten „Formatwechsels“ verbuchen die Kassierer den nicht erkannten Artikel rein wertmäßig unter Angabe von Abteilung, Preis und Menge. Diese rein finanzwirtschaftliche Buchung führt zu einer Divergenz zwischen Finanz- und Warenwirtschaft. Die Kennzahl setzt die wertmäßige Summe aller Formatwechsel ins Verhältnis zum gesamten warenwirtschaftlichen Umsatz. x Im Fall einer Pseudo-Bestellposition (Bepo) verbuchen die Kassierer den nicht erkannten Artikel unter Angabe von Preis und Menge auf einer Pseudo-Artikelnummer. Analog zum Formatwechsel führt diese Buchung zu einem fehlerhaften Bestand, die Buchung ist jedoch in der Warenwirtschaft abgebildet und nachvollziehbar. Die Kennzahl setzt

212

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

den Wert aller Pseudo-Bepo ins Verhältnis zum Wert der gesamten Bestellpositionen. Die durch Formatwechsel und Pseudo-Bestellpositionen beeinflussten Bestandswerte misst Karstadt zusätzlich direkt durch zwei Qualitätskennzahlen: x Der Minusbestand setzt die Anzahl aller Bestellpositionen mit negativen Beständen ins Verhältnis zur Gesamtanzahl der Bestellpositionen. x 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 (EKDifferenzen) sowie die Anzahl an Rechnungen ohne Auftrag. Über Fehlerlisten erfasst Karstadt darüber hinaus alle weiteren warenwirtschaftlichen 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 Korrekturen 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: x Erstens benennt Data Governance die Aufgaben, die im DQM zu erfüllen sind. Hierzu gehören z. B. die Definition von Datenpflegeprozessen sowie die Definition von Metadaten. x Zweitens identifiziert Data Governance die an den Aufgaben beteiligten Rollen. x Drittens müssen Zuständigkeiten festgelegt werden, die die Aufgaben den Rollen zuordnen. Die Zahl und Ausgestaltung der Rollen für DQM variiert von Unternehmen zu Unternehmen in Abhängigkeit von der bestehenden Gremienlandschaft und Rollenstruktur. Es haben sich aber die folgenden fünf Rollen als übergreifend relevant herausgestellt (English 1999; Dyché u. Levy 2006):

1

Stapf: Statistisches Auswertungsprogramm Filialen.

Unternehmensweites Datenqualitätsmanagement

213

x Sponsor in der Geschäftsleitung, der das Mandat zur Umsetzung der DQM-Maßnahmen erteilt. x Data Governance-Komitee zur Koordination und Kontrolle der DQMMaßnahmen über Geschäftsbereichsgrenzen hinweg. x Konzern-Datensteward zur Definition und Fortschreibung der Datenqualitätsstrategie und deren Abstimmung mit allen involvierten Geschäftsbereichen. x Fachlicher Datensteward zur Umsetzung der Data-Governance-Vorgaben im Tagesgeschäft (z. B. in Datenerfassungs- und Datenpflegeprozessen). Fachliche Datenstewards werden für einzelne Datenobjekte (z. B. Kundenstammdaten, Materialstammdaten) oder Geschäftsprozesse (z. B. Auftragsabwicklung, Einkauf) eingesetzt. x Technischer Datensteward zur Umsetzung der Regeln und Vorgaben für die Datenobjekte in den Anwendungssystemen, z. B. in Enterprise Resource Planning (ERP)-Systemen. In der praktischen Umsetzung konkretisiert sich Data Governance häufig in Verantwortlichkeitsdiagrammen, wie in Abb. 3 dargestellt. Dabei werden in Form einer Matrix Aufgaben des DQM und die beteiligten Rollen gegenübergestellt. Die Beziehungen zwischen den Rollen und Aufgaben eignen sich zur Modellierung von Verantwortlichkeiten. Folgende Zuständigkeitstypen lassen sich unterscheiden: x Rechenschaftspflichtig – und damit entscheidungsbefugt – z. B. im Sinne eines Budgets. x Verantwortlich im Sinne der Durchführung. x Unterstützend, z. B. durch Einbringen von Fachkompetenz. x Informiert, z. B. nachdem eine Aufgabe erledigt oder eine Entscheidung getroffen wurde. Speziell im angelsächsischen Wirtschaftsraum haben sich zur Benennung der Zuständigkeitstypen Notationen wie RACI (Responsible, Accountable, Consulted, Informed) eingebürgert (IT Governance Institute 2007). Für die Zuordnung von Aufgaben zu Rollen über die Zuständigkeitstypen gibt es keine allgemeinen Handlungsempfehlungen. Vielmehr ist die Ausprägung des Verantwortlichkeitsdiagramms im Einzelfall von der spezifischen 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): x Grad der Diversifikation des Unternehmens x Grad der Geschäftsprozessharmonisierung

214

x x x x

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

Bestehende Aufbauorganisation Branchenzugehörigkeit Wettbewerbsstrategie Vorhandene DQM-Expertise

In Abb. 3 ist exemplarisch ein Verantwortlichkeitsdiagramm für ein global agierendes Unternehmen mit verschiedenen Geschäftsbereichen (Vertriebsgesellschaften) sowie Abstimmungsbedarf zur Konzernmutter (Holding) dargestellt. Dabei erfolgt die Benennung der Zuständigkeiten gemäß der o. a. RACI-Notation. Rollen DataGovernanceKomitee Governance-Modell

KonzernDatensteward

Techn. Datensteward

Gesellschaft

Holding

R,A

C

I

C

Stammdatenobjekte

A

C

R

C

C,I

Stammdatenprozesse

A

C

R

C

Prozessüberwachung Aufgaben

Prozessverantwortlicher

Stammdatenqualität

R,A A

Qualitätsüberwachung

R

C

C

R,A

I

I

Stammdatenpflege

A

Informationsarchitektur

A

R

C

Projekte

I

R,A

C

R

R

C

R,A

C

C

R,A

I

Support Training Kommunikation

I

R: Responsible

A: Accountable

I I

C

I R

C

C

C,I C

I

C: Consulted

I I: Informed

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 Unternehmens, z. B. in Beschaffungs- und Vertriebsprozesse. Im Kontext eines präventiven Datenqualitätsmanagements sind die Datenmanagementprozesse derartig zu gestalten, dass die Datenqualität bei der Erfassung und Aktualisierung der Daten sichergestellt ist, also im Vorfeld der analytischen Nutzung. Durch die Definition, Modellierung und Implementierung von Datenmanagementprozessen lassen sich Aufwendungen für nachfolgende Maßnahmen zur Datenbereinigungen vermeiden.

Unternehmensweites Datenqualitätsmanagement

215

Die unterschiedlichen Datenmanagementprozesse werden am Beispiel der Pflege von Materialstammdaten erläutert. Grundsätzlich werden drei Prozesse unterschieden: x Anlage: Die Auslöser für die Anlage eines neuen Materialstammdatensatzes können vielfältig sein und hängen häufig von der Art des Materials ab. Die Anlage eines neuen Fertigprodukts beispielsweise wird von der Entwicklungsabteilung angestoßen, während die Anlage eines Rohmaterials vom Einkauf ausgelöst wird. Die Anlage sämtlicher Attribute erfolgt sukzessive gemäß der Sichten (nutzerspezifischen Attributmengen) durch die entsprechenden Prozessverantwortlichen. x Pflege: Über den Informationslebenszyklus eines Materials ergeben sich Änderungen, die in den Stammsatz übernommen werden müssen. Auslöser dafür sind z. B. die Änderung der Herstellung eines Produkts, die Änderung der Verpackung oder die Erweiterung des Verkaufsgebiets. x 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 Stammsä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 unterschiedlich gestaltet. Zum Beispiel sind die Prozesse für die Anlage und Pflege der Grunddaten eines Lieferantenstammdatensatzes zumeist unternehmensweit standardisiert und einer zentralen Stelle (z. B. im Zentraleinkauf) 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 Hoven 2003). Im Rahmen des DQM umfasst die Gestaltung der Datenarchitektur folgende Aufgaben: x Identifikation der Menge an relevanten Datenobjekten und Attributen: Im unternehmensweiten DQM werden häufig nur diejenigen Objekte

216

x x x x

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

betrachtet, die geschäftsbereichsübergreifend verwendet werden (z. B. Lieferanten- und Materialstammdaten). Definition der Beziehungen der Datenobjekte und Attribute untereinander. Festlegung einer eindeutigen Definition für die Datenobjekte und Attribute sowie Identifikation von Synonymen und Homonymen. Festlegung der organisatorischen Gültigkeit der Datenobjekte und Attribute (z. B. unternehmensweit vs. länderspezifisch). Festlegung des Wertebereichs für Attribute.

Die Gestaltung der Datenarchitektur bildet somit eine Grundlage für effiziente Informationslogistik, denn sie ermöglicht durchgehende Datenflüsse zwischen verschiedenen Organisationseinheiten. In Abb. 4 sind ausgewählte Elemente der Datenarchitektur am Beispiel eines Materialstammsatzes veranschaulicht. Materialstammsatz Grunddaten • Materialnummer • Materialbezeichnung

• Abmessungen • Mengeneinheit

• Materialgruppe •…

Funktionsspezifische Sichten Vertrieb • Verkaufspreis • Skontofähig • Min. Auftragsmenge •… Merkmale • Organisationseinheiten

Disposition • Losgrösse • Dispositionsmerkmal • Sicherheitsbestand • ...

Einkauf • Einkaufspreis • Toleranzen für Über/ Unterlieferung • ...

Buchhaltung • Preissteuerung • Bewertungsklasse •… • ...

…

• Sprache •…

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äftsprozesse relevant sind, werden Sichten je nach Geschäftsprozess unterschieden. 4.6 Systemunterstützung Die Systemunterstützung des DQM umfasst Aspekte der Architektur der Systeme, in denen die Daten gehalten werden, sowie derjenigen Werkzeuge, 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

Unternehmensweites Datenqualitätsmanagement

217

DQM, wohingegen Bereinigungswerkzeuge als reaktive Maßnahme infolge 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): x Das führende System ist das in der Praxis am häufigsten verwendete Verfahren für die Stammdatenverteilung. Dabei wird eines der bestehenden Systeme als führendes System für eine Stammdatenklasse definiert und ist damit Ausgangspunkt für die Verteilung an die anderen Systeme. Das erstmalige Anlegen der Stammdaten geschieht im führenden System mit den dort vorhandenen Attributen. Da in dieser Variante kein vollständig harmonisiertes Datenmodell vorliegt, sind bei der Verteilung Datenergänzungen in den empfangenden Systemen sowie ein Mapping von Primärschlüsseln und Attributen auf das Datenformat des Zielsystems notwendig. x 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 grundsätzlich in einem zentralen System statt, allerdings auf Basis eines harmonisierten 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 direkter 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 Stammdatensystem oft über zusätzliche Funktionalitäten und Workflow-Unterstützung für die Datenmanagementprozesse. x Die Verwendung von Standards führt nicht zu einer zentralen Speicherung 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 Standardisierung der globalen Attribute stellt sicher, dass einerseits ein Minimum an Attributen erfasst wird und diese andererseits in jedem System dieselbe Bedeutung haben. In der praktischen Umsetzung führt ein

218

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

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. x Bei der Föderation über ein Verzeichnis (Registry) werden systemübergreifend Zuordnungen der verschiedenen Stammdatensätze zu den verschiedenen Quellsystemen verwaltet. Benötigt beispielsweise ein System 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 Ansatz wird typischerweise bei sehr großen und verteilten Datenbeständen verwendet.

5

Zusammenfassung und Ausblick

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 Bedeutung des DQM als Managementaufgabe wird verkannt. Als Werkzeug zur Verknüpfung des DQM mit den betriebswirtschaftlichen Zielen eines Unternehmens, zur Verankerung in der Organisation sowie zur Gestaltung der einzelnen DQM-Aufgaben dient der vorgeschlagene 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 Weiterentwicklungen werden im Competence Center Corporate Data Quality des

Unternehmensweites Datenqualitätsmanagement

219

Instituts für Wirtschaftsinformatik der Universität St. Gallen in Zusammenarbeit mit Partnerunternehmen erarbeitet.

Literatur DAMA: Data Management Body of Knowledge (DMBOK) Functional Framework, 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 Burden, G00137680, Gartner Group, Stamford 2006. Hammer, M.; Champy, J.: Reengineering the Corporation: A Manifesto for Business 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, Boston 2006. Legner, C.; Otto, B.: Stammdatenmanagement, in: WISU - Das Wirtschaftsstudium 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 Francisco 2003. Österle, H.; Blessing, D.: Ansätze des Business Engineering, in: HMD 42 (2005) 241, S. 7-17.

220

Boris Otto, Kristin Wende, Alexander Schmidt, Kai Hüner, Tobias Vogel

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 Warenhaus 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 Consumers, 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 Information Quality (ICIQ-07), Cambridge 2007, S. 163-176. Wijnhoven, F.; Boelens, R.; Middel, R.; Louissen, K.: Total Data Quality Management: A Study of Bridging Rigor and Relevance, in: Österle H. et al. (Hrsg.): Proceedings of the 15th European Conference on Information Systems (ECIS), St. Gallen 2007.

11 Einsatzmöglichkeiten serviceorientierter Architekturen in der Informationslogistik

Barbara Dinter Universität St. Gallen

1  2  3  4  5 

1

Einleitung ....................................................................................... 221  Das Konzept der serviceorientierten Architektur ........................... 222  Einsatz serviceorientierter Architekturen in der Informationslogistik ............................................................................................ 227  Anwendungsszenarien serviceorientierter Architekturen in der Informationslogistik ....................................................................... 233  Zusammenfassung .......................................................................... 238  Literatur .......................................................................................... 239 

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 Unternehmen zu etablieren. Sowohl unternehmensinterne IT-Abteilungen als auch externe IT-ServiceDienstleister stehen heute vielfach vor der Herausforderung, sich in immer kürzer werdenden Zeitabständen flexibel an Änderungen in der Unternehmensstruktur anpassen und neue bzw. geänderte Geschäftsprozesse unterstü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 zunehmenden Bedeutung von SOA im operativen Umfeld vor die Notwendigkeit gestellt, dieses Paradigma hinsichtlich seines Einsatzpotenzials in dispositiven 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 „traditionellen“ IL-(Architektur)-Konzepten zum Einsatz kommt) bzw. welche Anwendungsmöglichkeiten sich daraus ergeben. Folglich ist das Spannungsfeld Informationslogistik und serviceorientierte 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 realisieren: • Beschleunigung der Datenintegration (ermöglicht Real Time Data Warehousing) • Automatisierung in den Entscheidungen (ermöglicht Active Data Warehousing) • Integration von Geschäftsprozessmanagement und Informationslogistik (prozessorientierte Informationslogistik) Das Kapitel gliedert sich wie folgt: In Abschn. 2 werden die grundlegenden Konzepte, Begriffe und Nutzenpotenziale von serviceorientierten Architekturen vorgestellt. Abschnitt 3 zeigt auf, wie Serviceorientierung in der Informationslogistik gestaltet werden kann und welchen Umsetzungsstatus dieses Thema heutzutage in der Praxis hat. Welche Anwendungsmö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 Bereitstellung und Nutzung von fachlichen Funktionalitäten als Dienstleistung ermö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 ITArchitektur im Idealzustand nicht mehr aus monolithischen Applikationen, sondern aus standardisierten, entlang der fachlichen Funktionalität geschnittenen Komponenten (Services) aufgebaut. Basierend auf den Geschäftsprozessen werden grobgranulare Funktionalitäten definiert, die in Form von Services gekapselt werden. Diese Services lassen sich über standardisierte Schnittstellen ansprechen. Damit werden Softwarefunktionalitäten aus dem starren Gerüst einer Applikation herausgelöst und können in verschiedenen Kontexten verwendet werden. Dadurch wird die Ablaufsteuerung aus den Applikationen auf eine übergeordnete Instanz verschoben („lose Kopplung“ und „Orchestrierung“ von so genannten Applikationsservices zu so genannten Enterprise Services zur flexiblen Unterstü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 sichergestellt. 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 Verortung im Business Engineering Framework (vgl. Kap. 2) an. Wie in (Winter 2008) erläutert, lässt sich das Prinzip der Serviceorientierung auf den Gestaltungsebenen 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 Business Engineering Framework:

224

Barbara Dinter Gestalten* der Strategie • • • •

Strategieebene

Geschäftsnetzwerkmodelle Kundenprozessmodelle Leistungsmodelle Zielsystem

Gestalten* der Organisation

3

Organisationsebene

2 Integrationsebene

1 Softwareebene

• • • •

Gestalten* der Integration • • •

Applikationslandschaft Fachliche Services Geschäftsfunktions-/ Informationsobjektmodelle

Gestalten* von Software • •

Infrastrukturebene

Prozesslandkarte/Prozessmodelle Aufbauorganisation Informationslandkarte Prozess-Services

Softwarekomponenten/ Software-Services Datenmodelle

Gestalten* der IT-Infrastruktur * Gestalten = Prozess der Erst- und Weiterentwicklung

• •

Plattforminfrastruktur Netzwerkinfrastruktur

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 charakterisiert: Die Services der Software-Architektur (Software-Services) sind technisch 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 Wiederverwendung. Software-Services sind die Voraussetzung, um auf der Integrationsebene 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änderungen möglichst einfach unterstützen zu können (Pfeil 2). Die Services

Einsatzmöglichkeiten serviceorientierter Architekturen

225

der Prozessarchitektur (Prozess-Services) fassen inhaltlich abgeschlossene Aktivitäten zusammen, die ein wohl definiertes Ergebnis mit betriebswirtschaftlichem 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 anzutreffende Verständnis, das Services auf technische Services (meist WebServices) 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 ITArchitekturen 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

Investitionsschutz

Komplexitätsreduktion

Kosteneinsparung

Evolutionäre Erweiterbarkeit

OutsourcingPotenzial

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 Schnittstellen von verschiedenen Prozessen genutzt werden, Mehrfachentwicklungen werden vermieden. Voraussetzung ist dabei eine geeignete Granularitä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ömmlichen Applikationen werden die Koordinationsmechanismen in die Integrationsebene verlagert und damit von den funktionalen Komponenten getrennt. Zusätzlich ermöglicht die Standardisierung von Schnittstellen eine Reduktion der Schnittstellenzahl. Wartbarkeit: In „traditionellen“ Applikationslandschaften müssen Änderungen 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 Schnittstellen 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 Anforderungen der Business-Seite zu reagieren. Dabei wird sowohl die Agilität (d.h. die effiziente Reaktion auf geplante Änderungen) als auch die Flexibilitä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 kompletten Neuplanung einer Applikationslandschaft aus. Vielmehr können bestehende Applikationen durch Kapselung ihrer Funktionalität in Services für SOA befähigt werden und so Altanwendungen länger und flexibler als bisher 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 serviceorientierter 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 gewachsene Software lässt sich durch die Integration über eine einheitliche SOAInfrastruktur ablösen. Outsourcing-Potenziale: Outsourcing-Potenziale lassen sich leichter identifizieren, denn aufgrund der Plattformunabhängigkeit, der weitestgehenden 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 beispielsweise eine Verkürzung der Time-to-Market, die Reduktion operati-

Einsatzmöglichkeiten serviceorientierter Architekturen

227

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 serviceorientierten 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 Ausgangssituationen anzutreffen. In vielen Fällen ist oder wird SOA (zumindest punktuell) im operativen Bereich eingeführt, so dass die ILOrganisationseinheiten, sei es durch die unternehmensweite IT veranlasst oder aus Eigeninteresse, vor der Frage stehen, ob und wie sie das serviceorientierte Paradigma auch im dispositiven Umfeld einsetzen werden. Es gibt aber durchaus auch Fälle, in denen die Informationslogistik eine Vorreiterrolle spielt und etwa zur Umsetzung bestimmter Anwendungsszenarien (vgl. Abschn. 4) auf SOA zurückgreift. Trotz der intensiven Diskussion des serviceorientierten Architekturparadigmas ist bislang allenfalls unzureichend untersucht, welche Implikationen die Einführung einer SOA für die Informationslogistik hat. Bestehende Arbeiten und Literatur adressieren in der Regel ausgewählt