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ählte Aspekte, hierbei insbesondere bestimmte Anwendungen. Daher wird im Anschluss zunächst eine Systematisierung vorgenommen, die aufzeigt, wo welche Services in einer IL-Architektur denkbar und sinnvoll sind. Aus ihnen lassen sich dann die in Abschn. 4 vorgestellten Einsatzmöglichkeiten von SOA in der Informationslogistik ableiten. 3.1 Services in der Informationslogistik Die Informationslogistik kann sowohl als Service Provider als auch als Service Consumer fungieren. Auch lassen sich Funktionalitäten innerhalb der dispositiven Systeme über Services abbilden. Hierbei hat sich mittlerweile hat ein gewisser Konsens herausgebildet, welche Services man in einer IL-Architektur differenzieren kann, wenngleich Klassifizierungskriterien, Terminologie und einzelne Servicetypen sich noch unterscheiden (vgl. Gordon et al. 2006; Besemer 2007; Dittmar 2007; Gassman 2007; Martin u. Nussdorfer 2007).
228
Barbara Dinter
Infrastruktur-Services
Abbildung 3 zeigt die Anordnung der am häufigsten genannten Servicetypen in einer generischen und vereinfachten IL-Systemarchitektur, die sich an der Hub and Spoke-Architektur (vgl. auch Kap. 7) orientiert. Die verschiedenen Servicetypen werden im Folgenden kurz vorgestellt.
Abb. 3. Services in der Informationslogistik-Systemarchitektur 3.1.1
Sourcing (oder Backend) Services
In der Vergangenheit wurden operative Quellsysteme „traditionell“, d.h. via herkömmlicher Datenschnittstellen (sei es mit ETL-Tools oder Eigenentwicklungen) angebunden. Insbesondere, wenn die operativen Systeme bereits serviceorientiert gestaltet sind, bietet sich an, die entsprechenden Zugriffsmöglichkeiten auch zu nutzen. Dies können sowohl Services sein, die extra für diesen Zugriff geschaffen werden (Extraktionsservices) als auch bereits bestehende Services der operativen Applikationen. Stehen die Services über einen Service Bus zur Verfügung, kann dieser ggf. an die Integrationsinfrastruktur für das Data Warehouse angebunden werden, so
Einsatzmöglichkeiten serviceorientierter Architekturen
229
dass die einzelnen Transaktionen auf dem Bus mitverfolgt und aktuelle Daten abgegriffen werden können (Schelp 2007). Im Gegensatz zu den durch Batchverarbeitung verursachten Verzögerungen (Latenzen) können auf diese Weise ereignisgesteuert Datenbewirtschaftung und folglich auch die Datenbereitstellung beschleunigt werden, was insbesondere bei zeitkritischen Vorgängen den entscheidenden Faktor ausmachen kann (vgl. auch Abschn. 4.1). Zudem lassen sich historisierte Daten aus dem Data Warehouse mit aktuellen („Real Time“- bzw. „Right Time“-) Daten aus den operativen Systemen transparent integrieren, ohne dass der Endanwender den Zugriff auf verschiedene Quellsysteme realisieren würde. Schließlich kann der SOA-Ansatz unter Umständen die Anbindung weitere Datenquellen ermöglichen, wenn beispielsweise unstrukturierte Daten integriert werden sollen. In der Praxis sind noch technische Restriktionen (wie die Verfügbarkeit der beteiligten Systeme und die Last auf der Businfrastruktur) und logische Herausforderungen (wie die gleichzeitige Verfügbarkeit aller für die Weiterverarbeitung in den ETLProzessen benötigten Daten aus verschiedenen Quellsystemen) zu meistern sowie ökonomische Fragen wie die Kosten, die mit der Protokollierung aller Daten verbunden sind (Schelp 2007). 3.1.2
Transformations-Services
Prinzipiell könnte auch die Transformationsfunktionalität innerhalb der Datenbewirtschaftungsprozesse, die üblicherweise einen großen Anteil an Entwicklungskapazitäten bindet, über Services realisiert werden. Ähnlich wie die Funktionsbausteine (Templates) der ETL-Tools stellen die Services dann Funktionalitäten wie Aggregationen, Filterungen, Umschlüsselungen, Formatkonvertierungen oder Joins zur Verfügung. Eine solche komplette Substituierung ist in der Praxis noch kaum anzutreffen, wenngleich die führenden ETL-Hersteller zunehmend Web Service-Schnittstellen anbieten, mit denen Transformationsfunktionen als Web Services zur Verfügung gestellt werden können. In (Wu et al. 2007) wird aufgezeigt, wie ETL-Prozesse durch Services ersetzt werden können. (Gordon et al. 2006) illustriert an einem Beispiel einen möglichen Mehrwert einer solchen Vorgehensweise: Fehlen in der Datenbewirtschaftung zunächst Datensätze aus einer Quelle (ein häufiges Problem in der Praxis), findet die Verarbeitung zunächst mit einer Art Platzhalter statt und eine entsprechende Notifikation wird an das „säumige“ Quellsystem geschickt, das seinerseits die fehlenden Daten via Services „nachliefert“, sobald sie bereitstehen.
230 3.1.3
Barbara Dinter Analytische (oder Frontend) Services
Neben den Sourcing-Services haben die analytischen Services (auch Frontend Services genannt) derzeit die höchste Praxisrelevanz, nicht zuletzt da sie einen wesentlichen Enabler für die so genannte Operationalisierung der BI (bzw. der Informationslogistik) darstellen (vgl. Abschn. 4.2). Via analytischer Services können die Produkte der Informationslogistik (oder Teile davon, vgl. auch Abschn. 4 in Kap. 12 und Abschn. 2.4 in Kap. 4) zur Nutzung bereitgestellt werden. Einen Überblick über analytische Services mit Anwendungsbeispielen findet sich u. a. in (Martin 2006; Martin u. Nussdorfer 2007), in denen die Autoren folgende Arten von Services unterscheiden: • • • • • • • •
Kennzahlen Berichtsservices Abfrageservices (Ad hoc und OLAP) Analyseservices (Datenvisualisierung, Data Mining, statistische Werkzeuge) Planung und Simulation Dashboard-Services (Präsentationssservice zur Veröffentlichung eines Scorecard-Modells) Alerting- und Broadcasting-Services interaktive Analytik (Datenexplorationsumgebung).
Die ebenfalls genannten Ausprägungen Datenintegration und EchtzeitAnalytik adressieren die in Abschn. 4 genannten Anwendungsszenarien. Beispiele für analytische Services könnten etwa Scorings, Kundenwertsegmentierung oder Bonitätsrating sein. Zahlreiche BI Tools können zumindest weniger komplexe Produkte der Informationslogistik (Kennzahlen, Reports, …), wie sie oben genannt wurden, in der Regel als Web Services zur Verfügung stellen bzw. in Portale integrieren. Umgekehrt ermöglichen bereits manche Werkzeuge, dass auf XML-Daten anderer Services zugegriffen und die Daten beispielsweise in einen Report eingearbeitet werden können. Die Rückführung der Analyseergebnisse in die operativen Systeme lässt das Data Warehouse innerhalb einer SOA aus Sicht der (operativen) Services als weiteren operativen Service in Erscheinung treten. Hier ist jeweils zu prüfen, ob die verwendeten Systeme einen solchen Closed Loop überhaupt leisten können (ob sie beispielsweise Variantenbildung bei Änderungen unterstützen etc.). Zugleich müssen den operativen Repositories die notwendigen Metadaten zur Verfügung gestellt werden, um die analytischen Services in gleicher Form in die operative Servicelandschaft einbin-
Einsatzmöglichkeiten serviceorientierter Architekturen
231
den zu können, wie es bei den operativen Services der Fall ist (Schelp 2007). 3.1.4
Infrastruktur-Services
Ergänzend zu den Services, die entlang des Datenflusses von den operativen Quellen hin zu den Informationskonsumenten anzusiedeln sind, gibt es Querschnittsaufgaben, die ebenfalls mit Hilfe von Services umgesetzt werden können. Sie betreffen im Wesentlichen die Infrastrukturthemen, wie sie bereits in Kap. 3, Abschn. 3.1.1 eingeführt wurden, und hierbei insbesondere Metadaten- und Stammdatenmanagement, Datenqualitätsmanagement sowie Datenschutz und Datensicherheit. In jedem dieser Themenfelder ist ein breites Spektrum an Services denkbar, sei es die Generierung von technischen Metadaten oder die Verknüpfung fachlicher und technischer Metadaten, die Durchführung von Plausibilitätschecks oder die Unterstützung des Datenqualitätsreportings durch Messung von Datenqualitätskennziffern oder Authentifizierungsservices. Letztere Services sind per se anwendungsneutral und damit auch nicht IL-spezifisch, so dass die (unternehmens- oder geschäftsbereichsweite) Wiederverwendungsquote eines solchen (generischen) Authentifizierungsservices vergleichsweise hoch sein dürfte. Dies illustriert die Realisierung eines wesentlichen Nutzenpotenzials des serviceorientierten Architektur-Paradigmas. 3.1.5
Umsetzung
Welche Services dann technisch umgesetzt werden und auch wie, hängt von den jeweiligen unternehmensspezifischen Anforderungen und technischen Rahmenbedingungen ab. Denkbar ist beispielsweise, dass die oben genannten Servicetypen über einen Enterprise Service Bus und das zugehörige Service Repository mit den operativen Services verbunden werden und damit durch Rückschreiben von Informationen in die operativen Quellen so genanntes Closed Loop realisiert werden kann. Angesichts der in Abschn. 2.1 getroffenen Unterscheidung von Servicetypen sollte man sich bei den oben genannten Services durchaus vor Augen halten, um welche Art von Service es sich jeweils handelt. Eine kritische Betrachtung der hier identifizierten Services zeigt, dass die Trennung von fachlichen Services und Software-Services durchaus sinnvoll ist. Bei den Infrastruktur-Services, Sourcing Services und TransformationsServices handelt es sich überwiegend nicht um fachliche Services, die fachliche Funktionalität zur Verfügung stellen würden. Vielmehr handelt es sich bei diesen Services um Softwarekomponenten, die fachlich neutrale Funktionalitäten wie z. B. Autorisierung oder Datenbankzugriffe ermögli-
232
Barbara Dinter
chen. Dagegen stellen die analytischen Services fachliche Funktionalitäten in Form von Enterprise Services zur Verfügung, ebenso wie einzelne Transformations-Services, die z. B. anhand von Geschäftsregeln Bewertungen berechnen oder Aggregationen vornehmen. 3.2 State of the Art in der unternehmerischen Praxis Im Sommer 2007 wurde auf einer Anwenderveranstaltung zum Data Warehousing eine Umfrage zum Thema „Serviceorientierte Architekturen in BI-Systemen“ durchgeführt (Bucher et al. 2007). 67 ausgefüllte Fragebögen gingen in die Auswertung ein. Abbildung 4 verdeutlicht, dass bei den befragten Unternehmen signifikante Bestrebungen bestehen, Services in die BI-Systeme (Informationslogistik) zu integrieren. Organisatorisch wird in zunehmendem Maße gezielt Know How zur Einführung von SOA in BI-Systemen aufgebaut. Dieses Know How soll in dedizierten Projekten zur Einführung von SOA in BI-Systemen verwendet werden und im Rahmen anstehender BI-Projekte zur (zunächst) punktuellen Einführung von SOA beitragen. Zukünftig soll das Service-Angebot in den Bereichen der Frontend Services (analytische Services), der Infrastruktur-Services und der Backend Services (in Abschn. 3.1 als Sourcing Services bezeichnet) verstärkt ausgebaut werden. Die einzelnen Servicetypen werden vergleichsweise ähnlich in ihrer Relevanz bewertet (Bucher et al. 2007). Auch künftig sind in der Gewichtung keine Verschiebungen zu erwarten. niedrig
Projekte & Service-Definition
In welchen Bereichen Ihrer BISysteme sind Services definiert?
hoch h
z
Es wird Know How zur Einführung von SOA in BI-Systemen aufgebaut
1,45
2,32
Es gibt dedizierte Projekte zur Einführung von SOA in BI-Systemen
1,20
2,03
Im Rahmen anstehender BI-Projekte wird SOA (punktuell) eingeführt
1,40
2,31
Es wird zwischen fachlichen und technischen Services unterschieden
1,81
2,55
Frontend Services
1,55
2,73
Infrastruktur Services
1,71
2,76
Backend Services
1,71
2,64
0
1
2
heute
Abb. 4. Umsetzungsgrad von BI und SOA (Bucher et al. 2007)
3
4
zukünftig
Ø 1,55 Ø 2,48
Einsatzmöglichkeiten serviceorientierter Architekturen
233
Die Umfrage zeigte, dass sich Unternehmen (zumindest zukünftig) mit der Einführung von Services im BI-Umfeld auseinandersetzen. Ähnliche Erkenntnisse lieferte eine Studie von Ventana Research im Oktober 2006. Demnach hielten mehr als 81% der Befragten SOA für BI für wichtig (Ventana Research 2006; Besemer 2007). Knapp 50% der Studienteilnehmer in den Fachbereichen meinten, dass BI-Services Informationen breiter verfügbar machen würden und dass die Fähigkeit des Business verbessert würde, schneller auf Veränderungen zu reagieren. Umgekehrt vertraten auf IT-Seite ca. 66 % der Befragten die Auffassung, dass BI-Services der IT helfen könnten, die Bedürfnisse des Business besser zu verstehen, während weitere 33% v. a. die leichtere Integration und die niedrigeren Lifecycle Management-Kosten als wesentliche Vorteile betrachten. Auch in dieser Studie wurden die Servicetypen Frontend und Backend Services (letztere beinhalten dort auch die Transformations- und Infrastruktur-Services) in etwa gleich gewichtet. Bei beiden Servicetypen planten mehr als die Hälfte der befragten Unternehmen eine baldige Umsetzung (Ventana Research 2006; Besemer 2007). Mehrheitlich hielten die Studienteilnehmer den Aufbau von Know How für die vordringlichste Aufgaben (53%), gefolgt von der Überprüfung der BI-Hersteller hinsichtlich ihrer SOA-Fähigkeiten (49%) und der Identifikation der ITRessourcen, die für Migration und Betrieb einer SOA-Umgebung notwendig wären (48%). Nur ein Drittel der Unternehmen traut ihrer internen IT das notwendige Know How zu, BI-Services zu implementieren (Everett 2006; Ventana Research 2006).
4
Anwendungsszenarien serviceorientierter Architekturen in der Informationslogistik
Als wesentliche Treiber für die Einführung von SOA in der Informationslogistik werden immer wieder die beiden Anwendungsgebiete Real Time / Active Data Warehousing bzw. Operationalisierung der Informationslogistik ins Feld geführt. Diese und weitere Anwendungsszenarien werden im Folgenden kurz vorgestellt. 4.1 Real Time Data Warehousing und Active Data Warehousing Die Agilität eines Unternehmens und die Nutzung des Faktors Zeit können als wesentliche Beiträge zur Sicherung der Wettbewerbsfähigkeit eines Unternehmens angesehen werden. Der Bedarf nach Beschleunigung von
234
Barbara Dinter
Entscheidungsprozessen trägt der Tatsache Rechnung, dass Maßnahmen umso wirksamer und wertvoller sind, je früher sie ergriffen werden. Wie bereits erwähnt, trägt SOA zur schnelleren Datenbereitstellung für Entscheidungsprozesse bei. Somit ist dieser Architekturansatz ein wesentlicher Enabler für das so genannte Real Time Data Warehousing. Auch wenn im Folgenden der Begriff „Real Time“ verwendet wird, so sei darauf hingewiesen, dass in den meisten Fällen der Ausdruck „Right Time“ treffender wäre, denn er bezeichnet eine für eine bestimmte Situation angemessene Geschwindigkeit (in diesem Fall: der Informationsbereitstellung). In (Gassman 2007) illustrieren Anwendungsbeispiele den kontextabhängigen unterschiedlichen Zeitbedarf: Im Wertpapierhandel werden Informationen sofort benötigt, für Analysen im Call Center im Sekundenbereich, für Auftragsbestätigungen im Minutenbereich, etc. Für (Nahezu-)Echtzeit gibt es (noch) vergleichsweise wenige Anwendungsanfälle, insbesondere angesichts technischer Herausforderungen und vergleichsweise hoher Kosten. Studien wie (Steria Mummert Consulting 2006) bestätigen diese Beobachtung aus der Praxis. Zur Realisierung von Real Time Data Warehousing wird in der Regel über den Einsatz von EAI (Enterprise Application Integration)Werkzeugen diskutiert, die dann in Ergänzung zu oder anstelle von ETLTools zur Datenbewirtschaftung (insbesondere bei Lösungen mit einem Operational Data Store) Verwendung finden. Eine Referenzarchitektur für ein Real Time Data Warehouse findet sich in Abschn. 3.2.2 des Kap. 7. SOA für die Datenbewirtschaftung (im Kontext Real Time) bedeutet auch einen Paradigmenwechsel vom traditionellen Pull-Prinzip (der ETLWerkzeuge) hin zum Push-Prinzip. Das hat u. a. auch organisatorische Implikationen, wenn etwa sich die Verantwortung für die Datenbereitstellung in die Quellsysteme verlagert. In (Tho Manh et al. 2007) wird mit ZELESSA eine Infrastruktur vorgestellt, deren BI Real Time-Architektur mit Hilfe von SOA realisiert wird. Neben „traditionellen“ Analysen auf dem Data Warehouse kann über so genannte Event Streams „Real Time Analytics“ stattfinden. Auch in (Abrahiem 2007) wird aufgezeigt, wie SOA beitragen kann, ein (Near) Real Time Data Warehouse aufzubauen. Zur Vertiefung zu Real Time Data Warehousing sei verwiesen auf (Schelp 2006; Abrahiem 2007; Tho Manh et al. 2007). Ebenfalls zur Beschleunigung von Entscheidungsprozessen dient das Konzept des Active Data Warehousing (auch unter Active BI oder Eventdriven BI bekannt). Im Gegensatz zum herkömmlichen Data Warehouse werden hier, sobald bestimmte, zuvor definierte Bedingungen erfüllt sind, relevante Personenkreise automatisch durch das analyseorientierte Informationssystem darüber in Kenntnis gesetzt (Push-Prinzip). Alternativ wer-
Einsatzmöglichkeiten serviceorientierter Architekturen
235
den automatisch ebenfalls zuvor spezifizierte Aktionen in der Systemumgebung angestoßen. Ziel ist die teilweise oder vollständige Automatisierung von Routineentscheidungen. Die Notwendigkeit der Ereignissteuerung im Active Warehousing wird wiederum durch SOA in besonderem Maße unterstützt. Für eine Referenzarchitektur sei ergänzend auf Kap. 7, Abschn. 3.2.1 verwiesen. 4.2 Prozessorientierte Informationslogistik Das Konzept der prozessorientierten Informationslogistik wird in Kap. 6 ausführlich vorgestellt. Auch in Kap. 1 wird unter dem Begriff „Operational Intelligence“ ausgeführt, wie analytische Informationen in die Ausführung operativer Geschäftsprozesse integriert werden können und welche Rolle SOA in diesem Kontext spielt. In (Bucher u. Dinter 2008) werden die Nutzenpotenziale einer solchen Verschmelzung erörtert: Sie reichen von Beschleunigung der Prozessausführung, qualitativer Verbesserung der Prozessleistung über höhere Kosteneffizienz bis hin zu Steigerung der Transparenz und Erhöhung von Flexibilität und Agilität. Ein einfacher Beispielprozess (ein Kundenanruf im Call Center) soll dies illustrieren (vgl. Abb. 5). Der Agent benötigt für ein optimales Kundenangebot analytische Informationen, z. B. den Kundenwert (setzt sich z. B. zusammen aus Mahnstufe, durchschnittlichem Rechnungsbetrag der letzten 12 Monate etc.) oder einen Produktvorschlag, der optimal zum Kundenprofil passt. Analytische Services ermöglichen hier eine transparente und zeitnahe Informationsbereitstellung und können ggf. mit den restlichen operativen Services dieses Prozesses „verzahnt“ werden. Die Abläufe werden dokumentiert und sauber strukturiert. Auftragsbearbeitung Kunde ruft in Call-Center an
Anrufgrund identifizieren
...
Agent unterbreitet optimales Angebot
Nimmt Kunde Angebot an
ja
nein
Agent hält Ergebnis fest Kundenwert ermitteln
Service „Ermittle Kundenwert“
Passendes Produkt ermitteln
Regeln anwenden
Angebot erstellen
Service „Ermittle passendes Produkt“
Abb. 5. Beispiel eines Geschäftsprozesses mit Nutzung von analytischen Services
236
Barbara Dinter
Weitere Fallbeispiele für prozessorientierte Informationslogistik finden sich in (Bucher u. Dinter 2008). (Raden 2006) enthält ebenfalls eine Übersicht. Die hohe Bedeutung von analytischen Informationen in Geschäftsprozessen wird durch Studien bestätigt, wie beispielsweise in (Steria Mummert Consulting 2006), der zufolge mehr als 70% der Unternehmen das BI-System bereits für das operative Tagesgeschäft nutzen. Eine weitere Konvergenz von Geschäftsprozessmanagent und Business Intelligence ist im Kontext Corporate Performance Management (CPM) zu beobachten. (Martin u. Nussdorfer 2007) gehen ausführlich auf die Bedeutung des Zusammenwachsens von BI und Geschäftsprozessen ein. Mit CPM können Unternehmensziele und Geschäftsprozesse kontinuierlich aufeinander abgestimmt und konsistent gehalten werden. Entsprechend müssen Prozesse geplant, überwacht und gesteuert werden. Laut (Martin u. Nussdorfer 2007) wird dieses CPM mit einer serviceorientierten Architektur realisiert. Auch (Dinter u. Bucher 2006) betrachten CPM als einen umfassenden Ansatz zur Steuerung der Wertschöpfung von Unternehmen. Folglich umfasst CPM neben der strategisch-taktischen Komponente auch eine operative Komponente, durch die die Verbindung hin zu den Geschäftsprozessen sowie deren Management und Messung geschaffen wird. Als Business Activity Monitoring (BAM) wird dabei die EchtzeitÜberwachung und Analyse kritischer Prozesskennzahlen bezeichnet, wodurch eine Entscheidungsunterstützung für das operative Management ermöglicht wird. Ziel ist die Verkürzung der Durchlaufzeiten sowie die Verbesserung der Effektivität von Geschäftsprozessen. Insbesondere, wenn die zu Grunde liegenden Geschäftsprozesse bereits in einer SOA eingebettet sind, bietet sich an, die für die Analysen relevanten Prozesskennzahlen auch über Services bereitzustellen (Dinter u. Bucher 2006). 4.3 Standardisierung der Nutzung analytischer Informationen In Abschn. 3.1.3 wurde ausgeführt, welche analytischen Services eine Informationslogistik-Infrastruktur in ihrer Rolle als Service Provider zur Verfügung stellen kann. Neben den bereits genannten Anwendungsmöglichkeiten unterstützt die Bereitstellung analytischer Informationen via Services eine Homogenisierung der Informationsversorgung, wie Abb. 6 veranschaulicht.
Einsatzmöglichkeiten serviceorientierter Architekturen
237
Ausgangssituation Reporting
Dashboards
Data Mining
Planung
Domäne 1
Domäne 2
Domäne 3
DWH
DWH
DWH
Zugriff via standardisierter Services Service
Service
Service
Service
Reporting
Dashboards
Data Mining
Planung
DWH
DWH
DWH
Abb. 6. Standardisierter Zugriff auf analytische Informationen durch Services
Historisch gewachsen oder durch Veränderungen in der Unternehmensstruktur bedingt (etwa bei Mergers and Acquisitions) liegen in vielen Unternehmen heterogene dispositive Systeme vor. Folglich werden Anwender mit unterschiedlichen Zugangsmöglichkeiten (heterogene Schnittstellen und/oder Werkzeuge) konfrontiert und sind oft nicht in der Lage, zu lokalisieren, wo sich die für sie relevanten Informationen befinden (bzw. ob sie überhaupt vorliegen). SOA kann hier helfen, für die Informationskonsumenten einheitliche Zugriffe via Services bereitzustellen. Standardisierte Zugriffe und Transparenz über die zu Grunde liegenden Informationsquellen helfen beim Auffinden benötigter Informationen und steigern die Nutzerakzeptanz. Schliesslich wird damit auch dem Trend Rechnung getragen, analytische Informationen nicht nur einem breiteren Anwenderkreis zugänglich zu machen, sondern diese mit innovativen Mitteln und über unterschiedliche Kanälen zugreifbar zu machen. Die analytischen Informationen sollen Teil der täglichen Arbeit werden und demzufolge integriert in Unterneh-
238
Barbara Dinter
mensportale, Suchmasken oder über verschiedene Medien zugreifbar sein. Die Bereitstellung via Services unterstützt ein solch breites Spektrum besser als traditionelle Ansätze. Analytische Services tragen damit bei zum Paradigmenwechsel vom Bring- zum Holprinzip hinsichtlich der Informationsversorgung der Unternehmensbereiche. Weitergehende Informationen zu einer möglichen technischen Umsetzung finden sich u. a. in (Hulford 2006).
5
Zusammenfassung
Im Beitrag wurde nach einer Einführung in das Konzept serviceorientierter Architekturen gezeigt, wo und wie dieses Paradigma in der Informationslogistik eingesetzt werden kann. Mit der Übertragung des SOA-Ansatzes in die Informationslogistik kommt man der Vision eines geschlossenen Handlungskreislaufes zwischen operativen und dispositiven Systemen einen entscheidenden Schritt näher. Wie in Abschn. 4 ausgeführt wurde, fungiert SOA zudem als Enabler für eine Beschleunigung (und ggf. Automatisierung) von Entscheidungsprozessen, was den Unternehmen nachhaltige Wettbewerbsvorteile verschaffen kann. Zunächst unterscheiden sich die Methoden zur Gestaltung der Services und die technischen Realisierungsmöglichkeiten für SOA allgemein und für SOA in der Informationslogistik nicht allzu sehr. Dennoch sollten immer die Spezifika der dispositiven Systeme berücksichtigt werden. In (Schelp 2007) wurde aufgezeigt, dass die vorrangigen Gestaltungsziele in operativen Systemen (im Wesentlichen Agilität) sich unterscheiden von denen in der Informationslogistik, die u. a. die zeitliche Stabilität in der Vordergrund rückt. Bei der Einführung von SOA stehen die Domänen Operativsysteme und Informationslogistik vor ähnlichen Herausforderungen. Diese sind fachlicher Natur – hier insbesondere die Schaffung einheitlicher Terminologien, einer notwendigen Voraussetzung für bereichsübergreifende, idealerweise unternehmensweite (Wieder)Verwendung von Services – aber auch technischer und organisatorischer Natur. Noch sind SOA-Projekte, insbesondere im Kontext der Informationslogistik, von einer gewissen Unsicherheit geprägt. Neben fehlendem Know How in den Unternehmen gibt es auch nur wenige etablierte Best Practices in methodischer (und teilweise auch in technischer) Hinsicht. Der Schritt vom Hypethema hin zu einem Konzept mit tragfähigen und umfassenden Lösungen ist noch nicht zur Gänze vollzogen.
Einsatzmöglichkeiten serviceorientierter Architekturen
239
Folglich bietet sich neben einem gezielten Know How-Aufbau ein iterativer Ansatz zur Umsetzung an. Machbarkeitsstudien und Pilotierung werden dringend empfohlen, bevor Erfahrungen idealerweise in Projekten mit übersichtlichem und handhabbarem Scope gesammelt werden. Dabei ist insbesondere darauf zu achten, konsequent in allen Projektphasen die Fachbereiche einzubeziehen. Der Aufbau einer serviceorientierten Architektur geht einher mit dem Aufbau passender Organisationsstrukturen. Auf Serviceebene sind Verantwortlichkeiten eindeutig festzulegen, eine klare und gelebte SOA-Governance (Keller 2007; Schelp u. Stutz 2007) stellt einen kritischen Erfolgsfaktor dar. Eine ausführliche Übersicht über Erfolgsfaktoren serviceorientierter Architekturen findet sich in (Durst u. Daum 2007). Hier wird auch die Relevanz der Verankerung von SOAInitiativen in der Unternehmens- und IT-Strategie betont, die einhergehen muss mit einer entsprechenden Unterstützung durch die Unternehmensleitung. Zudem erfordern SOA-Projekte ein starkes Business/IT-Alignment: Gerade wenn solche Initiativen aus der IT heraus gestartet werden, besteht sonst die Gefahr einer zu technischen Perspektive.
Literatur Abrahiem, R.: A new generation of middleware solutions for a near-real-time data warehousing architecture, in: Proceedings of the 2007 IEEE International Conference on Electro/Information Technology, Chicago 2007. Aier, S.; Schelp, J.: EAI und SOA - Was bleibt nach dem Hype?, in: Bichler M. et al. (Hrsg.): Proceedings der Multikonferenz Wirtschaftsinformatik 2008 (MKWI 2008), GITO-Verlag, München 2008, S. 1469-1480. Aier, S.; Winter, R.: Serviceorientierung - Ein Architekturthema, http://www.isisspecials.de/profile_pdf/3u005_ed_soa0108.pdf, Besemer, D.: Getting Started Now on SOA for BI, in: DM Review (2007) May 2007, S. 26-27. Bucher, T.; Dinter, B.: Anwendungsfälle der Nutzung analytischer Informationen im operativen Kontext, in: Bichler M. et al. (Hrsg.): Proceedings der Multikonferenz Wirtschaftsinformatik 2008 (MKWI 2008), GITO-Verlag, München 2008, S. 41-42. Bucher, T.; Dinter, B.; Lahrmann, G.; Schmaltz, M.; Stroh, F.: Ergebnisdokumentation 7. CC EIW Workshop, 2007. Dinter, B.; Bucher, T.: Business Performance Management, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Business IntelligenceTechnologien und -Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 23-50.
240
Barbara Dinter
Dittmar, C.: Integration von Real Time Business Intelligence in eine SOA – Auf dem Weg zum Active Business Intelligence, in: Gluchowski P. et al. (Hrsg.): Schlaglichter der Wirtschaftsinformatik, guc, Chemnitz 2007, S. 129-142. Durst, M.; Daum, M.: Erfolgsfaktoren serviceorientierter Architekturen, in: HMD - Praxis der Wirtschaftsinformatik 253 (2007), S. 18-27. Everett, D.: Service-Oriented Architecture for Business Intelligence Isn't Well Understood, http://www.dmreview.com/news/1072118-1.html, 29.02.2008. Gassman, B.: Data Integration for Strategic Business Intelligence and Beyond, Gartner, Stamford 2007. Gordon, S.; Grigg, R.; Horne, M.; Thurman, S.: Service-Oriented Business Intelligence, in: The Architecture Journal (2006) 1. Heutschi, R.: Serviceorientierte Architektur: Architekturprinzipien und Umsetzung in die Praxis, Springer-Verlag, Berlin, Heidelberg 2007. Hulford, P.: Why SOA is Important to Your BI Solutions, in: DM Review (2006) 4, S. 34-36. Keller, W.: SOA-Governance, in: Starke G. et al. (Hrsg.): SOA Expertenwissen, dpunkt, Heidelberg 2007, S. 289-308. Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA - Service-Oriented Architecture Best Practices, Pearson, Upper Saddle River 2005. Martin, W.: Analytics meets Enterprise SOA, 2006. Martin, W.; Nussdorfer, R.: CPM – Corporate Performance Management, Annecy 2007. Oey, K. J.; Wagner, H.; Rehbach, S.; Bachmann, A.: Mehr als alter Wein in neuen Schläuchen: Eine einführende Darstellung des Konzepts der serviceorientierten Architekturen, in: Aier S. et al. (Hrsg.): Unternehmensarchitekturen und Systemintegration, 2. Aufl., Gito, Berlin 2006, S. 197–220. Raden, N.: An Analytics Manifesto, 2006. Schelp, J.: Real-Time Warehousing und EAI, in: Chamoni P. et al. (Hrsg.): Analytische Informationssysteme - Business Intelligence-Technologien und Anwendungen, 3. Aufl., Springer, Berlin et al. 2006, S. 425-438. Schelp, J.: Ansatzpunkte zur Übertragung Serviceorientierter Konzepte auf das Data Warehousing, in: Gluchowski P. et al. (Hrsg.): Schlaglichter der Wirtschaftsinformatik - Festschrift zum 60. Geburtstag von Roland Gabriel, guc, Chemnitz 2007, S. 143-156. Schelp, J.; Stutz, M.: SOA Governance, in: HMD - Praxis der Wirtschaftsinformatik 253 (2007), S. 66-73. Starke, G.; Tilkov, S. (Hrsg.): SOA-Expertenwissen - Methoden, Konzepte und Praxis serviceorientierter Architekturen, Heidelberg 2007. Steria Mummert Consulting: Business Intelligence-Studie 2006 - Wie gut sind die BI-Lösungen der Unternehmen im deutschsprachigen Raum?, Steria Mummert Consulting AG, Düsseldorf 2006. Tho Manh, N.; Schiefer, J.; Min Tjoa, A.: ZELESSA: an enabler for real-time sensing, analysing and acting on continuous event streams, in: International Journal of Business Intelligence and Data Mining 2 (2007) 1, S. 105-141. Ventana Research: Service-Oriented Architecture for Business Intelligence. Trends, Needs and Practices, 2006.
Einsatzmöglichkeiten serviceorientierter Architekturen
241
Winter, R.: SOA braucht eine klare Definition, in: Computerwoche 34 (2008) 3, S. 20. Wu, L.; Barash, G.; Bartolini, C.: A Service-oriented Architecture for Business Intelligence, in: Proceedings of the IEEE International Conference on ServiceOriented Computing and Applications, Newport Beach, CA 2007, S. 279-285.
12 Methode zur Gestaltung einer Leistungsverrechnung für DWH Competence Center
Mario Klesse Universität St. Gallen
1 2 3 4 5 6
Problemstellung und Herausforderungen ....................................... 243 Ziele einer Leistungsverrechnung .................................................. 245 Elemente einer Leistungsverrechnung............................................ 246 Information als Produkt und Informationsproduktion .................... 247 Vorgehensmodell der Methode ...................................................... 257 Zusammenfassung und Ausblick .................................................... 269 Literatur .......................................................................................... 271
1
Problemstellung und Herausforderungen
Innerbetriebliche Informationslogistik wird häufig durch Data Warehousing-Konzepte realisiert (vgl. Kap. 3). Data Warehousing basiert auf einer weitgehend zentral gemanagten Integrationsinfrastruktur, die entwickelt und betrieben werden muss. In der Praxis wird diese Aufgabe häufig von innerbetrieblichen DWH Competence Centern (DWH-CC) wahrgenommen (vgl. Kap. 5). Obwohl Data Warehousing in der Unternehmenspraxis mittlerweile einen ähnlich hohen Reifegrad erreicht, wie die operative Applikationslandschaft und deren Betreuung (Chamoni et al. 2004), besteht das Problem, dass für DWH-CCs serviceorientierte Konzepte, wie bspw. in der ITIL (OCG 2001) beschrieben, nicht vorhanden sind. Während in der IT-Unterstützung operativer Prozesse Services definiert, ihre Kosten ermittelt und diese den Fachabteilungen (Leistungsabnehmern) in Rechnung gestellt werden (z. B. OCG 2001; Scheeg 2005), vermag auch heute noch kaum ein DWH-Leistungserbringer zu bestimmen, was die von
244
Mario Klesse
ihm angebotenen Informationsprodukte kosten und in welcher Qualität sie geliefert werden (Chamoni et al. 2004, S. 44f). Dieser Rückstand ist auf einige besondere konzeptionelle Schwierigkeiten bei der Entwicklung einer Leistungsverrechnung für das Data Warehousing zurückzuführen. Um Leistungen zu verrechnen, müssen Produkte definiert und Preise für diese ermittelt werden. Allein bei diesen Kernaufgaben bestehen zwei wesentliche Unterschiede zwischen operativer IT und der IT-Unterstützung von Entscheidungsprozessen: Zum Ersten unterscheidet sich das „Produkt“ des Data Warehousing erheblich von denen der operativen Welt. Während die operative Anwendungslandschaft in der Regel repetitive Prozesse unterstützt und die dazu bereitzustellenden Funktionen im Vordergrund stehen, zentriert sich die dispositive Applikationslandschaft im Data Warehousing um Informationen, die in Entscheidungsprozessen benötigt werden. Zum Zweiten fällt es schwer, die Kosten von Informationen in ihrem mehrstufigen Produktionsprozess entlang der DWH-Architektur zu bestimmen, nicht zu sprechen von der äußerst problematischen Nutzenbestimmung von Informationen (Rehberg 1973, S. 98ff. und 113ff.). Hinzu kommen die Probleme, die daraus resultieren, dass ein Grossteil des Data Warehousing auf gemeinsam genutzter Infrastruktur basiert (vgl. Kap. 3). Hierzu zählen nicht nur technische Plattformen, sondern auch Teile der Software, der Datenbestände und nicht zuletzt die Leistungen des DWH-CC. Dies führt unvermeidlich zu hohen, meist fixen Gemeinkosten, die sich in der Regel einer streng verursachungsgerechten Zuordnung zu Leistungsabnehmern entziehen. Gleiches gilt für alle Arten von Investitionen (z. B. Entwicklung, Plattformausbau etc.) in die weitgehend gemeinsam genutzte DWH-Landschaft. Hier resultieren aus der Gemeinkostenproblematik mitunter sogar Investitionsstaus, da Erweiterungen und Optimierungen der Infrastruktur keinem Kunden so recht zuzuordnen sind (Jung u. Winter 2001). Im Folgenden wird eine Methode (Gutzwiller 1994) vorgestellt, die es DWH-CCs erlaubt, ihre Leistungen zu strukturieren, in Produkte zu bündeln und in verständlicher Form abzurechnen. Vorraussetzungen für den Einsatz sind neben der Organisation als DWH-CC ein mittlerer bis hoher Reifegrad des Data Warehousing, d.h. die organisatorischen Prozesse im DWH-CC sollten weitgehend definiert sein und das DWH-CC sollte eine weitgehende Eigenverantwortung für seine Kosten haben. In vielen Großunternehmen sind diese Voraussetzungen heute gegeben (Klesse 2007, S. 46-52). Zunächst werden dazu die Ziele und die wesentlichen Bestandteile einer Leistungsverrechnung dargestellt. Anschließend werden mit dem Informationsprodukt und dem Informationsproduktionsmodell zwei wesentliche konzeptionelle Voraussetzungen vorgestellt. Danach wird das Vorgehens-
Leistungsverrechnung für DWH Competence Center
245
modell der entwickelten Methode skizziert. Es umfasst die wesentlichen Schritte, die zur Gestaltung einer DWH-Leistungsverrechnung nötig sind. Die vollständige Methode ist in (Klesse 2007, S. 219-383) dokumentiert. Der Beitrag schließt mit einer Zusammenfassung und einem Ausblick auf Weiterentwicklungsmöglichkeiten.
2
Ziele einer Leistungsverrechnung
Leistungsverrechnung ist kein Selbstzweck, sondern hat immer mehrere Ziele, die allgemein der Wirtschaftlichkeit dienen sollen. Je nachdem, wie die Prioritäten gesetzt werden, ist eine Leistungsverrechnung auch unterschiedlich auszugestalten (Marzinzik 1998, S. 68). Eine Leistungsverrechnung folgt jedoch immer drei Primärzielen (Gschwend 1986, S. 71): x Kostenrechnerisches Ziel: Im Mittelpunkt des kostenrechnerischen Ziels steht die objektive und zweckneutrale Wiedergabe des Werts der transferierten Leistung (Gschwend 1986, S. 78-80). Dies ist bspw. von Bedeutung, um Budgets zu planen und zu kontrollieren, um unternehmerische Entscheidungen zu fundieren oder um Marktleistungen zu kalkulieren. x Lenkungsziel: Durch die Steuerungswirkung von Verrechnungspreisen sollen dezentrale Entscheidungen derart koordiniert werden, dass sich auf Gesamtunternehmensebene optimale Entscheidungen ergeben (Gschwend 1986, S. 71-74). Einerseits soll der Leistungserbringer dahingehend gesteuert werden, sein Leistungsportfolio hinsichtlich Inhalt, Qualität und Preis am Leistungsabnehmer auszurichten. Anderseits soll der Leistungsabnehmer in seinem Nutzerverhalten dahingehend beeinflusst werden, vorhandene Kapazitäten des Leistungserbringers optimal auszunutzen. x Erfolgszuweisungsziel: Die einzelnen Unternehmensbereiche sollen ihren Anteil am Erfolg zugerechnet bekommen und dadurch zur Leistungssteigerung und Effizienzerhöhung motiviert werden (Gschwend 1986, S. 77-77). Beispielsweise soll der DWH-Leistungserbringer dazu motiviert werden, seine Ressourcen optimal auszunutzen. Gleichzeitig soll der Abnehmer zum wirtschaftlichen Einsatz der DWH-Leistungen angehalten werden. Dabei muss sich auch das Instrument der Leistungsverrechnung selbst in seiner Ausgestaltung dem Wirtschaftlichkeitsziel unterordnen (Fürer 1993, S. 32; Marzinzik 1998, S. 57). Die Berücksichtigung dieser Ziele ist immer
246
Mario Klesse
ein Kompromiss, sie sind daher unternehmensindividuell verschieden zu priorisieren.
3
Elemente einer Leistungsverrechnung
Der Gestaltungsgegenstand einer Leistungsverrechnung lässt sich in zwei Bereiche aufteilen (Abb. 1). Dies ist zum einen die Schnittstelle zum Leistungsabnehmer, welche für den Kunden sichtbare Elemente enthält. Dazu zählen folgende Elemente (OCG 2001, S. 33-38, 64-69, 92ff.): x Produkte / Services: Die Produkte bzw. Services stellen jene gebündelten Leistungen dar, die dem Abnehmer durch den Leistungserbringer angeboten werden bzw. für diesen erbracht werden. Wichtig für die Wirkung einer Leistungsverrechnung ist, dass diese für den Leistungsabnehmer verständlich und nutzenstiftend ist. Zudem sollte ihre Qualität beschrieben sein, damit nicht einseitig Kosten optimiert werden. x Abrechnungsmodell: Das Abrechnungsmodell legt die Form und Ausgestaltung der Abrechnung gegenüber dem Leistungsabnehmer fest. Die hierbei in der Praxis häufig angewandten Umlageverfahren erfüllen die Anforderungen an eine Leistungsverrechnung nicht (Britzelmaier 1999, S. 44). Damit eine Leistungsverrechnung die gewünschte Wirkung entfaltet, muss das Abrechnungsmodell preisbasiert sein. Die Abrechnungsgrößen, d.h. die Einheiten, die für die Produkte letztlich bepreist werden, sollten sich dabei an den gesetzten Zielen der Verrechnung orientieren. x Preismodell: Das Preismodell legt die Art und Weise der Preisbildung für die Abrechnungseinheiten der Produkte fest. Im unternehmensinternen Kontext von DWH-CCs ist die Bildung langfristig kostendeckender Verrechnungspreise in der Regel Grundanforderung. Diese sollten zudem auf nachvollziehbare Art und Weise entstehen, da sonst die Akzeptanz im innerbetrieblichen Kontext nicht gegeben ist. Zum anderen sind dies Elemente, die lediglich für den DWH-Leistungserbringer sichtbar sind und ihm bei der Planung und Istermittlung von Kosten, Qualität und Mengen seiner Produkte unterstützen. Dazu zählen folgende Elemente (OCG 2001, S. 33-38, 70-75): x Internes Leistungsmodell: Die extern angebotenen Produkte / Services korrespondieren mit internen Leistungen. Diese wiederum setzen sich aus entsprechenden Teil- bzw. Vorleistungen zusammen. Diese Leistungen müssen daher erfasst, strukturiert und miteinander in Beziehung gesetzt werden, um Qualität, Wert und Menge von Leistungen planen zu
Leistungsverrechnung für DWH Competence Center
247
können und letztlich das kostenrechnerische Wertabbildungsziel zu erfüllen. x Kosten- und Leistungsrechnungssystem: Das Kosten- und Leistungsrechnungsrechnungssystem (KLR-System) bildet die internen Leistungen, Produkte und Abrechnungsgrößen in Form von Kostenarten, Kostenstellen und Kostenträgern ab, so dass sich die Kosten der Leistungen bestimmen lassen.
Abb. 1. Gestaltungselemente einer Leistungsverrechnung
4
Information als Produkt und Informationsproduktion
Die Kernfrage „Was ist eigentlich das Produkt eines DWH-CCs?“ bildet den Ausgangspunkt der Gestaltung einer Leistungsverrechnung. Die in der Praxis gängigen Umlageverfahren nach Speicherplatz oder CPU-Sekunden unterstellen, dass dies das Produkt des DWH-Leistungserbringers ist. Das ist aber sicher nicht der Fall. Die Fachabteilungen benötigen zur Unterstützung ihrer Prozesse Informationen, die das DWH-CC mithilfe eines DWHInformationssystems bereitstellt. Was liegt also näher, als die Information selbst als Produkt zu definieren? Diese Sichtweise ist im Informationsqualitätsmanagement seit langem akzeptiert (Ballou et al. 1998; Wang et al. 2002) und entspricht dem Paradigma einer serviceorientierten IT, nachdem ein IT-Produkt einen engen Bezug zum Prozess des Leistungsabnehmers aufweisen soll (OCG 2001;
248
Mario Klesse
Scheeg 2005). Übertragen auf das Data Warehousing lässt sich jedes DWH-Produkt als Kombination von Informationsprodukten und Prozessbzw. Supportleistungen beschreiben. Definiert man Informationsprodukte als Kernleistung eines DWH-CC, folgt daraus auch der primäre Leistungsprozess – die Informationsproduktion (Wang et al. 2002). Dieser Prozess stellt aus Rohdaten über verschiedene Zwischenstufen qualitätsgesicherte Informationsprodukte her. Alle anderen Prozesse eines DWH-CCs sind folglich Supportprozesse der Informationsproduktion, d.h. sie liefern entweder Leistungen, x die Voraussetzung für die Informationsproduktion sind (z. B. Entwicklung), x die die Informationsproduktion unmittelbar unterstützen (z. B. fachlicher Betrieb), x die die Informationsproduktion tatsächlich ausführen (z. B. technischer Betrieb), x oder die den Kunden bei der Nutzung der Informationsprodukte unterstützen (z. B. fachlicher Support). Legt man diese Sichtweise zu Grunde, lassen sich Leistungen und Kosten auch unmittelbar verursachungsgerecht einzelnen Schritten der Informationsproduktion zuordnen. Für die Methode wurden daher zwei zentrale Modelle entwickelt. Das erste Modell dient der Beschreibung von Informationsprodukten (Abschn. 4.1). Das zweite Modell formalisiert den Informationsproduktionsprozess und seine Zulieferprozesse so weit, dass auf dieser Basis die Qualität, Kosten und Leistungen der zur produzierenden Information geplant werden können (Abschn. 4.2). 4.1 Informationsproduktmodell Das Informationsproduktmodell (IP-Modell) wurde so gestaltet, dass es sowohl zur Abbildung von Rohdaten, von Zwischenprodukten in der Informationsherstellung („Informationsobjekte“) als auch zur Abbildung der Endprodukte („Informationsprodukte“) geeignet ist. Basis des Modells sind Ansätze aus dem Informationsqualitätsmanagement (Wang u. Strong 1996; Nelson et al. 2005) und dem IT Service Management (OCG 2001; Klesse 2007, S. 206-218). Das Modell unterscheidet zwei Dimensionen und zwei Schichten (Abb. 2).
Leistungsverrechnung für DWH Competence Center
249
Abb. 2. Modell eines Informationsprodukts
Die Funktionsdimension eines Informationsprodukts beschreibt das „WAS“ des Informationsprodukts, die Qualitätsdimension das „WIE“. Die Schichten dienen der Abbildung des Umstandes, dass eine Information immer an ein Informationssystem gekoppelt ist (Bode 1993, S. 31; Kotkamp 2001, S. 48; Wang et al. 2002, S. 2). Einige Eigenschaften eines Informationsprodukts resultieren daher aus der Information selbst (Schicht „Information“), andere dagegen aus dem Informationssystem, welches diese beinhaltet oder bereitstellt (Schicht „Informationssystem“). Eine derartige Schichtung bietet damit die Möglichkeit, ausgehend von Anforderungen an ein Informationsprodukt einerseits jene Eigenschaften zu extrahieren, welche von den zur Informationsherstellung nötigen Basisdaten gefordert werden müssen und andererseits, welche von den sie herstellenden Informationssystemen benötigt werden. Die funktionale Dimension umfasst folgende Eigenschaften, die in der Regel zur Entwicklungszeit des Informationsprodukts determiniert werden (Kotkamp 2001, S. 45f.): x Gegenstand: Der Gegenstand beschreibt den eigentlichen Inhalt der Information. Er kann beispielsweise durch Datenmodelle oder durch verbale Beschreibung umrissen werden. x Struktur: Informationen sind entsprechend ihres Verwendungszwecks unterschiedlich strukturiert. Beispielsweise können Informationen mul-
250
x
x
x
x
Mario Klesse
tidimensional oder normalisiert strukturiert sein. Die Spezifikation der Struktur erfolgt integriert mit der Beschreibung des Inhalts. Darstellung: Informationen werden für die Verwendung verschiedentlich dargestellt. Darstellungsformen sind beispielsweise tabellarische Berichte, Dashboards oder Portfolios. Funktionalität: Jedes Informationsprodukt kann umfangreiche Funktionalität umfassen. Im Falle eines multidimensionalen Informationsprodukts erschöpft sich die Funktionalität in OLAP-Funktionen. Dennoch sind auch hochkomplexe Funktionen Bestandteile von Informationsprodukten, wie bspw. Preisbildungsmechanismen. Distributionsform: Diese Eigenschaft beschreibt, wie Informationen „vertrieben“ werden. Beispiele hierfür sind die zeitinduzierte (Jahresabschluss) und die ereignisorientierte Verteilung (exception reports) oder die Verteilung auf Abruf (interaktive Analysen). Speicherung: Informationsprodukte sind immer an ein Medium bzw. an ein Informationssystem gekoppelt. Die Eigenschaft hält daher fest, wo das Informationsprodukt hinterlegt ist.
Zur Beschreibung der Qualitätsdimension dient ein kennzahlenbasiertes Merkmalssystem, das sich an gängigen Ansätzen des Informationsqualitätsmanagements orientiert (Nelson et al. 2005). Jedes Merkmal lässt sich mit standardisierten Metriken operationalisieren und messen (Ballou et al. 1998): x Richtigkeit: Der Erfüllungsrad hinsichtlich einer Spezifikation, zu dem die Information korrekt, unmissverständlich, aussagekräftig, glaubwürdig und konsistent ist. Die Spezifikation kann beispielsweise in Form von Geschäftsregeln (Korrektheit), Dublettenprüfungen (Unmissverständlichkeit), Integritätsbedingungen (Konsistenz) vorliegen. Die Metrik kann hierfür darin bestehen, welcher Anteil dieser Bedingungen oder Prüfungen erfolgreich passiert wurde (Helfert 2002, S. 185). Glaubwürdigkeit kann z. B. statistisch geschätzt werden, indem die Inhalte des Informationsprodukts mit Referenzinhalten verglichen werden (Helfert 2002, S. 148ff.). x Vollständigkeit: Der Erfüllungsrad, zu dem ein bekannter und spezifizierter Informationsbedarf durch das Informationsprodukt gedeckt ist. Hierfür sind zwei grundsätzlich verschiedene Metriken denkbar. Zum einen kann der Abdeckungsgrad zwischen der zur Verfügung gestellten Information und dem bekannten Informationsbedarf gemessen werden (designorientiert). Zum anderen kann gemessen werden, welcher Anteil der Quellinformationen laut Spezifikation korrekt geladen wurde bzw.
Leistungsverrechnung für DWH Competence Center
x
x
x
x
x
251
wie viele Nullwerte oder unvollständige Datensätze bei der Informationsproduktion verarbeitet werden mussten (produktionsorientiert). Aktualität: Der Erfüllungsrad, zu dem die produzierte Information zeitaktuell gemäß Spezifikation ist. Als Metrik kann das tatsächliche Alter einer Information zu seiner voraussichtlichen "Haltbarkeitsdauer" ins Verhältnis gesetzt werden (Ballou et al. 1998). Deren Anwendung verursacht jedoch einen erheblichen Aufwand. Da in der Praxis die Aktualität häufig nur einen geringeren Anteil zum Nutzen des Informationsprodukts beiträgt (Nelson et al. 2005, S. 216), sollte eine einfache Metrik herangezogen werden. Eine solche ist das Verhältnis zeitgerecht geladener Quellen zu der Gesamtzahl der Quellen eines Informationsprodukts (Helfert 2002, S. 185). Zugänglichkeit: Der Erfüllungsrad, zu dem auf ein System und die darin enthaltene Information mit geringem Aufwand zugegriffen werden kann. Als Metrik hierfür bietet sich beispielsweise die gesicherte Betriebszeit des Zugriffssystems an. Zuverlässigkeit: Der Erfüllungsgrad, zu dem die spezifizierten Eigenschaften des Informationsprodukts zur Verfügung stehen. Typische Metriken sind hier der Anteil der Zeit, zu der das Informationsprodukt tatsächlich vom Anwender benutzt werden kann, im Verhältnis zur zugesicherten Nutzungszeit; die mittlere Häufigkeit zwischen dem Auftreten von Fehlern (sowohl in der Datenproduktion als auch im Datenzugriff) oder die durchschnittliche Dauer der Störungsbehebung. Antwortzeit: Der Erfüllungsgrad, zu dem das System rechtzeitige Ergebnisse auf eine Anfrage nach Informationen oder Verarbeitungsfunktionalität liefert. Die entsprechende Metrik ist die Antwortzeit. Bei einfachen Berichtsabrufen spielt diese Größe in der Praxis eine geringe Rolle (Nelson et al. 2005, S. 126), so dass hier in der Regel ein möglichst einfaches Messverfahren verwendet werden sollte. Flexibilität: Der Erfüllungsgrad, zu dem das System an die verschiedenen Nutzerbedürfnisse sowie an veränderte Bedingungen anpassbar ist. Als Metrik bietet sich hier z. B. die Reaktionszeit an, mit der auf eine Veränderung an einer operativen Datenquelle reagiert wird.
Das beschriebene Produktmodell lässt sich sowohl zur Beschreibung von quellseitigen und zielseitigen Datenlieferungen als auch zur Beschreibung von statischen Berichten, OLAP-Berichten und beliebigen DWH-Applikationen einsetzen (Klesse 2007, S. 218). Abbildung 3 zeigt beispielhaft die Funktionsdimension für ein Informationsprodukt aus dem analytischen CRM, das anhand des beschriebenen Merkmalsrasters spezifiziert ist.
252
Mario Klesse
MD-Bericht:
Marktpotenzialanalyse Geschäftskunden
Allgemeine Angaben Zweck Empfänger
Vertriebsplanung auf Basis von Marktpotenzialen, produktbezogen für Geschäftskunden Vertrieb Geschäftskunden
Informationsgegenstand Beschreibung
Welches sind die Kunden mit dem grössten Marktpotenzial?
Historisierung
24 Monate, rollierend
Dimensionen
Inhaltliche Beschreibung
Filter
Geschäftskunde
Kundennummer Unternehmen Branche Anzahl Mitarbeiter Groessenklasse
Gemäss Unternehmensstandard Voller Name des Unternehmens Branchenzugehörigkeit des Unternehmens Mitarbeiterzahl des Unternehmens Grössenklasse des Unternehmens
ohne Interne
Periode
Monat Quartal Jahr
Kalendermonat Kalenderquartal Kalenderjahr
Produkt
Produktnummer Produktname Produktgruppe Produktcluster
Unternehmensweite Produktnummer Bezeichnung des Produkts Produktgruppe Produktcluster
Ort Gebiet Bundesland Land
Ort (Ebene Postleitzahlen) Vertriebgebiet Bundesland / Kanton Land / Staat
Sicht Vertrieb Sicht Vertrieb
Inhaltliche Beschreibung / Berechnung
Berechnung
Einkaufspotenzial (EP)
EP = Anzahl_Mitarbeiter * Einkaufspotenzial des Geschäftskunden in CHF, basierend auf der Grössenklasse und der Einkaufspotenzial (Groessenklasse) Mitarbeiterzahl des Unternehmens
Fakturierter Betrag (FB)
Bisheriger Umsatz mit dem Kunden in CHF
FB = SUMME (Fakturierter Betrag)
Share of Wallet (SoW)
Anteil des Fakturierten Betrags am Einkaufspotenzial
SoW = FB / EP
Region
Kennzahlen Kennzahlen Marktpotenzialanalyse
Darstellung
Tabellarisch und grafisch, Exportierbar in CSV- und PDF-Datei
Funktionalität
Standard-Funktionalität multidimensionale Analyse
Sicht Vertrieb Sicht Vertrieb
Standard-Funktionen zur Definition abgeleiteter Felder Distribution Speicherung
Bereitstellung: Abfrage/Lieferung:
Periodisch, wöchentlich montags 9:00 Uhr Auf Abruf, bei Bedarf feste Selektion per E-Mail abonnierbar
Zentral
Abb. 3. Produktsteckbrief eines OLAP-Berichts (Funktionsdimension)
4.2 Informationsproduktion Um den Kernprozess der Leistungserstellung, die Informationsproduktion (IP) zu strukturieren, sowie um die nötigen Input-Leistungsmengen, ihre Qualität und ihre Kosten der Herstellung von Informationsprodukten planen zu können, dient das Informationsproduktionsmodell. Es besteht in Anlehnung an (Wild 1970; Bode 1993; Ballou et al. 1998) aus Produktionsgruppen, Produktionsstellen, Informationsobjekten, Plattformleistungen und Prozessleistungen (Abb. 4).
Leistungsverrechnung für DWH Competence Center
253
Abb. 4. Metamodell des Informationsproduktionsprozesses
Produktionsgruppen dienen der aggregierten Abbildung des Informationsproduktionsprozesses (IPP). Sie grenzen die logischen Produktionsstufen von Informationen gegeneinander ab. Jede logische Komponente des DWH-Informationssystems stellt eine Produktionsgruppe dar. Es werden folgende Produktionsgruppentypen unterschieden: x Quellinformationssysteme dienen zur Abbildung logischer Informationsquellen. Dies können beispielsweise eine CRM-Applikation oder ein ERP-System sein. x DWH-Integrationsinfrastrukturen dienen zur Abbildung von logischen infrastrukturellen Komponenten. In einer strengen Hub and SpokeArchitektur existiert genau eine solche Produktionsgruppe. x DWH-Applikationen dienen der Abbildung von anwendungsspezifischen Teilen des DWH-Informationssystems. Ein Beispiel ist ein Data Mart mit Zugriffskomponente für das Kampagnenmanagement oder eine komplexe Lieferschnittstelle für ein Zielsystem. Innerhalb der Produktionsgruppen übernehmen Produktionsstellen die eigentliche Informationsverarbeitung. Hierbei werden folgende Stellentypen unterschieden: x Sourcingstellen stellen die quellseitigen Grenzen des DWH-Informationssystems dar. Sie liefern eine Informationsart, die im Data Warehouse weiterverarbeitet wird. x Verarbeitungsstellen transformieren eine oder mehrere Informationsarten zu einer neuen Informationsart. x Permanentspeicherstellen dienen der langfristigen Lagerung von Informationsarten. Input und Output einer solchen Stelle ist ein und dieselbe Informationsart.
254
Mario Klesse
x Distributionsstellen stellen die outputseitigen Systemgrenzen des DWHInformationssystems dar. Sie stellen die Informationsprodukte her, die vom Nutzer des Data Warehouse verwendet werden. Dabei werden zwei Subtypen unterschieden. Abfragestellen dienen dem interaktiven Zugriff auf einen Datenbestand, Lieferstellen führen dagegen eine Datenlieferung an andere Systeme durch. Mit den genannten Modellelementen lässt sich jede DWH-Landschaft abbilden. Dabei sind nur so viele Stellen zu bilden, wie es die gewünschte Genauigkeit der anschließenden Rechnungen erfordert. Abbildung 5 zeigt einen mit diesen Modellelementen beispielhaft abgebildeten Informationsproduktionsprozess. Dargestellt ist ein DWH-Informationssystem, welches aus zwei Quellsystemen befüllt wird, einer CRM-Applikation und einer ERP-Applikation. Jede Quelle stellt je zwei Informationsarten bereit: Das CRM-System stellt die Informationsarten Vertragsbeschwerden (IV1) und Kundenstammdaten (IK1) zur Verfügung. Das ERP-System stellt Informationen zur Vertragserfüllung (IV2) und Kundenbonitätsdaten zur Verfügung (IK2). Jede dieser Informationsbereitstellungen wird durch je eine Sourcing-Stelle modelliert. Die Informationsarten werden im Data Warehouse integriert: Aus Partikularsichten über Kunden (IK1, IK2) werden integrierte Kundeninformationen (IK), aus den Einzelinformationen (IV1, IV2) zu Verträgen entsteht ein Gesamtbild über die Akzeptanz von Vertragsmodellen. Diese Transformation übernehmen Verarbeitungsstellen (V01, V02). Die Ergebnis-Informationen werden in Permanentspeicherstellen abgelegt (PV, PK). Zwei DWH-Applikationen verarbeiten diese Informationen weiter und speichern sie für Abfragen durch den Benutzer: Die erste Applikation ermöglicht OLAP-Analysen für die Kampagnensteuerung (IPKa). Dazu werden Vertrags- und Kundeninformationen werden integriert und es werden Kunden nach ihrer Akzeptanz von Vertragsmodellen segmentiert (IKa). Die zweite Applikation ermöglicht den Abruf von Bonitätsberichten für das Controlling (IPCo). Die integrierten Kundeninformationen werden dazu transformiert, multidimensional aufbereitet und in einer neuen Form (ICo) gespeichert. Auch die Vorgänge innerhalb der Applikationen werden wieder durch entsprechende Stellen modelliert.
Leistungsverrechnung für DWH Competence Center
255
Abb. 5. Beispiel eines Informationsproduktionsmodells
Auf Basis dieses Modells lassen sich bereits Informationsflüsse und Informationsqualitätseigenschaften planen (Ballou et al. 1998). Um jedoch eine Kosten- und Leistungsplanung vornehmen zu können, sind die zur Informationsproduktion nötigen nicht-informatorischen Input-Leistungen mit dem Informationsproduktionsmodell zu verknüpfen. Jede Stelle wird dazu mit den Leistungen verknüpft, die sie zur Verarbeitung ihrer Informationsarten benötigt. Dabei werden folgende Inputleistungsarten unterschieden: x Plattformleistungen sind die Leistungen, die von der DWH-Plattform bzw. vom DWH-Plattformzulieferer bereitgestellt werden. Hierunter können Verarbeitungsleistungen, Speicherleistungen und Übertragungsleistungen subsumiert werden. x Prozessleistungen sind alle Leistungen, die durch das DWH-CC erbracht werden. Hierunter sind die Prozesse der Entwicklung und des fachlichen Betriebs des DWH-Informationssystems zu subsumieren. Die Leistungen sind zunächst zu strukturieren und messbar zu machen. Tabelle 1 zeigt für einige Plattform- und Prozessleistungen mögliche Messgrößen. Anschließend sind die nicht-informatorischen Leistungen den Stellen zuzuordnen. Diese Zuordnung ist abhängig davon, um welche Leistungsart es sich handelt, auf unterschiedliche Weise vorzunehmen.
256
Mario Klesse
Tabelle 1. Nichtinformatorische Leistungen und Messgrößen Leistung Plattformleistungen Datenhaltung (Speichern) Verarbeitung Informationsbereitstellung (Batch) Verarbeitung Informationsabfrage (Online)
Messgröße Gigabyte-Tag CPU-Sekunde oder Joblaufzeit CPU-Sekunde oder Anfragelaufzeit Gigabyte-Tag Gigabyte
Daten sichern (Backup) Daten übertragen (Netz) Prozessleistungen (Entwicklung) Ersterschließung von Datenquellen Anzahl Ersterschließungen Erschließung von Daten einer erschlossenen Quelle Anzahl Datenarten / Tabellen Bereitstellen erschlossener DWH-Daten für eine Anzahl Datenarten / Applikation Lieferdateien Erstellung von Kennzahlen aus erschlossenen DatenAnzahl Kennzahlen Erstellung statischer Berichten aus erschlossenen Anzahl Berichte Daten Prozessleistungen (Fachlicher Betrieb) Prozessunterstützung Inf.-Produktion Anzahl unterstützter ETL-Prozesse Qualitätssicherung Inf.-Produktion Anzahl Qualitätskontrollen Metadatenpflege Anzahl Metadatenmutationen Referenzdatenpflege Anzahl Referenzdatenmutationen Fehlerbehebung Anzahl behobener Fehler „leicht“ Anzahl behobener Fehler „schwer“
Für Plattformleistungen sind den gebildeten Stellen jene Softwarekomponenten zuzuordnen, die die Aufgabe der jeweiligen Stelle realisieren. Im Falle von Sourcing-, Verarbeitungs- und Lieferstellen sind dies z. B. diejenigen ETL-Programme und temporären Datenstrukturen, die die Informationstransformation realisieren. Im Falle von Permanentspeicherstellen sind dies beispielsweise die Datei- und Datenbereiche, die zur langfristigen Lagerung der jeweiligen Informationsart erforderlich sind. Im Falle von Abfragestellen sind dies z. B. entsprechende Queries. Die Konsumation der Plattformleistungen durch die jeweiligen Stellen kann anschließend mithilfe von Monitoring-Werkzeugen oder aus ETL-Protokollen näherungsweise bestimmt werden. Daraus lassen sich entsprechende durchschnittlich pro Informationsart und -menge eingesetzte Plattformleistungsmengen ermitteln.
Leistungsverrechnung für DWH Competence Center
257
Für Prozessleistungen sind entsprechende Mengenzusammenhänge zwischen Informationseigenschaften und Prozessleistungsmenge zu formulieren. Hierbei ist nach der Art des Prozesses zu differenzieren (Wieding 2000, S. 142-145): x Potenzialorientierte Leistungsbeziehungen: Insbesondere die Leistungsmengen von Entwicklungsprozessen hängen nicht davon ab, wie viele Informationen einer Art produziert werden müssen, sondern welche Informationen hergestellt werden sollen. Die Zuordnung der Leistungsmenge zur entsprechenden Stelle erfolgt somit durch die Zuordnung der entwickelten IS-Komponenten bzw. zu den Stellen. x Prozessorientierte Leistungsbeziehungen: Insbesondere die Leistungsmengen des fachlichen Betriebs hängen von bestimmten Eigenschaften der von einer Stelle produzierten Information ab. Beispielsweise hängt der Aufwand der Qualitätssicherung vom Verhältnis zwischen der bestehenden und der angestrebten Informationsqualität ab. Diese Zusammenhänge sind für alle Prozessleistungen zu formulieren. Sind diese Zusammenhänge für alle Prozess- und Plattformleistungen festgestellt, lassen sich die zur Produktion einer Informationsart nötigen Vorleistungsmengen anhand von Mengen- und Qualitätseigenschaften der betreffenden Information sowohl feststellen (Istwerte) als auch planen (Planwerte).
5
Vorgehensmodell der Methode
Im Folgenden wird ein Überblick über das Vorgehensmodell der Methode gegeben (Abb. 6). Um die Übersichtlichkeit des Vorgehensmodells zu erhöhen und den Bezug zu den Gestaltungselementen der Leistungsverrechnung herzustellen, sind die Aktivitäten in Phasen gruppiert. Die einzelnen Aktivitäten werden im Folgenden erläutert (Klesse 2007, S. 243-253). Jede Aktivität erzeugt Entwurfsergebnisse, die hier als Inputs und Outputs der Aktivitäten dargestellt werden.
258
Mario Klesse
Abb. 6. Vorgehensmodell der Methode
5.1 Phase 1: Vorgaben Die Phase „Vorgaben“ dient dem Treffen grundsätzlicher Entscheidungen, die die Gestaltung der Leistungsverrechnung maßgeblich beeinflussen. Sie besteht aus den Aktivitäten „Szenario analysieren“, „Ziele festlegen“ und „Grundsätzliche Festlegungen treffen“.
Leistungsverrechnung für DWH Competence Center
259
Aktivität 1.1: Szenario analysieren Input: (DWH-Governance) Output: Szenario Diese Aktivität ist nötig, um die Anwendbarkeit der Methode sicherzustellen. Im Wesentlichen ist hier anhand einer Checkliste zu prüfen, ob das Szenario „Internes DWH Competence Center“ tatsächlich vorliegt. Anderenfalls sind ggf. Anpassungen an der Methode vorzunehmen. Aktivität 1.2: Ziele festlegen Input: (DWH-Governance) Output: Zielsystem (priorisiert) In dieser Aktivität werden die Ziele bestimmt, die mit der Leistungsverrechnung erreicht werden sollen. Insbesondere ist zu entscheiden, wie die drei Ziele „Kostenrechnerische Wertabbildung“, „Lenkungsfunktion“ und „Erfolgszuweisungsfunktion“ priorisiert werden. Daraus lassen sich die Prioritäten jeglicher anderer Anforderungen und Ziele ableiten (Technik in Klesse 2007, S. 254ff.). Aktivität 1.3: Grundsätzliche Festlegungen treffen Input: Zielsystem Output: Grundsätzliche Festlegungen zur Abrechnung und zur Produktbildung Ziel dieser Aktivität ist es, erste Grundsätze der Abrechnung und der Produktbildung zu wählen. Hinsichtlich der Abrechnung ist festzulegen, an welche Leistungsabnehmer prinzipiell welche Kosten zu verrechnen sind. In der Praxis existieren hierzu unterschiedliche Modelle, aus welchen eines zu wählen ist: Zum einen kann festgelegt werden, dass die Kosten des DWH-Informationssystems vollständig an die Informationsabnehmer zu verrechnen sind. Zum anderen bietet sich die Option, die Kosten der Integrationsinfrastruktur an die Datenlieferanten zu verrechnen, während Kosten von DWH-Applikationen an die jeweiligen Informationsempfänger verrechnet werden. Letztere Festlegung ist zweckmäßig, wenn im Unternehmen eine Bringschuld für Informationen etabliert ist. Zur Vorbereitung der Produktbildung ist festzulegen, inwieweit welche Leistungen des DWH-CC mit Informationsprodukten gebündelt werden und welche Leistungen prinzipiell separat verrechnet werden. Zielführend sind hier zwei Optionen, aus denen ein Modell zu wählen ist: Die serviceorientierte Abrechnung bündelt Entwicklungs- und Betriebsleistungen der DWH-Integrationsinfrastruktur und der DWH-Applikationen in infrastrukturelle und applikatorische Informationsprodukte und rechnet diese
260
Mario Klesse
mit dem Leistungsabnehmern ab. Dies ermöglicht es, Entwicklungskosten an der DWH-Integrationsinfrastruktur nutzungsgerecht zu verteilen. Die produktorientierte Abrechnung geht noch einen Schritt weiter: Hier werden alle Leistungen in Informationsprodukte gebündelt. Das heißt, der Kunde sieht lediglich das Informationsprodukt, das er auch nutzt, z. B. einen „Bericht Kampagnencontrolling“ (Technik in Klesse 2007, S. 257ff.). 5.2 Phase 2: Ist-Analyse Ziel der Phase Ist-Analyse ist, einen Überblick über die in die Leistungsverrechnung einzubeziehenden Elemente zu erhalten. Entsprechend sind die DWH-Architektur, die an der Leistungserstellung beteiligten Organisationseinheiten sowie die Prozesse des DWH-Leistungserbringers zu erheben. Die anschließende grobe Kostenstrukturanalyse unterstützt die Schwerpunktsetzung bei den nachfolgenden Analyseschritten. Aktivität 2.1: Organisation der Leistungserbringung erheben Input: -Output: Leistungserstellungslandkarte Für das Data Warehousing sind neben dem DWH-Informationssystem die organisatorischen Prozesse der Leistungserbringung notwendig. Erst diese ermöglichen es, Informationsprodukte mit einer gesicherten Qualität anzubieten und mit der nötigen Nutzerunterstützung zu versehen. Mit dieser Aktivität wird zunächst die Voraussetzung für die Prozessanalyse geschaffen, indem die am Leistungserstellungsprozess beteiligten Organisationseinheiten erfasst werden (Remer 1997). Dazu gehören nicht nur die DWHAbteilungen im Unternehmen, sondern auch interne und externe Zulieferer, die fest in die Leistungserstellung eingebunden sind. Gleichzeitig werden die Leistungen, die zwischen den Organisationseinheiten ausgetauscht werden, grob erfasst (Technik in Klesse 2007, S. 264ff.). Aktivität 2.2: DWH-Architektur erheben Input: -Output: DWH-Architektur (logisch und physisch) Mit dieser Aktivität wird die DWH-Architektur auf logischer Ebene (DWH-Informationssystem) und auf physischer Ebene (DWH-Plattform) erfasst. In diesem Zuge werden auch die Quellen des DWH-Informationssystems identifiziert. Die Architekturanalyse dient als Grundlage der Identifikation von Informationsprodukten sowie zur Vorbereitung der Analyse des Informationsproduktionsprozesses (Technik in Klesse 2007, S. 265ff.).
Leistungsverrechnung für DWH Competence Center
261
Aktivität 2.3: Kostenstruktur analysieren Input: -Output: Kostenstruktur des Data Warehousing Ziel der Aktivität ist es, die Kostenstruktur der bisher analysierten Elemente (Architekturkomponenten, Prozesse) zu erheben, einerseits um im weiteren Verlauf Schwerpunkte setzen zu können, andererseits um die bisherige Erfassung ggf. zu detaillieren. Verursacht die Leistungserbringung z. B. überwiegend Maschinenkosten, ist eine detaillierte Analyse der Prozesse zumindest für die Leistungsverrechnung nicht zielführend. Hingegen ist bei einer personalintensiven Leistungserbringung davon abzuraten, allein Messgrößen des automatisierten Prozesses als interne Bezugsgrößen in der Verrechnung heranzuziehen. Auch die Genauigkeit der Abrechnung richtet sich nach dem Kostenvolumen der zu verrechnenden Prozessleistungen und Architekturelemente. Beispielsweise erscheint es wenig sinnvoll, eine DWH-Applikation, die nur ca. 1% der Gesamtkosten verursacht, weitergehend in Informationsprodukte zu zergliedern (Technik in Klesse 2007, S. 269ff.). 5.3 Phase 3: Definition der Kundenschnittstelle Diese Phase dient der Ausgestaltung der Schnittstelle zu den Leistungsabnehmern. Im Wesentlichen werden die angebotenen Produkte und Service Level Agreements definiert sowie die dazugehörigen Preis- und Abrechnungsmodelle festgelegt. Aktivität 3.1: Informationsprodukte identifizieren Input: DWH-Applikationen aus DWH-Architektur, optional fachliche Metadaten Output: Informationsproduktverzeichnis (Kandidaten) Ziel dieser Aktivität ist es, auf Basis der erhobenen DWH-Applikationen schrittweise Informationsprodukte zu identifizieren. Ein ggf. bereits etabliertes Metadatenmanagement kann als weiterer unterstützender Input für diese Aktivität herangezogen werden. Ergebnis der Aktivität sind Informationsprodukte, die einerseits für den Kunden sinnvoll nutzbare Informationseinheiten darstellen, andererseits ein anhand der Genauigkeitsanforderungen festgelegtes Mindestkostenvolumen aufweisen. Sie sind der Dreh- und Angelpunkt des weiteren Vorgehens: Zum einen müssen sie anschließend spezifiziert werden, zum anderen richten sich die nachfolgenden Detailanalysen der Leistungserstellungsprozesse an ihnen aus (Technik in Klesse 2007, S. 272ff.).
262
Mario Klesse
Aktivität 3.2: Informationsprodukte spezifizieren Input: Informationsproduktverzeichnis, Internes Leistungsmodell Output: Informationsproduktsteckbrief (Spezifikation von Funktion und Qualität) Die identifizierten Informationsprodukte werden anschließend hinsichtlich ihrer funktionalen und qualitativen Eigenschaften spezifiziert. Als Grundlage dient das entwickelte allgemeine Modell des Informationsprodukts (siehe Abschn. 5.3), welches für die identifizierten Produkte operationalisiert und instanziiert wird (Technik in Klesse 2007, S. 278ff.). Aktivität 3.3: Kundendienstleistungen identifizieren und spezifizieren Input: Informationsproduktverzeichnis, Prozessleistungsverzeichnis (org. Prozesse) Output: Dienstleistungssteckbrief (Spezifikation von Funktion und Qualität) Nach der Spezifikation von Informationsprodukten können je nach grundsätzlicher Festlegung Prozessleistungen verbleiben, die nicht direkt den Informationsprodukten zuzuordnen sind. Beispielsweise können dies Benutzersupportleistungen sein, oder die Entwicklung leistungsabnehmerspezifischer DWH-Applikationen. Sie sind als (nicht ergebnisorientiert spezifizierbare) Services in den Produktkatalog aufzunehmen. Im Rahmen der Methode wird jedoch angestrebt, dass möglichst wenige derartige Services entstehen (Technik in Klesse 2007, S. 286ff.). Aktivität 3.4: Abrechnungsmodell festlegen Input: Zielsystem, Informationsproduktverzeichnis, Kundendienstleistungen Output: Abrechnungsmodell, bestehend aus Leistungsabnehmerverzeichnis und Abrechnungsgrößenverzeichnis Es werden Abrechnungsgrößen für die Produkte festgelegt und die Leistungsabnehmer konkretisiert. Es wird dabei angestrebt, dass möglichst wenige verschiedene Abrechnungsmodelle entstehen und dass sich diese streng an dem entwickelten Zielsystem der Leistungsverrechnung orientieren. Da sich Abrechnungsgrößen unmittelbar auf das Verhalten der Nutzer auswirken, sind diese potenziellen Auswirkungen zu analysieren und mit dem Zielsystem der Leistungsverrechnung abzugleichen (Technik in Klesse 2007, S. 288ff.).
Leistungsverrechnung für DWH Competence Center
263
Aktivität 3.5: Preismodell festlegen Input: Zielsystem, Informationsproduktionsmodell Output: Preismodell Das grundsätzliche Vorgehen der Preisbildung wird festgelegt. Es wird bestimmt, welche Parameter neben den Kosten bei der Preisbildung berücksichtigt werden und welche Informationen die Kosten- und Leistungsrechnung liefern können muss. Diese Festlegungen werden unter Berücksichtigung des Zielsystems und der bestehenden Engpässe in der Informationsproduktion getroffen. Zur Auswahl stehen kostenorientierte Preismodelle, die Qualitäts- und Zeitparameter einbeziehen können, um die im Zielsystem definierte Steuerungswirkung zu erzielen (Technik in Klesse 2007, S. 297ff.). Aktivität 3.6: Produktkatalog erstellen Input: Informationsproduktverzeichnis, Informationsproduktsteckbrief, Steckbriefe der Kundendienstleistungen, Leistungsabnehmerverzeichnis Output: Produktkatalog Die Informationsprodukte sowie die Kundendienstleistungen werden in einen Produktkatalog eingeordnet. Die Aktivität hat lediglich konsolidierenden Charakter (Technik in Klesse 2007, S. 307ff.). Aktivität 3.7: Verträge erstellen Input: Informationsproduktsteckbriefe, Dienstleistungssteckbriefe, Internes Leistungsmodell, Leistungsabnehmerverzeichnis Output: Service Level Agreements, Operational Level Agreements Die Informationsprodukte sowie die Kundendienstleistungen werden abschließend in Service Level Agreements festgehalten. Diese Aktivität führt die bisherigen Ergebnisse zusammen und nimmt die Vereinbarung kundenbezogener DWH-Produkte aus den Informationsprodukten und ggf. aus begleitenden Kundendienstleistungen vor. Zudem werden die Leistungsvereinbarungen mit den Lieferanten für Daten, Plattformen und Implementierungsleistungen vertraglich fixiert (Technik in Klesse 2007, S. 308ff.).
264
Mario Klesse
5.4 Phase 4: Erstellung des Internen Leistungs- und Kostenmodells Ziel dieser Phase ist es, unter Verwendung der in Abschn. 4.3 skizzierten Modellelemente ein unternehmensspezifisches Modell der DWH-Leistungserstellung zu entwickeln, auf dem die Kostenermittlung für die Informationsprodukte aufbauen kann. Als übergeordneter Hauptprozess dient der Informationsproduktionsprozess (IPP). Für die Analyse werden die Ergebnisse aus Phase 2 aufgegriffen und hinsichtlich der identifizierten Informationsprodukte detailliert. Aktivität 4.1: Informationsproduktionsprozess erheben (IPP Sicht: Information) Input: Informationsprodukte, Logische DWH-Architektur (Informationsquellen, DWH-Integrationsinfrastruktur, DWH-Applikationen) Output: Informationsproduktionsmodell – Sicht Information, bestehend aus Informationsproduktionsmatrizen und Stellenverzeichnis Zunächst wird der Informationsproduktionsprozess in seiner Gesamtheit erfasst. Basis dieser Aktivität ist das in Abschn. 4.3 beschriebene Modell der Informationsproduktion. Für jedes Informationsprodukt wird abgebildet, wie es über die verschiedenen Produktionsstufen des DWH-Informationssystems aus den Quellinformationen hergestellt wird. Die dazu nötigen Datenflüsse werden in Informationsproduktionsmatrizen festgehalten. Sie dienen als Ausgangsbasis für die Bildung von IPP-Stellen sowie ihrer Verknüpfung. Die Stellen werden in den nachfolgenden Aktivitäten schrittweise mit den nicht-informatorischen Leistungen verknüpft (Technik in Klesse 2007, S. 310ff.). Aktivität 4.2: Plattform-Leistungen erheben und zuordnen (IPP Sicht: Plattform) Input: Informationsproduktionsmodell – Sicht Information, physische DWH-Architektur bzw. DWH-Plattformarchitektur Output: Informationsproduktionsmodell – Sicht Plattform, bestehend aus Plattformleistungsverzeichnis und Zuordnungsmechanismus zur Sicht Information via Stellenverzeichnis, ergänzende Beschreibung im Plattformsteckbrief Zunächst werden die Plattform-Leistungen erhoben. Hierfür kann es ggf. nötig sein, mit den Zulieferern zunächst die benötigten Plattformleistungen neu zu strukturieren und ein geeignetes Abrechnungsmodell zu vereinba-
Leistungsverrechnung für DWH Competence Center
265
ren. Empfohlen wird die Trennung von Verarbeitungs-, Speicher- und Übertragungsleistung je Plattform bzw. je technischer Ressource (Scheeg 2005, S. 163-168). Anschließend werden die Elemente des DWHInformationssystems (Tabellen, ETL-Prozesse, etc.) den Stellen des IPP zugeordnet. Mithilfe einer initialen Messung werden für jede gebildete Stelle Ausgangswerte für die Verbräuche der verschiedenen Plattformleistungsarten ermittelt, die bei der Ausführung der zugeordneten DWHInformationssystemkomponenten entstehen (Technik in Klesse 2007, S. 321ff.). Aktivität 4.3: Prozessleistungen ermitteln und zuordnen (IPP Sicht: Organisation) Input: Informationsproduktionsmodell – Sicht Information, Leistungserstellungslandkarte Output: Informationsproduktionsmodell – Sicht Prozess, bestehend aus Prozessleistungsverzeichnis und Zuordnungsmechanismus zur Sicht Information via Stellenverzeichnis, ergänzende Beschreibung im Prozesssteckbrief Das Vorgehen innerhalb dieser Aktivität orientiert sich somit an etablierten Ansätzen zur Einführung der Prozesskostenrechnung (Remer 1997). Zunächst werden die Prozesse der Leistungserbringung erhoben und strukturiert. Insbesondere werden (organisatorische) Prozessleistungen definiert und messbare Bezugsgrößen für die Prozessleistungen identifiziert. Anschließend werden die Zuordnungsmechanismen für die Leistungen zu den Elementen des Informationsproduktionsprozesses festgelegt. Soweit möglich, werden Zusammenhänge zwischen Prozessleistungsbezugsgrößen und Eigenschaften der produzierten Informationen formuliert. Die Ergebnisse werden in einem Prozessleistungsverzeichnis und einem Prozesssteckbrief für jeden Prozess festgehalten (Technik in Klesse 2007, S. 335ff.). Aktivität 4.4: Abbildung in KLR-System vornehmen Input: Abrechnungsmodell, Produktkatalog, Informationsproduktionsmodell Output: Kostenartenplan, Kostenträgerplan, Kostenstellenplan, Kalkulationsschema, Planungsergebnisse der Phase 5 Ziel ist es, ein Kalkulationsschema zu entwickeln, welches die laufende Kalkulation der Informationsprodukte und Kundendienstleistungen ermöglicht. Das erstellte Informationsproduktionsmodell wird dazu in eine Kosten- und Leistungsrechnung abgebildet. Die Abbildung erfolgt vor al-
266
Mario Klesse
lem nach rechentechnischen Gesichtspunkten und berücksichtigt daher auch das entwickelte Abrechnungs- und Preismodell. Abschließend wird eine initiale Planung durchgeführt (Phase 5). Das Vorgehen innerhalb der Aktivität orientiert sich an bestehenden Ansätzen zur Konzeption von ITKostenrechnungssystemen (Mai 1996; Britzelmaier 1999). Vereinfacht dargestellt ergibt sich eine direkte Abbildung der IPP-Stellen, der Prozesse und der Plattformen in Form von Kostenstellen und Kostenplätzen, deren Leistungen Informationen, Prozessleistungen und Plattformleistungen darstellen (Technik in Klesse 2007, S. 344ff.). 5.5 Phase 5: Planung und Kalkulation Mit der Phase 4 ist die eigentliche Gestaltung des Verrechnungssystems abgeschlossen. Die entwickelten Artefakte müssen anschließend implementiert und in die Abrechnungs- und Servicemanagement-Prozesse des Unternehmens integriert werden. Diese Aufgaben werden hier nicht weiter ausgeführt, da sie stark von der entwickelten Konzeption und vom unternehmensspezifischen Rahmen abhängig sind. Zur Inbetriebnahme sowie für den laufenden Betrieb des Konzepts sind jedoch Prozesse nötig, die es erlauben, die Eigenschaften und Preise der Informationsprodukte zu planen. Diese sind in der Phase 5 zusammengefasst und in die Prozesse des DWH-CC zu integrieren. Aktivität 5.1: Veränderungen planen Input: IS-Architekturplanung (operativ und dispositiv), Anforderungen der Leistungsabnehmer Output: Neuprodukte, Produktänderungen, Nutzerstrukturveränderungen, Infrastrukturmaßnahmen, veränderte Qualitätsanforderungen Ein DWH-Informationssystem ist regelmäßigen Veränderungen unterworfen. Ursachen dafür sind sich ändernde Datenquellen, der Bedarf nach neuen Informationsprodukten oder nach der Veränderung bestehender Informationsprodukte. Zudem können Erweiterungen der Integrationsinfrastruktur selbst nötig sein, wie bspw. die Einführung oder Erweiterung eines Metadatenmanagementsystems. Die Aktivität dient dazu, die Veränderungen zu identifizieren, welche potentiell zu Mengen- und Kostenveränderungen im Informationsproduktionsmodell führen können. Ihr Output orientiert sich am Informationsbedarf aller nachgelagerten Prozesse (Details in Klesse 2007, S. 355ff.).
Leistungsverrechnung für DWH Competence Center
267
Aktivität 5.2: Informationsmengen planen Input: Fachliche Veränderungen, Neuprodukte, Produktänderungen, Nutzerstrukturveränderungen Output: Mengen der Informationsarten (Plan), Informationsproduktmengen gemäß Abrechnungsmodell (Plan) Veränderungen der geschäftlichen Lage des Unternehmens, der Analyseanforderungen, der Nutzerzahlen oder des Analyseverhaltens der Nutzer führen zu Veränderungen der Informationsmengen, die im Data Warehousing verarbeitet werden müssen. Die Aktivität dient der Planung der Informationsmengen aus fachlicher Sicht. Dies umfasst sowohl die Menge der bereitzustellenden Informationen als auch die Menge der voraussichtlich abgefragten Informationen. Ziel ist es einerseits, die benötigten Mengenzahlen für das Abrechnungsmodell zu gewinnen, andererseits einen wichtigen Input für die interne Leistungsplanung des DWH-CC zu generieren (Details in Klesse 2007, S. 356ff.). Aktivität 5.3: Informationsqualität planen Input: Qualitätsmesswerte der IPP-Stellen, Qualitätsanforderungen Output: Qualitätsmetrikwerte der Informationsprodukte (Plan), Qualitätsmetrikwerte der Quell-Informationsobjektarten (Soll) Die Qualität der Informationsprodukte ist maßgeblich von der Qualität der Quelldaten abhängig. Um zu ermitteln, inwieweit es realistisch ist, für ein Informationsprodukt die Kundenanforderungen hinsichtlich der Informationsqualität zu erfüllen, muss die Informationsqualität geplant werden. Dazu dient das in Abschn. 5.3 vorgestellte Modell. Grundsätzlich wird für alle gebildeten Stellen die Informationsqualität der Input- und Outputinformationen anhand der gebildeten Qualitätsmetriken für Informationsprodukte gemessen. Durch Extrapolation lassen sich die Auswirkungen veränderter Inputqualitäten oder von Qualitätsanforderungen entlang der Informationsproduktionskette planen (Ballou et al. 1998); (Details in Klesse 2007, S. 359ff.). Aktivität 5.4: Prozessleistungsmengen Entwicklung planen Input: Anforderungsbeschreibungen der Neuprodukte, Produktänderungen, Infrastrukturmaßnahmen Output: Entwicklungsleistungsmengen (Plan) je Stellen / Produktionsgruppen des IPP-Modells, bei Neuentwicklungen zusätzlich angepasstes IPP-Modell (neue Produktionsgruppen, Stellen, Zuordnungen von IS-Komponenten)
268
Mario Klesse
Die Einführung neuer Produkte, die Veränderung bestehender Informationsprodukte sowie Infrastrukturmaßnahmen erfordern Entwicklungsleistungen, die geplant werden müssen. Die Entwicklung erzeugt IS-Komponenten, die dem IPP-Modell zugeordnet werden müssen, um auf dieser Basis die Kostenermittlung von Informationsprodukten zu ermöglichen. Bei Neuentwicklungen muss zusätzlich das IPP-Modell angepasst werden. Diese Aktivität ermittelt die Planaufwände und ordnet diese dem gegebenenfalls anzupassenden IPP-Modell zu (Details in Klesse 2007, S. 361ff.). Aktivität 5.5: Prozessleistungsmengen Betrieb und Support planen Input: Mengen der Informationsprodukte, Veränderungen der Informationsproduktion Output: Planleistungsmengen Betriebs- und Supportprozesse (Plan), angepasste Einsatzfunktionen im IPP-Modell Auf Basis der ermittelten Informationsmengen und Veränderungen kann die Veränderung der Prozessleistungsmengen im fachlichen Betrieb und Support geplant werden. Zusätzlich werden Trends aus den Ist-Daten über die Bezugsgrößen- und Ressourcenverbrauchsentwicklung herangezogen. Diese Aktivität führt diese Planzahlen zusammen und ermittelt die Planleistungsmengen für Betrieb und Supportprozesse des DWH-CC (Details in Klesse 2007, S. 365ff.). Aktivität 5.6: Plattformleistungsmengen planen Input: Mengen der Informationsprodukte, Veränderungen der Informationsproduktion Output: Plattformleistungsmengen (Plan), angepasste Einsatzfunktionen im IPP-Modell Auf Basis der ermittelten Informationsmengen und Veränderungen kann die Veränderung des Plattformleistungsbedarfs geplant werden. Die Informationsmengen allein reichen jedoch für eine Planung nicht aus. Zusätzlich sind Messdaten über bestehende Entwicklungen der Plattformleistungsmengen heranzuziehen, die im Rahmen der Ist-Leistungsmessung (für laufende Abrechnung und Kapazitätsmanagement) gewonnen werden (Hahn et al. 2000). Diese Aktivität führt wiederum beide Planungen zusammen und ermittelt die Plattformleistungsmengen für die Informationsproduktion (Details in Klesse 2007, S. 367ff.). Aktivität 5.7: Informationsprodukte kalkulieren Input: Planmengen Informationen, Prozess- und Plattformleistungen Output: Plankosten und Preise der Informationsprodukte
Leistungsverrechnung für DWH Competence Center
269
Auf Basis der ermittelten Leistungsmengen sind die Kostenauswirkungen der Veränderungen zu planen. Mithilfe des in Abschn. 4.3 dargestellten Modells können anschließend die Kosten pro Informationsprodukt ermittelt werden (Klesse 2007, S. 194-203). Anhand des Abrechnungsmodells ergibt sich die Kostenbasis für die "Stückpreise" der Informationsprodukte (Details in Klesse 2007, S. 374ff.). Aktivität 5.8: Katalog und Verträge anpassen Input: Neuprodukte, Veränderungen, Planmengen, Qualitäten und Preise Output: Aktualisierte Service Level Agreements, Operational Level Agreements und Produktkatalog Die bestehenden Service Level Agreements müssen regelmäßig mit den Plan- und Solldaten aktualisiert werden. Neuprodukte müssen in neuen Service Level Agreements festgehalten werden. Die Aktivität gleicht in weiten Teilen der Aktivität "Verträge erstellen" und dient dem Abschluss des Planungsprozesses.
6
Zusammenfassung und Ausblick
Im Artikel wurde eine Methode vorgestellt, mit dem DWH-CCs eine Leistungsverrechnung für die von ihnen angebotenen Produkte konzipieren können. Die Methode berücksichtigt die häufig unterschiedlichen Zielsetzungen der Leistungsverrechnung eines DWH-CC, indem sie die Zielfindung durch eine eigene Aktivität unterstützt und die ermittelten Ziele konsequent in den Techniken verfolgt. Zudem unterstützt sie die Spezifikation von fachlichen, an Informationen ausgerichteten Produkten. Das dazu entwickelte verallgemeinerte Konzept eines Informationsprodukts ist auf analytische Prozesse, abgrenzbare Informationsarten sowie auf Applikationen anwendbar. Die Methode integriert in den Produkten eine Qualitätssicht. Durch das zu Grunde liegende Informationsproduktionsmodell werden Qualitätseigenschaften der Informationsprodukte systematisch planbar. Das Abrechnungsmodell und die Abrechnungsgrößen werden konsequent an den Zielen der Leistungsverrechnung ausgerichtet und berücksichtigen explizit ihre Wirkung auf die Nutzer. Die Methode bietet dazu mehrere kostenorientierte Preismodelle zur Auswahl, die die Bildung langfristig kostendeckender Preise ermöglichen. Alle zur Preisbildung benötigten Informationen werden durch das zu Grunde liegende IPP-Modell geliefert. Dieses Modell verfolgt den
270
Mario Klesse
Grundsatz, alle Leistungsflüsse zu erfassen, zu Informationen zuzuordnen und sowohl mengen- als auch qualitätsorientiert zu beschreiben. Eine Bewertung der Leistungen mit Kosten erfolgt auf Basis der Mengen und Qualitätssicht. Die Methode beschreibt weiterhin Abbildungsregeln für das Modell in eine Kosten- und Leistungsrechnung. Das KLR-System ist analog dem Produktionsmodell am Prozess der Informationsproduktion ausgerichtet. Die strenge Orientierung an Leistungsflüssen innerhalb des Modells und der Methode ermöglicht eine verursachungsgerechte Verrechnung fixer Gemeinkosten im Sinne des Finalitätsprinzips (Haberstock 1998). Das bedeutet, Leistungen werden jene Kosten zugeordnet, ohne die sie nicht erzeugt werden könnten. Durch die im Rahmen der Methode realisierte nutzungsorientierte Verrechnung von Infrastrukturleistungen wird zudem ein verursachungsrechter Lösungsansatz für die Infrastrukturproblematik präsentiert. Dies ermöglicht dem Leistungserbringer eine eigenständige Planung, Entwicklung und Optimierung der Infrastruktur. Die Methode wurde für interne DWH Competence Center entworfen, die die betriebliche Informationslogistik mit DWH-basierten Informationssystemen unterstützt. Da die Methode darauf basiert, betriebliche Informationsproduktionsprozesse mit allgemeinen Elementen flexibel abzubilden, ist sie prinzipiell ohne Weiteres auch für andere Formen der IT-Unterstützung der Informationslogistik einsetzbar (z. B. Entwicklung und Betrieb von Operational Data Stores oder ähnlichen Systemen). Zur Weiterentwicklung der vorgestellten Methode bieten sich mehrere Richtungen an. Zum einen kann die Methode auch für andere organisatorische Szenarien als das interne DWH-CC (vgl. Kap. 5) ausgestaltet werden. Vor dem Hintergrund einer zunehmenden Verselbständigung von IT-Dienstleistern könnten beispielsweise stärker marktorientierte Preisbildungsmechanismen und Abrechnungsmodelle eingebunden werden. Zum anderen kann das der Methode zu Grunde liegende Modell der Informationsproduktion weiterentwickelt werden. Beispielsweise wurde der Faktor „Zeit“ bewusst nicht in das Modell aufgenommen, um dessen Komplexität zu reduzieren. Dies schränkt jedoch die Aussagekraft des Modells in der Qualitätssicht ein. Sollte im Rahmen der Diskussion um Informationslogistik-Konzepte, die „(Near) Realtime“ Informationen liefern, der zeitlichen Dimension einer Information eine gestiegene Bedeutung zukommen, ließe sich diese Lücke unter Verwendung der Ansätze von (Ballou et al. 1998) schließen.
Leistungsverrechnung für DWH Competence Center
271
Literatur Ballou, D. P.; Wang, R.; Pazer, H. L.; Tayi, G. K.: Modeling Information Manufacturing Systems to Determine Information Product Quality, in: Management Science 44 (1998) 4, S. 462-484. Bode, J.: Betriebliche Produktion von Information, Deutscher Universitäts-Verlag GmbH, Wiesbaden 1993. Britzelmaier, B.: Informationsverarbeitungs-Controlling - Ein datenorientierter Ansatz, Teubner, Stuttgart, Leipzig 1999. Chamoni, P.; Gluchowski, P.; Gronwald, H.: Business Intelligence-Studie biMA 2004, Mummert Consulting, Hamburg 2004. Fürer, P.: Prozesse und EDV-Kostenverrechnung - Die prozessbasierte Verrechnungskonzeption für Bankrechenzentren, Diss., Universität St. Gallen, Bamberg 1993. Gschwend, W.: Die Zielproblematik des Verrechnungspreises - Eine kritische Analyse der verschiedenen Verrechnungspreisfunktionen, Diss., Universität St. Gallen, St. Gallen 1986. Gutzwiller, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Physica, Heidelberg 1994. Haberstock, L.: Kostenrechnung I - Einführung, 10. Aufl., Schmidt-Verlag, Berlin 1998. Hahn, S.; Jackson, M. H. A.; Kabath, B.; Kamel, A.; Meyers, C.; Matias, A. R.; Osterhoudt, M.; Robinson, G.: Capacity Planning for Business Intelligence Applications: Approaches and Methodologies, IBM Redbooks, 2000. Helfert, M.: Planung und Messung der Datenqualität in Data-WarehouseSystemen, Diss., Universität St. Gallen, Bamberg 2002. Jung, R.; Winter, R.: Justification of Data Warehousing Projects, in: Khosrowpour M. (Hrsg.): Managing Information Technology in a Global Economy (Proceedings zur IRMA 2001, Anchorage), IDEA Group Publishing, Hershey u.a. 2001, S. 54-57. Klesse, M.: Leistungsverrechnung im Data Warehousing - Entwicklung einer Methode, Diss., Universität St. Gallen, St. Gallen 2007. Kotkamp, S.: Electronic Publishing - Ökonomische Grundlagen des Handels mit Informationsprodukten, Diss., TH Karlsruhe, Karlsruhe 2001. Mai, J.: Konzeption einer controllinggerechten Kosten- und Leistungsrechnung für Rechenzentren, Peter Lang, Frankfurt/M. et al. 1996. Marzinzik, C.: Leistungsverrechnung als Instrument eines kostenorientierten Informationscontrolling - Ein prozesskostengestützter Ansatz zur Steuerung der Wirtschaftlichkeit der warenwirtschaftlichen Informationsverarbeitung von Handelsunternehmen, Verlag Dr. Kovac, Hamburg 1998. Nelson, R. R.; Todd, P. A.; Wixom, B. H.: Antecedents of Information and System Quality: An Empirical Examination Within the Context of Data Warehousing, in: Journal of Management Information Systems 21 (2005) 4, S. 199235.
272
Mario Klesse
OCG: IT Infrastructure Library (ITIL) - Service Delivery, Office of Government Commerce, The Stationery Office, 2001. Rehberg, J.: Wert und Kosten von Informationen, Harri Deutsch, Frankfurt/M. 1973. Remer, D.: Einführung der Prozesskostenrechnung - Grundlagen, Methodik, Einführung und Anwendung der verursachungsgerechten Gemeinkostenzurechnung, Schäffer-Poeschel, Stuttgart 1997. Scheeg, J. M.: Integrierte IT-Kostentabellen als Instrument für eine effiziente ITLeistungserbringung im Informationsmanagement - Konzeption und praktische Umsetzung, Universität St. Gallen, St. Gallen 2005. Wang, R. Y.; Allen, T.; Harris, W.; Madnick, S.: An Information Product Approach for Total Information Awareness, MIT Sloan School of Management, 2002. Wang, R. Y.; Strong, D. M.: Beyond Accuracy: What Data Quality Means to Data Consumers, in: Journal of Management of Information Systems 12 (1996) 4, S. 5-33. Wieding, A.: Leistungsrechnung: Ein prozessorientierter Ansatz, Gabler, Wiesbaden 2000. Wild, J.: Input-, Output- und Prozeßanalyse von Informationssystemen, in: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung 22 (1970) 1, S. 50-72.
13 Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
Robert Konzelmann Teradata
1 2 3 4
Einleitung ....................................................................................... 273 Planungsphasen .............................................................................. 280 TSM Phase: Design ........................................................................ 298 Zusammenfassung und Ausblick .................................................... 308 Literatur .......................................................................................... 310
1
Einleitung
Die Notwendigkeit von geeigneten Methodologien für die Entwicklung von Informationssystemen ist sicherlich unbestritten. Auch über ihre Wirkungen und ihr Zusammenspiel mit anderen grundlegenden Erfolgsfaktoren wie Fachwissen, Situationskenntnisse und Erfahrung wurde schon viel analysiert und geschrieben (vgl. hierzu z. B. Daenzer u. Huber 1992). Jedoch genauso groß wie die Einigkeit betreffend der Notwendigkeit (dem WAS?), ist die Uneinigkeit betreffend der eigentlichen Vorgehensweise (dem WIE?). Dies hat sicherlich auch mit den folgenden, in der Fachwelt etablierten, Grundsätzen einer Methodik zu tun (Daenzer u. Huber 1992): Eine Methodik… x ist nicht Selbstzweck, sondern muss zur Erarbeitung guter Lösungen dienen. x ist kein Ersatz für Begabung, erworbene Fähigkeiten, Situationskenntnisse, geistige Auseinandersetzung mit Problemen u. ä., sondern setzt diese voraus bzw. soll sie stimulieren. x soll mit sinnvollem Problemlösungsverhalten verträglich sein.
274
Robert Konzelmann
x ist kein Gegensatz zu Intuition und Kreativität, sondern macht diese zur Zielerreichung nutzbar. x bedeutet nicht Rezepte, sondern ist Leitfaden zur Problemlösung, der kreativ und intelligent anzuwenden ist. Der Nutzen der Anwendung ergibt sich erst aus dem eingebrachten geistigen Potenzial. x ist hinsichtlich des zu treibenden Aufwands auf den zu erwartenden Nutzen auszurichten. Die Schwierigkeit, die sich aus diesen Prinzipien ergibt, ist das finden der „goldenen Mitte“. Hier zeigt sich in der Praxis, dass das intuitive Vorgehen dem methodischen oft überproportional vorgezogen wird. Dies auf Grund mangelnden Methodenverständnisses und dem daraus resultierendem fehlendem Vertrauen, grober Unterschätzung der zu bewältigenden Problematik und Überschätzung der eigenen Fähigkeiten. Eine zusätzliche Schwierigkeit besteht darin, die für das jeweilige Problem korrekte Methode zu identifizieren. Zu oft wird daher auf generische Ansätze zurückgegriffen, die die spezifischen Problematiken nur ungenügend berücksichtigen. Dies macht sich insbesondere auch in Projekten zum Aufbau von Data Warehouse-Systemen bemerkbar, die sich in grundlegender Hinsicht von konventionellen Systemen unterscheiden (Strauch u. Winter 2002): x Das Data Warehouse-System stellt einen äußerst aufwändigen Bereich der betrieblichen Informationsverarbeitung dar, der sukzessiv aufgebaut werden muss und nur bei langfristiger und ganzheitlicher Betrachtung nachhaltig wirtschaftlich betrieben werden kann. Im Gegensatz dazu sind traditionelle betriebliche Anwendungssysteme im Normalfall besser isolierbar und müssen auch bei kurzfristiger, isolierter Betrachtung wirtschaftlich sein. x Alle Daten in einem Data Warehouse-System stammen aus den operativen Vorsystemen. Ein Data Warehouse-System kann also – im Gegensatz z. B. zu Anwendungssystemen zur Unterstützung bestimmter Kanäle oder Geschäftsbereiche (z. B. Call Center, Electronic Commerce) – nicht „auf der grünen Wiese“ entwickelt werden. x Die zukünftigen Benutzer eines Data Warehouse-Systems haben Schwierigkeiten, ihren Bedarf an Informationen, das heißt die Anforderungen an das zu entwickelnde System, zu Beginn eines Projekts überhaupt und abschließend zu spezifizieren. Für traditionelle betriebliche Anwendungssysteme ist dies zum Glück nicht der Normalfall. x Der Aufbau von Data Warehouse-Systemen stellt ein funktions- und bereichsübergreifendes Projekt dar, das nur erfolgreich sein kann, wenn es von genügend hoher Stelle im Unternehmen gefördert wird. Im Gegen-
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
275
satz dazu lassen sich Verantwortlichkeiten für bereichs- oder funktionsbezogene betriebliche Anwendungssysteme sehr gut lokalisieren („application owner“). Inmon definiert den Unterschied zwischen der Entwicklung von operativen und analytischen Systemen kurz und bündig: „Operational development is shaped around a development lifecycle that begins with requirements and ends with code. DSS processing begins with data and ends with requirements.“ (Inmon 1996). Diese eher plakative Aussage ist mit einer gewissen Vorsicht zu genießen, führt sie doch allzu oft zu einem angebotsorientierten Data Warehouse-Entwicklungsansatz, bei dem die Endbenutzer nur wenig Einfluss auf die Systemerstellung haben (Strauch u. Winter 2002). Korrekt dagegen ist die Aussage, dass die Informationsbedarfsanalyse einen gewichtiger Beitrag zum Erfolg oder Misserfolg eines jeden Data Warehouse-Systems beisteuert, und daher spezieller Beachtung bedarf. Dazu werden in der Praxis heutzutage meistens die Anforderungen zuerst auf einer hohen Abstraktionsstufe erfasst und anschließend sukzessive verfeinert. Dies ermöglicht ein iteratives Vorgehen, bei dem zusammen mit den Endbenutzern die Anforderungen ausgehend von den Geschäftszielen, über die daraus resultierenden Fachanforderungen mit ihren Kenn- und Steuerungsgrößen und der dafür benötigten Analysen der Informationsbedarf erhoben werden. Das iterative Vorgehen ist aber nicht nur für die Informationsbedarfsanalyse von Wichtigkeit, sondern stellt ein zentrales Konstrukt einer jeden Data Warehouse-Methodologie dar. Damit wird die Komplexität des Gesamtsystems in überschaubare Inkremente aufgebrochen und dadurch die Implementierung von neuen Anforderungen in einem vorhersehbaren und für die Endbenutzer akzeptablen Zeitrahmen ermöglicht. Um diesem hehren Ziel gerecht zu werden, bedarf es neben der iterativen Methodologie, flexibler und skalierbarer Strukturen, die die Widerverwendbarkeit schon vorhandener Daten fördern und eine einfache Integration neuer Datenobjekte ermöglichen. Die Teradata Solution Methodology (im weiteren TSM genannt) vereint all diese Anforderungen. Sie verfügt nicht nur über die oben erwähnten Grundkonzepte, sondern beinhaltet auch das Wissen und die Erfahrung aus einer Vielzahl erfolgreicher Data Warehouse-Implementierungen, welche jeweils in die kontinuierliche Weiterentwicklung der Methodologie einfließen. 1.1 Überblick Teradata Solution Methodology Methoden sind planmäßig angewandte, begründete Vorgehensweisen zur Erreichung von festgelegten Zielen (i. a. im Rahmen festgelegter Prinzi-
276
Robert Konzelmann
pien). Zu Methoden gehören eine Notation, systematische Handlungsanweisungen und Regeln zur Überprüfung der Ergebnisse (Hesse et al. 1992). Zu diesem Zweck definiert TSM in acht Phasen 43 Tätigkeiten, welche auf Aktivitätsebene die zu verwendenden Prozesse, Prozeduren und Techniken zusammen mit den dazugehörigen Rollen und Verantwortlichkeiten beschreiben (vgl. Abb. 1). Entsprechende Arbeitsvorlagen und Beispiele aus vergangenen Data Warehouse-Projekten ergänzen die Methodologie um „Best Practice“ Vorgehen, ermöglichen dadurch die Einbindung von vorhandenem Wissen und unterstützen und vereinfachen die Planung, Durchführung und Kontrolle der einzelnen Aktivitäten. Welche der Phasen und Aktivitäten jeweils zur Anwendung kommen, hängt von der zu erstellenden Lösung und der bestehenden Umgebung ab und muss jeweils vor Projektbeginn definiert werden. Diese Selektion kann horizontal, über die Tätigkeiten, und / oder vertikal, über die Phasen, erfolgen. So wird zum Beispiel die Strategie-Phase nur zu Beginn einer Enterprise Data Warehouse-Initiative durchlaufen, um dadurch die generellen Einsatzmöglichkeiten eines solchen Systems zu überprüfen und festzulegen. Andere Beispiele sind Projekte für die Datenqualitätsbereinigung, bei denen selektive Aktivitäten aus den Phasen Analyze und Build durchgeführt werden, oder Projekte, die den Betrieb eines Data Warehouse im Fokus haben und sich daher nur auf die Manage-Phase konzentrieren. Obgleich die in TSM definierten Phasen und Aktivitäten über eine logische Reihenfolge verfügen, handelt es sich nicht um ein klassisches Wasserfallmodell. Dies bedeutet insbesondere, dass Aktivitäten parallel ausgeführt werden können, und dass sie über einen iterativen Charakter verfügen. Weiter ist die abschließende Erstellung eines Objektes (wie zum Beispiel Analysedokumente oder Datenmodelle) nicht zwingend an eine einzelne Aktivität gebunden, sondern kann sich über mehrere Phasen, Tätigkeiten und Aktivitäten erstrecken. Die Phasen Strategy, Research und Analyze bilden die technologieneutrale Planungsphase und beinhalten unter anderem die Erhebung und Verfeinerung der Anforderungen und ihrer Informationsbedürfnisse, sowie die Definition der einzelnen Implementierungszyklen, sogenannte Inkremente. Am Ende dieser Phasen steht die logische Architektur.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
277
Strategy
Research
Analyze
Design
Equip
Build
Integrate
Manage
Opportunity Assessment
Business Value
Application Requirement
System Architecture
Hardware Installation
Physical Database
Components for Testing
Capacity Planning
Enterprise Assessment
EDW Maturity
Logical Model
Package Adaptation
Software Installation
ECTL Application
System Test
System Performance
Information Sourcing
Data Mapping
Custom Component
Support Management
Information Exploitation
Production Install
Business Continuity
Infrastructure & Education
Test Plan
Operational Mentoring
Operational Applications
Initial Data
Data Migration
Education Plan
Technical Education
Backup & Recovery
Acceptance Testing
System Relocation
User Curriculum
User Training
HardwareSoftware Upgrade
Value Assessment
Availability SLA
Planning
Implementation
System DBA Solution Architect Technical Expert
Production
Abb. 1. Teradata Solution Methodology (TSM)
Die Phasen Design, Equip und Build bilden zusammen die technologiegetriebene Implementierungsphase, welche die physische Architektur definieret und die Implementierung ihrer Komponenten steuert. Ein weiterer Schwerpunkt liegt in der Installation und Konfiguration der Systemumgebungen und der benötigten Software. Um die Integrität der Gesamtlösung jederzeit gewährleisten zu können, hat jede Änderung oder Erweiterung zumindest die System Architecture Aktivitäten innerhalb der Design Phase zu durchlaufen. Die Phasen Integrate und Manage bilden die Bereitstellungs- und Betriebsphase, in der die erstellte Lösung getestet, integriert, in die Produktion übergeben und gemäß den Anforderungen betrieben wird. Bevor wir nun in den folgenden Abschnitten aufzeigen, wie mittels TSM ein Data Warehouse-System erfolgreich zu gestalten ist, erscheint es uns als sinnvoll, den Begriff „System“ kurz zu erläutern. Dies insbesondere darum, weil in der Praxis leider immer noch viel zu oft ein beschränktes, die Technologie in den Vordergrund stellendes, Systemverständnis existiert. 1.2 Systeme und Architekturen „Das Wort System steht … für Konnektivität. Wir meinen damit jede Ansammlung miteinander in Beziehung stehender Teile … Was wir als Sys-
278
Robert Konzelmann
tem definieren, ist deshalb ein System, weil es miteinander in Beziehung stehende Teile umfasst und in gewisser Hinsicht ein … Ganzes bildet.“ (Daenzer u. Huber 1992). Jedes System lässt sich unter verschiedenen Gesichtspunkten betrachten und beschreiben. Dadurch treten jeweils bestimmte Eigenschaften (Merkmale von Elementen und ihrer Beziehungen) in den Vordergrund. Einen weiteren wichtigen Aspekt eines Systems definiert der IEEE-Standard 1471-2000 für softwareintensive Systeme. Jedes System dient mindestens einem Zweck (dies hat zumindest für Informationssysteme seine Gültigkeit), der über die Bedürfnisse der Stakeholder definiert wird.
Abb. 2. IEEE-Standard 1471-2000 für softwareintensive Systeme (Schekkerman 2004a)
Die Architektur vereint die unterschiedlichen Sichten (Views) und beschreibt somit das System. Dabei wird die Architektur als Gesamtarchitektur verstanden (vgl. hierzu z. B. Inmon et al. 1997), und definiert sich daher nicht ausschließlich über die Technologie, sondern beinhaltet auch die fachliche Sicht und die Informations- und Datensichten. Angelehnt an das Integrated Architecture Framework (IAF, vgl. Mulholland u. Macaulay 2006) lassen sich sechs Sichten über vier Ebenen für eine Data Warehouse-Systemarchitektur definieren, um daraus die benötigten Sichten zu generieren. x Die erste Ebene definiert den Zweck des Gesamtsystems. Im speziellen geht es um die Ziele die mit dem System zu erreichen sind, die Systemgrenzen und die einzuhaltenden Rahmenbedingungen. x Die zweite Ebene definiert, was zu tun ist, um diese Ziele zu erreichen. Dabei wird auch das Gesamtsystem in eigenständige Inkremente unterteilt.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
279
x Die dritte Ebene definiert technologieneutral, wie ein spezifisches Inkrement umgesetzt wird und beinhaltet die logische Architektur. x Die vierte Ebene definiert anhand der physischen Modelle, der benötigten technologischen Komponenten und ihrer Konfiguration die physische Architektur. Über diese Ebenen werden die Sichten gelegt, die die zu erstellenden Komponenten (Artefakte) und ihre Beziehungen definieren. x Die fachliche Sicht beschreibt alle bestehenden und zu erstellenden fachlich relevanten Komponenten wie Geschäftsziele, Geschäftsprozesse und Organisationsstrukturen. x Die Informationssicht definiert alle bestehenden und zu erstellenden fachlich relevanten Informationskomponenten wie Kommunikationsmodelle, Datenflüsse und Datenmodelle. x Die Informationssystemsicht definiert alle bestehenden und zu erstellenden Informationssysteme (Eigenentwicklungen und Standardsoftware), die die Geschäftsprozesse unterstützen und die relevanten Informationen beinhalten. x Die Technologiesicht definiert die vorhandene und benötigte Infrastruktur. x Die Betriebssicht definiert alle vorhandenen und benötigten Betriebskomponenten. Sie ist ein interdisziplinärer Bestandteil aller vorhergehenden Sichten. x Die Sicherheitssicht definiert alle vorhandenen und benötigten Sicherheitskomponenten. Sie ist ein interdisziplinärer Bestandteil aller vorhergehenden Sichten. Die Sichten (Views) ergeben sich aus der Gruppierung und Selektion von verschiedenen Artefakten, die zusammen einen Teilaspekt der Gesamtarchitektur definieren. Die Teradata Solution Methodology verfügt über mehrere solcher vordefinierter Sichten, die für die einzelnen Projekte individuell anpassbar sind. Abbildung 3 zeigt die Views für eine Enterprise Data Warehouse-Architektur, welche in den nächsten Abschnitten näher erläutert wird.
280
Robert Konzelmann
Opportunity Assessment
Enterprise Assessment
Business
Information
Information System
Technology Infrastr.
Security
Governance
Business Value Data Warehouse Maturity Information Sourcing
Application Requirement Logical Model Data Mapping
System Architecture Package Adaption Custom Components Test Plan
Abb. 3. Architekturrelevante TSM-Phasen (angelehnt an das Integrated Architecture Framework)
Ziel der nachfolgenden Abschnitte ist es, aufzuzeigen, wie mit Hilfe von TSM eine konsistente, erweiterbare und anforderungsgetriebene Data Warehouse-Architektur erstellt werden kann. Dafür werden die vier Phasen Strategy, Research, Analyze und Design genauer betrachtet. Während die darin enthaltenen Aktivitäten für die meisten Data Warehouse-Projekte ihre Gültigkeit haben und generell beschrieben werden können, hängt die physische Umsetzung der Architektur und der spätere Betrieb des Data Warehouse-Systems stark von den zu verwendenden einzelnen technischen Komponenten und Werkzeugen, sowie von der Umgebung, in der es betrieben wird, ab. Die Phasen Equip, Build, Integrate und Manage tragen diesem Umstand Rechnung, und sind daher sehr umfangreich gestaltet. Es wird daher im Rahmen dieses Buches darauf verzichtet, diese im Detail zu beschreiben.
2
Planungsphasen
Das wohl meistzitierte Gespräch zwischen Mensch und Tier in IT-Projektmethodologie-Büchern stammt aus „Alice's Adventures in Wonderland“ (Carroll 1865) und identifiziert das Problem so mancher Planung:
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
281
Das Fehlen einer der drei Komponenten Ist-Situation, Soll-Situation und des Wegs von Ist zu Soll. „‘Would you tell me, please, which way I ought to go from here?‘ said Alice. ‘That depends a good deal on where you want to get to‘, said the Cat. ‘I don't much care where –‘ said Alice. ‘Then it doesn't matter which way you go‘, said the Cat.“ Diese drei Komponenten sind die Treiber der folgenden technologieunabhängigen Planungsphasen und decken sich im Wesentlichen mit den von Strauch und Winter definierten Anforderungen für die Informationsbedarfsanalyse (Strauch u. Winter 2002): x Informationslandkarte: Als Ergebnis der Informationsbedarfsanalyse im Data Warehousing wird eine so genannte „Informationslandkarte“ verlangt, die auf aggregierter Ebene beispielsweise Aussagen darüber macht, aus welchen Quellsystemen welche Daten stammen, welche Organisationseinheiten welche Informationen erhalten, welche Begriffe homonym bzw. synonym verwendet werden etc. x Ist-Zustand der Informationsversorgung: Die Informationsbedarfsanalyse muss den Ist-Zustand der Informationsversorgung erfassen können. Dies bedingt sowohl die Analyse der bereits angebotenen Informationen wie auch der Datenqualität in den Quellsysteme. Die hiermit erzielten Ergebnisse müssen in die Informationslandkarte einfließen. x Soll-Zustand der Informationsversorgung: Der Soll-Zustand der Informationsversorgung muss auch zukünftige Anforderungen an die Informationsversorgung mittels Data Warehouse-Systemen umfassen. x Priorisierung: Die durch das Data Warehouse-System bereitzustellenden Informationen müssen auf Grund von beispielsweise zeitlichen oder finanziellen Restriktionen und ihrer Wichtigkeit für die betriebliche Aufgabenerfüllung beurteilt und priorisiert werden. x Homogenisierung der Begriffe: Die Integration operativer Daten in einem zentralen Data Warehouse bedingt die Vereinheitlichung der darauf aufbauenden Informationen und der entsprechenden Begriffswelt. x Abstimmung mit dem Modellierungsansatz: Die Informationsbedarfsanalyse muss die Objekte des gewählten semantischen Datenmodells (Fachkonzept) berücksichtigen. Dabei werden multidimensionale, semantische Datenmodelle bevorzugt. x Dokumentation: Die Informationsbedarfsanalyse liefert wertvolle Metadaten, die maschinell erfasst werden sollten, um diese im Anschluss an ein Data Warehouse-Projekt nicht mit hohem Aufwand zusammentragen zu müssen.
282
Robert Konzelmann
2.1 TSM Phase: Strategy Gängigen Business Engineering-Ansätzen folgend wird in dieser ersten Phase die strategische Positionierung des Data Warehouse spezifiziert (Winter 2003). Diese definiert insbesondere das „WARUM wird das System benötigt“, den Umfang und generell gültige Grundsätze. Allzu oft wird zu wenig Gewicht auf den eigentlichen Sinn und Zweck des Systems gelegt, und zu rasch der Fokus auf die zu erstellende Lösung gelegt. Der Grund dafür liegt oft in der kurzsichtigen Annahme, dass die Entwicklung von anforderungsgetriebenen Data Warehouse-Lösungen zu zeitintensiv sei. Basierend auf unseren Erfahrungen lohnt sich jedoch dieser Aufwand, garantiert doch nur dieser die Akzeptanz und die Verwendung des Systems durch die Endbenutzer (vgl. dazu auch Strauch u. Winter 2002; Gam u. Salinesi 2006). Inmon et al. formulieren diesen Umstand sehr treffend: „If motivations are ignored, the result may be a system which is very efficient in addressing the wrong objective.“ (Inmon et al. 1997). 2.1.1
TSM Tätigkeit: Opportunity Assessment
Ziel dieser Aktivitäten ist es, Nutzen und Einsatzmöglichkeiten einer möglichen Enterprise Data Warehouse-Lösung zu evaluieren. Dafür wird die Ist-Situation erhoben und mit den Unternehmenszielen verglichen. Eventuelle Diskrepanzen werden dahin gehend untersucht, ob und in wie weit diese auf fehlende oder ungenügende Informationsversorgung zurückzuführen sind. Dabei sollten auch Referenzen aus demselben oder vergleichbaren Geschäftsumfeld herbeigezogen werden, um zu verstehen, wie der Markt diese Themen angeht und wohin er sich in der nähren Zukunft bewegt. Am Ende dieser Aktivitäten steht eine Empfehlung, ob und in welchen Bereichen mit welchen Zielen ein Data Warehouse-System zu erstellen ist. 2.1.2
TSM Tätigkeit: Enterprise Assessment
Ausgehend von den definierten Zielen wird die Machbarkeit einer Data Warehouse-Einführung für alle relevanten Geschäftsbereiche anhand ihrer bestehenden Applikations- und Systemlandschaft, ihrer vorhandenen und benötigten Informationsarchitektur und ihrer Prozesse erhoben und gewichtet. Am Ende steht die Data Warehouse-Implementierungsstrategie, die die identifizierten und gewichteten einzelnen Data Warehouse-Initiativen beschreibt.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
283
Dazu werden verschiedene Übersichten und erste Modelle erstellt, die im Laufe des Projektes stetig verfeinert werden. Die Plattformübersicht ist eine erste Ist-Aufnahme aller relevanten Hardware- und Netzwerkkomponenten inklusive ihres Standortes. Zusätzlich zu dokumentieren sind geplante Systemerweiterungen oder Ablösungen und ihr Einfluss auf die bestehende oder die neu zu erstellende Data Warehouse-Umgebung. Die Applikationsübersicht ist eine erste Ist-Aufnahme aller potenziellen Quellen des zukünftigen Data Warehouse, ihrer Datenstrukturen und Schnittstellen. Zusätzlich zu dokumentieren sind geplante Erweiterungen oder Ablösungen und ihr Einfluss auf die bestehende oder die neu zu erstellende Data Warehouse-Umgebung. Die Organisationsübersicht ist ein um die System- und Applikationsverantwortlichen erweitertes Organigramm. Es dient insbesondere dazu, die benötigten Spezialisten frühzeitig zu identifizieren und ihre jeweilige Verfügbarkeit zu dokumentieren. Das Geschäftsprozessmodell bildet die heutigen und die zukünftigen Prozesse auf einer hohen Abstraktionsstufe ab. Ziel ist die Identifizierung der für das nachfolgend zu erstelllende Informationsmodell benötigten Kernentitäten. Das Informationsmodell ist ein in der ersten Normalform gehaltenes logisches Data Warehouse-Datenmodell. Dabei wird auch das initiale Data Dictionary erstellt, das die Definitionen der Entitäten und ihrer Beziehungen enthält. 2.2 TSM Phase: Research Basierend auf dem in der Strategy Phase definierten Gesamtumfang werden für die einzelnen Geschäftsbereiche die einzelnen Lösungen definiert und priorisiert. Dafür können die folgenden Kenngrößen als Entscheidungskriterien verwendet werden (Geiger 2007): x Prognostizierter Geschäftsnutzen x Datenverfügbarkeit im Unternehmen x Komplexität der Lösung Die nebenstehende Grafik visualisiert diese Kriterien anhand eines Entscheidungswürfels. Danach sollten die Projekte im äußeren rechten Quader (hoher Geschäftsnutzen, hohe Datenverfügbarkeit, geringe Komplexität) zuerst angegangen werden, gefolgt von den Projekten mit hohem Geschäftsnutzen.
284
Robert Konzelmann Zu priorisierende Lösungen
Geschäftsnutzen
Hoch Tief
Datenverfügbarkeit Hoch
Tief
Abb. 4. Entscheidungswürfel
Ziel der folgenden Aktivitäten ist es, diese Kriterien zu erheben und ihr Wechselspiel aufzuzeigen. Daraus resultiert die Data Warehouse-Gesamtplanung, welche die einzelnen zu erstellenden Lösungen gruppiert, und gemäß dem inkrementellen Vorgehen priorisiert (vgl. Abb. 5). Inkrement 2
Inkrement 3
EDW Infrastruktur
Inkrement 1 Integrierte Kundensicht
Kundenverhalten
Finanzberichte
Ziel und Zweck
Erstellen einer zentralen und skalierbaren Data Warehouse-Infrastruktur für die Gesamtunternehmung
Integrieren und unifizieren der unternehmensweiten Kundendaten, um eine „Single View of the Client“ zu ermöglichen
Durch die Integration von Transaktionsdaten können das Kundenverhalten analysiert und Segmente erstellt werden
Das Erstellen aller unternehmensweiten Finanzberichte geschieht über das Data Warehouse
BIO
Datenarchitektur, analytische Architektur und Modellierung
Unternehmensweite Datenintegration Datenqualität Master Data Management
Kundenbindung Zahlungsanalyse
FinanzkennzahlReporting
Kundenstammdaten Produktdaten
Transaktionsdaten
GL-Daten
Benötigte Daten Hauptaktivitäten
Aufbau Infrastruktur (Hardware und Software) Aufsetzen der benötigten Prozesse
Datenmodellierung Erstellen der Ladeprogramme Erstellen von Berichten Aufsetzen von Datenqualitätsprozessen
Erweitern des Datenmodells um Transaktionsdaten Erstellen Ladeprogramme für Transaktionsdaten
Erweitern des Datenmodells um Finanzdaten Erstellen der Ladeprogramme Erstelle der einzelnen Berichte
Zeitrahmen
1 Monat
8 – 10 Monate
4 – 6 Monate
4 – 6 Monate
Abb. 5. Beispiel-Übersicht über eine Data Warehouse-Gesamtplanung
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse 2.2.1
285
TSM Tätigkeit: Business Value
Um den Geschäftsnutzen einzelner Data Warehouse-Lösungen quantifizieren und gewichten zu können, müssen diese erst einmal erhoben und analysiert werden. Dafür hat sich in der Praxis ein vierteiliger Regelkreis bewährt; sogenannte Business Improvement Opportunities1 (BIO). Dabei werden die Geschäftsmöglichkeiten, die sich aus den Geschäftszielen ableiten lassen, erhoben, und daraus der Informationsbedarf2 der zur Steuerung und Kontrolle notwendigen Aktivitäten definiert. Die daraus entstehenden Prozessverbesserungen generieren den Geschäftsnutzen. Die nachfolgende Grafik zeigt einen solchen Regelkreis am vereinfachten Beispiel „Erhöhung der Kundenbindung“: Ziele:
Analysen:
• Identifizieren der „wertvollen“ Kunden • Verbessern der Kundenloyalität • Frühes Erkennen von abwanderungswilligen Kunden, und Einleiten von geeigneten Gegenmaßnahmen
• • • • • •
Kundenprofitabilität Kundenakquisitionskosten Erfolg der Kundenbindungsmaßnahmen Kundeloyalität und Zufriedenheit Veränderungen im Kundenverhalten Nächstbestes Angebot
Resultate:
Aktivitäten:
• Erhöhte Kundenbindung und Loyalität • Erhöhter LTV (durchschnittlich um x%) • Erhöhte Kundenzufriedenheit (Reduktion der Beschwerden um x%) • Reduzieren der Kundenakquisitionskosten (um x% für Segment A / y% für Segment B …) • Vermehrter Up- und Cross-Sell (durchschn. Anzahl Produkte = x)
• Entwickeln von kundenzentrierten Angeboten, um profitable Kunden zu behalten und / oder zurückgewinnen • Entwickeln von KundenloyalitätsProgrammen, um die Kundenbindung zu erhöhen
Abb. 6. Business Improvement Opportunity-Beispiel: Erhöhung der Kundenbindung
Lassen sich die ersten drei Komponenten durch gezielte Analyse erheben, so ist es doch ungemein anspruchsvoller, die anzustrebenden Resul1
2
Eine Business Improvement Opportunity enthält die Definition einer Geschäftsinitiative, die einmal umgesetzt einen direkten Geschäftsnutzen erzeugt (o. V. 2006b). Der Informationsbedarf wird definiert als die Art, Menge und Qualität der Informationen, die eine Person zur Erfüllung ihrer Aufgaben in einer bestimmten Zeit benötigt. Er ist in vielen Fällen nur vage bestimmbar und hängt vor allem von der zu Grunde liegenden Aufgabenstellung, den angestrebten Zielen und den psychologischen Eigenschaften des Entscheidungsträgers ab (Picot et al. 1996, S. 106).
286
Robert Konzelmann
tate und den daraus zu erwartenden Nutzen, zu spezifizieren und quantifizieren. Eigene Erfahrungen und Vergleichsdaten aus ähnlichen Projekten und Branchen können hierfür eine erste Basis bieten und damit diesen Prozess entscheidend unterstützen. Einen Schritt weiter gehen die Business Impact Models (BIM) von Teradata, die neben Referenzdaten auch über branchen- und lösungsspezifische Berechnungsmodelle verfügen und so nicht nur den Nutzen, sondern auch die zu erwartenden Kosten antizipieren können. Unabhängig vom gewählten Vorgehen resultieren dabei immer Näherungswerte, können doch verlässliche Kostenaussagen erst nach der Analyse zusammen mit der Auswahl der technischen Komponenten und der daraus abzuleitenden Architektur gemacht werden. Das zweite Selektionskriterium für die Initiativen, die Datenverfügbarkeit, sagt aus, in wie weit die einzelnen Informationsbedarfe durch bestehende operationelle oder analytische Systeme befriedigt werden können. Dieses lässt sich über Fragestellungen und benötigte Mess- und Kenngrößen (sogenannte Key Performance Indicators, KPIs) erheben. Für die „Erhöhung der Kundenbindung“ könnten diese unter anderem lauten: Fragestellungen x Wie viele Kunden können nicht bedient werden, wenn x% unserer Bankomaten während y Stunden nicht verfügbar sind? x Welche Muster im Kundenverhalten deuten auf eine baldige Auflösung der Geschäftsbeziehung hin? x Was ist das typische Kundenprofil pro Produkt? KPIs x Durchschnittliche Anzahl Transaktionen pro Kundensegment x Kundenprofitabilität x Kundenfluktationsrate Fragestellungen und KPIs können dabei Teil mehrerer Business Improvement Opportunities sein. Dabei zeigt sich auch einer der Hauptnutzen eines Enterprise Data Warehouse, ermöglicht dieses doch, mittels derselben Daten unterschiedliche Informationsbedürfnisse unternehmensweit, geschäftsbereichsübergreifend zu unterstützen. Daraus lässt sich auch das dritte Selektionskriterium, die Komplexität, ableiten. Diese ist insbesondere davon abhängig, wie viele neue Datenobjekte aus unterschiedlichen Datenquellen zu extrahieren, laden und integrieren sind. Dafür ist eine Gruppierung der einzelnen Business Improvement Opportunities anhand ihrer Informationsbedarfe und der daraus abzuleitenden Datenobjekte notwendig. Um diese Komplexität sinnvoll abbilden und analysieren zu kön-
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
287
nen, stellt Teradata ein Visualisierungswerkzeug zu Verfügung, das nachfolgend kurz beschrieben werden soll. Teradata EDW Roadmap Die Teradata Enterprise Data Warehouse-Roadmap ist ein Planungswerkzeug, welches dem Benutzer einerseits ermöglicht, sich eine Übersicht bezüglich des momentanen Nutzens und Informationsgehalts seines Data Warehouse zu verschaffen und anderseits zu analysieren, mit welchem Aufwand welche zusätzlichen BIOs, Fragestellungen und KPIs unterstützt werden können. Die nachfolgende Abbildung zeigt die Gesamtübersicht und die Verknüpfung einer Fragestellung (in der Mitte links) zu einer Business Improvement Opportunity (oben in der Mitte) und zu den benötigten Datenobjekten (untere Hälfte) und ihren Quellen. Weiter lassen sich auch erkennen, für welche Geschäftsbereiche (oben rechts) diese Fragestellung relevant ist. Darüber hinaus zeigt die EDW Roadmap, in wie weit für die Fragestellungen und KPIs benötigten Daten im DWH vorliegen.
Abb 7: Teradata Enterprise Data Wareouse Roadmap (EDWr, vgl. o. V. 2006b)
Analysen können dabei über den Ist-Zustand durchgeführt werden, wie zum Beispiel “Welche Fragestellungen und KPIs können heute schon durch das Data Warehouse beantwortet werden?“, oder zukünftige Inkremente betreffen und damit die Planung und Priorisierung aktiv unterstützen.
288
Robert Konzelmann
Entscheidend für die Qualität der Analysen ist die dem Modell zu Grunde liegende Datenbasis. Diese besteht einerseits aus den Vergleichsdaten, d. h. der Beschreibung der einzelnen Objekte, ihrer Verknüpfungen und ihrer relativen Gewichtung zueinander, und anderseits aus der Informatione, welche Daten bereits im Data Warehouse zur Verfügung stehen. Die Vergleichsdaten basieren auf den gesammelten Erfahrungen aus branchenspezifischen Teradata Data Warehouse-Projekten und können durch das Projekt beliebig verändert oder erweitert werden. So enthält zum Beispiel die Roadmap für die Finanzdienstleistungsbranche 29 Business Improvement Opportunities, 387 Fragestellungen und 161 KPIs mit ihren jeweiligen Abhängigkeiten und Verknüpfungen. Die Datenobjekte basieren auf dem Teradata Financial Services Logical Data Model (TD FS-LDM), welches mit seinen mehr als 1700 Entitäten in der Lage ist, ein Gesamtunternehmen umfassend abzubilden. 2.2.2
TSM Tätigkeit: Data Warehouse Maturity Assessment
Im Gegensatz zu den vorhergehenden Aktivitäten, welche neue Anforderungen erhoben und gewichteten, fokussiert ein Data Warehouse Maturity Assessment auf das bestehende System. Es ermöglicht die Gegenüberstellung der Geschäftsziele mit der momentanen Funktionalität der analytischen Plattform und zeigt Schwachstellen auf, die das Erreichen dieser Ziele erschweren oder gar verhindern können. Dafür muss ein Modell verwendet werden, welches die unterschiedlichen Reifestadien betreffend der Prozessführung und -steuerung innerhalb einer Unternehmung mit der einer analytischen Plattform vergleichen kann. Die involvierten Geschäftsbereiche müssen dabei einzeln bewertet werden, da sich diese in unterschiedlichen Stadien befinden können. Eine zusätzliche, insbesondere für die Data Warehouse-Strategie interessante Sicht ist der Vergleich gegen den Markbenchmark. Voraussetzung dafür ist die Verwendung eines etablierten Modells, welches über branchen- oder lösungsspezifische Vergleichsdaten verfügt. Ein solches ist das Teradata Data Warehouse Maturity Model, welches für jede Reifestufe spezifische Analysebedürfnisse definiert. Diese basieren auf der Annahme, dass die Komplexität der Analysen und ihre Einbindung in die Geschäftsprozesse mit der jeweiligen Reife der Geschäftsbereiche steigt.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
289
Business Maturity Operate
Understand
Change
Grow
Compete
Is it happening?
What happened?
Why did it happen?
What will happen?
What is happening?
Lead
Make it happen!
Data Warehouse Maturity
Abb: 8: Teradata Data Warehouse Maturity Model Bewertungsskala
Operate (Stufe 1) Das Unternehmen befindet sich in der Aufbauphase und hat den Fokus auf die Entwicklung seiner Produkte und Leistungen. Die Analysen werden direkt aus den operationellen Systemen oder aus nicht integrierten Eigenlösungen (z. B. Excel.Lösungen) erstellt. Understand (Stufe 2) Das Unternehmen ist weiterhin im Aufbau, verfügt aber über klar definierte Geschäftsziele und misst sich dagegen. Für die Analyse werden einfache Batchreports aus einer zentralen oder dezentralen Analyseumgebung erstellt. Change (Stufe 3) Das Unternehmen verfügt über eine Geschäftsstrategie, die sich über die Kundenzufriedenheit bezüglich der angebotenen Produkte und Leistungen definiert. Für erweiterte Analysen werden spezifische Data Marts mit OLAP-Fähigkeiten erstellt. Grow (Stufe 4) Das Unternehmen verfügt über alle grundlegenden Prozesse. Seine Wachstumsstrategie beinhaltet nun auch externe Faktoren und basiert unter anderem auf Vorhersagen. Technisch und analytisch versierte Benutzer verwenden vermehrt die Daten direkt im Data Warehouse zur Erstellung von Trendanalysenmodellen. Compete (Stufe 5) Um die Geschäftszyklen korrekt zu antizipieren und die Marktstellung langfristig zu behaupten, entwickelt das Unternehmen seine Prozesse, Infrastruktur, Organisation und Kultur stetig weiter. Daten werden täglich, und vermehrt auch untertags, in das Data Warehouse geladen. Die Analyse basieren auf integrierten und granularen Datensätzen. Lead (Stufe 6) Anhaltende Innovationen bezüglich Produkten, internen Prozessen und des Umgangs mit Informationen steigern nachhaltig die Produktivität der Unternehmung. Das Data Warehouse ist operationalisiert und wird zeitgerecht geladen, um so Geschäftsprozesse direkt zu unterstützen oder anzustoßen. Das Modell sieht vor, dass man in einem ersten Schritt den Geschäftsbereich oder die Geschäftsbereiche mittels Interviews und Dokumentenstudien anhand dieser sechs Stufen bewertet. Das Resultat ist ein gewichteter Wert und soll den generellen Trend widerspiegeln. In einem zweiten Schritt wird die analytische Landschaft (Data Warehouse und eventuelle
290
Robert Konzelmann
Data Marts) aus dem Blickwinkel der Planung, der Benutzer, der Daten und des Betriebes betrachtet und gemäß der Skala bewertet. Die Planungssicht beschäftigt sich mit den Fragen, wie mit Anforderungen und ihrer Finanzierung umgegangen wird, wie ihr Nutzen gemessen wird welche architektonischen Vorgaben und Richtlinien bestehen und wie diese umgesetzt werden. Die Benutzersicht beschäftigt sich mit den Fragen, welche Mitarbeiter wie, wann, wo und mit welchen Mitteln Zugriff auf die Daten erhalten. Auch wird erhoben, wie die Benutzer bezüglich der Verwendung der analytischen Plattform geschult und auf dem Laufenden gehalten werden. Die Datensicht beschäftigt sich mit den Fragen, wie und wo Daten integriert werden, wo welche Analysen stattfinden und welche Datenmodelle dafür verwendet werden. Ein weiterer Schwerpunkt wird dabei auf die Datenqualität und Datensicherheit gelegt. Die Betriebssicht beschäftigt sich mit den Fragen, wie die durch das Beladen und durch die Analysen und Berichte generierten Arbeitslasten miteinander in Einklang gebracht werden und ihren Einfluss auf die mit den Endbenutzern vereinbarten Service Level Agreements (SLA). Hierzu wird auch die Ausfallsicherheit und die Backup- und Recovery-Fähigkeit des Gesamtsystems untersucht. Die daraus resultierende Bestandsaufnahme der analytischen Umgebung zeigt die Diskrepanzen zwischen der Ist-Architektur und der von den Geschäftszielen abgeleiteten Zielarchitektur auf. Dabei werden zu schließende Lücken wie auch überdimensionierte Lösungskomponenten beleuchtet. 2.2.3
TSM Tätigkeit: Information Sourcing
Das Information Sourcing schließt die Arbeiten rund um die kontextuelle Ebene ab. In dieser Tätigkeit werden die fehlenden Informationen bezüglich der potenziellen Quellsysteme und der darin erhaltenen Datenelemente auf Entitätsebene erhoben, analysiert und dokumentiert. Als Basis dafür dienen die erhobenen Fragestellungen, KPIs und anderen existierenden Anforderungen (zum Beispiel gesetzliche Auskunftspflichten oder Berichte). Dabei ist jeweils zu beachten, dass die Daten aus dem System geladen werden, dass auch über die Daten-Ownership verfügt. In den meisten Fällen ist dies das System, in dem die Daten ursprünglich generiert wurden. Alle Bereiche, die einen Einfluss auf die Erstellung der Schnittstellen und das spätere Beladen haben, müssen dokumentiert werden. Dies betrifft insbesondere Informationen betreffend des Betriebssystems, der Datenbank und Filesystem sowie der Verfügbarkeit des Gesamtsystems und der benötigten Datensätze.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
291
Die nachfolgende Analysephase detailliert die Anforderungen des zu erstellenden Inkrementes, wodurch erste verlässliche Angaben betreffend des Aufwands gemacht werden können. 2.3 TSM Phase: Analyze Gemäß Strauch und Winter muss eine Methodik für die Informationsanalyse im Data Warehousing ausgehend vom Informationsbedarf der Benutzer einen Abgleich mit dem Ist-Zustand der Informationsbereitstellung vornehmen, abzudeckende Informationsbedarfe bewerten, priorisieren und homogenisieren, um schließlich daraus die Datensicht des Data Warehouse-Fachkonzepts abzuleiten (Strauch u. Winter 2002). Wurde dies in der vorhergehenden Phase für das Gesamtsystem auf einer höheren Abstraktionsstufe durchgeführt, werden diese Ergebnisse nun für das zu implementierende Inkrement detailliert. 2.3.1
TSM Tätigkeit: Application Requirements
Eine im Jahr 2000 durch die Standish Group International durchgeführten Studie identifiziert das Fehlen von „firm basic requirements“ als eine der zehn häufigsten Gründe für das Scheitern von IT-Projekten. Das Resultat einer internen Teradata Studie aus dem Jahre 2005 zeigt auf, dass 90% aller befragten Projektleiter das Anforderungsmanagement als ihre größte Herausforderung sehen (vgl. Tabelle 1). Tabelle 1. Teradata Project Methodology (TPM) Umfrageergebnisse 2005 Wichtigste Prozessprioritäten für TPM 5.0 nach Bereich Prozessbereich / TPM Work Stream % Angaben 1. Anforderungsmanagement 90% 2. Risikomanagement 86% 3. Qualitätsmanagement 81% 4. Zeit- und Budgetmanagement 76% 5. Konfigurationsmanagement 62%
Die Schwierigkeiten bei der Anforderungserhebung liegen meist im Detail und sind so vielschichtig wie das zu erstellende System. Objektiv lassen sie sich dennoch meistens auf folgende grundlegende Schwierigkeiten zurückführen.
292
Robert Konzelmann
x Die meisten Projekte enthalten Anforderungen von verschiedenen Benutzergruppen und Organisationseinheiten, welche sich oft nur schwer miteinander in Einklang bringen lassen. x Dem Projektteam fällt es schwer, die Anforderungen mit dem notwendigen Detaillierungsgrad zu erheben. Während die oft begrenzte Verfügbarkeit der benötigten Spezialisten innerhalb des Unternehmens zu einer oberflächlichen Analyse führt, birgt die Tendenz von vielen Projektmitarbeitern, über das absolute Wissen verfügen zu müssen, die Gefahr einer nicht endenden Analysephase. Eine weitere Schwierigkeit kann sich auch aus einer vorgängigen Proof of Concept-Phase ergeben, in der den Endbenutzern schon eine „fertige“ Lösung präsentiert wurde und er daher den Sinn einer weiteren Analyse nicht mehr einsieht. x Oft fehlt das Verständnis betreffend des Projektziels und der dafür zu erbringenden Leistung. Es ist insbesondere immer wieder in IT-Projekten zu beobachten, dass man versucht, die Lösung zu „vergolden“, indem man zusätzliche, meistens technische, Anforderungen einbringt, die nicht zur Erreichung der Projektziele notwendig sind. x Endbenutzer sind sich zu Projektbeginn oft unschlüssig, was sie benötigen (eher schon können sie definieren, was sie nicht wollen). Endbenutzer wissen, was sie wollen wen sie es sehen und versuchen daher, neue Anforderungen in späteren Projektphasen einzubringen. Wie solche Schwierigkeiten anzugehen sind, wurde in unzähligen Methodologien und Büchern bereits ausführlich festgehalten (vgl. z. B. Schienmann 2001). Es soll daher nicht Ziel dieses Beitrags sein, diese hier wiederzugeben. Nichtsdestotrotz scheint es uns von Bedeutung, die für uns wichtigsten Grundsätze in Bezug der Anforderungserhebung kurz zu erläutern. x Die Endbenutzer müssen über den Nutzen und die Wirkung von Anforderungen Bescheid wissen und bereit sein, ihr fachliches Wissen an das Projektteam weiterzugeben. x Das Erheben der Anforderungen erfolgt nach einem definierten Prozess mit definierten Endprodukten. Welche Methodologie dabei eingesetzt wird (z. B. Use Cases) ist zweitrangig und hängt von den Rahmenbedingungen und den Fähigkeiten der Projektmitarbeiter ab. Eine Anforderung besteht immer aus der Motivation, der Ist-Situation, der Soll-Situation und Transformation von Ist zu Soll. Unsicherheiten werden als Annahmen beschrieben, inklusive ihrer Auswirkungen, falls sie sich zu einem späteren Zeitpunkt als inkorrekt erweisen. x Prototyping und grafische Darstellungen helfen den Endbenutzern, ihre Anforderungen zu spezifizieren und zu verifizieren.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
293
x Das Projekt muss die Möglichkeit haben, auf sich verändernde Anforderungen zu reagieren. Dafür benötigt es zwingend neben den erforderlichen Detailkenntnissen eine ganzheitliche Sicht auf das zu entwickelnde System und seine Umsysteme. Gemäß IEEE Software Engineering sind Anforderungen Voraussetzungen oder Fähigkeiten, die ein System oder eine Systemkomponente gemäß Vertrag, Standard, Spezifikation oder anderen formellen Dokumenten erfüllen muss, um durch den Auftraggeber akzeptiert und abgenommen zu werden. Daraus lässt sich ableiten, dass Anforderungen eine Zerlegung des Gesamtsystems sind, wobei diese Komponenten in sich abgeschlossene und messbare Einheiten bilden müssen. Gemäß der Teradata Project Methodology (o. V. 2006a) sollten Data Warehouse-Anforderungen den folgenden Kriterien genügen: x Benötigt: Anforderungen beschreiben die von einem Benützer oder System benötigten Funktionen und Fähigkeiten um eine bestimmte Aufgabe und ihre Ziele zu erfüllen. x Durchführbar: Anforderungen müssen mittels der vorhandenen technischen und monetären Mittel erreichbar sein und müssen sich innerhalb der bekannten Rahmenbedingungen bewegen. x Testbar: Anforderungen müssen so gestellt sein, dass sie mittels eines definierten Verfahrens eindeutig auf ihre korrekte Implementierung getestet werden können. x Vollständig: Alle kritischen Anforderungen an ein System müssen definiert werden. Als kritische Anforderungen werden solche definiert, die ein System daran hindern, seinen eigentlichen Zweck zu erfüllen, falls sie weggelassen werden. x Elementar: Anforderungen sollen in kleinstmöglicher (elementarer) Form definiert werden. x Einmalig: Jede Anforderung darf nur einmal existieren und muss eindeutig identifizierbar sein. x Lösungsneutral: Anforderungen enthalten keine Spezifikationen, wie eine Lösung zu implementieren ist. Diese sind in Rahmenbedingungen festzuhalten, gegen die die einzelnen Anforderungen jeweils geprüft werden (siehe Durchführbar). x Nachvollziehbar: Anforderungen müssen nachvollziehbar sein und Informationen über ihren Ursprung enthalten. x Abhängigkeiten aufzeigen: Abhängigkeiten von oder zu anderen Anforderungen müssen definiert und dokumentiert sein. Dies gilt sowohl für funktionale wie auch nichtfunktionale Anforderungen.
294
Robert Konzelmann
x Priorisiert: Anforderungen müssen gemäß ihrer Wichtigkeit priorisiert werden. Vorgehen Zu Beginn einer Anforderungsanalyse steht immer die Definition des Projektumfanges. Dieser ergibt sich aus der Dekomposition der definierten BIOs in einzelne logisch und technisch zusammenhängende Lösungen, die jeweils als eigenständiges Inkrement implementiert werden. Dabei gilt es zu beachten, dass die Durchlaufzeit für die Entwicklung eines Inkrementes relativ kurz sein sollte, um einerseits zeitnah auf neue Anforderungen reagieren zu können und anderseits um den Wildwuchs von nicht integrierten „quick and dirty“ Lösungen in den einzelnen Geschäftsbereichen zu unterbinden. Ein wichtiger Erfolgsfaktor einer jeden Anforderungsanalyse ist das Verständnis des logischen Aufbaus von Anforderungen und ihren Wechselwirkungen. So werden in der Praxis leider immer noch viel zu oft allein stehende Teilsichten erhoben, die sich in einer späteren Phase entweder als widersprüchlich oder als lückenhaft erweisen. Die folgenden Aspekte sollten unserer Erfahrung nach durch eine Analyse beleuchtet werden: x Fachliche Anforderungen - Fachliche Anforderungen beinhalten alle notwendigen Anforderungen, um die vorgängig definierten Geschäftsprozesse zu unterstützen. Sie stellen im Normalfall die größte Anforderungsgruppe. - Länderspezifische, gesetzliche und richtliniengetriebene Anforderungen sind meisten nicht nur unternehmens- sondern auch standortabhängig. Diese stehen oft im Widerspruch zu den fachlichen Anforderungen und können diese übersteuern. - Auditbedingte Anforderungen leiten sich aus den oben genannten Anforderungen ab und stellen die Einhaltung und Überprüfbarkeit dieser sicher. - Besondere Unternehmens- oder Umgebungs-Anforderungen, die durch die Strategie und / oder Architektur getrieben sind. Dies können unter anderem Anforderungen betreffend der einzusetzenden Technologie, Softwarekompatibilität oder der Zugriffsmethoden sein. - Betriebs-Anforderungen umfassen alle Spezifikationen und Vorgaben, die beschreiben, wie eine Datenbank, Applikationen, Schnittstellen sowie Soft- und Hardwarekomponenten in die Produktion übernommen und betrieben werden. x Performance-Anforderungen - Performance-Anforderungen für Schnittstellen definieren, in welcher Zeitspanne Daten zwischen zwei Prozessen oder Applikationen durchgereicht werden müssen.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
Performance-Anforderungen für Prozesse definieren, in welcher Zeitspanne ein Geschäftsprozess die notwendigen Informationen benötigt. Es ist wichtig, dass Performance-Anforderungen schon zu Begin erhoben werden. Dies insbesondere aus den zwei folgenden Gründen: Einerseits hat die benötigte Performance einen großen Einfluss auf die Architektur der einzelnen Soft- und Hardware-Komponenten und ihre Integration sowie auf die Kosten eines Data Warehouse. Andererseits sollten so früh wie möglich Performance-Tests durchgeführt werden. Ist dies nicht der Fall, so wird es unter Umständen nicht mehr möglich sein, Performanceprobleme innerhalb der verbleibenden Zeit und im verbleibenden Budget zu beheben. Support-Anforderungen beinhalten die Funktionen und Ressourcen, die vom Kunden im späteren Betrieb benötigt werden und über Service Level Agreements (SLAs) definiert werden. Diese während der Implementierung erhobenen Informationen stellen einen ersten Richtwert dar und werden während der Inbetriebnahme nochmals verifiziert. Insbesondere, falls die notwendigen Support-Organisationen im Unternehmen noch nicht existieren oder aber der spätere Betrieb und Support ausgegliedert werden, müssen diese Anforderungen frühzeitig erhoben werden. Sicherheits-Anforderungen für die Daten (Datensicherheit und Datenschutz) und die Applikationen. Diese lassen sich im Normalfall direkt von den unternehmensweiten Sicherheitskonzepten ableiten. Schulungs-Anforderungen beschreiben den benötigten Schulungsumfang und Schulungsmodus für die definierten Benutzergruppen. Data Warehouse-Erfolgskriterien definieren, anhand welcher Kenngrößen der Erfolg des Systems gemessen wird und sind nicht zu verwechseln mit den Abnahmekriterien einer Lösung. Die Erfolgskriterien können monetärer Art sein, wie ROI oder Einsparungen, die durch die Konsolidierung der Systemlandschaft erreicht wurden, oder sich auf die Verwendung und Akzeptanz des Systems und der verfügbaren Informationen innerhalb des Unternehmens beziehen. Kommende Anforderungen sind all jene, die während der Analyse zur Sprache kamen, die aber nicht Teil des aktuellen Inkrementes sind. Nichtsdestotrotz ist wichtig, diese zu dokumentieren, zu gewichten, und in die Gesamtplanung einfließen zu lassen. Dadurch wird die Anforderungsimplementierung transparent und schafft die benötigte Vertrauensbasis zu den Endbenutzern.
-
x
x
x x
x
295
296 2.3.2
Robert Konzelmann TSM Tätigkeit: Logical Model
Ein weiterer wichtiger Teil der Analysephase ist das Erstellen des Logischen Datenmodells, welches die Informationsverwaltung aus der fachlichen Perspektive abbildet und den Kern des Data Warehouse darstellt. Die Schwierigkeit bei der Erstellung eines solchen Modells liegt in der notwendigen Flexibilität und Erweiterbarkeit. Es muss in der Lage sein, heute bekannte sowie zukünftige Anforderungen und die dafür notwendigen Datenobjekte abzudecken respektive zu integrieren, um dadurch die geforderte unternehmensweite Informationssicht zu gewährleisten. Dazu wird in einem ersten Schritt ein Subject Area Model erstellt, welches den Informationsbedarf des Gesamtsystems wiedergibt. Ausgehend davon werden in einem zweiten Schritt für das aktuell zu erstellende Inkrement die notwendigen Entitäten und Attribute definiert und modelliert. Die folgende Hierarchie von Modellen und ihren Abstraktionsstufen hat sich dafür bewährt: x Das Subject Area Model ist die semantische Beschreibung der wichtigsten Datenbereiche einer Unternehmung und definiert den Umfang der Informationsarchitektur. x Das Conceptual Model beschreibt die für das Data Warehouse-System relevanten Hauptentitäten und ihre Beziehungen. Es ist eine erste Verfeinerung des Subject Area Model und beinhaltet allgemein gehaltene und nicht normalisierte Datenstrukturen und Relationen. Dabei werden die Fachbegriffe und die dazugehörigen Geschäftsregeln eindeutig definiert und dokumentiert. x Das Key Based Model identifiziert alle benötigten Entitäten und ihre Beziehungen. Dafür wird das Conceptual Model weiter verfeinert, um SubEntitäten ergänzt und normalisiert. Jede Entität verfügt über die Attribute, die es zur eindeutigen Identifizierung seiner Datenelemente benötigt. x Das Attributed Model ist das endgültige logische Datenmodell, das über alle relevanten Entitäten und Attribute verfügt. Es beschreibt die integrierte, unternehmensweite und technologieneutrale Informationsarchitektur und ist die Basis für das später zu entwickelnde physische Datenmodell. Existieren bereits logische Datenmodelle im Unternehmen oder wurde als Teil der Strategiephase ein High Level-Modell erstellt, können diese als Ausgangspunkte verwendet werden. Leider existieren vielerorts nur physische Modelle, die aktuell und dokumentiert sind. Diese sind mit Vorsicht zu genießen, enthalten sie doch oft implementierungs- und technologiespe-
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
297
zifische Besonderheiten, die die Geschäftsproblematik nur bedingt wiedergeben und zu falschen Schlüssen führen können. Ein weiterer Ausgangspunkt sind logische Datenmodelle von Drittanbieter. So stellt zum Beispiel Teradata für alle Branchen eigene logische Datenmodelle zur Verfügung, die stetig weiterentwickelt werden. Ein solches Modell reduziert den Eigenentwicklungsaufwand massiv, da es Erfahrungen und Best Practices aus unzähligen branchenspezifischen Enterprise Data Warehouse-Projekten beinhaltet. Dadurch stellt es ein reifes Fundament dar, welches um die jeweiligen projektspezifischen Anforderungen erweitert werden kann. Basierend auf den erhobenen Fragestellungen werden die Subject Areas, Entitäten und Attribute für das Modell definiert. Besonderes Augenmerk ist hierbei auf die Konstrukte zu richten, die in keinem der vorhandenen Modelle abgebildet sind, da diese von Grund auf neu modelliert werden müssen. Neben den Business Questions gilt es auch, die restlichen relevanten fachlichen und insbesondere Sicherheits-Anforderungen zu berücksichtigen, sofern diese das logische Modell betreffen. Das logische Modell wird zusammen mit den Endbenutzern anhand der Business Questions hinsichtlich der Vollständigkeit und der Navigation durch das Modell getestet. Ziel sollte es sein, das Modell zu brechen, also relevante Fragestellungen, die nicht durch das Model beantwortet werden können, zu spezifizieren, um dadurch die Grenzen des Modells aufzuzeigen. Data Mapping Die logische Datenarchitektur wird durch das Definieren der benötigten Quellsysteme und das Zuordnen ihrer Datenelemente zum logischen Datenmodell komplettiert. Hierfür ist ein tiefes Verständnis der existierenden Systemlandschaft und der Datenflüsse von eminenter Bedeutung. Andernfalls riskiert man, dass diese Aktivität übermäßig viel Zeit beansprucht und ein unbefriedigendes Endresultat liefert. Jedes Datenelement wir über seine primäre Datenquelle, d. h. von seinem Ursprung, geladen. In Fällen, bei denen ein Datenelement sein Ursprung in verschiedenen Datenquellen haben kann (zum Beispiel Daten, die während des Tages in Zwischensystemen hochgerechnet und während der Tagesendverarbeitung definitiv berechnet werden, wie dies bei Kontoständen oft der Fall ist), gilt es klar zu definieren, zu welcher Zeit welche Quelle gültig ist. Ferner müssen die für den Ladeprozess notwendigen Datentransformationen erhoben und dokumentiert werden. Die definierten Datenelemente werden einer Datenqualitätsanalyse unterzogen, die entweder auf dem gesamten Datenbestand oder auf einer aussagekräftigen Stichprobe basiert. Von Vorteil hierbei ist es, wenn man diese Analyse skriptbasiert (zum Beispiel unter Zuhilfenahme eines Data
298
Robert Konzelmann
Mining-Werkzeuges) durchführt, was einem später ermöglicht, dieselbe Analyse auf neuen Datensätzen wiederkehrend durchzuführen. Basierend auf den Resultaten werden erste Data Cleansing-Anforderungen mit den entsprechenden Data Owners und Data Stewarts sowie den Endbenutzern definiert, die dann in das Extract Transform Cleanse Load (ETCL)-Design einfließen. Ein Fokus sollte hierbei auf die Verwendung von „schlechten“ Daten gelegt werden. Es empfiehlt sich, diese trotz ihrer jeweiligen Mängel in das Data Warehouse zu laden und nicht zu verwerfen. So können Funktionen wie zum Beispiel die Summe aller verkauften Produkte trotz inkorrekter Datensätze berechenbar bleiben. Voraussetzung dafür ist, dass man sich der Datenqualität und ihrer Auswirkungen bewusst ist, und diese auch an die Endbenutzer kommuniziert. Die Lade-Anforderungen definieren, wann welche Daten geladen werden, und komplettieren die logische Datenarchitektur. Der zeitliche Aspekt beinhaltet dabei zwei Dimensionen: Erstens, bis wann (Tageszeit) neue Daten im Date Warehouse zu laden sind und zweitens wie schnell nach ihrer Erstellung im Quellsystem die Daten im Data Warehouse vorhanden sein müssen. Hierbei sind die Verfügbarkeit der Quellsysteme und ihrer Schnittstellen sowie mögliche Abhängigkeiten im Erstellen oder bei der Extraktion der Daten zwingend mit einzubeziehen.
3
TSM Phase: Design
Während der Designphase wird die logische Architektur in eine physische, technologiegetriebene Architektur überführt. Dazu müssen vorgängig die notwendigen Soft- und Hardwarekomponenten gemäß den Anforderungen aus der logischen Architektur evaluiert werden. Dabei müssen die einzelnen Komponenten immer auch bezüglich ihrer Skalierbarkeit hinsichtlich der zu erstellenden Gesamtlösung überprüft werden. Skalierbarkeit ist hierbei nicht, wie oft irrtümlich angenommen, ausschließlich auf die Datenmenge beschränkt, sondern betrifft zahlreiche zusätzliche Aspekte, wie: x x x x x x
die Anzahl gleichzeitig zu unterstützender Benutzer die Anzahl gleichzeitig zu unterstützender Abfragen und Abfragetypen das gleichzeitige Beladen und Abfragen derselben Datenbasis das zu analysierende Datenvolumen pro Abfrage die Komplexität der einzelnen Abfragen die zu unterstützenden Datenmodelle
Zusammengefasst betrifft sie all die Dimensionen, die notwendig sind, um die unterschiedlichen Service Level Agreements zu gewährleisten, die
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
299
sich aus den jeweiligen Anforderungen aus den zu unterstützenden operativen und analytischen Geschäftsprozesse ergeben. Das Design der physischen Architektur gliedert sich in vier Teile, deren jeweiliger Aufwand direkt von der einzusetzenden Technologie abhängt. 3.1 TSM Tätigkeit: System Architecture Die Systemarchitektur stellt den Bauplan des Gesamtsystems dar und umfasst einen High Level-Design der ETCL (Extraction, Transformation, Cleansing and Loading)-Architektur, der Applikationen, des physischen Datenmodells und der Betriebsprozesse. Die Systemarchitektur dient als Grundlage für alle nachfolgenden Designaktivitäten. Da das Volumen und die Frequenz der zu verarbeitenden Daten sicherlich den größten Einfluss auf die Architektur haben, müssen diese, falls nicht schon in der Analysephase abschließend definiert, spätestens zu diesem Zeitpunkt vollständig erhoben werden. Dabei muss zwischen dem initialen Laden, bei dem zusätzlich historische Daten für den Aufbau des Data Warehouse geladen werden, und dem täglichen Beladen unterschieden werden. Daraus lässt sich eine erste ETCL-Architektur definieren, die den gesamten Ladeprozess, ausgehend vom jeweiligen Quellsystem über mögliche Zwischenstationen (Staging Area) bis zum Data Warehouse, beinhaltet. Für jede dieser Ladestrecken beschreibt die Architektur das Transportmedium und Technologie (in Bezug auf Betriebssystem, Hardware und Netzwerk). Am anderen Ende der Architektur steht die Applikationslandschaft. Sie definiert, welche Funktionen wo und mit welcher Technologie wie implementiert werden, welche Benutzer wie darauf zugreifen und die Anbindung an das Data Warehouse. Zusätzlich ergänzt sie die erhobenen Datenvolumetriken um die von ihnen benötigten sowie erzeugten Datenflüsse. Auf Grund dieser Teilarchitekturen und dem in der Analyse entwickelten logischen Datenmodell wird nun ein erster Entwurf des physischen Datenmodells als Kern des Gesamtsystems erstellt. Insbesondere werden dabei Architektur-, Datenbank- und Sicherheits-Anforderungen (wie zum Beispiel Schnittstellen und View Layers) zum Modell hinzugefügt. Aggregationen sollten zu diesem Zeitpunkt nur erstellt werden, wenn eine dokumentierte und ausgiebig geprüfte Notwendigkeit dafür besteht. Alle zusätzlichen Tabellen und / oder Attribute generieren automatisch Mehraufwand bezüglich Implementierung, Test und Wartung und erhöhen dadurch die Komplexität der Lösung. Als letzte Komponente der Systemarchitektur wird die Betriebssicht erstellt. Diese definiert wie und insbesondere, womit die einzelnen Kom-
300
Robert Konzelmann
ponenten und das Gesamtsystem betrieben, verwaltet und überwacht werden. Wurden die vorangegangenen Teilarchitekturen mit dem klaren Fokus auf das Enterprise Data Warehouse erstellt, so steht hier die Integration mit der bestehenden Systemumgebung und den bestehenden Prozessen im Vordergrund. 3.2 TSM Tätigkeit: Package Adaption Die Package Adaption beschäftigt sich mit der Implementierung und Integration von Standardsoftware und betrifft hauptsächlich den Einsatz von ETL- und Business Intelligence-Werkzeugen. Die meisten heute verfügbaren ETL- und BI-Werkzeuge besitzen eine Vielzahl von Funktionalitäten und Implementierungs- und Verwendungsmöglichkeiten, die sich oft überschneiden (so verfügen zum Beispiel etliche BI-Applikationen über eigene ETL-Werkzeuge für die Datenextraktion aus dem Data Warehouse). Aus diesem Grund muss zu Beginn für ein jedes dieser Werkzeuge der Verwendungszweck und daraus abgeleitet der Umfang der zu verwendenden Funktionen definiert werden. Neben dem Reifegrad der einzelnen Funktionen und ihrer Prozessdurchgängigkeit ist auch ihre Skalierbarkeit im Sinne der heutigen und zukünftigen Anforderungen ein wichtiges Selektionskriterium. Darauf folgend werden alle erforderlichen Transformationen, Kalkulationen, Bereinigungsregeln, Fehlerverwaltung und Kontrollprozesse definiert, die benötigt werden, um die Daten von der Quelle in das Data Warehouse und vom Data Warehouse in die analytischen Applikationen zu laden. Oft ist es dabei nicht möglich oder aus Performance- und / oder Wartungsgründen nicht sinnvoll, den jeweiligen Prozess komplett mit dem Werkzeug abzubilden. Hierfür können einzelne Teile aus dem Design herausgelöst und als Eigenentwicklung implementiert werden. Der Nachteil dieser dadurch erlangten Flexibilität ist, dass es zu Brüchen im Gesamtprozess und der Ablaufsteuerung kommen kann. Daher sind hierfür von der Architektur klare Richtlinien zu definieren und periodisch zu überprüfen, unter welchen Umständen dies geschehen darf. Am Ende dieser Aktivität existieren für jede Ladestrecke eine Definition der dafür zu verwendenden Ladewerkzeuge und Funktionen und die Beschreibung (inklusive Begründung) aller Ausnahmen, bei denen Eigenentwicklungen zu verwenden sind.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
301
3.3 TSM Tätigkeit: Custom Components Trotz des Einsatzes von Standardsoftware sind Data Warehouse-Systeme keine Standardlösungen. Vielmehr sind sie komplexe Gebilde aus unterschiedlichen Softwarekomponenten und Werkzeugen, die miteinander in Einklang gebracht werden müssen. Die dafür notwendigen Aktivitäten sind in TSM unter Custom Components zusammengefasst und beinhalten das Design der Lademechanismen, der physischen Datenmodelle sowie der analytischen Applikationen. 3.3.1
Physical Database Design
Kernstück des physischen Datenbankdesigns ist das physische Datenmodell, welches mehr oder minder eine 1:1-Abbildung des logischen Datenmodells zuzüglich technischer Komponenten wie Views, Indizes, Schlüsselattribute und Triggers ist. Alle Abweichungen vom logischen Modell können direkte Auswirkungen auf die Aussagekraft, Integrationsfähigkeit und Flexibilität des Data Warehouse haben und müssen daher klar begründet und dokumentiert werden. Benutzersichten und Applikationsschnittstellen sind als zusätzliche Schicht (View Layer) über dem Basismodell zu konzipieren. Neben dem Datenmodell werden alle Komponenten, die für den Betrieb und die Wartung benötigt werden (wie zum Beispiel Datenbankadministration, Backup and Recovery und der Change Control Prozess) spezifiziert. 3.3.2
Application Design
Die Art und Weise, wie die analytischen Applikationen entworfen und angebunden werden, ist ein kritischer Erfolgfaktor jeder Data WarehouseLösung, da sie die Schnittstelle zu den Endbenutzern sind. Sie sind verantwortlich dafür, ob und wie ein System benutzt wird. Dementsprechend müssen neben den Anforderungen alle Informationen betreffend wie, von wem und wo die Applikation benutzt werden soll in das Design einfließen. Sie beeinflussen nicht nur die Benutzerführung und Informationspräsentation, sondern auch die Datenhaltung und Verwaltung. Das Design einer Applikation, die von Tausenden Benutzern weltweit gleichzeitig verwendet wird, unterscheidet sich in den meisten Belangen gegenüber einer Applikation, die für eine Handvoll lokaler Spezialisten konzipiert wird. Die Anbindung an das Data Warehouse kann aktiv über SQL-Aufrufe, Makros, Stored Procedures oder Triggers erfolgen oder, falls die Applikation über eine eigene Datenhaltung verfügt, mittels periodischer Ladepro-
302
Robert Konzelmann
zesse. In der Praxis haben sich dabei Mischlösungen bewährt, bei denen Aggregate in den BI-Lösungen gehalten werden und Basisdaten im Data Warehouse. Wo genau der Schnitt gemacht wird, hängt einerseits von den Anforderungen und anderseits von der Skalierbarkeit der einzelnen Lösungskomponenten ab. Ein weiterer Aspekt ist die geforderte Datenverfügbarkeit, verzögert sich doch diese bei jeder zusätzlich zu ladenden Umgebung. Das Applikationsdesign beinhaltet... x die benötigten Daten, Datenflüsse und Schnittstellen, x die benötigten Funktionen und ihre Verteilung, x die benötigten Datenstrukturen, wie zum Beispiel multidimensionale Modelle, x die Sicherheitsanforderungen und Berechtigungen, x wie und von wem Abfragen erstellt und initiiert werden, x die Informationspräsentation, x die Benutzerführung und x die benötigten HW- und SW-Komponenten und ihre Konfiguration. 3.3.3
Design der Extract Transform Cleanse Load (ETCL)-Prozesse
Das Design der ETCL-Prozesse ist sicherlich der aufwändigste und komplexeste Arbeitsschritt, gilt es doch für jede Datenstrecke die zu implementierenden Funktionen sowie die Abhängigkeiten gegenüber anderen Datenstrecken, Quellsystemen und Geschäftsprozessen zu spezifizieren. Erschwerend kommt dazu, dass zwischen dem initialen und dem periodischen Beladen jeweils unterschieden werden muss, was im jeweiligen Design zu reflektieren ist. Abbildung 9 zeigt schematisch den Datenfluss vom Quellsystem in das Data Warehouse und in die analytischen Applikationen.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
303
SRC A SRC B
SRC Z
Source Systems
Landing Zone
Staging Area
EDW Target Tables
Data Marts & Extracts
Abb. 9. Datenflüsse im Data Warehouse
Waren früher solche Prozesse ausschließlich Batchprozesse, die jeweils in der Nacht das Data Warehouse beluden, wird heute vermehrt auch untertags oder gar near real time geladen. Dadurch entstehen erhöhte Anforderungen an die Verfügbarkeit des Gesamtsystems und dessen Datenbankobjekte, die nun gleichzeitig beladen und gelesen werden, sowie an die Anbindung der Umsysteme, die nun vermehrt lose gekoppelt (z. B. über eine serviceorientierte Architektur) stattzufinden hat. Extraction Das Design der Extraktion bestimmt, wie welche Daten wann wo abgezogen werden und ist primär von den Quellsystemen und ihrer Auslastung abhängig. Dokumentiert werden: x x x x x x
die Quellsysteme und benötigten Benutzer- und Zugriffsrechte, das Extraktionsformat und Extraktgröße, die Extraktionsmethode, der Zeithorizont für die Extraktion, die Landing Area, welche die Daten zwischenspeichert und die Transportmethode, wie die Daten in die Landing Area kommen.
Die darauf basierende Designlogik definiert den Prozess, die Verantwortlichkeiten und integriert die notwendigen Werkzeuge. Transform Das Design der Transformation definiert, welche Daten wann, wie und wo transformiert werden. Da diese Transformationen oft rechenintensiv sind und die Prozesse meist zu Randzeiten laufen, in denen die Datenbank nicht ausgelastet ist, wechselt man vermehrt von einer klassischen ECTL-Architektur zu einer ELCT basierten Architektur, bei der die Daten erst ins Data Warehouse geladen und dann dort transformiert werden. Ausschlaggebend für die Architekturentscheidung sind sicherlich
304
Robert Konzelmann
nicht zuletzt die Performance-Anforderungen und die Skalierbarkeit der verfügbaren Technologie, muss man doch bei einem ELCT-Design in der Lage sein, unterschiedliche Arbeitslasten zur selben Zeit mit derselben Plattform und Konfiguration abzudecken. Cleanse Die Bereinigungsprozesse basieren auf bekannten, durch die Analysephase aufgedeckten Datenqualitätsproblemen. Die zu definierenden Regeln können einfache Bereinigungen auf Attributebene beinhalten oder komplexe Funktionen, wie zum Beispiel die Identifikation vom Dubletten. Das Design beinhaltet neben den Regeln zusätzliche für die Bereinigung benötigte Informationen (wie zum Beispiel Referenztabellen), wo die bereinigten Daten zu speichern sind und eventuell zusätzliche benötigte Softund Hardware. Load Das Schreiben der Daten in das Data Warehouse geschieht über die Ladeprozesse. Hierfür ist ein Mapping vom Quellsystem in die Staging Area und von dort in die Zieltabellen notwendig, welches neben den Verbindungen auch die Historisierungskonzepte für die einzelnen Datenobjekte beinhaltet. Ausgehend von der Architektur, der Beladungsart und der Komplexität der Transformationen kann das Data Warehouse auch direkt, unter Umgehung der Staging Area, beladen werden. Dies gilt insbesondere für Mini Batches und Near Real Time Feeds, bei denen wenige Daten in kurzer Zeit geladen und den Benutzern zur Verfügung gestellt werden müssen. Zusätzlich sind jeweils die Fehlerverarbeitungen (inklusive des Schwellenwerts, bei dem der Prozess zu beenden ist), die Funktionen zur Aufzeichnung der Datenveränderungen sowie die Spezifikation der Testfälle und der dafür benötigten Testdaten für jeden der oben beschriebenen Teilprozesse separat zu spezifizieren3. Abschließend werden die definierten Teilprozesse in den ETCL-Gesamtprozess eingebunden. Dazu gehören neben der Abbildung aller Abhängigkeiten das Design der Prozesssteuerung und die Spezifizierung von Fehler- und Statusmeldungen. Jede Ladestrecke muss dabei über definierte Kontrollpunkte verfügen, die im Falle eines Abbruchs ein kontrolliertes Wiederaufsetzen der Prozesse ermöglichen. 3.4 TSM Tätigkeit: Test Plan Ein Data Warehouse ist per Definition ein datenzentrisches System. Der ETCL-Prozess stellt dabei den Lebensfluss dar, der das korrekte und zeitgerechte Beladen des Systems und im Endeffekt seinen Erfolg garantiert. 3
Siehe Testplanung „Unit Test“
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
305
Die Überprüfung dieser Prozesse ist daher unabhängig von den Lösungsspezifischen Anforderungen immer eine Hauptaktivität eines jeden Data Warehouse-Tests. Dabei steht insbesondere die Gültigkeit der Daten und die Performance der Prozesse im Vordergrund. Weitere wichtige Faktoren sind der Betrieb und die Datensicherheit. 3.4.1
Daten-Gültigkeit
Um die Korrektheit der Daten im Data Warehouse zu garantieren, muss der ETCL-Prozess die richtigen Daten zur richtigen Zeit aus den jeweiligen Quellsystemen extrahieren, die unterschiedlichen Bereinigungen und Transformationen korrekt durchführen und die jeweiligen Datenobjekte entsprechend dem Data Mapping aktualisieren. Um dies zu überprüfen, existieren unterschiedliche Vorgehensmodelle mit ihren jeweiligen Stärken und Schwächen. 1. Die Daten im Data Warehouse werden mit denjenigen in den Quellsystemen verglichen. Üblicherweise vergleicht man dabei die Anzahl der Datensätze und stichprobenartig Datenwerte auf unterschiedlichen Aggregationsstufen. Dabei ist zu berücksichtigen, dass basierend auf den Transformationsregeln nicht zwingend alle Datensätze aus dem Quellsystem in das Data Warehouse geladen werden. 2. Die Daten werden, dem Datenfluss folgend, auf allen Schichten (Landing Area, Staging Area und Data Warehouse) auf ihre Gültigkeit geprüft. Dies hat einerseits den Vorteil, dass Fehlerquellen einfacher identifiziert werden können, und anderseits, dass die Anzahl zu verifizierender Transformationen und Bereinigungen kleiner und daher einfacher nachzuvollziehen ist, als bei einem durchgehenden Vergleich. Das Prüfverfahren ist dasselbe wie beim obigen Vorgehensmodell. 3. Jeder ETCL-Prozess wird individuell und isoliert gegen seine spezifischen Anforderungen getestet. Dies ist insofern möglich, da jeder dieser Prozesse für sich allein existieren kann, und über einen definierten In- und Output verfügt. Die beiden letzteren genannten Vorgehen stellen sicherlich die umfangreicheren Tests dar und ermöglichen eine schnelle Lokalisierung der Fehlerquellen. Auch unterstützen sie ein inkrementelles Testvorgehen, da nicht alle Komponenten benötigt werden. Der Nachteil liegt in dem größeren Aufwand, der hierfür betrieben werden muss. Ein kritischer Punkt für alle Modelle ist das Erstellen der Testdaten. Wann immer möglich, und insbesondere für Vorgehen 1 und 2, sollten produktive Daten verwendet werden. Dies ermöglicht den Abgleich der Resultate gegen existierende
306
Robert Konzelmann
Systeme und garantiert die zwingend notwendige inhaltliche Konsistenz der Daten. Dies aber nur, falls der Datenabzug über alle Quellsysteme synchron, das heißt zur selben Zeit, erfolgt. 3.4.2
Performance
Die Performance der ETCL-Prozesse ist primär abhängig von der Systemumgebung und dem einerseits zu verarbeitenden und anderseits schon im Data Warehouse vorhandenen Datenvolumen. Diese Faktoren werden üblicherweise in der Testumgebung nur bedingt wiedergegeben, führt man die Tests doch im Normalfall auf einem kleineren System mit reduziertem Datensatz aus. Eine Analyse über der Anzahl verarbeitenden Datensätze pro Ladestrecke und definierter Zeiteinheit kann aber immerhin Tendenzen und mögliche Flaschenhälse aufzeigen. Eine weitere Möglichkeit sind sogenannte Stresstests, bei denen versucht wird, die Grenzen und die Skalierbarkeit eines Gesamtsystems oder einer ihrer Komponenten aufzuzeigen. Ziel ist es, die Auswirkungen einer Systemüberlastung auf Prozesse und Daten aufzuzeigen, was mögliche Schwachpunkte frühzeitig erkennen lässt. 3.4.3
Test-Phasen
Verschiedene Vorgehensmodelle für das Testen von Software wurden im Rahmen des klassischen Software Engineering in den letzten 20 Jahren entwickelt. Wie für Modelle üblich, basieren sie alle auf einer vereinfachten Sicht der Realität und haben ihre Stärken und Schwächen. Eine klassische und bewährte Methode um Tests zu klassifizieren und spezifizieren ist das in Abb. 10 dargestellte V-Modell (Balzert 1998; Nørgaard u. Byrd 2006), welches Tests relativ zur jeweiligen Entwicklungsstufe definiert und einen Modultest, Integrationstest, Systemtest und Abnahmetest vorsieht. Diese sollten jeweils den aktuellen Gegebenheiten angepasst werden. Solche Anpassungen können zum Beispiel in der Zusammenfassung von einzelnen Testschritten sein, wie dies in einigen Unternehmen beim System- und Abnahmetest der Fall ist, oder den Verzicht auf einen Integrationstest für Änderungen, bei denen keine neuen Ladestrecken hinzugefügt wurden. Insbesondere aber sollte die Planung iterative und sich überlappende Tests vorsehen und nicht stur linear vollzogen werden.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse Anforderungsdefinition
Abnahmetest
Systemtest
Grobentwurf
Feinentwurf
Modulimplementation
307
Integrationstest
Modultest
Abb. 10. V-Modell (Balzert 1998)
Der Modultest-Plan spezifiziert wie, wann, wo und von wem in sich geschlossene Programmteile getestet werden. Der Vorteil von solchen Modultests besteht darin, dass sie es erlauben kleine, in sich abgeschlossene Einheiten isoliert zu testen und mögliche Fehler so früh wie möglich zu identifizieren. Die Tests beinhalten insbesondere x die Verifikation der korrekten Implementierung von Data Mappings, Transformationen und Bereinigungen, x den Umgang mit Datenanomalien und Grenzwerten wie zum Beispiel Nullwerten, minimalen und maximalen Werten, „Space“ und fehlenden oder inkorrekten Werten, x Den Umgang mit inkompatiblen Feldtypen wie zum Beispiel Integer und Long, Integer und Char, Datumsformate und Feldgrößen, x Indizes und Schlüsselattribute und x die Fehlerbehandlung inklusive Fehlerstatus, Roll-back und Prozessterminierung. Der Integrationstest-Plan spezifiziert wie, wann, wo und von wem Gruppen von Programmteilen in ihrem Zusammenspiel getestet werden. Für die Ablaufsteuerung wird dabei die später zu verwendende Job Control Language (JCL) und / oder die Job Scheduling Software verwendet. Die Tests beinhalten insbesondere: x Die Verifikation von durchgehenden Ladestrecken (End to End Processing).
308
Robert Konzelmann
x Die Überprüfung von Ladesequenzen und ihren Abhängigkeiten. x Die Fehlerbehandlung inklusive Fehlerstatus, Roll-back und Prozessterminierung. x Die Messung der benötigten Zeit pro Ladestrecke als erste Hinweise auf mögliche Performance Probleme. Der Systemtest-Plan spezifiziert wie, wann, wo und von wem alle relevanten Komponenten als Gesamtsystem getestet werden und überprüft, ob alle fachlichen und technischen Anforderungen korrekt umgesetzt wurden. Die Datenbasis sollte hierfür ein aussagekräftiger Auszug aus der Produktivumgebung sein. Die Tests beinhalten insbesondere: x Die Verifikation von durchgehenden Ladestrecken für das initiale und periodische Beladen. x Die Integration der Ablaufsteuerung. x Die Überprüfung der Daten anhand der definierten Fragestellungen und Kenn- und Steuergrößen. x Die Überprüfung von Performanceanforderungen. Der Abnahmetest-Plan spezifiziert wie, wann, wo und von wem die Abnahme des Gesamtsystems geschieht. Dieser steht unter der Verantwortung des Auftraggebers und kann als Teil des System-Tests definiert werden. Am Abschluss der Designphase steht die physische Architektur, dir der Definition und Spezifikation des zu implementierenden Systems entspricht, und die detaillierte Planung für die Implementierung und Inbetriebnahme der Lösung inklusive aller Kosten. Die Implementierung und der spätere Betrieb des Systems werden in den anschließenden TSM Phasen Equip, Build, Integrate und Manage definiert, welche nicht Bestandteil dieses Kapitels sind. Änderungen an der Architektur, die während der Implementierung auf Grund von auftretenden Problemstellungen notwendig werden, müssen jeweils in einer verkürzten Design- und eventuell auch Analysephase erarbeitet, auf ihre Auswirkungen auf die Systemintegrität und die Planung überprüft und freigegeben werden.
4
Zusammenfassung und Ausblick
Jedes komplexe Ding, welches als ein System zu funktionieren hat, muss als ein System entworfen und geplant werden, um die Integration und Kohärenz aller Komponenten zu garantieren und um sicherzustellen, dass das System in der Art und Weise funktioniert, wie dies bei seiner Erstellung vorgesehen war (Schekkerman 2004b). Dieser Grundsatz ist eine der Triebfedern der hier vorgestellten Methodologie, welche in einem ersten
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
309
Schritt die Bedürfnisse und Abhängigkeiten des Gesamtsystems erhebt und basierend darauf einzelne klar definierte, in sich abgeschlossene und Nutzen generierende Inkremente definiert, implementiert und in die bestehende Systemumgebung integriert. Dabei steht die Architektur im Zentrum, welche die über den Informationsbedarf definierten fachlichen Anforderungen mit der Systemlandschaft in Einklang bringt. Ein weiterer wichtiger Aspekt einer erfolgreichen Methodologie ist ihre Akzeptanz. Dazu müssen unterschiedliche Ziele erfüllt werden. Während das Unternehmen anhand der Methodologie ein strukturiertes Vorgehen einführen will, um dadurch die Planbarkeit der Projekte zu verbessern und gleichzeitig deren Risiken zu vermindern, benötigt der Projektmitarbeiter eine flexible Struktur, die ihn in seiner täglichen Arbeit unterstützt, keinen Mehraufwand generiert und ihn seines Gestaltungsfreiraums nicht beraubt. Der modulare Aufbau der TSM kommt diesen Anforderungen entgegen. Sie reflektiert ein strukturiertes und mehrfach erprobtes Vorgehen, welches an die jeweilige Situation, deren Anforderungen und Umfeld angepasst werden kann. Die komplette softwareunterstütze Methodologie beinhaltet neben dem eigentlichen Vorgehen Tipps und Tricks zur Ausführung der Aktivitäten, Arbeitsvorlagen und Module zur Berechnung von Aufwandsschätzungen und zur Generierung von Projektplänen und Vertragsentwürfen. Korrekt eingesetzt, entlasten diese Funktionalitäten die Mitarbeiter von wiederkehrenden Arbeiten und stellt ihnen eine Wissensbasis zur Verfügung, die eine effizientere Arbeitsweise ermöglichen. Dadurch entstehen de-facto Standards, die die Qualität der Projekte beständig weiter treiben. Die Informationstechnologie bewegt sich in einem schnell wandelnden Umfeld. Neue fachliche Anforderungen benötigen in kurzer Zeit neue Lösungen, die wiederum in vielen Fällen auf neue Technologien und / oder Produkte aufsetzen. Will eine Methodologie diesen Umstand gebührend berücksichtigen, muss sie entweder auf generische Ansätze zurückgreifen oder sich stetig weiterentwickeln. TSM wurde vor über 15 Jahren von Entwicklern für Entwickler entworfen und reflektiert seitdem die Erfahrungen aus unzähligen Data Warehouse-Projekten. Neue Erkenntnisse, die durch ein zentrales Knowledge Management gesammelt werden, fließen dabei entweder direkt in die Methodologie ein, oder werden als Arbeitsvorlagen beigelegt. Die nächste größere Erweiterung ist für das Frühjahr 2008 geplant und hat zum Ziel, durch das Bilden von Workstreams die Benutzerfreundlichkeit und die Projektplanung zu verbessern. Dazu werden Aktivitäten aus einer oder mehreren Phasen zu logischen Aktivitäten (wie zum Beispiel Datenmodellierung) oder einem Lieferobjekt (wie zum Beispiel Systemarchitektur) gruppiert.
Robert Konzelmann Research
Analyze
Requirements Gathering & Analysis Security & Privacy
Design
Equip
Data Mapping & Data Quality
Build
System Install
Modeling Metadata Services Data Integration
Integrate
Manage
Production R ollout
Strategy
S ystem A rchitecture
310
Business Intelligence Quality Assurance
Abb 11: Auszug TSM Workstreams
Ein weiterer Vorteil der Workstreams ist ihre Unterstützung der stetigen Weiterentwicklung der Methodologie, können dadurch doch neue Lösungen und ihre dafür notwendigen Prozesse einfach abgebildet werden, ohne den Kern der Methodologie zu ändern. Dadurch wird sichergestellt, dass auch in Zukunft mittels TSM erfolgreich unternehmensweite Data Warehouse-Systeme strukturiert aufgebaut, weitergeführt und betrieben werden können.
Literatur Balzert, H.: Lehrbuch der Software-Technik - Software-Qualitätssicherung, Unternehmensmodellierung, Spektrum, Heidelberg 1998. Carroll, L.: Alice's Adventures in Wonderland, 1865. Daenzer, W.; Huber, F.: Systems Engineering Methodik und Praxis, Verlag Industrielle Organisation, Zürich 1992. Gam, I.; Salinesi, C.: A Requirement Driven Approach for Designing Data Warehouses, in: Proceedings of the Twelfth Working Conference on Requirements Engineering, Luxembourg 2006. Geiger, J.: The Missing Link, in: Teradata Magazine 7 (2007) 1. Hesse, W.; Merbeth, G.; Frölich, R.: Software- Entwicklung. Vorgehensmodelle, Projektführung, Produktverwaltung, Oldenbourg, 1992. Inmon, W.: Building the Data Warehouse, Wiley, New York 1996. Inmon, W.; Zachman, J.; Geiger, J.: Data Stores, Data Warehousing and the Zachman Framework, McGraw Hill, New York 1997. Mulholland, A.; Macaulay, A.: Architecture and the Integrated Architecture Framework, Capgemini, 2006. Nørgaard, N.; Byrd, B.: Data Warehouse Testing Best Practices, Teradata, 2006.
Vorgehensmodell zur Erstellung eines Enterprise Data Warehouse
311
o. V. : Requirements Definition and Management Best Practices Guide, Teradata, 2006a. o. V. : Teradata Enterprise Data Warehouse Roadmap for Financial Services, Teradata, 2006b. Picot, A.; Reichwald, R.; Wigand, R. T.: Die grenzenlose Unternehmung, 2. Aufl. Aufl., Gabler, Wiesbaden 1996. Schekkerman, J.: Another View at Extended Enterprise Architecture Viewpoints, Capgemini, 2004a. Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frameworks, 2. Aufl., Trafford, Victoria 2004b. Schienmann, B.: Kontinuierliches Anforderungsmanagement. Prozesse - Techniken - Werkzeuge, Addison-Wesley, 2001. Strauch, B.; Winter, R.: Vorgehensmodell für die Informationsbedarfsanalyse im Data Warehousing, in: von Maur E. et al. (Hrsg.): Vom Data Warehouse zum Corporate Knowledge Center, Physica, Heidelberg 2002, S. 359-378. Winter, R.: Modelle, Techniken und Werkzeuge im Business Engineering, in: Österle H. et al. (Hrsg.): Business Engineering - Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Aufl., Springer, Berlin etc. 2003, S. 87-118.
14 Die Informationslogistik bei der Swisscom Mobile
Maximilian Ahrens Universität St. Gallen
Markus Huber, Peter Kühni Swisscom Mobile AG
1 2 3 4 5 6 7 8
1
Einleitung ....................................................................................... 313 Marktsituation und Unternehmen ................................................... 314 Swisscom Mobile Unternehmen ..................................................... 315 Strategische Ausrichtung der Informationslogistik bei der Swisscom Mobile ........................................................................... 317 Organisation der Informationslogistik ............................................ 320 Einführung des neuen DWH........................................................... 323 Analyse des DWH der Swisscom Mobile ...................................... 327 Konsequenzen und Ausblick .......................................................... 329 Literatur .......................................................................................... 330
Einleitung
Diese Fallstudie erhebt den Stand der Informationslogistik bei der Swisscom Mobile. Dabei wurden sowohl die Entwicklung als auch die zukünftigen Planungen der Swisscom Mobile analysiert. Das Kapitel gliedert sich wie folgt: Zunächst werden einführend einige grundlegende Informationen zum Mobilfunkmarkt in Europa und der Schweiz gegeben. Anschließend
314
Maximilian Ahrens, Markus Huber, Peter Kühni
soll das Unternehmen Swisscom Mobile vorgestellt werden. Im Kernabschnitt dieses Textes werden abschließend die InformationslogistikOrganisation und -Architektur der Swisscom Mobile vorgestellt und die wichtigsten Erfolgsfaktoren erläutert.
2
Marktsituation und Unternehmen
In diesem Abschnitt sollen zunächst die Rahmenbedingungen des Mobilfunkmarktes in Europa und der Schweiz gezeigt werden. Dies ist für die Herausforderungen der Informationslogistik interessant, da der Markt einer großen Dynamik einerseits, sowie einer staatlichen Regulierung andererseits unterliegt. 2.1 Mobilfunkmarkt in Europa und der Schweiz Der Mobilfunkmarkt in Europa befindet sich seit der Entwicklung der digitalen Mobilfunktechnologie in einer starken Wachstumsphase. Nach den Mobilfunktechnologien der ersten Generationen (B- und C-Netz), die nur wenige Abnehmer fanden, wurde durch die Einführung der GSM-Technologie in Europa ein Massenmarkt für mobile Kommunikation eröffnet. Dies führte dazu, dass in den meisten westeuropäischen Märkten um die Jahrtausendwende herum mehr Mobilfunkanschlüsse als konventionelle Festnetzanschlüsse existierten. Im Jahr 2006 betrug so die Marktdurchdringung im Mobilfunkbereich bereits 103%, d.h. es gibt mittlerweile mehr Mobilfunkanschlüsse als Einwohner. Mobile subscribers penetrationin EU (2G and 3G) 120%
600 103.2% 95.0%
500
100%
300
60%
436.68
200
40%
20%
100
0%
0 Oct. 2004
Oct. 2005 EU subscribers
Oct. 2006
EU penetration rate
Abb. 1. Entwicklung des Mobilfunkmarktes in der EU (o. V. 2007a)
EU penetration rate
80%
478.39
400
386.61
Million of subscribers
84.6%
Die Informationslogistik bei der Swisscom Mobile
315
Die dynamische Entwicklung dieser Märkte sowie eine neue Industriepolitik führten zu einer Privatisierung vieler europäischer Telekommunikationskonzerne. Während bis in die 80er Jahre die Telekommunikation vorwiegend als staatliche Aufgabe gesehen wurde, setzte sich die Auffassung durch, dass durch eine Privatisierung ein höherer Kundennutzen erreicht werde könne. Parallel wurden Regulierungsstrategien eingeführt, die eine Öffnung des Marktes ermöglichen sollten. Im europäischen Umfeld führte diese Entwicklung zu einer weiteren Dynamisierung des Marktes und einem Streben der nationalen Unternehmen in die internationalen Märkte. Auch in der Schweiz wurde eine ähnliche Entwicklung vollzogen, wenn auch nicht im selben Umfang wie in den EU-Ländern. Die Swisscom als Marktführer hatte nach der Marktöffnung im Jahr 1998 im Jahr 2006 noch einen Marktanteil von über 63%, in der EU halten die ehemaligen Monopolisten jedoch im Durchschnitt nur noch 40% Marktanteil (o. V. 2007a). Bedingt durch die Attraktivität des Schweizer Marktes sind jedoch einige Wettbewerber in den Markt eingetreten (Jost 2004). Dadurch entsteht eine ähnliche Situation wie in vergleichbaren europäischen Märkten. Zuletzt haben die Mobilfunkmärkte erneut einen Innovationsschub erhalten durch die vermehrt angebotenen innovativen Services (z.B. Mobile TV und Musikdienste), die vollständig neue Marketing- und Abrechnungskonzepte benötigen. So müssen Kunden individuell angesprochen werden und nutzungsbasierte Tarife von Datendiensten entwickelt werden. Es lässt sich also feststellen, dass insbesondere die Dynamik der Märkte die Mobilfunkprovider unter erheblichen Druck setzt. Dabei entsteht diese Dynamik nicht nur durch neue technologische Innovationen, sondern auch durch neue industriepolitische Ansätze. Die Informationslogistik-Strategien der Unternehmen müssen diesen komplexen Herausforderungen begegnen und dem Mobilfunkprovider die notwendige informatorische Unterstützung für kundengerechte Angebote bereitstellen.
3
Swisscom Mobile Unternehmen
3.1 Überblick Die Swisscom Mobile AG ist die Mobilfunktochter der Swisscom. Die Swisscom Mobile hat ihren Hauptsitz in Bern und bedient den schweizerischen Markt mit unterschiedlichen Mobilfunkdienstleistungen.
316
Maximilian Ahrens, Markus Huber, Peter Kühni
Verwaltungsrat
CEO
Swisscom Fixnet AG
Group Strategy & Business Development
Group Finance & Controlling
Group Human Ressources
Group Communiucations
Swisscom Mobile AG
Swisscom IT Services AG
Swisscom Solutions AG
Swisscom Beteiligungen
Fastweb S.p.A.
Group Headquarters Gruppengesellschaften
Abb. 2. Konzernstruktur der Swisscom AG (o. V. 2006)
Die Swisscom Mobile wird im Verbund mit den anderen Business Units der Swisscom (Fixnet, Services, Solutions) als integrierter Informationsund Telekommunikationstechnologie-Konzern geführt. In der Organisation des Konzerns wird dies sehr gut deutlich (vgl. Abb. 2). Es gibt zentrale Einheiten für Business Development und Human Ressources für die gesamte Gruppe. Tabelle 1. Kurzporträt der Swisscom Mobile AG (o. V. 2006)
Firmensitz Branche Homepage
Swisscom Mobile AG 1998: Gründung der Swisscom AG und Börsengang 2000: > 3 Mio Mobilfunkkunden und Ersteigerung einer UMTS-Lizenz 2002: Einstieg in den Public Wireless LAN-Markt 2004: Präsentation der ersten UMTS Geräte für den Schweizer Markt 2005: Erste Pilotprojekte zum Thema Mobile TV basierend auf dem DVB-H Standard Bern (CH) Telekommunikation http://www.swisscom.ch
Umsatz Ergebnis Marktanteile Mitarbeiter Kunden
4,02 Mio CHF (2006) 1,41 Mio CHF (2006) 63,4% (2006) 2550 (2007) >5 Mio Subscriber (2007)
Historie
Die Informationslogistik bei der Swisscom Mobile
317
3.2 Herausforderung und Wettbewerb Die Swisscom Mobile steht vor erheblichen Herausforderungen. Wie schon im vorangegangenen Abschnitt dargestellt, entwickelt sich der Mobilfunkmarkt sehr dynamisch, weshalb die Unternehmen flexibel auf aktuelle Herausforderungen reagieren müssen. Durch das Marktumfeld besteht nach wie vor ein erheblicher Druck auf die Swisscom Mobile. Der gesättigte Markt mit mehr Mobilfunkanschlüssen als Kunden ermöglicht Wachstum der Kundenzahlen nur noch auf Kosten der Wettbewerber, die ihrerseits den Druck auf die Swisscom Mobile erhöhen. Zudem geraten die Margen durch EU-Regulierungen unter Druck, die die Preise für das Roaming in ausländische Netze beschränken. Schließlich entsteht Druck durch die Gerätehersteller, die in Konkurrenz zu den Mobilfunkanbietern selber Content-Angebote im Markt zu positionieren versuchen. Der strategische Fokus besteht darin, im zunehmend gesättigten Markt neue Umsatzpotenziale zu erschließen. Dabei werden insbesondere technisch komplexe Produkte oder Lösungen für spezielle Segmente angeboten. Im Privatkundensegment sind insbesondere Media-Dienste im Fokus der Wachstumsstrategie. So sollen internetprotokoll-basiertes TV sowie mobiles TV weiter ausgebaut werden. Die Muttergesellschaft Swisscom (Schweiz) AG setzt hier besonders auf integrierte Angebote in Zusammenarbeit mit verschiedenen Konzerngesellschaften. Zur Bewältigung dieser komplexen Herausforderungen hat sich die Swisscom entschieden, ihre Divisionsstruktur teilweise aufzulösen und den Mobil- und Festnetzbereich zu fusionieren. Dadurch entsteht eine neue Swisscom, die stärker nach Kundensegmenten aufgestellt ist (o. V. 2007b).
4
Strategische Ausrichtung der Informationslogistik bei der Swisscom Mobile
Zum besseren Verständnis der aktuellen Herausforderungen der Informationslogistik bei der Swisscom Mobile soll zunächst kurz die Entwicklung beschrieben werden. Gemeinsam mit den Herausforderungen des Marktes, die in den vorangegangenen Kapiteln beschrieben wurden, entsteht so ein präzises Bild der konkreten Herausforderungen des DWH bei der Swisscom Mobile.
318
Maximilian Ahrens, Markus Huber, Peter Kühni
4.1 Entwicklung der Informationslogistik Ein zentrales DWH wurde bei der Swisscom Mobile zunächst ab 1997 für die Bedürfnisse des Marketings entwickelt. Dieses DWH wurde 2002 in einem umfangreichen Entwicklungsschritt um Daten zu Finanzen und Controlling erweitert. Zunächst wurden Topline-Kennzahlen definiert, die von der Finanzabteilung definiert wurden. Für diese Zahlen hatte die Finanzabteilung die Datenhoheit inne und konnte sie somit in einem System zusammenführen. Dieses System war somit das erste zentrale DWH bei der Swisscom Mobile. Das System war allerdings nur aus logischer Sicht eine Einheit, physisch gab es mehrere verknüpfte heterogene Komponenten, welche Änderungen und Erweiterungen und gesamtheitliche Auswertungen zeit- und kostenintensiv machten (vgl. Abschn. 4.2). Nach der Etablierung dieses Systems wurde 2006–2007 ein konsistentes und ganzheitliches System eingeführt (vgl. Abschn. 7). Nach wie vor verantwortet jedoch die Finanzabteilung die Business-Steuerung des Systems. Der hauptsächliche Grund für diese Aufstellung liegt in der Annahme, dass in der Finanzabteilung keine Partikularinteressen vorhanden sind, sondern das gesamte Unternehmen ganzheitlich betrachtet wird. Als Sponsor des DWH tritt innerhalb der Swisscom Mobile die Geschäftsführung auf, Sponsor und System Owner ist der CFO. 4.2 Ziele und Leidensdruck der Informationslogistik Die Marktsituation der Swisscom Mobile zeigte deutlich die Notwendigkeit, mit der Informationslogistik auf sich dynamisch ändernde Herausforderungen zu reagieren, um die strategischen Ziele des Unternehmens optimal zu unterstützen. Es wurde offensichtlich, dass die bestehende, komplexe Informationslogistik-Infrastruktur nicht geeignet war, die sich daraus ergebenden Anforderungen insbesondere an die Flexibilität der Systeme zu erfüllen. Dies zeigte sich in einer Reihe von fachlichen und technischen Problemen: In der frühen Phase des DWH gab es bedingt durch die unterschiedlichen Systeme keine konsistenten Finanzkennzahlen, was zu inkonsistenten Analyseergebnissen führte. Insbesondere der Bedarf der Geschäftsführung nach konsistenten und verlässlichen Zahlen führte zu der Zentralisierung des DWH. Zusätzlich war die Senkung der Betriebskosten ein vordringliches Ziel. Ausgehend von diesem anfänglichen Beweggrund stiegen die Ansprüche an die quantitative Unterstützung durch die Informationslogistik. Insbesondere die Unterstützung bei der Entwicklung und Durchfüh-
Die Informationslogistik bei der Swisscom Mobile
319
rung von erfolgreichen Marketingkampagnen ist ein neu hinzugekommenes Ziel. Um dies zu gewährleisten, brauchen Produktmanager hoch spezialisierte Informationen, die durch das DWH individuell bereitgestellt werden müssen. Weiterhin sind die Ansprüche durch die zunehmende Produktvielfalt komplexer geworden. Neue und durch Content getriebene Dienste verlangen sehr viel komplexere Analysen, um eine kundenorientierte Ausrichtung des Produktportfolios zu ermöglichen. Ein dritter entscheidender Punkt, welcher auch zu der Einführung des ganzheitlichen Enterprise Data Warehouses im Jahr 2006 führte, war der erhöhte Anspruch an die Datenqualität. Nachdem zunächst nur die wichtigsten Top-Kennzahlen fundiert erhoben wurden, sollte der gleiche Qualitätsanspruch auch für die unterliegenden Zahlen gelten. Die bestehende Situation, in der oft vermeintlich gleiche Zahlen aus unterschiedlichen Systemen von einander abwichen, sollte verbessert werden. Dies war nur möglich durch die Einführung eines erweiterten, ganzheitlichen Systems. Neben diesen fachlichen Anforderungen an eine neue DWH Struktur, gab es auch Treiber aus der Technik, die zur Umsetzung des „New Mosaic (NeMo)“-Projektes führten. Ein wesentliches Problem im Zusammenhang mit der bestehenden Architektur der DWH-Plattform vor der Neugestaltung war die hohe Anzahl untereinander abhängiger Schichten. Zwei mit einander verzahnte Systeme zur Verwaltung von Transaktionsdaten und Stammdaten führten zu einer Architektur mit insgesamt fünf Datenhaltungsschichten mit großen Abhängigkeiten untereinander. Dadurch entstanden hohe Latenzzeiten zwischen dem Entstehen der Transaktionsdaten und der Verfügbarkeit der Daten in den Berichten, teils waren nur wöchentliche Ladezyklen möglich. Zudem entstanden erhebliche Probleme, falls Stammdaten nicht zeitgleich mit den Transaktionsdaten verfügbar waren. Das Datenmodell des Altsystems war gemäß einem Sternschema aufgebaut, was die Flexibilität bei sich ändernden Anforderungen einschränkte. Änderungsanforderungen im Reportsystem führten häufig zu komplexen Änderungen in allen darunter befindlichen Systemen, was den Aufwand für Änderungsprojekte erheblich steigen ließ. Schließlich fand während der Initialisierung des Projekts eine umfangreiche Neugestaltung der operativen Liefersysteme des DWH statt. Die daher erforderliche Neugestaltung der ETL-Schicht ließ eine komplette Erneuerung des DWH sinnvoll erscheinen. Die drei hauptsächlichen Anforderungen an die neue Architektur waren daher, die Latenzzeiten zu reduzieren, die Flexibilität zu erhöhen und die Betriebskosten zu senken. Für die Latenzzeiten wurde die Anforderung definiert, alle Daten vortagsaktuell bereit zu halten und in einigen Bereichen für einen noch kürzeren Ladezyklus strukturell bereit zu sein. Zur Steige-
320
Maximilian Ahrens, Markus Huber, Peter Kühni
rung der Flexibilität wurden zwei Architekturprinzipien gebildet: die Reduzierung auf so wenige physische Schichten wie möglich und die Reduzierung von eigenentwickeltem Code, etwa für Aggregationen und Transformationen auf ein Minimum zur Reduktion der Komplexität, insbesondere bei Änderungen. Diese Anforderungen machten eine komplett neue Architektur erforderlich, die auch von einer organisatorischen Neuausrichtung der Informationslogistik begleitet wurde.
5
Organisation der Informationslogistik
Im Rahmen der neuen Ausrichtung des DWH der Swisscom Mobile wurde auch die Organisation der Informationslogistik neu aufgestellt. In diesem Abschnitt sollen die Zuständigkeiten und Rollen der beteiligten Stakeholder dargestellt werden. Abbildung 3 gibt einen Überblick über die Stakeholder im Umfeld des DWH bei der Swisscom Mobile.
Steering Board
Kontrolle der
Kontrolle des
technischen Umsetzung
DWHAuf trages
Informationskonsumenten
Def inition von Analysen
FrontendTeam
Def inition technischer Bedingungen
BackendTeam
Abb. 3. Stakeholder-Überblick
5.1 Frontend-Team Das Frontend-Team hat die Kernverantwortung für die Prozesse des DWH. Die wesentlichen Aufgaben des Frontend-Teams lassen sich in drei Gruppen unterteilen: die Standard-Reportings, die Kampagnen-Analysen und die strategische Entwicklung der nutzerseitigen Aspekte der Informa-
Die Informationslogistik bei der Swisscom Mobile
321
tionslogistik. Wie in Abb. 3 ersichtlich, liegt der Fokus der Verantwortung des Frontend-Teams dabei auf den fachlichen Aspekten der Informationslogistik. Im Rahmen dieser Tätigkeit werden enge Beziehungen zu den Verantwortlichen der Technik und den Produktverantwortlichen gepflegt. 5.2 Informations-Konsumenten Informations-Konsumenten (z.B. das Produktmanagement oder das Controlling) sind z. B. für die Entwicklung neuer Produkte und Kampagnen auf die Daten und Analysen aus dem DWH angewiesen. Die jeweiligen Fachspezialisten sind verantwortlich für die Definition der Analysen, die dann durch das Frontend-Team implementiert werden. 5.3 Steering Board Das Steering Board ist das Kontrollgremium der DWH Aktivitäten. Es bewilligt die strategischen Planungen des Frontend-Teams und achtet auf die Einhaltung des Geschäftsauftrages aller beteiligten Stakeholder. Die Mitglieder des Steering Boards sind zugleich Mitglieder der Geschäftsleitung der Swisscom Mobile. 5.4 Backend-Team Das Backend-Team ist verantwortlich für Entwicklung und Betrieb der DWH Backend-Komponenten. Dieses Team verantwortet die technische Bereitstellung der Daten. Die Hauptschwerpunkte des Backend-Teams sind die Steuerung des BI-Projektgeschäfts (Projektleitung, Definition und Weiterentwicklung der DWH Architektur in Abstimmung mit dem Frontend-Team und den Enterprise Architekten, Lieferantenmanagement) und die Koordination der Betriebstätigkeiten. Eine Abbildung der Verantwortlichkeiten auf die (vereinfachte) technische Architektur des DWH ist in Abb. 4 dargestellt. Das Backend-Team verantwortet die datenhaltenden Systeme inklusive des zentralen DWHs. Das Frontend-Team verantwortet die Analysesysteme, während das Produktmanagement lediglich Konsument der Reports ist.
Maximilian Ahrens, Markus Huber, Peter Kühni
Reports, interaktive Tools, Cubes
Microstrategy
Reports
RS / AS
…
NeMo
BackendTeam
FrontendTeam
Informationskonsumenten
322
ERP
Billing
…
Abb. 4. Verantwortlichkeiten der DWH-Organisation
5.5 Prozesse der Informationslogistik Wie bereits beschrieben, existieren drei Kernprozesse im Bereich des Frontend-Teams: Standard-Reports, Kampagnen-Reports und Entwicklungsprozesse. Für sämtliche Standard-Reports hat das Frontend-Team die Verantwortung für die Definition der Daten und die Korrektheit der Analysen. Das Backend-Team hat die Aufgabe, die Daten gemäß den Anforderungen des Frontend-Teams zu Verfügung zu stellen und die Datenqualität sicherzustellen. Diese Aufteilung ist durch einen klaren Managementauftrag gesteuert. Das Top-Management akzeptiert nur solche Reports, die durch das Frontend-Team erstellt wurden und deren Daten aus dem DWH stammen. Die Kampagnen-Prozesse werden wesentlich flexibler erstellt. Normalerweise definieren die Produkteinheiten das Analyseziel und das Frontend-Team stellt im Sinne einer Dienstleistung die entsprechenden Analy-
Die Informationslogistik bei der Swisscom Mobile
323
sen zusammen. Historisch bedingt gibt es teilweise auch noch sogenannte Power User mit erweiterten Zugriffsrechten, welche selbstständig Analysen anfertigen. Dies ist jedoch in Zukunft nicht mehr angestrebt, da die zunehmende Komplexität der vorhandenen Daten hohe Fehlerwahrscheinlichkeiten solcher Analysen mit sich bringt. Die Entwicklungsprozesse zielen darauf ab, eine konsistente Roadmap für das Thema Informationslogistik zu entwickeln. Diese Roadmap wird im Konsens aller Stakeholder entwickelt. Der übliche Planungshorizont beträgt etwa 3 Jahre, wobei Projekte teilweise im Laufe dieser drei Jahre anders priorisiert werden. Die Roadmap wird durch das Steering Board des DWH überwacht. Die in der Roadmap aufgeführten Einzelprojekte werden jeweils auch durch das Steering Board genehmigt.
6
Einführung des neuen DWH
In diesem Abschnitt wird das Transformationsprojekt und das dabei entwickelte System NeMO detailliert vorgestellt. Dabei werden auch einzelne technische Herausforderungen die zu bestimmten Architekturprinzipien führten detaillierter ausgeführt. 6.1 Projektverlauf Das Projekt NeMo verlief in vier Phasen von den ersten Ideen bis zur Abschaltung der Altsysteme in einem Zeitraum von circa 3 Jahren. Da NeMo als Greenfield-Ansatz unabhängig von den bestehenden Altsystemen umgesetzt wurde, war insbesondere eine umfangreiche Planungs- und Evaluierungsphase notwendig, wie in Abb. 5 deutlich wird. 2004 Initiale Kostenschätzung
09/2005
Pilotierung
03/2006 Machbarkeit und Scoping
08/2006 Implementierung
05/2007 Test und Produktivsetzung
Abb. 5. Projektphasen NeMo Projekt
Nach einer initialen Kostenschätzung im Jahr 2004 wurde nach einer Phase der Diskussion die Grundsatzentscheidung gefällt, das Projekt intensiver zu betrachten. Darauf wurde im September 2005 zunächst eine Pilotimplementierung durchgeführt. Nach dem erfolgreichen Abschluss dieser Implementierung wurden von März bis August 2006 detaillierte Machbar-
324
Maximilian Ahrens, Markus Huber, Peter Kühni
keitsstudien durchgeführt. Dabei wurden alle potenziell zu erschließenden Datenquellen individuell mit Kostenfaktoren bewertet und teilweise aus dem Projektsope ausgeschlossen. Die komplette Implementierung wurde in der letzten Phase vom August 2006 bis zum Mai 2007 durchgeführt. Nach einer anschließenden Test- und Überführungsphase wurden im September 2007 die Altsysteme komplett abgeschaltet. Sämtliche operative Tätigkeiten des Projektes wurden durch einen externen Generalunternehmer und weitere Partner durchgeführt, während innerhalb der Swisscom Mobile ein Projektsteuerungsteam installiert war. Bei der Auswahl der beteiligten Unternehmen wurde insbesondere Wert darauf gelegt, dass die Unternehmen auch in den folgenden Phasen des Lebenszyklus das Technikteam der Swisscom unterstützen können und dass bestehende Erfahrungen mit den DWH-Systemen in das Projekt einfließen können. 6.2 Systemarchitektur Die in Abschn. 4.2 aufgeführten Anforderungen führten zur Auswahl einer zentralisierten Systemarchitektur. Sämtliche Daten werden in einem zentralen Enterprise Data Warehouse gespeichert, das über eine zentrale Staging Area mit Daten beliefert wird (vgl. Abb. 6). Es wurde versucht möglichst, in der neuen Architektur möglichst wenige Data Marts zu benötigen. Lediglich für einige komplexe Analysen aus dem Finanzbereich wurde ein individueller Datamart erstellt, der multidimensionale OLAP-Analysen ermöglicht. Das Ziel der Vereinfachung konnte erreicht werden, statt bisher fünf Schichten bestehen im neuen System nur noch zwei Datenschichten.
Die Informationslogistik bei der Swisscom Mobile
325
Reports Reports
Reporting Portal
Meta data
EDW derived data
EDW aggregation
Data Mining
EDW data mart
Enterprise Data Warehouse EDW base data
volatile
Staging Area
permanent
Source systems
Abb. 6. Systemarchitektur des Enterprise Data Warehouse
In der neuen Systemarchitektur wurden mehrere bestehende Systeme konsolidiert. Aus der alten Systemwelt wurden neben den Teilsystemen des DWH insbesondere das umfangreiche Kernsystem für das Teilnehmerreporting und das Backend des Contolling-Systems in das NeMo-System integriert. Da das Teilnehmerreporting innerhalb der Swisscom Mobile eine hohe strategische Bedeutung hat, existierten für die Integration dieses Systems sehr hohe Anforderungen an Daten- und Systemqualität, die in der neuen Systemarchitektur erfüllt werden konnten. Das Datenmodell wurde in der dritten Normalform umgesetzt, um maximale Flexibilität für die Auswertungen zu erreichen. Zum Erreichen der nötigen Verarbeitungsgeschwindigkeit wurde eine massiv parallele Shared Nothing-Architektur gewählt (vgl. Kap. 1). Neben den Transaktionsdaten führt NeMO ein eigenes MetadatenRepository. Hier werden insbesondere Log-Daten über die durchgeführten
326
Maximilian Ahrens, Markus Huber, Peter Kühni
Ladeprozesse und Datenqualitätsindikatoren geführt. Fachliche Metadaten werden außerhalb des Systems in eigenen Datenbanken geführt. 6.3 Daten im Enterprise Data Warehouse Die Swisscom Mobile verfolgt einen ganzheitlichen Ansatz der Informationslogistik. Dies wurde erreicht, indem eine konsistente Kennzahlenpyramide erstellt wurde, wobei die Zahlen auf allen Ebenen durch Werte aus dem zentralen DWH-System hinterlegt sind. Dies ermöglicht eine sehr hohe Datenqualität, führt jedoch auch zu einem gewissen Verlust an Flexibilität des Systems, da die Einführung neuer Datendefinitionen Einfluss auf das gesamte Kennzahlensystem hat. Aus diesem Grund ist die klare Datenhoheit in der Hand des BI-Teams von herausragender Bedeutung. Abbildung 7 zeigt die Entwicklung den Aufbau der Datenstrukturen in der Swisscom Mobile. In der ersten Phase des DWH wurden lediglich die Top-Kennzahlen erhoben und dann wie oben beschrieben weiter nach unten bis auf die Basisdaten ausgedehnt. Heute werden umfangreiche Detaildaten im DWH gehalten, täglich werden mehrere Millionen Datensätze geladen. Die Basisdaten werden im neuen System nicht nur als Basis für Aggregationen genutzt, zusätzlich basieren auch die meisten Analysen direktem Zugriff auf die Basisdaten.
TopKennzahlen Aggregierte Kennzahlen
Basisdaten Abb. 7. Aufbau der Daten des Swisscom DWH
Die Informationslogistik bei der Swisscom Mobile
7
327
Analyse des DWH der Swisscom Mobile
7.1 Systemarchitektur Bei der Umsetzung des Enterprise Data Warehouse wählte die Swisscom Mobile eine zentrale DWH-Architektur, die weitgehend ohne Data Marts auskommt. Die zentralisierte Architektur bietet gegenüber anderen Architekturen einige Vorteile (vgl. Kap. 7), die auch im vorliegenden Projekt zu Tage treten. Die Datenqualität kann im Vergleich zu anderen Lösungen mit geringem Aufwand sichergestellt werden, da zentral gewartete Stammdaten auf demselben Aktualitätsstand für alle Daten vorliegen. Durch die integrierte Architektur können Transformations- und Verarbeitungsschritte vermieden werden, was die Aktualität steigert. Schließlich steigert die Verfügbarkeit von technischen Metadaten die Transparenz der Verarbeitungsprozesse. Durch die zentrale Verfügbarkeit aller Daten ist die Integration von Informationen über verschiedenen Prozessschritte und Funktionsbereiche im Unternehmen einfacher möglich als bei separaten, themenbezogenen Teilsystemen. Dies steigert die Flexibilität bei der Umsetzung von Auswertungen. Schließlich ermöglicht die parallele Systemarchitektur hohe, skalierbare Systemleistung bei hoher Verfügbarkeit, da bei Ausfall einzelner Systemteile die Last auf redundante Systemkomponenten verteilt werden kann, die zudem zur Skalierung des Systems einfach ergänzt werden können (vgl. Kap. 1). 7.2 Organisation Die Struktur des DWH der Swisscom Mobile weist einige interessante Eigenschaften auf, die einer detaillierteren Einordnung bedürfen. Basierend auf der Analyse in Kap. 5 lassen sich vier unterschiedliche Formen der Organisation der Informationslogistik identifizieren: Business Service Provider, DWH Competence Center, Full Service Provider, DWH Platform Provider (vgl. Abb. 8).
328
Maximilian Ahrens, Markus Huber, Peter Kühni
Geschäftsnähe
Business Service Provider
Full Service Provider
Nutzung
60%
Nutzung
50%
DWH-IS
40%
DWH-IS
60%
Technik
20%
Technik
70%
n=10
n=14
DWH Competence Center
DWH Platform Provider
Nutzung
30%
Nutzung
30%
DWH-IS
40%
DWH-IS
50%
Technik
30%
Technik
n=29
60% n=15
Fertigungstiefe DWH-Informationssystem
Abb. 8. Leistungserbringertypen (aggregierte Tätigkeitsanteile, vgl. Kap 5)
Die Informationslogistik-Organisation bei der Swisscom Mobile ist in diesem Klassifizierungsschema als Business Service Provider einzustufen. Diese Art der Organisationseinheit erbringt eine hohe Fertigungstiefe im fachlichen Bereich bei geringer Fertigungstiefe im technischen Bereich während der Betriebsphase. Auch in der Aufbauphase war die Fertigungstiefe im fachlichen Bereich sehr hoch, hier wurden zusätzlich wesentliche fachliche Aufgaben im Rahmen der Projektumsetzung vom Backend-Team übernommen. Dies wird insbesondere deutlich, wenn man die Prozesshoheit des Frontend-Teams über sämtliche Prozesse betrachtet. Auch die klare Trennung zwischen technischer und inhaltlicher Verantwortlichkeit ist ein Charakteristikum einer als Business Service Provider aufgestellten Informationslogistik-Organisation. Jedoch weist der Aufbau des Enterprise DWH einige Besonderheiten auf, wobei zwischen technischen und organisatorischen Aspekten zu trennen ist. Organisatorisch ist eine extrem starke Position des FrontendTeams erkennbar. Die Geschäftsleitung hat für sämtliche Fragestellungen der Informationslogistik die ausschließliche Verantwortung an das Frontend-Team delegiert. Die drückt sich zum Beispiel dadurch aus, dass sämtliche quantitativen Berichte an die Geschäftsleitung durch Daten des Frontend-Teams gestützt werden müssen und nicht durch Datenerhebungen in einzelnen Geschäftsbereichen. Weiterhin ist das Steering Board direkt durch Mitglieder der Geschäftsleitung besetzt, was die strategische Bedeutung des Themas aus der Sicht der Geschäftsleitung der Swisscom Mobile unterstreicht.
Die Informationslogistik bei der Swisscom Mobile
329
Diese Besonderheiten der Organisation der Informationslogistik haben Vor- und Nachteile, die im Folgenden kurz analysiert werden sollen.
8
Konsequenzen und Ausblick
8.1 Projektergebnisse Das NeMo-Projekt hat die gesteckten Ziel voll erreicht. Sämtliche Daten können vortagsaktuell dargestellt werden und die neue Architektur hat die Erstellung neuer Reports erheblich vereinfacht. Die so gewonnene Flexibilität steigert die Akzeptanz des Systems erheblich. Weiterhin wurde durch die Abschaffung vieler einzelner Data Marts eine wesentlich höhere Datenqualität und -konsistenz erreicht. Schließlich konnten die Betriebskosten um über 50% gesenkt werden. Als wesentliche Erfolgsfaktoren für das Umsetzungsprojekt wurden bei Swisscom Mobile insbesondere die Kommunikation der strategischen Bedeutung des NeMo-Projekts identifiziert. Auch die umfangreiche Planungsphase hat den Erfolg des Projektes wesentlich beeinflusst. 8.2 Organisatorische Aspekte Die Organisation der Informationslogistik in der Swisscom Mobile ist durch eine hohe Effizienz bei gleichzeitig hohen Qualitätsstandards gekennzeichnet. In diesem Abschnitt sollen die Erfolgsfaktoren sowie die Herausforderungen der speziellen Organisationsform der Informationslogistik bei der Swisscom Mobile kurz analysiert werden. Die kritischen Erfolgsfaktoren der Informationslogistik werden in der Swisscom Mobile durch regelmäßige Kundenbefragungen des FrontendTeams identifiziert. Neben der vom Management geforderten maximalen Datenqualität ist insbesondere schnelle und automatisierte Analyse von aktuellen Daten von Bedeutung. Gerade im dynamischen Telekommunikationsgeschäft ist die Häufigkeit und Reaktionsgeschwindigkeit der BI-Analysen ein entscheidender Vorteil, der die der Time to Market von neuen Produkten verkürzen kann. Ein weiterer Erfolgsfaktor ist die Effizienz des DWH. Obwohl in der Swisscom Mobile zurzeit keine interne Kostenverrechnung stattfindet, besteht ein hoher Kostendruck durch das Topmanagement. Aus dieser Perspektive wurde auch Anfangs 2007 die Outsourcing-Entscheidung für das DWH getroffen, welche zu erheblichen Kosteneinsparungen führte.
330
Maximilian Ahrens, Markus Huber, Peter Kühni
Die starke Position des BI-Teams führt zwangsweise zu besonderen Herausforderungen. Ein häufig auftretendes Phänomen bei starker Zentralisierung ist die Fokussierung auf interne Abläufe und ein Verlust der Marktorientierung, da keine Konkurrenz um die Kunden existiert. Diesem Phänomen begegnet man in der Swisscom Mobile durch eine enge Zusammenarbeit und regelmäßige Kundenbefragungen. Nichtsdestotrotz ist das Frontend-Team mit der ständigen Herausforderung konfrontiert, die Effizienzbemühungen nicht zu Ungunsten der Leistungsvielfalt einzuschränken. 8.3 Ausblick: Zukünftige Herausforderungen für die Swisscom Mobile Nach der erfolgreichen Erweiterung der Informationslogistik 2006-2007 steht die Swisscom Mobile bereits wieder vor großen Herausforderungen. Eine umfangreiche Reorganisation der gesamten Swisscom führt zu einer Reintegration der verschiedenen Geschäftssparten. Im Zuge dieser Reintegration spielt auch die Integration der Informationslogistik eine große Rolle. Aus diesem Grunde wurden zum Zeitpunkt der Erstellung der Fallstudie unterschiedliche Integrationsszenarien diskutiert. Neben dieser immensen Herausforderung soll das Portfolio an StandardAnalysen erweitert werden. Die Möglichkeit, einfach standardisierte Reports abzurufen, bietet den Produktmanagern einen großen Mehrwert. Die größte Herausforderung besteht dabei in dem Schaffen von verlässlichen Daten. Gerade aus dieser Sicht bleibt die Sicherstellung der hohen Datenqualität des DWH der Swisscom Mobile ein vordringliches Ziel.
Literatur Jost, M.: Der Markt für IT Services in der Schweiz, 2003 - 2008, IDC, Frankfurt 2004. o. V. : Jahresbericht der Swisscom, Swisscom AG, Bern 2006. o. V. : Der Schweizer Fernmeldemarkt im internationalen Vergleich, Bundesamt für Kommunikation - Abteilung Telecomdienste, Biel 2007a. o. V. : Swisscom in neuem Kleid, Medienmitteilung, Bern 2007b.
Autorenverzeichnis
Maximilian Ahrens Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected] Tobias Bucher Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], eiw.iwi.unisg.ch Dr. Barbara Dinter Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], eiw.iwi.unisg.ch Markus Huber Swisscom (Switzerland) Ltd Waldeggstrasse 51, CH-3097 Bern-Liebefeld
[email protected], www.swisscom.ch Kai Hüner Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], cdq.iwi.unisg.ch Dr. Mario Klesse Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], eiw.iwi.unisg.ch Robert Konzelmann Teradata (Schweiz) GmbH Postfach, CH-8301 Glattzentrum
[email protected], www.teradata.com
332
Autorenverzeichnis
Peter Kühni Swisscom (Switzerland) Ltd Waldeggstrasse 51, CH-3097 Bern-Liebefeld
[email protected], www.swisscom.ch Gerrit Lahrmann Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], eiw.iwi.unisg.ch Dr. Boris Otto Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], cdq.iwi.unisg.ch Moritz Schmaltz Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], eiw.iwi.unisg.ch Alexander Schmidt Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], cdq.iwi.unisg.ch Florian Stroh Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], eiw.iwi.unisg.ch Dr. Jochen Töpfer Teradata (Schweiz) GmbH Postfach, CH-8301 Glattzentrum
[email protected], www.teradata.com Tobias Vogel Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], cdq.iwi.unisg.ch
Autorenverzeichnis
Hans Wegener Zurich Financial Services Postfach, CH-8085 Zürich
[email protected], www.zurich.com Kristin Wende Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], cdq.iwi.unisg.ch Prof. Dr. Robert Winter Universität St. Gallen, Institut für Wirtschaftsinformatik Müller-Friedberg-Str. 8, CH-9000 St. Gallen
[email protected], www.iwi.unisg.ch
333
Sachverzeichnis
A Abrechnungsmodell 246 Active Data Warehouse 4, 9, 15, 145 Active Data Warehousing 234 Active Enterprise Intelligence 4, 15 Aggregation 167, 168 Agilität 35, 166, 226 Aktualität 19, 132, 251, 327 Alignment 4, 39, 55, 165, 166, 167 Analyselatenz 170 analytische Applikation 301 analytische Nutzung 45 Anforderung 293 Anforderungsanalyse 294 Anforderungserhebung 291 Anspruchsgruppe 34 Antwortzeit 251 Architektur 129, 278, 298 serviceorientierte 221 Architekturtyp 138 Attribut 215 Aufgabe 212 Aufgabenstrukturierung 32 Aufgabenverteilung 82 B Backend-Team 321 Balanced Scorecard 73 Basel II 169 Basisdaten 326 Bereinigungswerkzeug 216 Best Practice 276 Betrachtungseinheit 44, 45
Betriebswirtschaftslehre 31 BI-Strategie 65 Bonitäts-Score 165 Business Activity Monitoring 107, 236 Business Case 168 Business Engineering 30, 31, 33, 36, 41, 207 – Gegenstand des 36 – Modelle des 37 – Vision des 35 Business Engineering-Landkarte 33 Business Impact Assessment 173 Business Impact Model 286 Business Improvement Opportunity 285, 287 Business Intelligence 2, 21, 48 Business Performance Management 107 Business Service Provider 88, 328 BYNET 10 C Change Management 31, 173 Change the Business 33 Closed Loop 231 Clusteranalyse 84 Common Warehouse Metamodel 194 Competitive Potential Alignment 62 Compliance 169 Corporate Performance Management 236 Cross-Selling 165
336
Sachverzeichnis
D Data Dictionary 19 Data Governance 207, 212, 213 Data Governance Council 205 Data Governance-Komitee 213 Data Management Body of Knowledge 205 Data Mart 324, 327 – Busarchitektur 139 – unabhängige 139 Data Warehouse 3, 8, 47, 77, 78, 158, 274, 318 – Betrieb 81 – Entwicklung 80 – Nutzung 80 – Support 82 Data Warehouse Maturity Assessment 288 Data Warehouse Maturity Model 288 Data Warehousing 47, 77, 79, 243, 244 Data-Warehousing-Prozess 77 Daten 203 Datenarchitektur 207, 215, 216 Datenfluss 44, 45, 202, 216 Datenhaltungssystem 216 Datenintegration 2, 15, 179 Datenlatenz 170 Datenmanagement 204 Datenmanagementprozess 214 Datenmodell 17, 189, 325 logisches 296 physisches 301 Datenobjekt 215 Datenqualität 21, 130, 132, 168, 201, 202, 203, 319, 327 – Kosten von 209 – Messen von 210 – Nutzen der 210 – Verbesserung 216 – Ziele der 209 Datenqualitätsmanagement 204, 205, 214 – Nutzen des 209
– Systemunterstützung 216 Datenqualitätsproblem 210 Datenqualitätssicherung 79 Datenqualitätsstrategie 207, 208 Datenqualitätsziel 210 Datenquelle 79, 185 Datensteward 213 Decision Support Systems 49 Delivery-Strategie 68 detaildatenbasierte Massenkalkulationen 165 Dimensionsdaten 168 Distributionsform 250 DWH Competence Center 91, 243 DWH Platform Provider 90 DWH-Applikationen 79 DWH-CC 92, 244 DWH-FSP 86 DWH-Informationssystem 79 DWH-Integrationsinfrastruktur 79 DWH-Leistungserbringer 82 DWH-Leistungserbringertypen 86 DWH-Organisation 77 DWH-PP 90 E EAI 146 Effektivität 34 Effizienz 34 Einzelhandel 210 empirische Untersuchung 82, 110 Enterprise Data Warehouse 324 Enterprise Data WarehouseRoadmap 287 Enterprise Event Management 24 Entkopplung 37 Entkopplungsmechanismus 37 Entscheidung 165 Entscheidungslatenz 170 Entscheidungsprozess 165 Entscheidungsunterstützung 1, 9, 44, 45 Entwicklung 275 Entwicklungsmodus 30 Entwicklungsstrategie 69
Sachverzeichnis Ereignis 24 Erfahrungsdatenbank 110 Erfolgsfaktor 162 Erneuerung 30 eventgesteuerte Aktivität 164 Executive Information Systems 49 Extraction, Transform, Cleanse Load 298, 302
– Lebenszyklus des 36, 37
F
I
Fachabteilung 82 Fachbegriff 189 fachliches Verständnis 184 Fertigungstiefe 85, 95 Finanzierung 136 Flexibilität 35, 135, 226, 251, 318 Föderierte Architektur 142 Formalziel-Dimension 35 Frontend-Team 320, 328 Führungsgröße 210 Führungsinformationssysteme 49 Führungssystem 207, 210 Full Service Provider 86 Funktion 244, 249 Funktionalität 250 G Ganzheitlichkeit 31 Gegenstand 249 Gemeinkostenproblematik 244 Geschäftsbegriff 193 Geschäftsbereich 44 Geschäftseinheit 31 Geschäftsmodell 2, 5 Geschäftsnähe 85, 95 Geschäftsnutzen 285 Geschäftspotenzial 8 Geschäftsprozess 5, 159, 214 Geschäftsregel 189 Geschwindigkeit 169 Gestaltung 31 Gestaltungselement 206 Gestaltungsfaktor 113 Gestaltungsmethode 36 Gestaltungsobjekt 36, 37
337
H Homonym 216 Horizontale Informationsintegration 137 Hub and Spoke-Architektur 141
IL-Infrastruktur 158 IL-Leitbild 73 IL-Masterplan 74 IL-Projekte 158 IL-Strategie 63 Implementierung 300 Information 45, 79, 203, 244, 247, 249 Informationsbedarf 157, 175, 285, 291 Informationsbedarfsanalyse 281 Informationslandkarte 281 Informationslogistik 41, 44, 54, 59, 77, 78, 101, 102, 103, 107, 157, 243, 317 – Abgrenzung 47 – Aufgaben der 47 – Betrachtungseinheiten der 44 – Nutzen der 158, 160 – prozessorientierte 102, 107, 108, 110, 112, 116, 120, 235 – Synergiepotenziale der 50 – Wertbeiträge der 163 – Ziele der 47, 318 Informationslogistik-Infrastruktur 109 Informationslogistik-Projekte 158 – Bewertung von 160 – Eigenschaften von 158 Informationslogistik-Strategie 59 Informationsmanagement – integriertes 65 Informationsobjekte 248 Informationsprodukt 244, 248 Informationsproduktion 247, 248, 252
338
Sachverzeichnis
Informationsproduktionsmodell 255 Informationsproduktionsprozess 253 Informationsproduktmodell 248 Informationsqualität 130 Informationsversorgung 102, 117, 121, 281 Infrastruktur 51, 54, 171, 244 Infrastrukturcharakter 51, 159 Infrastrukturkosten 171 In-Memory Analytics 147 Innovation 30 Integrationsebene 37 Integrationsgrad 117 Integrationsinfrastruktur 243 Integrationsschicht 223 Internes Leistungsmodell 246 Investitionsschutz 15 Ist-Analyse 260 Ist-Situation 282 IT / Business Alignment 62 IT-Innovation 33 IT-Strategie 60 K Kalkulation 266 Kausalanalyse 110 Kennzahl 318 Kennzahlen 174, 175, 211 Kennzahlensystem 326 Komplexität 159 Konsistenz 35, 37, 133 Konstruktionslehre 31, 38 Kontext 36 Konzerndatenqualität 204 Kosten 158, 243 Kostenund Leistungsrechnungssystem 247 Kosteneffekt 168 Kosteneinsparungen 171 Kostenersparnis 161 Kostenschätzung 175 Kostensenkung 159, 161, 168 Kundenbeziehung 164
Kunden-Lieferanten-Beziehungen 87 Kundenmanagement 202 Kundenorientierung 163 Kundenschnittstelle 261 L Latenzzeit 169 Leistung 244 Leistungs- und Kostenmodell 264 Leistungserbringer 85 – Typen 85 Leistungserbringertyp 95 Leistungsverrechnung 244, 245, 246, 247 – Elemente der 246 – Ziele der 245 Lieferfähigkeit 171 M Management Information Systems 49 Management Support Systems 49, 50 Marktöffnung 315 Marktsegmentierung 165 Massively Parallel Processing 10 Merkmals-Modellierung 190 Metadaten 19, 189, 325 Meta-Programmierung 190 Methode 38, 244, 257, 275 Methodenbasierung 31 Mobilfunkmarkt 314 Modell 38, 180, 185 Modellbasierung 31 Modellevolution 180 Modellintegration 180 N Nutzen – Bewertung von 158, 173 Nutzenbetrachtung 158 Nutzeneffekt 110, 112 Nutzenkategorie 161
Sachverzeichnis Nutzenpotenzial 159, 172 – Bewertung von 174 – Prognose von 175 O Operational Business Intelligence 108 Operational Data Store 11 Operational Intelligence 4, 7 Optimierung 30 Ordnungsrahmen 205, 206 Organisation 29, 34, 320, 329 Organisationsebene 33 Organisationseinheit 44 Organisationsform 93, 95 – Auswahl der 95 organisatorische Einbettung 172 Outsourcing-Partner 95 P Parametrisierung 190 Partikularsicht 55 Performance 10 Performanz 134 Personal 136 Personalkosten 171 Pervasive Business Intelligence 15, 21 Planung 266 Planungssystem 60 Plattform 171 Plattformleistungen 255 Politisch-kulturelle Ebene 33 Portfoliostrategie 95 Portfolio-Strategie 69 Preis 244 Preismodell 246 Privatisierung 315 Produkt 244, 246, 247 Produktionsprozess 244 Produktionsstrategie 70 Projektcontrolling 174 Projektkennzahl 175 Projekttyp 36
339
Prozess 29, 33, 79, 102, 104, 105, 121, 244, 248 Prozesscharakter 51, 53 Prozesslandschaft 121 Prozessleistungen 255 Prozessmanagement 101, 105 Prozessoptimierung 161, 162 Prozessorganisation 101, 103 Prozessorientierung 102, 103, 107 Q Qualität 249 Quellsystem 290, 297 R Real Time Data Warehousing 234 Realisierungsform 116, 119 Real-Time Warehousing 146 Referenzdaten 190 Referenzmodell 18 Reifegradmodell 5 Ressourcen 136 Richtigkeit 250 Risikofaktor 54 Risikomanagement 169 Rolle 82, 212 S Sachziel 35 Sarbanes-Oxley-Act 169 Service 223, 243 Analytischer 230 Applikations- 223 Enterprise 223 Extraktions- 228 fachlicher 224 Frontend 230 Infrastruktur- 231 Prozess- 225 Software- 224 Sourcing 228 Transformations- 229 Service Level Agreement 15 Service Level Alignment 62
340
Sachverzeichnis
Serviceorientierung 2, 222 Shared Nothing-Architektur 10, 14 Shared Resource-Architektur 10 Sicherheit 136 Situationsanalyse 72 Skalierbarkeit 13 Solvency II 169 Sourcing-Strategie 67, 95 Speicherung 250 Sponsor 212 St. Galler Anwenderforum 83 St. Galler Managementmodell 29, 32 Staging Area 324 Stammdaten 191, 214 – Sicht 216 Stammdatenmanagement 217 Standardisierung 30 Steering Board 321, 328 Stelle 44 Strategic Alignment Model 61 Strategic Intelligence 4, 7 Strategie 60, 282 Strategieebene 32 Strategieentwicklung 74 Strategieentwicklungsprozess 71 Strategische Bedeutung 136 strategische Planung 60 Strategische Zielplanung 72 Strategischer Charakter 51, 53 strategischer Wettbewerbsvorteil 161, 162 Strategy Execution Alignment 62 Strategy Map 73 Struktur 249 strukturelles Beschreibungsmerkmal 184 Supportprozess 248 Swisscom Mobile AG 313, 315 Synonym 216 System 79, 277 Systemarchitektur 130, 159, 216, 324, 325, 327 Systemebene 33 Systemqualität 130, 134 Systems Engineering 31
T Technologiebeobachtung 31 Technology Transformation Alignment 62 Teradata 173 Teradata Solution Methodology 275, 279 Phasen 277 Test 305 Total Data Quality Management 204 Total Information Quality Management 205 Total Quality data Management 205 Transparenz 35, 39, 134, 327 U Umlageverfahren 247 Unternehmen 157 Unternehmensmodell 5, 22 Unternehmenssteuerung 202 Unternehmensstrategie 208 Unternehmung 29, 31 V Veränderung 30, 31, 34 – Aufgaben der 31, 32 – Ergebnis der 34 – Gegenstand der 36 – Ziel der 34, 35 Veränderungsmethode 36 Veränderungsprojekt 32 Veränderungsprozess 34, 38 – Typen des 38 Veränderungsvorhaben 31, 32, 35 Verantwortlichkeit 212 Verantwortlichkeitsdiagramm 213, 214 Vereinfachung 35 Verfügbarkeit 12, 135 Vernetzungsfähigkeit 30 Vertikale Informationsintegration 137 Verwendungsform 138
Sachverzeichnis Virtuelle Architektur 144 Vision 72 V-Modell 306 Vollständigkeit 133, 250 Vorgabe 258 Vorgehensmodell 119, 257 W Wertebereich 216 Wertschöpfung 51 Wertschöpfungsnetzwerk 30 Wiederverwendung 187
341
Wirtschaftlichkeitsbetrachtung 158 Wirtschaftlichkeitsziel 34 Workload 12 Z Zentralisierte Architektur 141 Zielwert 210 Zielwerte 175 Zugänglichkeit 251 Zuständigkeit 212 Zuständigkeitstyp 213 Zuverlässigkeit 251
